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:

o*Frever 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.

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 there is no other code changes needed and we cannot possibly screw up the code. 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)

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.