Admin UI - Deletion | Impact Analysis by Table

Context:

The previous page describes the various mechanisms by which a user can delete a field/record on TIS currently, and provides suggestions as to how this might be tackled in future (with re-work on the FE and BE), however, there is no downstream review of impact. This page gives an overview of the following

tables and fields used across TIS and where they're used
suggestion of deletion mechanism
commentary on downstream impacts of deletion mechanism

In conclusion, deletion could continue to be applied by status, however each status would imply a particular action. These are described below:

Inactive

the field/form can be viewed on TIS UI if it has been applied to a record. For example, reference values that have been made inactive in their respective table are rendered read only, or can be removed from a TIS form
the inactive field cannot be viewed in the TIS UI drop downs. For example, reference values that have been made inactive in their respective table are no longer viewable within drop downs across TIS forms
the inactive form cannot be linked to any other record. For example an inactive post cannot be linked to a trainee and become a placement

Delete

the field/form cannot be viewed on the TIS UI
the field/form remains in the Back End of TIS to allow it be shared with NDW and retrieved if required (until it must be filed or archived)
the field/form is sent to NDW as a "deleted" value

Archive

the field/form cannot be viewed on the TIS UI
the field/form cannot be viewed in the TIS back end
the field/form must be stored in an archived location (TBD)
the archiving process is automated (TBC)
archiving should be read only (snapshot), without requirement for reference values

Note:

A "form" is the TIS UI format of a particular set of data in TIS e.g. Person screen = a form

A "record" can refer to either a table or a form within TIS, so is not used in this page to remove confusion

This will need to be updated once "missing" fields have been agreed for the TIS UI (see here: NDW UAT feedback)

Impact Analysis

The fields listed are only those displayed in the TIS front end:

TIS table	Field name	TIS location	Applicable statuses	Impact analysis (assumptions)	Comments
RolePermission whole entry status can be: INACTIVE / DELETE / ARCHIVE on the FE Should be stored against a relevant person ID (tbc) when deleted or archived
	roleName	TBC	DELETE ARCHIVE	deletion will remove the role from the FE, but retain the it in the BE permissions will be removed to the user on login a role must be assigned to any user who needs to use the system roles should be archived against a person record (i.e. for users who are also managed within TIS) roles should be archived against users (i.e. for users who are not managed within TIS)	This is held in Keycloak currently, this is only relevant where role/permission management moves into TIS
	permissionName	TBC	N/A	the permission is removed where the role is removed	This is held in Keycloak currently, this is only relevant where role/permission management moves into TIS
Role whole entry status can be: INACTIVE / DELETE / ARCHIVE on the FE
	name	TBC	INACTIVE DELETE	inactive will remove the role from being applied in the FE delete will remove the value from the table delete will remove data from forms where the role is in use	This is held in Keycloak currently, this is only relevant where role/permission management moves into TIS (as reference data) Assumption is that reference data archiving is not necessary
UserRole whole entry status can be: INACTIVE / DELETE / ARCHIVE on the FE Should be stored against a relevant person ID (tbc)
	userName	TBC	DELETE ARCHIVE	usernames are mandatory so at least 1 is necessary for a user to be active in TIS delete will remove their ability to login to TIS archive will retain a copy of the username details	Is it necessary to retain username details?
	roleName	Person form	DELETE ARCHIVE	deletion will remove the role from the FE, but retain the it in the BE permissions will be removed to the user on login a role must be assigned to any user who needs to use the system roles should be archived against a person record (i.e. for users who are also managed within TIS) roles should be archived against users (i.e. for users who are not managed within TIS)	This is held in Keycloak currently, this is only relevant where role/permission management moves into TIS Is this data linked to the data held in the RolePermission or is it held separately? If so, then would the status of one or both instances of a like-role need to be altered?
PersonalDetails entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	maritalStatus	Person form	DELETE ARCHIVE
	dateOfBirth	Person form	DELETE ARCHIVE
	gender	Person form	DELETE ARCHIVE
	nationality	Person form	DELETE ARCHIVE
	dualNationality	Person form	DELETE ARCHIVE
	sexualOrientation	Person form	DELETE ARCHIVE
	ethnicOrigin	Person form	DELETE ARCHIVE
	religiousBelief	Person form	DELETE ARCHIVE
	ethnicOrigin	Person form	DELETE ARCHIVE
	disability	Person form	DELETE ARCHIVE
	disabilityDetails	Person form	DELETE ARCHIVE
	nationalInsuranceNumber	Person form	DELETE ARCHIVE
TrainingNumber entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	trainingNumber	Person form	DELETE ARCHIVE
GdcDetails entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	gdcNumber	Person form	DELETE ARCHIVE
	gdcStatus	Person form	DELETE ARCHIVE
	gdcStartDate	Person form	DELETE ARCHIVE
	gdcEndDate	Person form	DELETE ARCHIVE
GmcDetails entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	gmcNumber	Person form	DELETE ARCHIVE
	gmcStatus	Person form	DELETE ARCHIVE
	gmcStartDate	Person form	DELETE ARCHIVE
	gmcEndDate	Person form	DELETE ARCHIVE
ContactDetails entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	surname	Person form	DELETE ARCHIVE
	forenames	Person form	DELETE ARCHIVE
	knownAs	Person form	DELETE ARCHIVE
	maidenName	Person form	DELETE ARCHIVE
	initials	Person form	DELETE ARCHIVE
	title	Person form	DELETE ARCHIVE
	telephoneNumber	Person form	DELETE ARCHIVE
	email	Person form	DELETE ARCHIVE
	workEmail	Person form	DELETE ARCHIVE
	postCode	Person form	DELETE ARCHIVE
	legalSurname	Person form	DELETE ARCHIVE
	legalForenames	Person form	DELETE ARCHIVE
	address1	Person form	DELETE ARCHIVE
	address2	Person form	DELETE ARCHIVE
	address3	Person form	DELETE ARCHIVE
	address4	Person form	DELETE ARCHIVE
RightToWork entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	eeaResident	Person form	DELETE ARCHIVE
	permitToWork	Person form	DELETE ARCHIVE
	settled	Person form	DELETE ARCHIVE
	visa Issued	Person form	DELETE ARCHIVE
	visa ValidTo	Person form	DELETE ARCHIVE
	visa Details	Person form	DELETE ARCHIVE
Qualification entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	qualification	Person form	DELETE ARCHIVE
	qualificationType	Person form	DELETE ARCHIVE
	qualificatinAttainedDate	Person form	DELETE ARCHIVE
	medicalSchool	Person form	DELETE ARCHIVE
	countryOfQualification	Person form	DELETE ARCHIVE
Comment entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	parentId	Person form	DELETE ARCHIVE
	threadId	Person form	DELETE ARCHIVE
	author	Person form	DELETE ARCHIVE
	body	Person form	DELETE ARCHIVE
PersonTrust entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	trustCode	Person form	DELETE ARCHIVE
	trustName	Person form	DELETE ARCHIVE
PersonOwner entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	owner	Person form
RotationPerson entry status can be: INACTIVE / DELETE / ARCHIVE
	rotationId	Person form
Rotation entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	programmeId
	name
	status
RotationPost entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	postId
	rotationId
PlacementSupervisor entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	placementId
	personId
Programme entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	status	Person form
	owner	Person form
	programmeName	Person form
	programmeNumber	Person form
Placement entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	specialty	Person form
	dateFrom	Person form
	dateTo	Person form
	placementWholeTimeEquivalent
	ttraineeId
	postId
	localPostNumber
	siteCode
	gradeAbbreviation
	placementType
	status
	trainingDecriptionsiteId
	gradeId
Curriculum entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	name
	curriculumSubType
	assessmentType
	doesThisCurriculumLeadtoCct
	periodofGrace
Post entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	nationalPostNumber
	status
	employingBodyId
	traningBodyId
	suffix
	owner
	postFamily
	localPostNumber
	trainingDescription
PostFunding entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	startDate
	endDate
	fundingType
	info
	fundingBodyId
Specialty entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	status
	college
	specialtyCode
	specialtyGroupId
	name
ProgrammeMembership entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	programmeMembershipType
	rotation
	curriculumStartDate
	curriculumEndDate
	periodOfGrace
	programmeStartDate
	curriculumCompletiondate
	programmeEndDate
	leavingDestination
	trainingNumberId
Assessment entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	firstName
	lastName
	reviewDate
	programmeNumber
	programmeName
	status
	type
AssessmentDetail entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	curriculumId
	curriculumName
	curriculumStartDate
	curriculumEndDate
	curriculumSpecialtyId
	curriculumSpecialty
	curriculumSubType
	membershipType
	gradeAbbreviation
	gradeName
	periodCoveredFrom
	periodCoveredTo
	portfolioReviewDate
	monthsWteDuringPeriod
	monthsCountedToTraining
	traineeNtn
AssessmentOutcome entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	outcome
	underAppeal
	comments
	trainingCompletionDate
	extendedTrainingCompletionDate
	extendedTrainingTimeInMonths
	tenPercentAudit
	externalTrainer
	nextRotationGradeName
	traineeNotifiedofOutcome
	nextReviewDate
	academicCurriculumAssessed
	academicOutcome
	detailedReasons
	mitigatingCircumstances
	competencesToBeDeveloped
	otherRecommendedActions
	addCommentsFromPanel
	reason
	nextRotationGradeAbbr
Revalidation entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	concernSummary
	responsibleOfficerComments
Reference Tables - these have been summarised since the rules should be similar in the majority of instances (some have other values which will be impacted if the below rules are adhered) entry status can be: INACTIVE / DELETE / ARCHIVE Should be stored against a relevant ID (tbc)
	code
	label
	name
	status