Forum posts to 'Archive'

Re: Page security

Markus — Thu, 16 Aug 2007 22:07:22 +1200

> The option to inherit page permissions is evaluated each time that the page is
> accessed, not just when it is created.

> When set to 'inherit', the page should instead evaluate the permissions of the current user
> against the settings of the parent page. You can always change this setting for child pages.

OK, this is an option.. but then we need to extend the interface so that we can set a permission also to inherit. So we have tree states: Enable, disable, inherit.

If we implement that behavior, we need to extend the Permission system because at the moment there is no way to deny a permission. I will add a field "type" to the Permission class which can have three values: -1 (deny), 0 (inherit), 1 (allow).
"Inherit" is not really needed, but I think it's a good thing to support it explicitly.

What about the other question?

My next question is about how the permissions should work. Iâ€™ll create the permission â€œEdit pageâ€ and in the security tab you can then assign this right to the various groups. So what happens now on the access tab of a specific page? Letâ€™s assume group A has the â€œEdit pageâ€ permission and group B not.

Is A now allowed to edit all pages or just pages where I defined the Edit page permission with that specific page ID? Should it be possible to grant B the right to one specific page without the â€œglobal edit pageâ€ permission?

GSoC finishes on Monday (pencils down) so please tell me exactly on what you are working and on what I should work next. Currently I'm extending the Permission system to allow "deny permissions".

Posted to: Page security Show Thread | Post Reply

Re: Page security

Hayden — Thu, 16 Aug 2007 09:04:18 +1200

The MemberTableField probably isn't the best way to go about it, as adding more columns as the number of groups increases might be a pain.

You might need to create a FormField from scratch.

Posted to: Page security Show Thread | Post Reply

Re: Page security

Hayden — Thu, 16 Aug 2007 08:54:09 +1200

The option to inherit page permissions is evaluated each time that the page is accessed, not just when it is created.

When set to 'inherit', the page should instead evaluate the permissions of the current user against the settings of the parent page. You can always change this setting for child pages.

To use the department homepage example: yes, the managers should be the only ones with permission to change the homepage, but you can still set other permissions on the child pages:

Homepage: editable by managers, visible to all
-Department: visible to department members
--Department page 1: visible to department members
---Nested department page: visible to department managers

In this case, the department page would have specific permissions, and department page would inherit from that. The nested page would then have different permissions.

Posted to: Page security Show Thread | Post Reply

Re: Page security

Markus — Thu, 16 Aug 2007 05:19:47 +1200

Iâ€™m currently implementing the new permissions system but I encounter a lot of problems

The first one is that Iâ€™m really unsure if the permissions should be inherited in the way as described above? Just think of a website for a company that has different departments. All pages of a department are subpages of the department homepage. Normally only the department manager (or his secretary) should have the right to change the department homepage, but the subpages should be changeable for all employees in the department.

So I think the best would be to inherit the permissions only on page creation - if at all.

And finally the last question is how I can implement Timâ€™s matrix style to display/edit the permissions (maybe a transposed version - which means groups as columns and permissions as rows).

I played with MemberTableField but I had no success

I wanted to create a component to which I can pass a parameter that specifies which permissions (and maybe with which labels) should be shown, so that for example the page access tab shows only â€œView this pageâ€ and â€œEdit this pageâ€ whereas the matrix in the security tab shows all permissions.

Please look also into sapphire/security/Permission.php. Hayden created permission groups that allow the grouping of permissions so that they can be displayed quite nice.

Posted to: Page security Show Thread | Post Reply

Re: Page security

Whizzle — Tue, 14 Aug 2007 03:51:23 +1200

One thing not sure if you've touched on this... Could you have an option to show only to Non-Logged in users.... This would be great for having a home page for Anonymous users and then one specific for logged in users...
Also can you add the access tab to all items (Redirects, etc...) I know there are a couple that don't have it...

BWT I'm a SS noob and this stuff rocks I have my site up and running and so far it's gone great!... Please keep it coming...

Posted to: Page security Show Thread | Post Reply

Re: Page security

Tim — Thu, 09 Aug 2007 22:31:00 +1200

Hi Markus

Please see my note here re the interface for this - we are going to need to use the matrix style interface for this.

Posted to: Page security Show Thread | Post Reply

Re: Page security

Sam — Thu, 09 Aug 2007 15:49:10 +1200

This looks good. I would recommend implementing the group selector as a subclass of FormField that is designed to save to any many-many join. This is what we've done with TreeMultiselectField and CheckboxSetField and it makes the code nice really reusable. It will also mean that you could easily switch between the control you've presented and CSField / TMField.

Saving to a many-many join is pretty straight forward: treat the form field name as the name of a method on the associated data object, and call setByIdList() on the ComponentSet that gets returned

See this piece of CheckboxSet for a sample.

Posted to: Page security Show Thread | Post Reply

Re: Page security

Markus — Thu, 09 Aug 2007 02:29:42 +1200

++ Update ++

I'll change the interface of the "Access" tab which currently looks as follows:

to an interface like:

Has someone a better idea how to label the two list boxes ("Available groups", "Selected groups")?

Page security

Markus — Thu, 09 Aug 2007 01:53:49 +1200

The next days I'll focus on the page security stuff. I'll implement it as follows:

The "Access" tab will look at it does now:

Who can view this page on my site?
- Anyone
- Logged-in users
- Only these people (choose a group in the provided list)

Who can edit this inside the CMS?
Anyone who can log-in to the CMS
Only these people (choose a group in the provided list)

This works already, so what I'll add next is inheritance:

Page A
|-Page B (child of A)

If view/edit of A is set to a specific group, page B requires also that group. If set to logged in users, B requires a logged in user or a specific group and if set to anyone page B can be restricted to logged in users or a specific group.

Do you think it makes sense to implement something so that it is possible to select more than one group? Something like "This is visible only by" ... "the specified groups:" and then something like a list box where one can select the groups?

What about creating two pseudo-groups, namely "Anyone" and "Authenticated Users"?

Posted to: Page security Show Thread | Post Reply