Type ACLs


Many of our customers asked for a sophisticated right management to allow the management of specific object types for specific user groups.

Handling in backend
Evaluating access rights should be handled in backend for security reasons.

Access rights on group level
All access rights should be configured for user groups (not for individual users). One user is linked to one user group.

Navigation elements in UI
If a usergroup does not have sufficient rights for specific actions, navigation elements (buttons, links, …) should be hidden.

System Level Permissions
For a user group, system wide rights can be configured (like it is implemented today). System level rights define access to objects, types, categories, export jobs, docapi template, … (e.g. base.framework.object.edit, base.docapi.*, …) These rights are set independent from the object type. For example, the right base.framework.object.edit means edit access to objects of all types. Implementation for system level rights is already done.

Type Management Permissions
Beside the system level permissions, permissions for the management of specific object types should be defined for user groups. If a user group has type management permissions for an object type, the following actions can be done for that object type:

  • type definition edit

  • docapi templates edit

  • exportd job edit

Management of DocAPI templates or Exportd Jobs should only be possible, if a user group has management accesss for all types that are handled by an Exportd Job/DocAPI template.

  • Exportd Job for router

    • usergroup has management access for router

    • => job can be managed

  • Exportd Job for router and server

    • usergroup has management access for router, but not for server

    • => job cannot be managed

Type Management Permissions should be set on user group level.




Michael Batz