Fork me on GitHub

secure (who can do what)

An article by Gaspard Bucher



Versions traverse different statuses during their life time. Here is a list of the values a version’s status can take. We list them by decreasing order of expected quality (we expect a new proposition to be better then the current publication, a publication to be better then anything that was removed, etc).

  • redaction
  • proposed
  • proposed with
  • published
  • replaced
  • removed

The colors correspond to the ones used for visual feedback on the website and on the list of versions in the drive popup.


New versions start with this state. When the owner of a redaction changes the content, this updates the version. When someone tries to edit another author’s redaction, this moves the redaction into replaced status and creates a new redaction for the new author.

Redactions are only visible to writers.

When an author updates a redaction older then redit time (default is 2 hours), this will create a new version (backup). The “redit time” setting can be changed on the site’s settings page.


When an author (member of the write group) finds that a redaction (his own or someone else’s) is ready for publication he can either publish it (if he is a member of the drive group) or propose it for publication (status becomes proposed).

Any writer can propose a redaction for publication. A proposition is only visible to writers.

Once a node has a version proposed for publication, writers cannot edit the node for the given language until the proposition is either accepted or refused. When a proposition is refused it simply goes back to redaction status.

Documents that are direct children of a proposed node are automatically proposed with their parent. Their status is then proposed with.


When the content of a version is considered ready to be visible by all readers, it is published (status changes to published). If there was a previously published version for the same language, it is replaced (status changes to replaced).

A node becomes visible to all members of the read group when it has at least one published version and the current time is after the publication date.

A node can have only one published version for each language used in the site.


A draft is a node with a single version in redaction status from the creator of the node. The creator of a node has special rights over the draft: just as she as created it, she can remove it or put it somewhere else, even if she is not in the drive group for this node.

Special rights for the draft owner: delete and move

Defining group based accesses

Accesses are defined through groups and ownership. Each node has one owner and three groups to define it’s accesses. Each version in the node has one owner which may be different from the node’s owner.

access groups

drive group

People in this group can make content visible to the readers by publishing or removing (unpublish) versions. They can also change the node’s name, class, access rights, move it around or destroy it.

write group

People in this group can create new redactions for the current node and add new content to the node (new pages, notes, projects, ...). They can create content, but they cannot publish it or alter the structure of the site (they cannot move objects around).

read group

People in this group will be able to see the node if it is published.


The owner is the creator of the node. She has special rights when the node is a draft.

change groups

To change the access groups the user must be in the node’s drive group.


To change a node’s parent from A to B (moving it out of A and into B ), we consider two situations:

  1. the node is published or contains published content: user must be in the drive groups of A and B .
  2. the node is not published and does not contain published content: user must be in the write groups of A and B .

Relations (links) and permissions

To create or edit a link, a visitor needs to have the appropriate node permissions for the nodes on both ends?

Visitor status

On top of the access rights defined above, there is another site wide layer based on the user’s status:

Here are the different statuses which a user can have:


Super user (special, only 1 for each site) used only to solve problems (I never used it, might be removed in future version of zena).


Belongs to all groups, can add/remove/change users, can change any settings in the “admin” part of the site.


Normal user with read/write/drive power. No access to the admin part of the site.


Can only read and post comments.


Can only read and post comments that are moderated (not automatically published).

This is used when you want to restrain a user from posting stupid comments with tons of spelling mistakes.


Can only read.

This is used when you want to give readonly access to a user (because she writes silly things).


Cannot login.

Used for bad guys who worked with you once and are now trying to destroy your reputation.

Finer grained rules

Finer grained rules can be defined based on access control lists (ACL).

See the access control lists (ACLs) and Mastering Sites.