Message Level Access Control

If this feature is enabled, the Managing Editor of a site can define Cohorts - arbitrary groups of members - and activate a control that permit users to restrict visibility of messages to members of any cohort to which they belong whenever they create or edit a message or picture.

The Managing Editor can also activate a second control which allows users to specify a duration during which a message should be visible. The duration is specified by two timestamps, the release date and the expiry date. Either are optional, so the duration can be open ended.

Both flavours of Access Control can be applied to the same message simultaneously, if either restriction applies the message will be inaccessible. A user cannot make a message inaccessible to the message owner or to an editor, and a Managing Editor can always see every page. In other words, if Manila permitted you to edit the message before any restrictions were set, you will still have read and edit access after the restrictions are imposed.

There are no controls available to change the visibility of messages which are responses within Discussion Groups - responses always inherit the access restrictiosn applied to the topic of which are part.

Accesibility is tested before displaying a message, story or picture. It is not tested before displaying a picture from the picture list (this list can be restricted using standard Manila settings), nor for the home page or Gems.

If a page is inaccessible, the user is redirected to a page like this

Requests for inaccessible pictures are re-directed to the no access gif (the no access logo above), which may be distorted to fit the height and width specified in the IMG tag.

Message Level Access Control also defines 4 macros which return the cohorts that can view and the release and expiry timestamps for the current page respectively, if they are defined, otherwise they return a null string. The accessTimestampString macro returns a string that describes the time restrictions relative to the time of inquiry - its importance is that the text returned may be localised

• manilaExtras.messagecohorts()
• manilaExtras.messageExpiryDate()
• manilaExtras.messageReleaseDate()
• manilaExtras.accessTimestampString()

Message Level Access Control adds the following RPC handlers to manilafixer. They allow retrieving and setting the release date, expiry date and lists of cohorts of individual messages. The first four parameters are always

• the name of a member, either the message owner or editor.
• matching password for user name.
• short name of site. That is, myfirstSite, not myfirstsiteManilawebsite.
• message number of message to operate upon.

There are 3 pairs of get and set entry points. The get handlers return the requested value, should it exist. The set handlers take one further parameter, the value to apply; they return true if the set operation completes successfully.

• manilaFixer.rpcHandlers.accesscontrol.cohorts.get
• manilaFixer.rpcHandlers.accesscontrol.cohorts.set - extra parameter must be a list of cohort names
• manilaFixer.rpcHandlers.accesscontrol.expiryDate.get
• manilaFixer.rpcHandlers.accesscontrol.expiryDate.set - extra parameter must be any value that can be coereced to a date, including net standard date strings
• manilaFixer.rpcHandlers.accesscontrol.releaseDate.get
• manilaFixer.rpcHandlers.accesscontrol.releaseDate.set - extra parameter must be any value that can be coereced to a date, including net standard date strings

Message Level Access Control works by modifying certain keys scripts within your Manila website. It does not modify scripts inside Manila or any other Userland root.

Access Control has benefited from design discussion from David Davies, Peter Peter Baumgartner and Daniel Springett; none of whom are responsible for bugs or design flaws, which are all mine.