ntation.
Being that osc is (AND I USE THIS TERM LOOSELY) modular, this will permit root admins to assign base permissions to new and/or existing pages on the fly.
To define any number of exceptions to these permissions or user specific rules per page, applied/implied or imposed upon any group, individual or combination of the two.
Further, restrict [single] functions, buttons or links, anything that would submit data to be updated, stored or changed. This, is intended to prevent
or restrict site settings being altered, or people playing with things they shouldn't.
This includes the same abilities for child pages defined by ?action=this, etc. to be regulated specifically, if desired. Pages that consist of possibly
multiple files being included by any number of scripts, in very much the same manner. With or without individual restriction.
- User Access levels
Any number of named [base] access levels can be defined, on the fly by top level (root) admins. These levels will define an abstract
group, and the access staff assigned to this group will be permitted or denied as a result. This is a starting point, defining optional denial of
access or permission of access to individual pages (..or their children defined in the url itself, should that be the case) by default.
These groups can be assigned further specific restrictions or exceptions, as part of their base access class. These specific rules, as
defined on the staff access levels page, will be explicitly imposed upon staff members categorized as subject to them.
* User specific exceptions and restrictions - A staff access level can be further extended on a per user basis, indiscriminately.
No restrictions imposed upon, or exceptions granted to a single person will have any bearing on, nor inspire any consideration for other staff
members sharing that same access level distinction. In these cases, the root user defined access level, or group itself will serve truely as
a base. In a case where an exception or restriction, defined as part of a users assigned access level/group, as well as another specific to
the user exclusively are both relevent to the request simultaneously, the user specific definition will not only take precendence over, but will
completely override all related base access level distinctions. This is done as a further security precaution, to contain any potential abiguity
between them. So the desired result can be achieved.
User permission, a unique global flag used to categorize this user defined level. This, in the absence of further staff member/group specific
exceptions or restrictions, will be compared with page permissions and permit or deny access accordingly.
(User [base] permission respective to the pages in question are applicable to all staff implicitly, and those carrying relevent root user
defined exceptions explicitly.)
- Page Permissions
Individual pages and their children, can be assigned a numeric value to signify their base user permissions, or level of importance/security.
This is a relative comparison to another defined in the above 'user access level', which takes precedence. This only applies, should no user/group
specific exception or restriction be defined or relevent to the staffs request from this page. In which case, this will decide a
course of action based on this default permission.
- Default user access levels 'root', 'admin'
'root' provides implicit access to all of the site, it differing from a secondary 'Admin' level only by permitting access of root users
to the user access/restriction/etc controls pages that will be created, where rules applied to varying staff restrictions and
such can be defined, altered, added & removed. Also, access to controls for the staff accounts themselves, where they are categorized, managed,
added or removed.