* PM-37621 - Fix Device.LastActivityDate surfacing legacy NULL rows as DateTime.UtcNow
Dapper's deserializer skips the property setter when a nullable column is
DBNull, leaving the property at its CLR default. The field initializer
`public DateTime? LastActivityDate { get; internal set; } = DateTime.UtcNow`
poisoned that default, so rows whose LastActivityDate column was NULL (e.g.
devices created before the column existed) read back as the current time.
Drop the initializer, relax `internal set` to `set`, and stamp
LastActivityDate explicitly at the two creation call sites
(DeviceValidator.GetDeviceFromRequest and DeviceRequestModel.ToDevice). Adds
an integration regression test that creates a device with an explicit null
LastActivityDate and asserts the read path surfaces null. Augments
DeviceValidatorTests.GetDeviceFromRequest_RawDeviceInfoValid_ReturnsDevice
to lock in the creation-time stamp.
* PM-37621 - DeviceSeeder - creation should set LastActivityDate
* PM-37166 - Add ClientVersion to Device entity and repository contract
* PM-37166 - Add ClientVersion SQL schema and refactor bump stored procedures
* PM-37166 - Implement combined bump in repositories and add EF migrations
EF snapshot regeneration also absorbs Collection / CollectionGroup /
CollectionUser namespace moves (Bit.Infrastructure.EntityFramework.Models
-> Bit.Infrastructure.EntityFramework.AdminConsole.Models) that were left
un-regenerated by PR #7523 (PM-35489). Namespace-only, no SQL impact;
flagged with the AC team for awareness.
* PM-37166 - Replace DeviceLastActivityCacheService with DeviceDataCacheService
* PM-37166 - Replace BumpDeviceLastActivityDateCommand with BumpDeviceDataCommand
* PM-37166 - Pass ClientVersion through identity request validators
* PM-37166 - Align migration script with SQL style guide
Refresh Device_ReadBy* sprocs after DeviceView change so their cached
schema picks up ClientVersion, swap retired-sproc drops to
DROP PROCEDURE IF EXISTS, and tighten the ALTER TABLE indent in step 1.
* PM-37166 - Rename BumpData to UpdateLastActivity across device write pathway
The "BumpData" naming was vague — "data" named a category, not the thing
being written. Rename to "UpdateLastActivity" everywhere: SP, repositories,
command, cache, validators, tests. "Last activity" names the event of the
device's most recent appearance; LastActivityDate (when) and ClientVersion
(what was running) are facts we observed about that event. ClientVersion is
treated as a property of the activity event rather than an independent value,
so future last-observed properties (last IP, OS, etc.) slot in without renaming.
The SQL layer uses Update* per architect guidance on bitwarden/server#7302;
the Bump* SPs in this codebase are legacy and not being extended. The
extensibility note lives on IUpdateDeviceLastActivityCommand with short
pointers from the SP, repo, and cache.
Cache key prefix changes from device:data: to device:last-activity: — safe
because the cache is only a write-suppression optimization (SP guards ensure
correctness) and entries TTL out within 24h.
Migration renamed to 2026-05-14 to reflect the rewrite.
* PM-37166 - Add UTF-8 BOM to device last activity cache files
Aligns file encoding with the repo's .editorconfig (charset = utf-8-bom for .cs) so dotnet format --verify-no-changes passes.
* PM-37166 - Compare LastActivityDate at second precision in device creation test
GetManyByUserIdWithDeviceAuth_ReturnsLastActivityDate_ForNewDeviceAsync was
flaking on SqlServer: Dapper binds DateTime params as legacy `datetime`
(~3.33ms granularity), so the entity initializer's UtcNow can be rounded a
few ms earlier than the in-memory `beforeCreation` capture, making a strict
>= comparison occasionally false. Truncate both sides to the second to
absorb that drift while still rejecting stale or defaulted values.
* PM-37166 - Rename Device.ClientVersion EF migration
Renames migration class/files from AddDeviceClientVersionRefactorDeviceDataBump
to AddDeviceClientVersion to drop stale "Bump" terminology and the misleading
"RefactorDeviceData" prefix. The EF migration only adds the ClientVersion
column; the BumpData -> UpdateLastActivity SP refactor lives in MSSQL .sql
files and has no EF representation.
* PM-37166 - Document null-is-no-op semantics for ClientVersion on IUpdateDeviceLastActivityCommand
Tighten the interface-level summary and add a <param> note clarifying that
a null clientVersion is treated as "no opinion" and will not clear an
existing stored value.
* PM-37166 - Regenerate Device.ClientVersion EF migration on post-#7634 baseline
PR #7634 merged AddLastApiKeyRotationDateToUserTable into main while this
branch was open. The prior AddDeviceClientVersion migration's frozen model
snapshot (its .Designer.cs) was generated before that PR landed, so it did
not include User.LastApiKeyRotationDate. Applying migrations incrementally
against that stale snapshot would produce an inconsistent model graph.
Regenerated AddDeviceClientVersion on top of the merged-from-main baseline
so the new .Designer.cs files include both columns. The migration body
itself still only adds Device.ClientVersion; the top-level
DatabaseContextModelSnapshot.cs files were already correct from git's
three-way merge.
New timestamps (20260514192xxx) come after the User migration
(20260514011xxx), preserving migration order.
* PM-37166 - util/Migrator/DbScripts/2026-05-14_00_AddDeviceClientVersionAndUpdateLastActivitySp.sql - fix wrong comment
* PM-37166 - Bump Device.ClientVersion column width from 20 to 43
43 is the upper bound of Version.ToString() for any input parseable by
Version.TryParse — four Int32 components (Int32.MaxValue = 10 digits)
joined by 3 dots. Sizing to the type's mathematical max prevents
SQL Server error 8152 on malformed/hostile Bitwarden-Client-Version
headers without paying the cost of normalization at the call sites.
Real Bitwarden CalVer (YYYY.M.B) remains well within bounds at ~9 chars.
- Device.cs [MaxLength] + entity doc comment
- SSDT table + 4 stored procedures
- Cloud migration ALTER TABLE + SP parameters
- EF migrations regenerated for MySQL / Postgres / SQLite
* PM-37166 - Defer dropping old single-column UpdateLastActivityDate SPs to follow-up
Server and DB deploys are decoupled, so dropping the old SPs in the same migration that
introduces the new combined ones would break server rollback. Per discussion on PR #7632:
- Remove DROP PROCEDURE statements from the migration; replace with a note explaining the deferral.
- Restore the old Device_UpdateLastActivityDate{ById,ByIdentifierUserId}.sql files in src/Sql/dbo
so the SSDT source-of-truth stays aligned with deployed schema (EDD).
A follow-up ticket will drop the old SPs and delete the .sql files together once we're
confident no deployed server version still calls them.
* PM-37166 - Pass @LastActivityDate into Device_UpdateLastActivity SPs
Bitwarden convention is to compute timestamps in the application layer
and pass them as DATETIME2(7) params, not call GETUTCDATE() inside SPs.
Dapper repo now computes DateTime.UtcNow locally (matching the EF repo
and UserRepository.cs precedent) and passes LastActivityDate through.
* Completed grouping of feature flags by team.
* Completed grouping feature flags by team.
* Remove email delay feature flag
* Removed feature flag
* Fixed reference.
* Remove flag after merge.
* Removed flag from server.
* Removed feature flag from server
* Remove new device verification feature flag.
* Removed unnecessary using.
* Remove feature flag from Constants
* feat(newDeviceVerification) : Initial update to email
* fix : email copying over extra whitespace when using keyboard short cuts
* test : Fixing tests for new device verificaiton email format
feat(NewDeviceVerification) :
* Created database migration scripts for VerifyDevices column in [dbo].[User].
* Updated DeviceValidator to check if user has opted out of device verification.
* Added endpoint to AccountsController.cs to allow editing of new User.VerifyDevices property.
* Added tests for new methods and endpoint.
* Updating queries to track [dbo].[User].[VerifyDevices].
* Updated DeviceValidator to set `User.EmailVerified` property during the New Device Verification flow.
feat(NewDeviceVerification) :
Added constat for the cache key in Bit.Core because the cache key format needs to be shared between the Identity Server and the MVC Admin project.
Updated DeviceValidator class to handle checking cache for user information to allow pass through.
Updated and Added tests to handle new flow.
* feat(BaseRequestValidator):
Add global setting for new device verification.
Refactor BaseRequestValidator enabling better self-documenting code and better single responsibility principle for validators.
Updated DeviceValidator to handle new device verification, behind a feature flag.
Moved IDeviceValidator interface to separate file.
Updated CustomRequestValidator to act as the conduit by which *Validators communicate authentication context between themselves and the RequestValidators.
Adding new test for DeviceValidator class.
Updated tests for BaseRequestValidator as some functionality was moved to the DeviceValidator class.
