8000 PM-12565: Add settings badges for account setup steps by matt-livefront · Pull Request #972 · bitwarden/ios · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

PM-12565: Add settings badges for account setup steps #972

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

Merged
merged 2 commits into from
Sep 26, 2024

Conversation

matt-livefront
Copy link
Collaborator
@matt-livefront matt-livefront commented Sep 25, 2024

🎟️ Tracking

PM-12563 - Add badge indicator to bottom navigation for missing autofill setup
PM-12564 - Add badge indicator to bottom nav for missing unlock method setup
PM-12565 - Implement badge count logic

📔 Objective

Adds a badge to the settings tab indicating how many account setup steps remain. These will be added if the user chooses to set up autofill or vault unlock at a later point from the onboarding flow. Once they enable autofill or a vault unlock method, the corresponding badge will be removed.

📸 Screenshots

Screenshot 2024-09-25 at 10 31 53 AM

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 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

Copy link
codecov bot commented Sep 25, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.80%. Comparing base (c20c8b3) to head (d8d36d2).
Report is 1 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #972      +/-   ##
==========================================
+ Coverage   88.77%   88.80%   +0.02%     
==========================================
  Files         638      638              
  Lines       40129    40180      +51     
==========================================
+ Hits        35625    35680      +55     
+ Misses       4504     4500       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor
github-actions bot commented Sep 25, 2024

Logo
Checkmarx One – Scan Summary & Details7e0fe1aa-a8ef-4c7f-8a22-929cd2a1c76f

No New Or Fixed Issues Found


// Kick off this task in init so that the tab bar badge will be updated immediately when
// the tab bar is shown vs once the user navigates to the settings tab.
badgeUpdateTask = Task { @MainActor [weak self] in
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just for my understanding, whats the benefit of storing this task in a variable vs just kicking off the Task in the init?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Storing a reference to the task allows us to cancel it when the processor goes away (e.g. when you switch accounts or logout, etc).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, thanks!

phil-livefront
phil-livefront previously approved these changes Sep 25, 2024
Copy link
Collaborator
@phil-livefront phil-livefront left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Very clean.

@matt-livefront matt-livefront merged commit 9b78dfc into main Sep 26, 2024
9 checks passed
@matt-livefront matt-livefront deleted the matt/PM-12565-settings-badges branch September 26, 2024 15:41
Comment on lines +1525 to +1531
try await updateSettingsBadgePublisher(userId: userId)
}

func setAccountSetupVaultUnlock(_ vaultUnlockSetup: AccountSetupProgress?, userId: String?) async throws {
let userId = try userId ?? getActiveAccountUserId()
appSettingsStore.setAccountSetupVaultUnlock(vaultUnlockSetup, userId: userId)
try await updateSettingsBadgePublisher(userId: userId)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 @matt-livefront these methods are currently called in loginWithMasterPassword so potentially if updateSettingsBadgePublisher throws then loginWithMasterPassword would fail which is not correct IMO. The badge update is a secondary effect but that shouldn't block the flow of logging in.
I think the updateSettingsBadgePublisher should not throw and just wrap the code in a do...catch and log any error to the errorReporter so it doesn't affect any caller flows.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, great point! I have a fix here: #988.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0