History of ProtectorService
!!Basic Outline
The basic design of the protector service is to provide a package agnostic way of identifying material that is to made visible to different groups of users. In it's simplest implementation it provides a means of creating an anonomous set of pages that cover all of the packages available, and gets round the current restrictions that the package based permissions system imposes.
Guest visitors are presented with a fully functional set of content that they can view and navigate as if they were registered users, and which they can search without being able to see 'secure' content.
This facility gets round the problems of 'view' permission being set on a package by package basis. Each content item is allocated to a group, and is only visible to members of that group. Since users can be assigned to a number of groups, there is no need to assign content to more than one group ( however that facility can be made available, but complicates the basic plan of protector ).
In a default system, content would be identified as anon, registered, and admin, and only admin users would be able to see pages that are 'restricted' to the admin group. Registered users are also members of the anon group, and so also so the base anon content.
!!Simple Developments
One of the reasons for wanting to introduce this structure was to provide for different 'types' of registered users. As an example, genealogy information can be of a personal nature, but the core information should be generally available. The anon level would provide an overview of historic and other public material, registered users would have access to a larger range of material, while family members would be allowed access to more private information. Where larger bases of information exist, there may be more than one 'family' group, and users can be members of a number of those groups, but still be blocked to accessing data on other family groups.
A more 'commercial' application of protector is the restriction of material based on the organisational structure of a company. The general workers get access to the first level of documentation, while supervisors can see material related to their level of 'security', and managers, a higher level of security. Different departments may have their own supervisor and manager groups, so that supervisors for one department can't see content in anothers, while managers may be members of multiple supervisor groups, and see all the information for their area of the company.
!!Moderation
Hopefully it is now obvious that this approach can be applied to other areas of restricted access, such as content moderation.
The basic design of the protector service is to provide a package agnostic way of identifying material that is to made visible to different groups of users. In it's simplest implementation it provides a means of creating an anonomous set of pages that cover all of the packages available, and gets round the current restrictions that the package based permissions system imposes.
Guest visitors are presented with a fully functional set of content that they can view and navigate as if they were registered users, and which they can search without being able to see 'secure' content.
This facility gets round the problems of 'view' permission being set on a package by package basis. Each content item is allocated to a group, and is only visible to members of that group. Since users can be assigned to a number of groups, there is no need to assign content to more than one group ( however that facility can be made available, but complicates the basic plan of protector ).
In a default system, content would be identified as anon, registered, and admin, and only admin users would be able to see pages that are 'restricted' to the admin group. Registered users are also members of the anon group, and so also so the base anon content.
!!Simple Developments
One of the reasons for wanting to introduce this structure was to provide for different 'types' of registered users. As an example, genealogy information can be of a personal nature, but the core information should be generally available. The anon level would provide an overview of historic and other public material, registered users would have access to a larger range of material, while family members would be allowed access to more private information. Where larger bases of information exist, there may be more than one 'family' group, and users can be members of a number of those groups, but still be blocked to accessing data on other family groups.
A more 'commercial' application of protector is the restriction of material based on the organisational structure of a company. The general workers get access to the first level of documentation, while supervisors can see material related to their level of 'security', and managers, a higher level of security. Different departments may have their own supervisor and manager groups, so that supervisors for one department can't see content in anothers, while managers may be members of multiple supervisor groups, and see all the information for their area of the company.
!!Moderation
Hopefully it is now obvious that this approach can be applied to other areas of restricted access, such as content moderation.