-
Notifications
You must be signed in to change notification settings - Fork 223
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
MNTOR-3863 and MNTOR-3840 - Fix user dashboard state for manual removal flag #5473
Changes from all commits
fde294e
157a21d
1dbc11f
2c60b47
cf67902
dec8f32
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,6 +6,8 @@ import { OnerepScanResultDataBrokerRow } from "knex/types/tables"; | |
import { BreachDataTypes } from "../universal/breach"; | ||
import { RemovalStatusMap } from "../universal/scanResult"; | ||
import { SubscriberBreach } from "../../../utils/subscriberBreaches"; | ||
import { DataBrokerRemovalStatusMap } from "../universal/dataBroker"; | ||
import { FeatureFlagName } from "../../../db/tables/featureFlags"; | ||
|
||
export type DataPoints = { | ||
// shared | ||
|
@@ -96,6 +98,7 @@ export const dataClassKeyMap: Record<keyof DataPoints, string> = { | |
export function getDashboardSummary( | ||
scannedResults: OnerepScanResultDataBrokerRow[], | ||
subscriberBreaches: SubscriberBreach[], | ||
enabledFeatureFlags?: FeatureFlagName[], | ||
): DashboardSummary { | ||
const summary: DashboardSummary = { | ||
dataBreachTotalNum: 0, | ||
|
@@ -204,15 +207,22 @@ export function getDashboardSummary( | |
r.status === RemovalStatusMap.WaitingForVerification) && | ||
!isManuallyResolved; | ||
|
||
// TODO: Waiting for criteria for data brokers under maintenance to be determined | ||
// const isRemovalUnderMaintenance = | ||
// r.broker_status === DataBrokerRemovalStatusMap.RemovalUnderMaintenance; | ||
// TODO: MNTOR-3886 - Remove EnableRemovalUnderMaintenanceStep feature flag | ||
// If the flag is disabled, include the data. | ||
// If the flag is enabled, include the data only if the broker status is not | ||
const isRemovalUnderMaintenance = | ||
r.broker_status === DataBrokerRemovalStatusMap.RemovalUnderMaintenance; | ||
|
||
// The condition ensures that removal under maintenance is only considered when the flag is enabled. | ||
/* c8 ignore next 3 */ | ||
const countRemovalUnderMaintenanceData = | ||
Comment on lines
+213
to
+218
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A bit of a nit I guess, but it took me a while to understand the logic below because of the In the end, isn't a data broker under maintenance just not in progress? i.e. instead of this code and the additional const isInProgress =
(r.status === RemovalStatusMap.OptOutInProgress ||
r.status === RemovalStatusMap.WaitingForVerification) &&
- !isManuallyResolved;
+ !isManuallyResolved && (
+ // TODO: MNTOR-3886 - Remove EnableRemovalUnderMaintenanceStep feature flag
+ !enabledFeatureFlags?.includes("EnableRemovalUnderMaintenanceStep") ||
+ r.broker_status !== DataBrokerRemovalStatusMap.RemovalUnderMaintenance
+ ); There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Vinnl I think that the |
||
!enabledFeatureFlags?.includes("EnableRemovalUnderMaintenanceStep") || | ||
!isRemovalUnderMaintenance; | ||
|
||
if (isInProgress) { | ||
// TODO: Waiting for criteria for data brokers under maintenance to be determined | ||
// if (!isRemovalUnderMaintenance) { | ||
summary.dataBrokerInProgressNum++; | ||
// } | ||
if (countRemovalUnderMaintenanceData) { | ||
summary.dataBrokerInProgressNum++; | ||
} | ||
} else if (isAutoFixed) { | ||
summary.dataBrokerAutoFixedNum++; | ||
} else if (isManuallyResolved) { | ||
|
@@ -234,14 +244,13 @@ export function getDashboardSummary( | |
summary.allDataPoints.familyMembers += r.relatives.length; | ||
|
||
if (isInProgress) { | ||
// TODO: Waiting for criteria for data brokers under maintenance to be determined | ||
// if (!isRemovalUnderMaintenance) { | ||
summary.inProgressDataPoints.emailAddresses += r.emails.length; | ||
summary.inProgressDataPoints.phoneNumbers += r.phones.length; | ||
summary.inProgressDataPoints.addresses += r.addresses.length; | ||
summary.inProgressDataPoints.familyMembers += r.relatives.length; | ||
summary.dataBrokerInProgressDataPointsNum += dataPointsIncrement; | ||
// } | ||
if (countRemovalUnderMaintenanceData) { | ||
summary.inProgressDataPoints.emailAddresses += r.emails.length; | ||
summary.inProgressDataPoints.phoneNumbers += r.phones.length; | ||
summary.inProgressDataPoints.addresses += r.addresses.length; | ||
summary.inProgressDataPoints.familyMembers += r.relatives.length; | ||
summary.dataBrokerInProgressDataPointsNum += dataPointsIncrement; | ||
} | ||
} | ||
|
||
// for fixed data points: email, phones, addresses, relatives, full name (1) | ||
|
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.
Is there any reason to leave this optional? Feels like everywhere we use this function, we want to take feature flags into account as well to make sure that under-maintenance brokers aren't counted, right?
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.
@Vinnl I made it optional because we may remove the flag at some point, and it was tedious having to update all of the test files and also making changes to the function in
actions.tsx
was throwing an error for me.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 was the only part of the experience that was flagged by QA, I don't think it would show in the Welcome view, AFAIK a data broker wouldn't immediately be under
removal_under_maintenance
it would take some time to become such.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 added it to those files anyways: 1dbc11f
I can request for QA to check out those views and verify that the calculations are accurate with the flag.
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.
Hmm OK, if we're not simply passing it everywhere, then we'd have to judge per call site whether it's necessary to consider under-maintenance status, so I manually visited all the call sites and found the following two that I think would also need updating?
ResolutionContainer
seems to refer todataBrokerInProgressDataPointsNum
at least - I think for the "In progress" column here?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 going through the trouble of visiting the call sites! I can ping QA to double check those touchpoints.
Added the flag to
ResolutionContainer
here: 2c60b47and to Plus monthly activity email: cf67902
It's really tedious wrapping a feature flag around this feature precisely because it touches so many parts of the experience :\ This feature is relatively low risk though, since the altered part of the feature is wrapped behind the flag.