Security critical preferences editable when databases are locked

[aeisi]

When all databases are locked, one can open the preferences dialog and modify security critical preferences.
For example when a person has configured that his databases are locked "after minimizing the window" and frequently leaves his desktop unlocked but minimizes his database, another person could change the behaviour to not lock after minimizing the window. The owner of the database would then again think to lock the database by minimizing his windows (expected behaviour), leave his desktop unlocked without knowing that his preference has been changed and the other person could then simply maximize the window and get all the passwords.

Expected Behavior

Security ciritical preferences cannot be modified when all databases are locked, so that the required and configured behaviour of the application is ensured.

Current Behavior

Security critical preferences can be modified when all databases are locked, leading to the situation described above, that an unauthorized person could gain access to the databases.

Possible Solution

I would suggest to only have non-critical preferences be editable when all databases are locked. Only when a database is unlocked, security critical preferences can be edited.
Maybe this implies to have individual security preferences per database.

Steps to Reproduce (for bugs)

1. Lock all databases
2. Modify security critical preferences

Operating system: macOS
CPU architecture: x64

[droidmonkey]

Preferences are entirely unrelated to individual databases. I am calling this a duplicate of #2224

[michaelk83]

@droidmonkey , I think the point here was that global security settings shouldn't be editable without some sort of password protection? This would be covered by #2224 if the security settings are only availabe per-database. But if they're global, then that's a separate issue.

(Sorry if this has been addressed elsewhere. I just ran into this while looking over other things.)

edit: Nevermind, found #3627, #2646, #891. Should've waited a little before posting.