[PM-33951] feat(admin-console): Add bulk confirmation and pending auto-confirmation#7661
[PM-33951] feat(admin-console): Add bulk confirmation and pending auto-confirmation#7661JaredScar wants to merge 5 commits into
Conversation
…ion methods for organization users - Implemented ConfirmManyOrganizationUsersAsync to confirm multiple users in a single operation. - Added GetManyPendingAutoConfirmAsync to retrieve users pending automatic confirmation. - Created stored procedures for bulk confirmation and fetching pending users. - Updated relevant repository interfaces and implementations across Dapper and Entity Framework.
🤖 Bitwarden Claude Code ReviewOverall Assessment: APPROVE This PR adds the database layer for bulk organization user confirmation and pending auto-confirm reads, split from PR #7527 to keep change size manageable. It introduces two stored procedures ( Code Review DetailsNo findings. The implementation follows established patterns in this codebase:
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7661 +/- ##
==========================================
- Coverage 60.43% 60.39% -0.04%
==========================================
Files 2140 2140
Lines 94622 94683 +61
Branches 8443 8446 +3
==========================================
Hits 57188 57188
- Misses 35429 35490 +61
Partials 2005 2005 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
r-tome
left a comment
There was a problem hiding this comment.
Claude pointed out a few things to fix. Let me know when to review this again
|
There are similar database changes in PR 7527, as well as this one. Do both PR's need a review from dbops or only this one? |
Valid question! @mkincaid-bw -- Sorry for the confusion. @eliykat suggested we split up that PR into smaller PRs like this one that we merge first, then that original PR will be smaller and easier to review since that big chunk of code are broken into pieces. Theoretically speaking, this should be the only one DB ops needs to worry about 😄 |
…ationUsersAsync to IReadOnlyCollection - Updated the ConfirmManyOrganizationUsersAsync method signature in the IOrganizationUserRepository and its implementations to use IReadOnlyCollection instead of IEnumerable for better performance and clarity. - Adjusted related repository methods in both Dapper and Entity Framework implementations to reflect this change. - Added unit tests to ensure the new implementation behaves as expected, including scenarios for mixed batches and idempotency.
There was a problem hiding this comment.
Thanks @JaredScar for splitting this to a separate PR - I cannot tell you how much easier it is to review smaller PRs.
Aside from my comments below, please check the CI runs:
- db integration test is failing - potentially faulty prod or test logic
- db validation is failing - this ensures that the migration scripts match the
src/Sqlfiles - validate new migration naming and order - this is failing because later migrations have overtaken you and you need to bump the dates on your script
More info available in each of the runs, or hit me up on Slack if you have questions.
EDIT: please also add more info to your PR description, e.g.
This PR contains the database changes needed for #7527, split to their own PR to manage PR size.
The PR link is particularly useful to understand what's going on.
…s part of database cleanup.
…dingAutoConfirm methods - Introduced ConfirmManyOrganizationUsersTests to validate the confirmation of multiple organization users, ensuring only accepted users are confirmed and idempotency is maintained. - Added GetManyPendingAutoConfirmTests to verify retrieval of pending auto-confirm users, ensuring only eligible users are returned based on specific criteria. - Removed duplicate test implementations from OrganizationUserRepositoryTests to maintain clarity and organization in the test suite.
|
| @@ -0,0 +1,43 @@ | |||
| CREATE PROCEDURE [dbo].[OrganizationUser_ConfirmByIds] | |||
There was a problem hiding this comment.
This stored proc name does not follow our naming standards (I realize we have OrganizationUser_ConfirmById as well, which I previously approved but should not have). It should start with OrganizationUser_Update..., and perhaps be named something like OrganizationUser_UpdateStatusKey, or something to that effect.
| WHERE | ||
| [OrganizationId] = @OrganizationId | ||
| AND [Status] = 1 -- Accepted | ||
| AND [Type] = 0 -- User |
There was a problem hiding this comment.
❓According to src/Core/AdminConsole/Enums/OrganizationUserType.cs, Type 0 is Owner and Type 2 is User. Is the value for Type supposed to be User or Owner?
There was a problem hiding this comment.
Good catch! This is also the cause of the test failure, so good to know our tests are working :D
eliykat
left a comment
There was a problem hiding this comment.
My changes have been addressed, I can approve once @mkincaid-bw is happy and CI checks are passing.
| public class ConfirmManyOrganizationUsersTests | ||
| { | ||
| [Theory, DatabaseData] | ||
| public async Task ConfirmManyOrganizationUsersAsync_MixedBatch_ReturnsOnlyAcceptedIds( |
There was a problem hiding this comment.
Also assert that RevisionDate is updated. The simplest way is to capture var before = DateTime.UtcNow before the call and assert updated.RevisionDate >= before afterwards.
A more thorough alternative (which I'd lean toward but not a blocker!) is to pass RevisionDate in as a parameter to the repository method, as we do for example in GroupRepository.DeleteUserAsync. This lets the caller (the command/service) generate the timestamp via TimeProvider, the repository becomes a pure persistence layer, and the test can assert exact equality. Example:
There was a problem hiding this comment.
Bump the date on the migration file names
| WHERE | ||
| OU.[Status] = 1 -- Accepted | ||
|
|
||
| EXEC [dbo].[User_BumpAccountRevisionDateByOrganizationUserIds] @UpdatedIds |
There was a problem hiding this comment.
The singular update sproc checks if any rows are updated before calling this. Might be worth it to be consistent and add that here too.
| EXEC [dbo].[User_BumpAccountRevisionDateByOrganizationUserIds] @UpdatedIds | |
| SET @RowCount = @@ROWCOUNT; | |
| IF @RowCount > 0 | |
| BEGIN | |
| EXEC [dbo].[User_BumpAccountRevisionDateByOrganizationUserIds] @UpdatedIds | |
| END |



🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-33951
📔 Objective
This PR contains the database changes needed for #7527, split to their own PR to manage PR size.