Currently, favorites are tracked at the cipher level. For org-owned ciphers,
this means that if one user sets it as a favorite, it automatically becomes a
favorite for all other users that the cipher has been shared with.
Main changes:
- Splitted up settings and users into two separate pages.
- Added verified shield when the e-mail address has been verified.
- Added the amount of personal items in the database to the users overview.
- Added Organizations and Diagnostics pages.
- Shows if DNS resolving works.
- Shows if there is a posible time drift.
- Shows current versions of server and web-vault.
- Optimized logo-gray.png using optipng
Items which can be added later:
- Amount of cipher items accessible for a user, not only his personal items.
- Amount of users per Org
- Version update check in the diagnostics overview.
- Copy/Pasteable runtime config which has sensitive data changed or removed for support questions either on the forum or github issues.
- Option to delete Orgs and all its passwords (when there are no members anymore).
- Etc....
PostgreSQL updates/inserts ignored None/null values.
This is nice for new entries, but not for updates.
Added derive option to allways add these none/null values for Option<>
variables.
This solves issue #965
I've checked the spots when `Invitation::new()` and `Invitation::take()`
are used and it seems like all spots are already correctly gated. So to
enable invitations via admin API even when invitations are otherwise
disabled, this check can be removed.
Because of differences in how .on_conflict() works compared to .replace_into() the PostgreSQL backend wasn't correctly ensuring the unique constraint on user_uuid and atype wasn't getting violated.
This change simply issues a DELETE on the unique constraint prior to the insert to ensure uniqueness. PostgreSQL does not support multiple constraints in ON CONFLICT clauses.
- Added security check for previouse used codes
- Allow TOTP codes with 1 step back and forward when there is a time
drift. This means in total 3 codes could be valid. But only newer codes
then the previouse used codes are excepted after that.
This includes migrations as well as Dockerfile's for amd64.
The biggest change is that replace_into isn't supported by Diesel for the
PostgreSQL backend, instead requiring the use of on_conflict. This
unfortunately requires a branch for save() on all of the models currently
using replace_into.
