Trapa at 01:06, 7 October 2021

2021-10-07T01:06:52Z

← Older revision		Revision as of 20:06, 6 October 2021
Line 19:		Line 19:
	**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.		**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''':		*'''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.		*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==		==New Legal Field and Move==
Line 30:		Line 31:
	**'''No other changes needed'''		**'''No other changes needed'''
	*'''Advantages''':		*'''Advantages''':
	**The advantage of this, is that ~~there is~~ no ~~other code changes needed and we cannot possibly screw up~~ the ~~code~~. ~~Legal name~~		**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)		*'''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)

Line 42:		Line 43:
	**'''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.		**'''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.		**'''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.		*'''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)

Trapa: Created page with " 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 a..."

2021-10-07T01:04:44Z

Created page with " 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 a..."

New page

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.

DeadNames - Revision history

Trapa at 01:06, 7 October 2021

Trapa: Created page with " 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 a..."