[ HelpTop ]
An ACL in YakiBiki is a configuration list of users and groups with permission(hidden/read/read and write).
In YakiBiki, users prepare ACL in advance. When creating new pages, users assign an ACL to a page.
Following descriptions only focus "Permission".
There're three "Permission" in YakiBiki.
There's no permission which combination is "Editable, but Not Readable". And also, there's no "Delete" permission.
In YakiBiki, only page owner (who created its page) or "System role" user can delete its page datas.
You can "delete" your data by changing acl to "Draft" ACL, its recommended way.
NOTICE: "System role" user can read/edit/delete ALL page datas, ignoreing ACL.
Users who has "ACL role" or "System role" only can edit ACLs.
Main elements of ACL are following three items.
Above three permissions are available in user/group permission list for each user/groups.
Users or Groups are added explicitly when setting permissions.
Secial user permission (described below) is applied to non-added users/groups.
In YakiBiki ACL, there's probability of permission conflict.
For example, "Read Only" permission to GroupA, "Read and Edit" to GroupB, which permission is applied to users who belongs to both GroupA and GroupB ?
YakiBiki tries to solve these confilict by "Policy" ACL configuration.
There're two policies in YakiBiki.
"Read and Edit" is the most "Positive" permission. "non:invisible" is the most "Negative" permission.
There're two users in user permission list, "Guest (NOT Logined) users" and "Logine users".
These two special user permissions are applied to implicit users and groups.
For example, YakiBiki applies "Read Only" permissions only to users who don't belongs to any of GroupA, GroupX, GroupY.
Guest (NOT Logined) users only | non:invisible |
Logined users only | Read Only |
GroupA | non:invisible |
GroupX | non:invisible |
GroupY | non:invisible |
See following link, for actual ACL configuration examples.
ACL_Examples
[ HelpTop ]