History of TP-DB-Permissions
!Current Tables=-
__Users_Permissions__
The table's primary key is permissoin name itself which is often long text. Having primary key that is often referenced to be non-numerical is considered a bad design and slows database access as well as increases size of database tables and indices. So it is best to untroduce new numerical id for each permission.
In order to not make it necessary to lookup the id while for user view and for how its accessed from php pages its all done by name, it might be good to add php configuration file for each package that is written (and updated) whenever permissions are added. Then php function will convert from real name to numerical id without requirying database access.
Also it might be good idea to rename this table from user_permissions to tiki_permissions as in reality it represents tiki-specific information and not user-specific data
__Users_Objectpermissions__
This table needs to be replaced to allow permissions control on per-content (rather then per object) and per group
!New Permission/Access Tables
__tiki_permissions__ (primary key is perm_id, unique constraint on perm_name):
This table is used to hold information about each permission
===perm_id=== - Numerical ID of the permission, assigned when package is added
===perm_name=== - integer - Actual name of the permission
===perm_desc=== - varchar - Full description
===level==== - varchar - This is might have been better if it was called "permission type". It specifies appropriate control level needed to use this permission, typical values are "admin", "editors", "basic". This closely corresponds to what group is typically this permission assigned to.
===package=== - varchar - Name of the package which uses this permission
===maintainer_url=== - varchar - This is used to point to whoever supports use of this permission. Normally this would be "tikipro.org", but for custom permissions the value would be something else
__tiki_access__ (primary key is access_id):
This table has information about each specific access mode. Access specifies what is required to be able to use certain restriction, typically this is used for password-protection.
===access_id=== - integer - Unique numerical id
===access_desc=== - varchar - Description of the access
===access_question=== - varchar - Question to ask before granting this type of access
===access_answer=== - varchar - Expected answer (i.e. password). Note that it might be good idea to have this be MD5 hash of actual answer
__tiki_access_permissions__
Access is a grouping of one or more permissions as it applies to the content.
!Thoughts regarding "hidden" access.
Its been thought that it would be good idea to have special way to designate some page as hidden so that it does not show up on pages and that should be property of the access_type (is_hidden tag in access table). After thingking about it more, I believe this actually more closely corresponds to permission. In fact the permission should be "tiki_p_searchable" and represents that given user/group can in fact do searches for particular object. Normally this would be standard permission (like tiki_p_view) but it might be disabled for some content.
__Users_Permissions__
The table's primary key is permissoin name itself which is often long text. Having primary key that is often referenced to be non-numerical is considered a bad design and slows database access as well as increases size of database tables and indices. So it is best to untroduce new numerical id for each permission.
In order to not make it necessary to lookup the id while for user view and for how its accessed from php pages its all done by name, it might be good to add php configuration file for each package that is written (and updated) whenever permissions are added. Then php function will convert from real name to numerical id without requirying database access.
Also it might be good idea to rename this table from user_permissions to tiki_permissions as in reality it represents tiki-specific information and not user-specific data
__Users_Objectpermissions__
This table needs to be replaced to allow permissions control on per-content (rather then per object) and per group
!New Permission/Access Tables
__tiki_permissions__ (primary key is perm_id, unique constraint on perm_name):
This table is used to hold information about each permission
===perm_id=== - Numerical ID of the permission, assigned when package is added
===perm_name=== - integer - Actual name of the permission
===perm_desc=== - varchar - Full description
===level==== - varchar - This is might have been better if it was called "permission type". It specifies appropriate control level needed to use this permission, typical values are "admin", "editors", "basic". This closely corresponds to what group is typically this permission assigned to.
===package=== - varchar - Name of the package which uses this permission
===maintainer_url=== - varchar - This is used to point to whoever supports use of this permission. Normally this would be "tikipro.org", but for custom permissions the value would be something else
__tiki_access__ (primary key is access_id):
This table has information about each specific access mode. Access specifies what is required to be able to use certain restriction, typically this is used for password-protection.
===access_id=== - integer - Unique numerical id
===access_desc=== - varchar - Description of the access
===access_question=== - varchar - Question to ask before granting this type of access
===access_answer=== - varchar - Expected answer (i.e. password). Note that it might be good idea to have this be MD5 hash of actual answer
__tiki_access_permissions__
Access is a grouping of one or more permissions as it applies to the content.
!Thoughts regarding "hidden" access.
Its been thought that it would be good idea to have special way to designate some page as hidden so that it does not show up on pages and that should be property of the access_type (is_hidden tag in access table). After thingking about it more, I believe this actually more closely corresponds to permission. In fact the permission should be "tiki_p_searchable" and represents that given user/group can in fact do searches for particular object. Normally this would be standard permission (like tiki_p_view) but it might be disabled for some content.