Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

Our old forums are still available as a read-only archive.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo

Page security

Go to End

9 Posts   6311 Views


Google Summer of Code Hacker, 152 Posts

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?
- 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"?


Google Summer of Code Hacker, 152 Posts

9 August 2007 at 2:29am

Edited: 09/08/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


Administrator, 690 Posts

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.


Community Member, 201 Posts

9 August 2007 at 10:31pm

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.


7 Posts

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...


Google Summer of Code Hacker, 152 Posts

16 August 2007 at 5:19am

Edited: 16/08/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, 19 Posts

16 August 2007 at 8:54am

Edited: 16/08/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, 19 Posts

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.

Go to Top