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.
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.
I don't really like how long this construct got, but didn't have any nice ideas to simplify it, so taking suggestions!
| @@ -22,36 +22,6 @@ import os.log | |||
|
|
|||
| struct MapperToUI { | |||
|
|
|||
| func mapToUI(_ dataBroker: DataBroker, extractedProfile: ExtractedProfile) -> DBPUIDataBrokerProfileMatch { | |||
There was a problem hiding this comment.
All this has now moved into constructors on the individual UI objects
| @@ -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.
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
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