NAME

access.pod - access control for administration of BSE

SYNOPSIS

How to configure and enable access control for BSE administration.

DESCRIPTION

As of release 0.12_13 of BSE, it provides a moderately powerful mechanism to control access to various administration functions, especially for maintaining content.

The aim is to provide flexible access control, without requiring micro-management from the administrators.

Internally BSE now provides for fairly fine-grained access to editing existing articles and creating new articles, hopefully without overloading the person who will manage the users and groups.

BEFORE ENABLING ACCESS CONTROL

Make sure you create users with sufficient access control to maintain the system.

At the very least create a user and give them the User/Group management global permission.

ENABLING ACCESS CONTROL

Once you have at least created a user/groups administrator, set the access_control value to 1 in bse.cfg.

Once you've done that you will be prompted for a username and password whenever you try to access BSE's administration functions.

USERS, GROUPS AND PERMISSIONS

All permissions in BSE are positive - the permissions you give a user and their groups are combined together so that if the user has a right enabled for themselves, for any group they are a member of, or for the everyone group, they will have access to the function.

The permissions visible to the user administrator are split into two categories:

  1. Global permissions - these apply in general, like access to the order list, or to user/group management. These can also include article permissions that have been applied to specific articles, or to subsets of the article tree.

  2. Article permissions - these are applied to specific articles by the user administrator, and can control the article or all of the children of the article, depending on how the permission was setup.

BSE provides default sets of global and article permissions, but you can add extrs more specific to your business needs, see ADDING NEW PERMISSIONS.

The standard global permissions shipped with BSE are:

The article permissions are:

ADDING NEW PERMISSIONS

Besides the standard permissions described above, you can add permissions more specific to your organizaton by adding entries to a few sections in the bse.cfg file.

Each permission has a unique index associated with it. This must be a natural number (0 or a positive whole number).

Each permission has an identifier which is used to choose the configuration section that the permission is described in.

Article permissions are listed in the [Article permissions] section, and global permission in the [Global permissions] section, with the identifer being the key, and the index being the value. eg.

  [Global permissions]
  shop_access = 1
  all_but_shop = 3
  subscriptions=4
  orders=5
  users_and_groups=6
  [Article permissions]
  full_access = 0
  change_body = 2

The identifier for each permission is used to find the description of the permission, for an identifier the section would be [permission identifier].

For article permissions you can define the following entries in the description:

Group permission require only one extra entry:

See the supplied bse.cfg for the definitions of the standard global and article permissions.

Describing low-level permissions

The permissions keyword is a comma separated list of permission names, or patterns for permission names.

Typically you will either use explicit permission names, or a base name with a wildcard, but it's possible to use more complex matches.

Alternatively, the permission can be not(permission list) where permission list is a comma separated list of permission names or patterns.

Eg. if you want the permission to give the use access to all edit functions for the selected articles you could do:

  permissions=edit_*

If you want to give the user access to edit and save all field of an article:

  permissions=edit_field_edit_*,edit_save

Alternatively this could be:

  permissions=edit_(field_edit_*|save)

but the first is probably clearer.

The patterns you can use, are effectively any perl regular expression, except that you're limited by the permissions field being split on commas, and the translation of '*' to '.*'. If you don't understand this, just use '*' to match anything.

See LOW-LEVEL ARTICLE PERMISSIONS and LOW-LEVEL GENERAL PERMISSIONS for descriptions of the permissions themselves.

Selecting articles for global permissions

The simplest form for the articles value is a list of article ids:

  articles=3,9

You can also match articles that are children of a given article:

  articles=childof(3)

or a given type of article:

  articles=typeof(Product)

You can also to negate a set of articles:

  articles=not(child(3),9)

LOW-LEVEL ARTICLE PERMISSIONS

These permissions are applied to specific articles, and depending on whether the childof() operator or descendants flag is set, can apply to the give article or it's children.

Article editing

These control adding new articles and modifying the content of existing articles.

If you want a "macro" to allow all of the following, add 'edit_*' to the permissions keyword.

Image management

You can control whether a user can add, remove, reorder or change the details of the images attached to an article.

There is no control over individual images.

If you want to give users full image control, add 'edit_images_*' to the permissions entry.

File management

Regeneration

Step children/parents

These are unusual in that you will need permission to modify both the parent and child in the given relationship. ie. if article A is a stepparent of article B, then you need both edit_stepkid_delete permission on A and edit_stepparent_delete permission on B.

LOW-LEVEL GENERAL PERMISSIONS

These permissions don't apply to specific articles and control operations outside of the article tree. For the permissions to be applied they should be applied to article "-1" (the site)

Subscriptions

Shop orders

These permissions provide no control over the content of the shop, since that can be controlled through article permissions.

To create a "macro" with access to all order management functions, use 'shop_order_*'.

User/Group Administration

This controls whether a the user can manage users and groups.

Typically you will just want to add 'admin_*' to the permissions key for the macro.

These permissions assume a bit of foresight on the user - ie. that they won't delete the permissions they need to do their job.

Regeneration

Site users

AUTHOR

Tony Cook <tony@develop-help.com>

REVISION

$Revision$