DeadNames

This page discusses how we could move into doing "dead Names" or "preferred Name"

Because Registrant_rl_first and rl_last have been used so long for your legal name. There are twooptions for upgrading.

Considerations

• Rl_First,Rl_last are used hundreds or thousands of places within CM already, and Converting those to be only used soemtimes is impractical and is a more dangerous path to go, because if we miss even one usage, we've leaked the wrong name.
• We may or may not want to store someone's same name twice. (Storage concerns here would be minimal)

New Legal Field and Copy

• Migration: On migration, copy all "rl_first" and "rl_last" fields over to new "legal_first","legal_last".
• Kiosk Interactions: On a kiosk the when reviewing names the kiosk displays the usual "Legal first name","Legal last name" fields as they have been previously. (Populated now from Legal_first,Legal_last). If the rl_first,rl_last match legal_first,legal_last then a unfilled checkbox would be provided: [] I prefer to go by a different name. Which if checked would then show two new input boxes "Preferred Name" which would be populated by the fields rl_first,rl_last. If this checkbox is UN-CHECKED, upon save, the rl_first,rl_last fields would be copied/updated from Legal_first,Legal_last.
• Console Changes:
  • Cashier: The id check section of cashier would show only Legal Name fields (populated from legal_first,legal_last) if the rl_first,rl_last fields matched. If the fields don't match, the system would add the Preferred Name field and populate it from rl_first,rl_last.
  • ViewReg: The Legal Name field would be hidden behind a pII icon the same as phone numbers are, and would have a audit trail applied.
  • AUP: Printed Aup's might need to refer to legal field.
  • No other changes needed
• Advantages:
  • The advantage of this, is that only NEW code, that explicitly has reason to look for the "dead name" of attendees needs to be changed.
• Disadvantages:
• Forever more, we will need to maintain and store two copies of the same name, if the person's preferred name is the same as their legal name.
• The 'rl_first' and 'rl_last' field which many considered the legal name, are no longer actually legal name but instead "Real Name/Preferred Name" and new fields "Legal_first,legal_last" reflect their legal name on ID

New Legal Field and Move

• Migration: On migration, move all "rl_first" and "rl_last" fields over to new "legal_first","legal_last".
• Kiosk Interactions: On a kiosk the when reviewing names the kiosk displays the usual "Legal first name","Legal last name" fields as they have been previously. (Populated now from legal_first, legal_last). If the rl_first,rl_last fields are empty, then a unfilled checkbox would be provided: [] I prefer to go by a different name. Which if checked would then show two new input boxes "Preferred Name" which would be populated by the fields rl_first,rl_last. If this checkbox is UN-CHECKED, or if no data is provided, upon save the rl_first,rl_last fields would be nulled.
• Console Changes:
  • Cashier: The id check section of cashier would show only Legal Name fields (populated from legal_first,legal_last) if the rl_first,rl_last fields were null. If the fields were not null, the system would add the Preferred Name field and populate it from rl_first,rl_last.
  • ViewReg: The Legal Name field would be hidden behind a pII icon the same as phone numbers are, and would have a audit trail applied.
  • ALL OTHER: All other functions forms, fields, database queries, and badge image code would need code modification to find and replace instances of rl_first with a new checker to determine if preferred name field is null.
  • No other changes needed
• Advantages:
  • The advantage of this, is that we only store one copy of the name, no duplicate data will be in the database.
• Disadvantages: This would require a major, intensive code refactor that selectively select from legal_first if rl_first was empty for every instance that rl_first is used. (Same with rl_last/legal_last)

New preferred name field and no copy:

• Migration: On migration a new field called 'preferred name' is created, and no data is copied into it.
• Kiosk Interactions: On a kiosk the when reviewing names the kiosk displays the usual "Legal first name","Legal last name" fields as they have been previously. (Populated now from rl_first,rl_last). If the preferred_name field is empty then a unfilled checkbox would be provided: [] I prefer to go by a different name. Which if checked would then show one new input box "Preferred Name" which would be populated by the fields preferred_name field. Upon save, the rl_first,rl_last fields are saved as always, and the preferred_name field is saved only if not empty.
• Console Changes:
  • Cashier: The id check section of cashier would show only Legal Name fields (populated from rl_first,rl_last) if the preferred_name fields was null. If the preferred_name field was not null, the system would add the Preferred Name field and populate it from preferred_name.
  • ViewReg: The Legal Name field would be hidden behind a pII icon the same as phone numbers are, and would have a audit trail applied.
  • ALL OTHER: All other functions forms, fields, database queries, and badge image code would need code modification to find and replace instances of rl_first with a new checker to determine if preferred name field is null.
• Advantages:
• The database would retain the field rl_first, rl_last (which stands for "real name") as the user's legal name.
• Disadvantages: This would require a major, intensive code refactor that selectively select from legal_first if rl_first was empty for every instance that rl_first is used. (Same with rl_last/legal_last)