-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add required information to DBP NA<->FE API for removal timeline support #3268
Conversation
addresses: extractedProfile.addresses?.map {DBPUIUserProfileAddress(addressCityState: $0) } ?? [], | ||
alternativeNames: extractedProfile.alternativeNames ?? [String](), | ||
relatives: extractedProfile.relatives ?? [String](), | ||
foundDate: optOutJobData.createdDate.timeIntervalSince1970, |
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 don't love that this information is gained from the optOutJobData, but what you can't see from looking just at this struct is if you see further above is that all these extracted profiles are taken from the opt out jobs the first place.
So I don't think there's anything I can do about it outside of making more serious challenges to our data architecture (which I'd love to do. In making this PR I really noticed how my issues with the DB scheme trickle all the way up to cause a lot of the things I don't like in the UI mapping stuff)
} | ||
|
||
extension DBPUIDataBrokerProfileMatch { | ||
init(optOutJobData: OptOutJobData, |
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 don't really like how long this construct got, but didn't have any nice ideas to simplify it, so taking suggestions!
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.
Tried rewriting this a different way, but it was mostly just different, not necessarily better. However, leaving one suggestion.
@@ -22,36 +22,6 @@ import os.log | |||
|
|||
struct MapperToUI { | |||
|
|||
func mapToUI(_ dataBroker: DataBroker, extractedProfile: ExtractedProfile) -> DBPUIDataBrokerProfileMatch { |
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.
All this has now moved into constructors on the individual UI objects
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.
Nice one!
@@ -74,21 +44,39 @@ struct MapperToUI { | |||
totalScans: totalScans, | |||
scannedBrokers: partiallyScannedBrokers) | |||
|
|||
let matches = mapMatchesToUI(brokerProfileQueryData) | |||
let matches = mapMatchesToUI(withoutDeprecated) | |||
|
|||
return .init(resultsFound: matches, scanProgress: scanProgress) | |||
} | |||
|
|||
private func mapMatchesToUI(_ brokerProfileQueryData: [BrokerProfileQueryData]) -> [DBPUIDataBrokerProfileMatch] { |
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 don't like how much this and the maintenance scans function duplicate each other. However I'm also afraid to touch them since there seem to be some subtle differences which I assume are deliberate
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.
Agree.
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.
Nice one @THISISDINOSAUR ! Great work adding tests to the UI model layer 🥳. Left a few comments but nothing blocking. However, I’ll wait to approve until I can test. I ran and the UI just hung. Maybe you can check and if we can confirm it’s only a me issue, I’ll try again.
@@ -135,7 +146,79 @@ struct DBPUIDataBrokerProfileMatch: Codable { | |||
let addresses: [DBPUIUserProfileAddress] | |||
let alternativeNames: [String] | |||
let relatives: [String] | |||
let date: Double? // Used in some methods to set the removedDate or found date | |||
let foundDate: Double |
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.
👍🏼
} | ||
|
||
extension DBPUIDataBrokerProfileMatch { | ||
init(optOutJobData: OptOutJobData, |
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.
Tried rewriting this a different way, but it was mostly just different, not necessarily better. However, leaving one suggestion.
...ckages/DataBrokerProtection/Sources/DataBrokerProtection/Model/DBPUICommunicationModel.swift
Outdated
Show resolved
Hide resolved
if age != extractedProfile.age { | ||
return false | ||
} | ||
|
||
if name != extractedProfile.name { | ||
return false | ||
} | ||
|
||
if !(alternativeNames ?? []).isASubSetOrSuperSetOf(extractedProfile.alternativeNames ?? []) { | ||
return false | ||
} | ||
|
||
if !(addresses ?? []).isASubSetOrSuperSetOf(extractedProfile.addresses ?? []) { | ||
return false | ||
} | ||
|
||
if !(relatives ?? []).isASubSetOrSuperSetOf(extractedProfile.relatives ?? []) { | ||
return false | ||
} |
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.
Prob just a preference, but guard
statements seem to fit this pattern better IMO (where we return true
at the end if all conditions pass). Again, maybe just subjective preference.
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 thought about this and I think I prefer not using guards because to me guard suggests something went wrong or some prerequisite weren't satisfied. I think that is a biased view on my part though and probably not shared universally
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.
Fair, one subjective view -vs- another 😅! Fine with me to stick with what you have.
@@ -22,36 +22,6 @@ import os.log | |||
|
|||
struct MapperToUI { | |||
|
|||
func mapToUI(_ dataBroker: DataBroker, extractedProfile: ExtractedProfile) -> DBPUIDataBrokerProfileMatch { |
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.
Nice one!
@@ -74,21 +44,39 @@ struct MapperToUI { | |||
totalScans: totalScans, | |||
scannedBrokers: partiallyScannedBrokers) | |||
|
|||
let matches = mapMatchesToUI(brokerProfileQueryData) | |||
let matches = mapMatchesToUI(withoutDeprecated) | |||
|
|||
return .init(resultsFound: matches, scanProgress: scanProgress) | |||
} | |||
|
|||
private func mapMatchesToUI(_ brokerProfileQueryData: [BrokerProfileQueryData]) -> [DBPUIDataBrokerProfileMatch] { |
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.
Agree.
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.
Tested and looks good @THISISDINOSAUR ! 👍🏼
# Conflicts: # LocalPackages/DataBrokerProtection/Sources/DataBrokerProtection/UI/DBPUICommunicationLayer.swift
Task/Issue URL: https://app.asana.com/0/1203581873609357/1208164179397484/f
Tech Design URL:
Initial API additions: https://app.asana.com/0/481882893211075/1208203761791777/f
Parent - child api info and matching logic: https://app.asana.com/0/72649045549333/1208303545057273/f
Where to put the matching logic: https://app.asana.com/0/481882893211075/1208325118544624/f
CC:
Description:
Adds four new fields as per the first tech design. Also moves some of the construction of these objects to constructors.
Also removes an old date field that isn't officially in the api, and apparently varied what it was used for. It seemed unused on the native side, and the FE side doesn't know it exist.
It then also adds "parent child" matching logic so we can identify orphaned child records that will never be removed.
Steps to test this PR:
Definition of Done:
Internal references:
Pull Request Review Checklist
Software Engineering Expectations
Technical Design Template
Pull Request Documentation