Problem Description

In the version passwords which cannot be decrypted for other users could be created. In this case, individual users or even all users do not have the necessary legal key. If a user wants to reveal an affected password, the following message is displayed:


The bug was fixed with the version Hotfix 1. If an older version is in use, it is important to update to the latest version

Review and settlement of records

When updating to version, the AdminClient is checked for affected data records.

Review via the AdminClient

The results of the query show which passwords can be fixed by which user. (In this example, the entries are highlighted in color).

Blue = password name
Yellow = Repairable / Irreparable
Orange = users / roles who can fix the password

Reparable records

Passwords in which users / roles with entitlement right and right key exist:

Irreparable records

Passwords in which users / roles without a legal key or with a legal key but without an authorization right exist:

Settlement of reparable records

Damaged passwords are corrected automatically with the users / roles specified under ‘repairable with’ when logging on to the client or WebClient.

The right key can be checked using the form field permissions of password fields. If at least one user has the right key, the password can be fixed. In the following example, only the user ‘white’ has the right key and thus only this user can discover and correct the password.

When logging on to the database via the client, a cleanup task is started automatically. This task always runs with the logged in user. In this case – as far as it is possible with the user – all affected passwords are corrected. Thus, when all users have logged in once, all affected passwords should be adjusted.

Irreparable records (not repairable)

Irreparable passwords cannot be corrected automatically. Nevertheless, it may happen that passwords marked as irreparably can be corrected manually.

First case

In the first case, no user / role has the right key on the password. Thus, no user can decrypt or correct the password.

The affected passwords have to be recreated. For the security, a new database with an older backup can be included. From this database, the affected passwords / data can be taken over into the current database again.

Second case

In the second case, there are users / roles who have the right key but not the right to claim. As far as the number of irreparable passwords is limited, these can be used to check the form field permissions manually.

For the passwords concerned, the user with the legal key must be given the right of authorization temporarily to correct. If the corresponding user has the entitlement right, he can reset the legal key, either automatically when logging in or manually when saving the authorizations.

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.