-
Notifications
You must be signed in to change notification settings - Fork 11
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
Freemium PIR: Prerequisite Checks and Scheduled Scans #3178
Freemium PIR: Prerequisite Checks and Scheduled Scans #3178
Conversation
func disableAndDeleteForAllUsers() | ||
func isPrivacyProEnabled() -> Bool |
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.
Methods unused, removing.
...okerProtection/Sources/DataBrokerProtection/Scheduler/DataBrokerProtectionAgentManager.swift
Outdated
Show resolved
Hide resolved
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.
Mostly looks great, love some of the tangental improvements to the code base this includes. Just one thing, the description says "Adding debug menu commands and the associated hierarchy of XPC calls" but I don't see the xpc calls, I might be missing it though
...okerProtection/Sources/DataBrokerProtection/Scheduler/DataBrokerProtectionAgentManager.swift
Outdated
Show resolved
Hide resolved
...taBrokerProtection/Sources/DataBrokerProtection/Utils/DataBrokerProtectionAgentStopper.swift
Outdated
Show resolved
Hide resolved
...es/DataBrokerProtection/Tests/DataBrokerProtectionTests/DataBrokerExecutionConfigTests.swift
Outdated
Show resolved
Hide resolved
...okerProtection/Sources/DataBrokerProtection/Scheduler/DataBrokerProtectionAgentManager.swift
Outdated
Show resolved
Hide resolved
.../DataBrokerProtection/Sources/DataBrokerProtection/Scheduler/DataBrokerExecutionConfig.swift
Show resolved
Hide resolved
@@ -194,23 +222,23 @@ extension DataBrokerProtectionAgentManager: DataBrokerProtectionAgentAppEvents { | |||
|
|||
userNotificationService.requestNotificationPermission() | |||
fireMonitoringPixels() | |||
queueManager.startImmediateOperationsIfPermitted(showWebView: false, operationDependencies: operationDependencies) { [weak self] errors in | |||
queueManager.startImmediateScanOperationsIfPermitted(showWebView: false, operationDependencies: operationDependencies) { [weak self] errors in |
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.
We discussed over MM, but posting here for prosperity:
- Previously (i.e. prior to this PR), things higher up the stack (agent manager, queueManager) would tell stuff lower (e.g. DataBrokerOperation) to run "immediate operations" when a profile is saved. I.e. it was non specific about what immediate operations included
- Now, they explicitly tell it only to do scans (and are now specific for the kinds of scans)
- This is enforced through DataBrokerOperation.filterAndSortOperationsData()
- Ignoring freemium, this actually represents mostly no change in practice for subscribed users, because for manual scans we never actually ran opt outs immedtiely anyway (which I think might actually be an implementation mistake, but seems to be the observed behavior)
So now instead AgentManager is explicit about what immediate operations includes, which I think is an improvement and where the decision should be made.
But the main reason I mention it is because I think that original behavior is a bug and we do want opt outs to run immediately after the scans, so it's worth discussing if we want to codify it like this.
I think we do, because of how I think we should fix that bug, which is on the completion for the manual scans, in agent manager, call the thing on queuemanager, rather than waiting for the scheduler to do it. But there's a slight asterisk of we'd need to move something around in how the QueueManager handles completions. atm it would break some stuff cos it calls the completion before clearing errors
The alternative approach is to somehow add the opt outs to the queue as we make them. If it was easy to do I'd seriously consider doing it, but as it would be much much harder and be a big increase in implementation complexity lower down the stack solely for making AgentManager slightly clearer.
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.
Thanks for capturing this here @THISISDINOSAUR . You set a really good standard for prosperity, it’s great.
Thanks for the review @THISISDINOSAUR , feedback addressed (commit has mostly renaming changes). Apologies on the inaccurate description - I had a change included that I removed before opening the PR, but I forgot to remove that line. Description updated! |
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.
LGTM! I have opt out jobs in my DB (but no actual signs of them being run), I assume this is expected?
IMO this isn't ideal, but then the way we create those jobs I think is not ideal anyway and well beyond the scope of this PR to change
Thanks @THISISDINOSAUR . Yes, we still create opt-out jobs as if a user subscribes we want to then run them. However, when the user is Freemium, they are not run. |
…ountManager (#3197) Task/Issue URL: https://app.asana.com/0/1201621853593513/1208197280287450/f CC: @miasma13 **Description**: As an outcome of [this](#3178 (comment)) discussion, I have refactored `FreemiumPIRUserStateManager` to remove it’s dependency on `AccountManager`. This includes the removal of the `isActiveUser` computed property.
Task/Issue URL: https://app.asana.com/0/1206488453854252/1208052452067290/f **Description**: This PR (_to a feature branch_) implements two Freemium PIR aspects: 1. When checking PIR prerequisites (see `GateKeeper..` `AgentStopper…` types), it accounts for Freemium PIR users 2. When running scheduled operations, it only performs scans, and not opt-outs
…ountManager (#3197) Task/Issue URL: https://app.asana.com/0/1201621853593513/1208197280287450/f CC: @miasma13 **Description**: As an outcome of [this](#3178 (comment)) discussion, I have refactored `FreemiumPIRUserStateManager` to remove it’s dependency on `AccountManager`. This includes the removal of the `isActiveUser` computed property.
Task/Issue URL: https://app.asana.com/0/1206488453854252/1208052452067290/f **Description**: This PR (_to a feature branch_) implements two Freemium PIR aspects: 1. When checking PIR prerequisites (see `GateKeeper..` `AgentStopper…` types), it accounts for Freemium PIR users 2. When running scheduled operations, it only performs scans, and not opt-outs
…ountManager (#3197) Task/Issue URL: https://app.asana.com/0/1201621853593513/1208197280287450/f CC: @miasma13 **Description**: As an outcome of [this](#3178 (comment)) discussion, I have refactored `FreemiumPIRUserStateManager` to remove it’s dependency on `AccountManager`. This includes the removal of the `isActiveUser` computed property.
Task/Issue URL: https://app.asana.com/0/1206488453854252/1208052452067290/f **Description**: This PR (_to a feature branch_) implements two Freemium PIR aspects: 1. When checking PIR prerequisites (see `GateKeeper..` `AgentStopper…` types), it accounts for Freemium PIR users 2. When running scheduled operations, it only performs scans, and not opt-outs
…ountManager (#3197) Task/Issue URL: https://app.asana.com/0/1201621853593513/1208197280287450/f CC: @miasma13 **Description**: As an outcome of [this](#3178 (comment)) discussion, I have refactored `FreemiumPIRUserStateManager` to remove it’s dependency on `AccountManager`. This includes the removal of the `isActiveUser` computed property.
Task/Issue URL: https://app.asana.com/0/1206488453854252/1208052452067290/f
Description: This PR (to a feature branch) implements two Freemium PIR aspects:
GateKeeper..
AgentStopper…
types), it accounts for Freemium PIR usersThese aspects are implemented by:
FreemiumPIRUserState
type to check freemium state (if user has onboarded to freemium, and has no subscription, they are freemium).scheduledScan
operation type (and renaming an existing one)Testing Prerequisites
DataBrokerProtectionQueueManager
line 141DataBrokerProtectionQueueManager
line 150Steps to test this PR:
Test 1 - Checking initial scan works
Test 1 - Checking background scan does not perform opt-outs
Definition of Done:
—
Internal references:
Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation