a memo
So you're an Editor... what does that mean, exactly? What can a Writer do that a Member can't, and what does it really mean to be Anonymous?
Roles like Member and Editor control access to berylium objects. Generally speaking, Editors have access to everything on the site (public or private; new, hidden, posted, or even deleted), while Members can view but not edit posted objects (public or private), and Anonymous viewers can only see public, posted objects. Read on for more...
By default, berylium 1.0 comes with five roles:
Admin - the super-administrator
Admins can control anything on the site short of settings that require access to the filesystem. Typically, the admin is the person who created the site in the first place, the first member. Admins are the only users who can create new contexts (controlling the look of the site) or change the passwords of other users in case of lockout.
Editor - an all-access backstage pass
Editors are your most-trusted users. They can create, view, and edit most objects, even deleted ones. The only thing that controls an editor's access to an object is her rank: if an editors rank is lower than the rank of the object she is trying to modify, the changes won't take.
In this way, you can specify an Editor-In-Chief who has exclusive control of content on the front page of your site, say, or of very-important-documents-that-must-not-be-changed, that kind of thing. We don't recommend that, though.
Writer - creative contributors
(Writer is unimplemented until 1.0 release)
Writers have access to all objects except deleted ones.
Writers can create and modify their own objects, except for folders. They also have a degree of control over the publishing properties of their objects: public or private, posted or deleted, and rank up to their own rank.
Thus they are semi-autonomous, trusted members of your community, but they can only work with their own material.
Member - read-only access with an invitation to contribute
Members have access to all posted objects (public or private), and they can generally create new, private objects (not folders). They can modify objects that they created, provided that the object rank is 100 or less, but when they edit their object, the status will be reset to "new"-- that is, the approval of an editor is required to republish that object. This is easy to modify on an object by object or even folder by folder basis for advanced applications, but members are considered untrusted contributors by default.
Anonymous - the huddled masses
Anonymouses (as I call them) have access to public, posted objects only, and they can't create or edit anything by default. (Not really true, they can create new Sessions and new Sitemembers, but not any content objects.)
Changing the World
Those are the default policies, and they are maybe too restrictive for most sites, and not restrictive enough for most others. There are two ways to override the defaults: 1) write your own policy and 2) override the current policy in a custom context.
Custom Policies:
Writing your own policy is simple (if not straightforward)-- the policy files control things like the default publishing status for new or updated objects, what objects can be viewed, and what objects can be created. They can be saved on a per-site basis (in /beryliumroot/files/sitename/policies/).
See the default policies in /beryliumroot/code/policies/.
Overriding Policy in Context:
If you need a finer degree of control, or wish to relax or tighten policies in a particular folder, you'll need to create custom contexts and override the policy in preprocess(). The context "comment-save-member-html" is a good example of how to do this, allowing members to create public-posted comment objects, which they technically can't do by policy. Remember, if you override a policy in preprocess() to reapply the policy in postprocess().
You can only do this if you have access to custom per-site contexts (in /beryliumroot/files/sitename/contexts/), as database contexts (the kind admins have access to online) don't have editable preprocess() or postprocess() fields.
By Chris Snyder on September 18, 2002 at 12:45pm