Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »



Konzept

The primedocs authorization concept pursues the following goals:

  • Reduce administrative overhead

  • Ensuring that only user-relevant data is synchronized on the user's computer

  • Involving the specialist departments in the maintenance of snippets

  • Restricting the visibility of templates and snippets based on organizational and role affiliation

  • Support of Active Directory and Windows groups

The authorization concept is based on roles, users, user groups and objects. Roles and thus permissions are linked to the objects by AD groups, AD users, primedocs groups or primedocs users.

primedocs groups

primedocs groups and primedocs users are independent authorization classes.

A primedocs group can contain groups or users - this can be defined statically or made dynamic by a configuration. For dynamic groups, a configuration is stored which automatically assigns or removes a user from a group based on user information.


Roles

Permission / Role

Sys admin

Org admin

User admin

Template admin

Campaign admin

Snippet admin

User

Manage organizations

Manage logo

Manage templates

Modify templates and their permissions

1

Manage users

Manage shared snippets

2

Create template snippets

Manage fields

Manage campaigns

Manage signatures

  1. Provided that the template administrator has an explicit modification right on the template.

  2. Provided that the user has an explicit modification right on the snippet.

The following roles are provided in primedocs:

System administrator

Highest authorization. System administrators can assign roles for users and groups. In addition, they can edit all templates (including those to which the user does not have explicit modification rights) and manage organizations, snippets, users and fields.

Organization administrator

Permission to modify all organizational units (create, delete, insert logos, change addresses, etc.).

User administrator

Permission to administrate all users and profiles: this is useful for all those who provide support for the OneOffixx environment.

Template administrator

Permission to edit and create templates: Template administrators see all templates and their permissions. However, templates can only be edited if the user has the explicit modification right on the template or template group. This also applies to the respective permissions of the templates.
Template administrators can also edit all template snippets and create new ones. They have a right to change the global document functions, the global configurations and translations as well as all tags.

Campaign administrator

Permission to edit and create campaigns.

Snippet administrator

Permission to edit and create shared snippets: snippet administrators do not need explicit modification rights on the snippets. They can always edit all snippets.

NOTE
It is recommended to create one template group per office or per department. This makes it easier to limit the visibility of templates, which in return helps users in finding the template they need.


Permissions for snippets

In primedocs there are Shared snippets, Template snippets as well as Private snippets. Only snippets for which the user has read access will be synchronized to the OneOffixx Client.

Shared snippets

Read access is allowed for a snippet or a snippet group if

  • the user has read access to the element itself and all parent snippet groups,

  • it is the root element "Shared snippets"

  • the user has write access via one parent snippet group

  • the user is a snippet administrator

  • or the user is system administrator.

Write access is allowed for a snippet or snippet group if the user

  • has write permissions to the element or one parent snippet group

  • and the top-level element is visible with write access, i.e. the user must also have read access for this element

  • or they are snippet/system administrator.

NOTE
Note that an element without explicit permissions inherits all permissions from the parent group and therefore has no influence. Conversely, this means that as soon as explicitly defined, it is no longer inherited from above.

Only snippet/system administrators can create elements at the top level.

It is not possible to make a snippet group visible if the parent group is not visible as well. For such a case, simply restructuring into further subfolders may help:

Example

Group Management
├─ Personnel
├─ Snippet A
├─ Snippet B
└─ Snippet C

A person is now to be authorized to the Personnel group, but not to see the modules in the management group itself. To do this, another group is created and the snippets are moved into it:

Group Management
├─ Personnel
└─ More
   ├─ Snippet A
   ├─ Snippet B
   └─ Snippet C

Now the person can simply have the read access for "Further" revoked.

Template snippets

Read access is granted to all users, i.e. the text modules are made available to all users for document generation. However, they are only displayed to system/text module administrators.

Write access is only granted the system and snippet administrators.

Private snippets

Read access and Write access is only granted the corresponding user. System and snippet administrators do not have access for privacy reasons.

  • No labels