With version 7.7, the special system level OWNER group has been defined to allow owner restricted access to selected items. The core Ittrium engine has always supported an id within every resource of the party who created the item. ACE has been extended to allow this creator to be changed.
The idea of a personal page has been frequently batted about, and often implemented by the rather crude mechanism of a single user specific group, with a single member who is that user. This causes a proliferation of groups that are rather hard to manage. And it also has a negative impact on page caching. The list of groups that any one user belongs to becomes part of the caching key. So two different users who belong to the same set of groups see the same cached version of any component. But if a user belongs to a group where they are the only member, then all caching occurs for that single user only. No sharing is possible.
The OWNER group addresses this problem. The OWNER group acts like a provisional group, but rather than being active for a specific section of the site, is is active only when the current user is the actual creator of an item. This addresses most of the page caching issues. Now the caching is specific to the current user only for those components where the user is the creator. Shared items like banner, footer, tools, and often times, navigation are no longer cached per individual, since the owner group is not active.
One final complication with this implementation is that provisional groups have a common problem with navigation and nested items. A provision only kicks in once the target item is part of the path. But if you are building navigation elements, your path is typically pointing at the parent item, not the provisional item, so the provisional group is not activated. But the desire is for the navigation to reflect only those subitems where the OWNER is active.
This has been solved by the new ability to mark a category element for special handling. The special handling flag has been added as a column in the database, and ACE has been enhanced to support selecting which special handling to apply. The OWNER Aware special handler flag informs the engine to activate the special OWNER group for itself and all its child elements. So you can activate OWNER Aware at a parent level, and use the permission system to selectively display only those subitems that the current user owns.
Personal Page activation check list
- Ensure the OWNER group is defined
(sql boot 7.7 or upgrade 7.7 will include the appropriate definitions) - Include any Users who require access to a personal page within the OWNER group
- Create a parent page somewhere and turn on the OWNER Aware special handling
(only admins, webmasters, and publishers will see this option in ACE) - Create a set of personal pages / inner pages within the parent. Remove normal visitor viewing permissions from these personal pages, and grant read/peek to the OWNER group instead.
- Assign the appropriate creator to each of these personal pages
(only those who have create permission for the User type will have access to alter the creator via ACE)
-- NOTE --
To expedite processing based on the special handling feature of the various content elements, the unused localization slot within the PK has been commandeered for the special handling flag. Localization will no longer be active as part of an encoded PK.
The expectation is that the localization id in every encoded key has always been the integer value one. Therefore, the special handling flag value of one means that no special handling is required.
The handling flag of two means that the corresponding resource element is OWNER Aware. The provisional OWNER group will be active for any item that is marked OWNER Aware (and for any of its child elements as well)