The permission system does not change with the new DocuWare client. Documents stay exactly as secure as they are today, based on the configuration that is already in place. Nothing has to be reassigned, and no permission is lost or widened.
DocuWare has two ways of controlling how user work with documents: file cabinet permissions and dialogs. They often work side by side, which makes it easy to assume they do the same thing. They do not. Permissions secure documents. Dialogs shape how users see and work with them.
The new DocuWare client makes that distinction visible. The search across several file cabinets and DocuWare Aura query the documents a user has permission for, independent of any search or result dialog. Where access was managed through dialogs rather than through permissions, users can now find documents they did not see before, although the permission model itself has not changed.
Supported versions: DocuWare Cloud + new DocuWare client only
On this page
Important
File cabinet permissions decide what can be accessed. Dialogs are still there and can drive visibility of data - but this is not a security layer. The multi file cabinet search does not rely on dialogs. The single file cabinet search still runs on dialogs and their settings. A user who has the permissions to a document can find it by its index values, even when those fields are hidden in a dialog or in a result list. Confidential information is protected through file cabinet and document permissions, not by hiding dialog fields.
Permissions and dialogs: two separated jobs
File cabinet permissions decide what a user is allowed to access: which documents, which index fields, and which operations, such as searching, viewing, editing, deleting, and exporting. They are enforced by the platform at the data level, no matter how the user reaches the file cabinet. No permission, no access, whether the request comes from a client, from an integration, or from the API.
Dialogs are views. They decide which fields a user is offered, in which order, with which preset filters, so that everyday work is quicker. A dialog filters what is shown. It does not change what a user is allowed to access.
Why a dialog cannot restrict access
A setup that keeps documents out of reach by leaving a field out of a dialog, or by not assigning a search dialog, is only hiding it. The document itself stays accessible to everyone who holds the permission for it.
Such a document can still be reached:
through the DocuWare Platform Service or another interface,
by reading the traffic between browser and server,
through any other client or integration on the same file cabinet.
Two examples of a rule that a dialog cannot carry:
The salary field is left out of the result list of the personnel file cabinet, so that team leads do not see it. But everyone who was granted access to the salary field, can see it in results.
A search dialog is preset to one vendor, so that a clerk sees only that vendor's invoices. If the same clerk has permissions on the other vendors he can find the invoices of every other vendor in the file cabinet with a keyword search.
In both cases the rule belongs in the file cabinet permissions, where it applies to every client and every interface.
Where this becomes visible in the new DocuWare client
The permission model has not changed. What has changed is that several parts of the new DocuWare client no longer work through a dialog, so a dialog cannot narrow what they return.
Search across multiple file cabinets
The search covers every file cabinet a user has access to and does not use a search dialog. Index fields hidden in a dialog are available in the result table, and menu entries hidden in a result dialog are offered.
DocuWare Aura
Answers are based on the documents a user has permission for, and the answer names the documents it used. Document and index field permissions apply unchanged.
Result list functions in a dialog
A result dialog in DocuWare Configurations > File Cabinets has the setting Result list functions, which decides which functions appear in the context menu and as buttons above the result list. The new DocuWare client does not evaluate that setting, also where a dialog is used.
Every one of these functions is backed by a permission of its own. The setting only decided what a user was offered on screen. A user who holds the permission can carry out the function on other routes, so clearing a checkbox there never restricted anything.
In the new DocuWare client the context menu is built from the permissions instead: a function a user is not allowed to use is left out of the menu, not shown and refused.
A predefined lists and all other lists still follow their dialog, but the menu of a list is built from permissions, not from the dialog settings. Also, the document menu of a workflowtask shows the actions the user's file cabinet permissions allow, instead of a fixed set.
Where there is no dialog at all, such as the search across multiple file cabinets, result list functions were never available anyway, and in the classic client they were never available for folders either.
What to check in a configuration
Find the dialogs that are hiding elements. Wherever a missing field, a preset filter, or an unassigned dialog is what keeps documents out of view, treat it as a permission gap.
Move the rule to the permission layer. Define in the file cabinet permissions what each role is really allowed to access. The rule then holds in every client, in integrations, and in the API.
Keep dialogs for what they are good at: tailored views, shorter masks, result lists per department.
Review the file cabinet permission profiles before users move to the new DocuWare client, so that what is hidden today is also restricted.