17488 Posts in 4473 Topics by 1978 members
Page: 1 2
|Go to End||Next >|
9 August 2007 at 1:53am
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?
- 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 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"?
9 August 2007 at 2:29am Last edited: 9 August 2007 2:31am
++ 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")?
See also this thread
9 August 2007 at 3:49pm
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.
Core Development Team
14 August 2007 at 3:51am
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...
16 August 2007 at 5:19am Last edited: 16 August 2007 5:35am
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.
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?
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.
Core Development Team
16 August 2007 at 8:54am Last edited: 16 August 2007 9:02am
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.
Core Development Team
16 August 2007 at 9:04am
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.
Page: 1 2
|Go to Top||Next >|