| **robust object permission management (can set perms for individual objects)
|
| **watch feature (notify by email)
|
|
|
| -!!Group Category and Object Permissions system.
|
| +!!Group, and Category Permissions system. |
| +The permissions structure inherited from tikiwiki was fairly robust, and by tikiwiki 1.9.2 a fully customizable group ''and'' category permissions regime emerged. This beats mediawiki and most other wikis because it allows for multiple private areas assigned to any number of groups (who may or may not have the same general permissions). |
| + |
| + |
| +!!!Basic logical structure |
| *Category is a set of any objects (including modules)
|
| +**objects can have many categories assigned/nonexclusive |
| +**categories are organized in heirarchies. |
| *Group is a set of any users.
|
| +**users can be assigned to many groups/nonexclusive |
| +**groups are organized in heirarchies (permission sets can include other groups) |
| + |
| !!!Group Permission Sets
|
| -*Default 4 or 5 level Group Heirarchy, editable
|
| +*__General Permissions___ have a default 4 or 5 level group heirarchy, which is editable. (so all new installs have a ready to go basic heirarchy) |
| **anonymous - can alter little or none.
|
| **registered - standard user perms
|
| **editor - power user perms
|
| **admin - system wide perms
|
| **god - create and define admins
|
| -*Batch import and export by group.
|
| -*users may give permissions they have to other users
|
| +*__Batch Import and Export__ by group. |
| +*__Allow delegation and promotion__ users may give permissions they have to other users. Delegate means permission is granted conditionally by a senior user and can be removed by same person (who may be implicitly/explicity responsible for their delegates). Promote is a "permanent" upping of perms (which can of course be removed by admins). |
|
|
| !!!Category Permission Structure.
|
|
|
| -Permission Structure
|
| -1. Can Y do X for this module (based on group)?
|
| -2. Can Y do X for this object (based on category)?
|
| +__Category Permission Structure__ |
| +The trinity of permissions checks |
| +1. Can user of group Y do X for this module ? |
| +2. Can user of group Y do X for this category ? |
| 3. Are there any object specific exceptions for Y on X? (i.e. password required each time)
|
|
|
| -iow category overrides module and object overrides category and module.
|
| +__The more local the permission, the more dominant__ category overrides module and object overrides category and module. This is good because it enables the fastest application of all permissions by administrators. |
|
|
| -*There are three kinds of categories
|
| -**tag category - a label only
|
| -**tag + perm category (user viewable category with defined permission set)
|
| +__Three kinds of categories__ |
| +Categories can be used in two ways: |
| +*tags for sorting and structure |
| +*perms for access control |
| + |
| +Sometimes you want only one of these functions, sometimes both. If the category is a tag, you probably want it displayed (ok maybe there are some display-categories-to-group possiblities) |
| +don't want to display a category, just have it turned on to provide access control. In this way, there are three ways categories can be used. |
| + |
| +*a "tag" - which is a label only |
| +*a "tag + perm category (user viewable category with defined permission set) |
| **perms only category (non user viewable category with defined permission set)
|
| -*objects may inherit permissions from object they were created from.
|
| + |
| +__Objects should inherit permissions__ from object they were created from. (is their any reason why this should not be default behavior) |
|
|
| !!!Categories from namespaces:
|
| pagename begins with or includes string x is automatically assigned to category y.
|