-
Notifications
You must be signed in to change notification settings - Fork 926
[PM-28468] Updated validation and navigation for MigrateToMyItems #6279
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Great job! No new security vulnerabilities introduced in this pull request |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #6279 +/- ##
==========================================
- Coverage 85.53% 85.49% -0.05%
==========================================
Files 761 761
Lines 54522 54569 +47
Branches 7833 7856 +23
==========================================
+ Hits 46636 46653 +17
- Misses 5169 5192 +23
- Partials 2717 2724 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Claude finished @aj-rosado's task in 4m 40s —— View job Code Review CompleteI've reviewed PR #6279 with a focus on the validation and navigation logic for the MigrateToMyItems flow. Overall Assessment: REQUEST CHANGESThe implementation follows proper architectural patterns with excellent test coverage, but requires addressing a critical user experience issue before merge. Critical FindingMissing Migration State Persistence ( The
Recommendation: Add persistence tracking before removing draft status: // In SettingsDiskSource or AuthDiskSource
fun storeMigrationAttempted(userId: String, organizationId: String)
fun hasMigrationBeenAttempted(userId: String, organizationId: String): BooleanCheck this in Questions Requiring Clarification
Positive Findings
RecommendationAddress the persistence issue (Finding 1) before removing draft status. The current TODO at |
| cipherListView.any { it.organizationId == null } | ||
| } | ||
|
|
||
| // Updates [shouldMigratePersonalVaultFlow]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⛏️ Don't really need this comment. The function name is descriptive enough.
| val orgId = policyManager.getPersonalOwnershipPolicyOrganizationId() | ||
| val orgName = authRepository.userStateFlow.value | ||
| ?.activeAccount | ||
| ?.organizations | ||
| ?.firstOrNull { it.id == orgId } | ||
| ?.name |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❓ Passing args makes for a simpler ViewModel; specifically in regards to handling scenarios when either orgId or orgName are null. Is there a reason why this approach is taken instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed this quite a bit from original idea. RootNavViewModel only verifies if it should navigate from the shouldMigratePersonalVaultFlow, not having any info regarding the org that should do the migration.
This was changed because if the vault was updated on a different client, the migration flow would still be displayed as it would not check with the most synced data. Now we are syncing before displaying the screen to make sure we are not displaying the screen unless it is needed.
This being said, I agree that if we could pass the parameters would simplify the VM, not sure about a good way to achieve it, only that I can think about is the flow having the Organization object?
| val shouldMigrate = policyManager | ||
| .getActivePolicies(PolicyTypeJson.PERSONAL_OWNERSHIP) | ||
| .any() && | ||
| featureFlagManager.getFeatureFlag(FlagKey.MigrateMyVaultToMyItems) && | ||
| connectionManager.isNetworkConnected && | ||
| cipherList.any { it.organizationId == null } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
⛏️ 🎨 Not a mandatory change request, but some of this duplication could be eliminated if userShouldMigrate() is changed to accept hasPersonalItems as a lambda.
private fun userShouldMigrateVault(
hasPersonalItems: () -> Boolean,
) : Boolean {
return connectionManager.isNetworkConnected &&
featureFlagManager.getFeatureFlag(...) &&
policyManager.getActivePolicies(...).any() &&
hasPersonalItems
}
private fun verifyAndUpdateIfUserShouldMigrateVaultToMyItems(
cipherList: List<Cipher>,
) {
mutableShouldMIgratePersonalVaultFlow.update {
userShouldMigrateVault {
cipherList.any { it.organizationId == null }
}
}
}There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would also be a performance improvement since it would short-circuit before attempting to iterate over the entire cipher collection when any of the preceding conditions are false.
…arameter to MigrateToMyItems
…ation # Conflicts: # app/src/test/kotlin/com/x8bit/bitwarden/ui/vault/feature/migratetomyitems/MigrateToMyItemsViewModelTest.kt

🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-28468
📔 Objective
Added an observable flow that will be updated after a sync and if the conditions are met will trigger the RootNavViewModel to display the
MigrateToVaultItemsflow.Only after a sync in order to ensure we are not displaying the migration screen with stale data.
The conditions for the navigation are
VAULT_OWNERSHIPpolicy is activeorganizationId)This is only in draft, missing all the unit tests and some manual tests
⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes