About system permissions

Default Permission

If granted, the user or the members of the group can create number of configuration items, and access to objects or attributes without having an explicit permission, unless the permissions has been explicitly denied. See Which items you can create only with the Default permission?

It is recommended to grant this permission only to the Administrators group.

Manage Volumes

If granted, the user or the members of the group can manage – i.e. list, create, modify and delete the volumes description. For more info, see Volumes.

It is recommended to grant this permission only to the Administrators group.

Delete

If granted, the user or the members of the group can permanently delete or undelete deleted objects.

The permission to delete an object is controlled by the access permissions (see below) – but this is only a ‘logical’ deletion – also called ‘spike’, i.e. the object still exists in the database. Such objects can be physically deleted (purged) or ‘undeleted’ (i.e. converted back to normal visible objects) only by users with the ‘Delete’ system privilege.

It is recommended to grant this permission to the Everyone group.

Access audit

If granted, the user or the members of the group can access the audit trail of other users.

All the operations on the database objects (creation, modification etc.) are logged by the system, every user can see the list of operations done by him, but only users with the Access audit can see the list of operations done by other users (i.e. ‘snooping’ on other users’ activity).

It is recommended to grant this permission to the groups of senior users, e.g. Editors, Section heads etc.

Manage UI

If granted, the user or the members of the group can modify the translation strings.

It is recommended to grant this permission only to the Administrators group.

Manage Tasks

If granted, the user or the members of the group can manage scheduled tasks.

It is recommended to grant this permission to all the users that are supposed to publish on the publishing destinations, e.g. the Everyone group or the Publish group.

Unlock

If granted, the user or the members of the group can unlock locked items.

It is recommended to grant this permission to the Everyone group.

Audit searches*

Log search operation. If granted, every search operation user performs will generate an entry in the audit trail. These entries specify the search conditions, how many objects where returned by the search, if the search excluded deleted objects and a string describing the operation that called the search (simple search, export with a condition, loading of folder trees etc.)

*This audit option is to be enabled ONLY when superusers want to monitor activity of a user/group for debugging, inspection only. See also the paragraph "About system performance related permissions".

See Removing old items from AuditTable and AuditLoginTable and Making AuditTable smaller.

Audit objects loading*

Log loading objects. If granted, every time a user loads an object belonging to a type with gs:auditLoad="true" the operation is recorded in the audit trail as a 'Load' action. These actions specify the user that executed the load, the loaded object and the list of attributes of the object that have been read.

*This audit option is to be enabled ONLY when superusers want to monitor activity of a user/group for debugging, inspection only. See also the paragraph "About system performance related permissions".

Audit objects check out*

Log objects check-out. If granted, every check-out and check-in operation generates an entry in the audit trail. These entries specify the objects that have been checked-out and how - i.e.e with which access classes = which attribute.

Manage Schema

This privilege is checked only in the following commands:

do exportschema and updatedatabase 

srv4 mime

It is recommended to grant this permission only to the Administrators group.

Manage Triggers

If granted, the user or the members of the group can manage triggers.

It is recommended to grant this permission only to the Administrators group.

Create Keywords

If granted, the user or the members of the group can add new keywords to the set of keywords, by means of any entry dialog box that contains keywords list. Otherwise, the user can only select an existing keyword and apply it on the GN4 object.

When granting this permission have in mind that the Back4 typically runs under Administrator user, and therefore, if the templates Back4 uses handle the automatic adding of keywords from wires, the Create Keyword permission granted to the Administrators group will cause overfilling of keyword sets with all the wires keywords. To avoid it, grant this permission only to the group of users who maintain keywords sets and are skilled enough to avoid ambiguous or duplicated terms.

Each user or group has an associated list of system permissions that are either granted or denied for that specific user or group. (In schema terms: the security object type from with both the user and group object types descend has a ‘privs’ attribute of type ‘permissions’ – see above for a definition of such an object type. All this is defined in GN4Base.xsd).

The system permissions that a logged user has are computed combining the granted/denied ones for the corresponding user and for all the groups the user is member of. The user's setting take precedence over the group ones. Higher priority group's settings take precedence over lower-priority group ones. If a permission is not explicitly granted or denied in the user nor in any of the groups the user is member of, it is implicitly denied.

Examples: let’s say that group ‘Everyone’ denies ‘Audit’ and group ‘Administrator’ grant ‘Audit’, group ‘G’ does not specify anything for ‘Audit’; then:

•User ‘Jack’ does not specify anything (grant or deny) for ‘Audit’ and belongs only to ‘Everyone’: ‘Jack’ does not have ‘Audit’ (gets the value from ‘Everyone’);

•User ‘Jim’ grant ‘Audit’ and belongs only to ‘Everyone’: ‘Jim’ has ‘Audit’ because the user setting takes precedence on the group one;

•User ‘Admin’ does not specify anything for ‘Audit’ and belongs to ‘Administrators’ and ‘Everyone’ (in this order): ‘Admin’ has ‘Audit’ because the ‘Administrators’ setting takes precedence over the ‘Everyone’ one. Note that is ‘Admin’ belonged to ‘Everyone’ and ‘Administrators’ (opposite order) he would NOT have had ‘Audit’.

•User ‘Mary’ does not specify anything for ‘Audit’ and belongs only to the group ‘G’: ‘Mary’ does NOT have ‘Audit’ – because if there are no specification the system assume no permission.

The AuditSearch, AuditLoad and AuditCheckOut options potentially can cause slow-down of the GN4 system and extremely huge database. These are to be enabled ONLY when superusers want to monitor activity of a user/group for debugging, inspection only.

The flags say to the system to write an entry in the AuditTable and AuditSearchTable for every operation on objects, and since in GN4 everything is an object, above settings cause a very high SQL traffic that slows down operations.

It is recommended to deny and keep denied those system permissions for every user and group.