Update biometric comparison language #11296
Conversation
| def identity_verified_with_facial_match? | ||
| FACIAL_MATCH_IDV_LEVELS.include?(active_profile&.idv_level) |
There was a problem hiding this comment.
just while I'm here, maybe for a future PR, wondering if if we could have moved this constant to the Profile class, and then delegate via something like active_profile&.verified_with_facial_match?
There was a problem hiding this comment.
i added it as a task -- will take care of this in a future PR!
| @@ -78,7 +78,7 @@ def formatted_ipp_due_date | |||
| I18n.l(user.pending_in_person_enrollment.due_date, format: :event_date) | |||
| end | |||
|
|
|||
| def formatted_nonbiometric_idv_date | |||
| def formatted_nonfacial_match_idv_date | |||
There was a problem hiding this comment.
in other parts of the project we call this "legacy IDV", do you think that would be a good rename here too?
There was a problem hiding this comment.
hm i agree that nonfacial_match is not great!
but i am a bit torn about what to call about our original idv offering. i think the term "legacy" isn't great because a lot of existing integrations are not going to update. in other circumstances i have used "base idv" (rather than defining it as a negation of a facial match). i am happy to update this to legacy to be more in line with what we currently have, but am curious if you (and others) have an opinion about updating that language overall
There was a problem hiding this comment.
I don't feel too strongly, but since it looks to me like this is an internal method used for rendering in a view, the choices partner make shouldn't affect it too much? But "Base IDV" makes sense too, I was just trying to match the descriptions we got from Product with "Legacy IDV"
There was a problem hiding this comment.
ah okay, didn't realize there was direct guidance on this from product, thanks! will update to legacy
There was a problem hiding this comment.
updated in b1b77c3 -- thanks for flagging!
| @@ -47,7 +47,7 @@ def show | |||
| end | |||
| end | |||
|
|
|||
| context 'SP does not require biometric_comparison' do | |||
| context 'SP does not require facial_match' do | |||
There was a problem hiding this comment.
❤️ appreciate you updating the spec descriptions as well!
Sgtpluck
force-pushed
the
dmm/update-biometric-comparison-language
branch
from
5a89cb4
to
bcb4474
Compare
Sgtpluck
force-pushed
the
dmm/update-biometric-comparison-language
branch
from
b1b77c3
to
9c390d5
Compare
|
I know I'm late to the party here but if you wanted to change the SpBiometricUpgradedProfile class you can go ahead and rename it and create a new table and remove the old one. There are currently no records in it. There is an accompanied report that would need adjusted. idv-legacy-conversion-report. Up to you. |
|
@MrNagoo oh thanks for those details, that's great to hear! i will try to get that done asap. |
* changelog: Internal, Identity Proofing, Update code to reflect program language
* changelog: Internal, Identity Proofing, Update code to reflect program language
🎫 Ticket
Link to the relevant ticket:
https://gitlab.login.gov/lg-people/Melba/backlog-fy24/-/issues/116
🛠 Summary of changes
This change is a first pass at removing most of the "biometric comparison" phrasing that is found in our code base. Since we are moving away from using that terminology, it will help if our code base isn't littered with references to it!
This change includes many things, but highlights are:
facial_matchas a requirement rather thanbiometric_comparison?facial_match?method rather thanbiometric_comparison?Things that were not changed, because it's not worth it or they need more specific PRs:
bio=preferredandbio=required.biois in them in a way that we can't extract, it seemed fine to keep it that waylocales/*.ymlfiles (i wasn't sure if there were any considerations i should be aware of before changing those files)SpUpgradedBiometricProfilemodel -- was curious about people's thought about this new model. matt hinz suggetsted renaming the model and usingself.table_name = :sp_upgraded_biometric_profilesbut wanted to hear if anyone had strong opinions for or against.More work that is out of scope but related:
vtr, a la idv_helper. this needs to be updated, since going forward we are deprecating vectors of trust.Feedback wanted!
Thank you for your time and attention 🙏 If/when it gets approved, I will definitely alert folks in app-dev before and after, to try to minimize horrible merge conflicts.