Hi guys,

I'm looking at deploying Silverstripe for our company intranet, but one of the big things that I need it to do is to allow the different teams of our company to be able to edit and add their own pages without making any other site-wide changes.

Eg there would be a 'HR' tree of pages, and the 'HR' manager would be able to edit that page and everything under it, and add/remove pages under that tree.

I've had a quick play with a default install, and whilst it looks like you can set access privileges on pages using user groups, it doesn't look like you can set multiple groups as being able to edit a page/section, nor does it look like changes actually propagate or cascade down to child objects?

Is this right, or am i doing something wrong?

Please, anyone confirm?

How do I submit it as a bug?

To be honest, the security in this CMS seems to be a bit half baked...

Hi FrostySonic,

Sorry about not responding faster, I've created a bug report for the security issue you raised and marked it as a blocker for our next release, so it should be sorted by the time 2.2.3 rolls around at the very least. We may look at patching 2.2.2 as well.

The bug report can be seen here: http://open.silverstripe.com/ticket/2701

Hey FrostySonic,

With a bit of delay, most of your concerns have been addressed in the current trunk, and should find their way into the upcoming 2.3 release:

> However, if UserA first clicks on a page that he can edit, and then clicks on a page he can't edit, then the buttons down the bottom of the content view still show on the page he isn't supposed to edit, AND if he clicks on them they do actually perform their function (e.g. Unpublish or delete!)!
Just tested, opening an editable page followed by opening a readonly page hides the buttons. The permissions should be enforced regardless on the controller now. Can you confirm?

> The fact that access permissions were not applied down trees of pages.
Theres a new option "Inherit from parent page", which is then used in SiteTree->canView() and canEdit().

> That you can't add multiple security groups to the Access settings of pages.
Fixed, its now a many_many relationship

> That one single user can't belong to multiple security groups (not 100% sure on that one)
Hm, that was possible since 2.0 afaict.

> The unfriendly URLs (to me non-hierarchical URLs are only slightly more useful as having the old page.php?pageid=1234)
Thats being addressed in a feature branch at the moment: http://open.silverstripe.com/browser/modules/sapphire/branches/nestedurls

See http://open.silverstripe.com/ticket/2701#comment:4

I'm just working on a migration script which will transfer data from the legacy columns like the ViewersGroup has_one relationship to the new schema.

The changes are mostly unit tested, but we might have missed some assumptions and controller actions where permissions aren't fully enforced, so any manual testing and feedback is welcome! FrostySonic, any chance you find some time for this?