More about groups, actions, and permissions is defined here: Content Object in Cassandra (Content Tree)
It is to be noted that in regard to terminology, the terms used in the many document are somewhat confusing. It will get fixed with time. In the software, however, the terminology we are trying to be correct. There are 4 terms that are important defined as:
The Permissions feature is certainly one that we will have to talk about at length.
The most basic permission is whether the user is logged in or not. When not logged in, a user is generally quite limited (write a contact message, a search query, a comment on a page.)
Logged in users will generally be able to do more things such as submit a controlled survey (i.e. one submission per user) or edit a page.
At this level, permissions are required to know who can do what. For example, users who can edit pages are scarces, maybe one single person. On the other hand, people who should answer to a survey could be in the thousands.
There are many different ways to handle permissions, but it generally comes down to two main systems: per individual and per group permissions.
Using just a group system, you can still have a per individual permission since each person can be assigned an individual group. In that case, you get thousands of groups as you get thousands of users signing up to your website. Unix uses this method with great success.
Implementation Details
It seems to me that it will be possible to implement this viewing each user as a group since users and groups are both rows in the same content table, it can very well be viewed as the same thing when it comes to permissions. Assuming we have a Group type where each group is defined, each user will be a child item of that Group type. Implemented. However, the links are created in a slightly different way than I first thought possible because we need to know whether a permission aaplies to that very page or to the user or page attached to that group.
Groups can be defined in the form of a tree (and the default is just like that!) where someone who has access to a higher level group ("smaller path") have all the rights from all the children of that higher level group. For example, an Editor group would allow the user to edit any page (meaning pages that the Editor is not the author of). The Editor group has a child group named Author. The Author has the right to delete his own pages and so will the Editor.
To make it more complete, there should be two levels of permissions that allow some individuals to gain access to certain feature because another person is on a business trip or on vacation. This can be important in large businesses that want a tight control over who can do one thing or another.
By default the level of a user is his current group. In certain circumstances, that level can go up. At this point, the only circumstances would be when a certain user is marked as absent and the former needs access to those features to be able to conduct business until the return of that other user.
Example:
User A can create a new page. In normal circumstances, user A cannot change the creation date of any page. He has to ask user B with a (special) request to get that changed.
User B goes on vacation for 2 weeks.
While User B is out, user A gains access to the access right that user B has and can himself/herself change the date of that new post.
Note that when I say here that user A gains access to user B rights, it's not entirely true. A gains access to a new ("more powerful") group. This group allows A to do more things while B is out so business can continue as usual. This being said, A may not gain all of B's rights. For example, maybe B can assign and change vacation information for users. But A should never be able to do that... So the level implementation defines the group that A gains when B is absent not all of B's group.
Implementation Note
A user can be considered to have a status. This status is used to determine the group(s) he's part of. The "blocked" status obviously prevents the user from doing most everything. The status "on vacation" prevents the user from accessing the system until the vacation is over. The status can thus be another list of terms in a user status taxonomy.
See: Firewall feature
In most cases users get an Access Denied error when they visit a page. This generally means the user is shown a special page: the Access Denied page. That special page probably looks similar to the rest of the website, but has very limited information about the page being visited (maybe the title) and possibly a way for the user to go to another page or to log in.
On the other hand, if the Access Denied error is not for a page, then the output should be the normal 401 or 403 error as we see with a default Apache installation. This saves a lot of resources as we don't have to generate a full page for those. This should make sense because a user who is just trying to check out a picture should not see a full HTML page.
The permissions offered to the user will depend on the plugins.
For a page, a user can have many different types of rights as in:
Of course, we can start with a very few features such as create, edit, delete and modify a page. However, the permissions system can be incredibly detailed.
The permissions are defined per type by defining them in the type of the page. So the content has a link from the page to a type, and the type has links to the different rights. That defines the permissions of that content type that a user needs to have in order to act on that content.
There is an example of a blog page which would have a link to the type Blog Page. That type defines 4 different permissions that the user must have in order to edit those pages. The User is an author so he can create and edit, and since he's an author, he also is a visitor, and as such he also have the view right.
Page -> Type: Blog Page -> Rights: Create Blog, Edit Blog, Delete Blog, View Blog
User -> Group: Blog Author -> Rights: Create Blog, Edit Blog
-> Group: Blog Visitor -> Rights: View Blog
One idea is that Edit may be forbidden to a moderator. In that case, when the moderator sees a problem, he/she can add a note to the page and the author / editor will then make the necessary modifications. The note is a log, a bit like a post-it (or maybe even very much like a post-it!) and while the note is up, the page could be hidden from anonymous users.
There are different features one can use that will prevent others with a lower level of permissions to edit content.
For example, the filter used on a page may require permission level 1, so a user at level 2 (i.e. level 2 users have less rights) cannot access the page content (because there could be data that does require level 1 permissions that this other user doesn't have.)
In order to offer an exclusion feature, we also want to support a substraction (exclude operator) to remove a set of individuals, groups, etc. This can be reached with our system as we make use of unions and intersections. The latter is an equivalent to a substraction.
Snap! Websites
An Open Source CMS System in C++
