Ulrich Windl

Looking for something similar, I also found https://sourceforge.net/p/keepass/feature-requests/2050/ My idea was to introduce some "date math", so one could enter "+90D" (for example) for the expiration date, and the date would be set to 90 days from now. "D" for" days" might be subject to localization (like "T" for "Tage" in German); maybe not. Several professional programs dealing with time a lot allow such kind of date mathematics. Related to https://sourceforge.net/p/keepass/feature-requests/2050/...

Feature Request: Non-admin instalation on Windows

Note on label "Scan wird ausgeführt (2) export (3)": Some stupid local security software interacted with scripting in a bad way to it replaced the original "export" label with the nonsense string. Unfortunately I cannot edit the entry. (So my recommendation is to protect yourself from https://www.checkpoint.com/harmony/endpoint/) ;-)

Allow password retry when exporting entries

Most likely adding some more details would help processing.

So if an enforced profile does not exist, and the password generator profiles are stored in the user's profile, any new password generator profiles would be stored in a newly-created enforced profile, while a user could still define new password generator profiles by simply editing the user's profile? If that's true, that's at least a very bad design, but I think that's simply a bug (feature not completely implemented). Despite of that I think the text in the release notes is quite confusing: If...

So if an enforced profile does not exist, and the password generator profiles are stored in the user's profile, any new password generator profiles would be stored in a newly-created enforced profile, while a user could still define new password generator profiles by simply editing the user's profile? If that's true, that's at least a very bad design, but I think that's simply a bug (feature not completely implemented).

So if an enforced profile does not exist, and the password generator profiles are stored in the user's profile, any new password generator profiles would be stored in a newly-created enforced profile, while a user could still defined new password generator profiles by simply editing the user's profile? If that's true, that's at least a very bad design, but I think that's simply a bug (feature not completely implemented).