[Sm-1588] secrets versioning - #8307
Conversation
…at editorName gets returns to clients side properly
SecretUpdateRequestModel.ToSecret mutates the entity in place and returns the same reference, so originalSecret aliased the already-updated secret and every version snapshot stored the new value rather than the previous one. Capture the value and revision date before ToSecret runs. VersionDate used the secret's CreationDate, which never changes, so every version for a secret shared one timestamp. That made OrderByDescending a total tie, leaving history order arbitrary, and let the retention prune in CreateAsync delete the newest versions instead of the oldest. Use the revision date of the value being archived. The restore path had the same problem using DateTime.UtcNow, which collided with the secret's new revision date, so it now keeps the date the archived value was set. Drop EditorName from the version response. Machine account names are encrypted with the organization key, which the server cannot read, so the field carried ciphertext for service-account editors and plaintext for user editors. Callers get EditorServiceAccountId and EditorOrganizationUserId instead and can resolve a display name from data they have already decrypted. This also removes the per-version editor lookups along with the IServiceAccountRepository and IUserRepository dependencies they needed. Add tests for the update and restore snapshots, the get-by-ids endpoint, and the ten-version retention cap, none of which were covered.
…den/server into SM-1588-SecretsVersioning
…ersioning UI, extracted logic into a command for adding and updating new Secret Versions. Adding and updating relevant tests
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #8307 +/- ##
==========================================
+ Coverage 63.97% 64.00% +0.03%
==========================================
Files 2471 2474 +3
Lines 105812 105895 +83
Branches 9596 9602 +6
==========================================
+ Hits 67692 67777 +85
- Misses 35769 35773 +4
+ Partials 2351 2345 -6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
🤖 Bitwarden Claude Code ReviewOverall Assessment: REQUEST CHANGES This revision moves version writes into Code Review Details
|
Co-authored-by: Rui Tomé <108268980+r-tome@users.noreply.github.com>
…'t display. I added a way to look up the actual names. Member names are stored as plain readable text, but machine-account names are encrypted and the server genuinely cannot read them. So these can't be one combined "name" field — the member name is sent as-is, and the machine-account name is sent still-encrypted for the browser to unscramble. Saving a secret and saving its version-history entry were two separate operations. If the first succeeded and the second failed, the secret was already permanently saved but the user got an error screen — so they'd try again and end up with two copies of the same secret. The fix is like a bank transfer: both steps now happen inside a single all-or-nothing operation. If the version entry fails, the secret save is undone too, so the user's retry is safe.
…den/server into SM-1588-SecretsVersioning
… upon change doesn't retain version history
…den/server into SM-1588-SecretsVersioning
🎟️ Tracking
https://bitwarden.atlassian.net/jira/software/c/projects/SM/boards/74?assignee=625cb516fd06270069beaf5d&selectedIssue=SM-1588
📔 Objective