<< Previous Learning Trail | Contents | Section 1: Users Next >>

Permissions

Permissions control a user's ability to see and/or edit objects in the database. The permissions settings will usually be used to protect items from being edited (either accidentally or intentionally). Items with permissions are: wells, stratigraphic schemes, composite standards, palaeoenvironment schemes, groups, sets and chart templates. 'Read Only' items are usually displayed with a padlock symbol before their name.

Only Super Users and Key Users have the privilege to set permissions. If the permission is not 'Public Read/Write', the item's user list must contain at least one Super User or Key User (who has the privilege to change the item's permissions). Super Users can change the permissions on any item at any time, whether or not they are on the user list. Key Users can only change permissions on items where they are on the user list. Thus, if a User needs to edit an item, they will have to seek permission from a listed Key User who can temporarily 'unlock' the item and perform the edit.

Users can be added to the user list even though they cannot change permissions; this is so that the user list can act as a record of interested parties. If a user's privileges are elevated in future (e.g. they are promoted to a Key User), then they would be able to edit permissions.

Permissions are set using the Permissions dialog. This same dialog is used for all items with permissions settings. Usually a Permissions menu option makes this dialog available. Any user will be able to open this dialog but not all users will be able to change the settings (see above).

The default permission level is Public Read/Write.

Permission levels are as follows:

Permission Level

Items

Description

Public Read/Write all* Any unrestricted (i.e. not a "Read only") user can read and edit. No key holders required.
Public Read Only all* Can't be edited, but can be read by all. Can be unlocked by a key holder on the list.
Restricted Read/Write Wells only Users in the list can read & edit. Hidden from other users.
Restricted Read Only Wells only Users in the list can read. Hidden from other users.

*stratigraphic schemes, composite standards, palaeoenvironment schemes, groups, sets, panel templates, block templates, correlation templates, charts

Recommended Use

The obvious candidate for a Public Read Only item is a chronostratigraphic scheme. Typically this is a published scheme (perhaps with local modifications) which is shared by all users of the database. Once the scheme is in place no user in the database should have any reason to edit it. It should be set to Read Only by a Super User (no other users can change the permissions).

Typically a group of users will work on one project. There may be one or two Key Users within this group. If the project uses its own schemes, composite standards, taxon groups etc, these should be entered into the database. When agreed by the group, they can be locked by the Key User. They can now only be unlocked by this Key User (not other Key Users). If the project is confidential, any wells entered can be set to Restricted, with all the project's users included in the User list. Now the project group has exclusive control over their project data.

All types of chart templates can be set to Read Only (panel, block, correlation and chart templates). 'Locking' any of these templates protects existing charts from being edited inadvertently by changing the templates. This is especially important for global, general-purpose templates which might be used throughout the database. For example, you might develop a template to display your standard chronostratigraphy scheme, which you want people to use throughout their charts but you don't want people to edit.

Notes for Wells

Only wells can be Restricted, i.e. hidden from all users except those on the user list. Only these users can select the well using the Well : Select dialog - which means opening it in Samples & Interpretations, Schemes & Interpretations, adding it to Charts, etc. Although the data are hidden, the well name and code are still visible to all users of the database. It is intended that wells be restricted for a limited time only and that they are moved to 'public' when data are no longer confidential.

Setting a well to Read-Only (Public or Restricted) stops any user editing samples, analyses, occurrences and interpretations. It does not however prevent edits which originate from other parts of the system and may affect the well:


Page last updated: 11-Oct-2022 11:18