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 | ☑ | ☐ | ☐ | ☑ | ☐ | ☐ | ☐ |
Provided that the template administrator has an explicit modification right on the template.
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.