I've been in contact with the live support and this change seems to be intentional.. for some reason.
If I was unclear before, here is an example of how the access rights are applied in version 7.5 (7.7.0.0).
Example tree structure with (access rights) version 1:
RootPage (Everyone = Read, WebAdmins = Administer)
PublicPage (Everyone = Read, WebAdmins = Administer)
ProtectedPage (WebAdmins = Administer)
If we add a group called Internal to the RootPage and give them Read access, then tick the "Apply settings for subitems" box so that they can read every page (not just RootPage), the new access rights are as follows:
Example tree structure with (access rights) version 2:
RootPage (Everyone = Read, WebAdmins = Administer, Internal = Read)
PublicPage (Everyone = Read, WebAdmins = Administer, Internal = Read)
ProtectedPage (WebAdmins = Administer, Everyone = Read, Internal = Read)
Notice how both Everyone and Internal was applied to ProtectedPage. This is not what we want.
Given a site with 40-50 pages, adding the group Internal to all pages one by one is doable (but not fun). For larger sites however that is unthinkable.
It has to be done, Find a way!
The first solution that came to mind (which only works during development or if none of the pages are inheriting directly from your root) is as follows.
The reason it only works in dev/not inheriting from root is because you don't want to temporarily lock any users out of your system
Given the tree structure presented above (as version 1).
Example tree structure with (access rights) version 3: Notice how Everyone has been removed from RootPage
RootPage (WebAdmins = Administer, Internal = Read)
PublicPage (Everyone = Read, WebAdmins = Administer, Internal = Read)
ProtectedPage (WebAdmins = Administer, Internal = Read)
Example tree structure with (access rights) version 4: Notice how Everyone has been added to rootpage again
RootPage (Everyone = Read, WebAdmins = Administer, Internal = Read)
PublicPage (Everyone = Read, WebAdmins = Administer, Internal = Read)
ProtectedPage (WebAdmins = Administer, Internal = Read)
If anyone else can think of an easier solution I'd be more than happy.
I'd be even happier if the checkbox for "selected row" that was present in earlier versions of CMS makes a comeback.
Hope this helps someone out there, enjoy!
// Kim
Hi Kim,
That functionality was removed (due to complexity) when inheritance was introduced, but maybe we need to consider its return.
We will talk it over within the team.
I appreciate your feedback on the matter!
Best regards,
Jonas
How does one apply new access rights for one group without adding/removing any additional groups.
In earlier version of CMS, for instance cms 6, you could add a group to a page, give it read access and "apply settings for subitems" but only for that selected row.
With this, one could easily create a new group and give it read or edit access to all pages without changing any of the other access rights.
With CMS 7.5 (7.7.0.0 to be precise) it doesn't seem to be that easy any more.
The checkbox for "apply settings for subitems" is still there, but the checkbox that let you select one or more rows has been removed.
Because of this, adding one group without messing with the rest seems impossible.
Any ideas?