CurrentlyPage Content:
Background
There are currently multiple ways of making a field or record unavailable 'deleting' records within the TIS Admin UI, the some of which are hard deletes and some soft deletes. The uses have not been applied consistently across the front end/back end, however the general summary is as follows:
...
. The below table is an audit of all the types and delete available across TIS and the desired To-Be recommendations for each as discussed with data leads.
...
# | Type | As-Is - Functional description on TIS | Where used in TIS | Warning/error messages in TIS | Comments | To-Be | Jira tickets |
---|
1 | Delete DELETE (statusStatus)Image Added | Users can apply a status of "deleteDELETE" to a particular record, which would mean that the record would be deleted hidden from the front end - applied at both record and field levellevel
- this acts as a soft delete
- removed remove the field from record from the front end
- does not de-link where appliedremoves link ability for new scenariosremove the relationship where already in use, e.g. where a 'Curriculum' status is changed to 'DELETE', it'll remain available against Programmes where it's attached to retrospectively.
- removes the ability to use an DELETE status value when creating/editing a record. i.e. made unavailable in the Front End to be used against new records. e.g. you cannot attach a 'Curriculum' with a status of 'DELETE' when creating a new programme.
Example: People (Sensitive Data / Manage Record / Status) | - People
- Programmes
- Posts
- Curriculum
- Rotations
- Reference (All those maintained in TIS)
| No error message displayed | TBC: In intrepid, this flagged the applicable field or record applicable record for archiving in the back end but kept it in view on the UI.
Applicable to fields in ref table and records
Reversible | - Remove “DELETE” as a status that can be applied in the FE across all records
- Apply "DELETE" status in the BE only, in certain scenarios (see below)
- Remove Status against People altogether and consider the use and recording of Leaving Destination and Leaving Reason within Programme membership as suggested on workshop 2018-09-21
- Ensure if there are records with a Status of DELETE in the BE, the various API calls/end points consider ignoring/including them in any search
- Display the records with DELETE status in the FE/BE audit logs
Matt UX: Example of the
| UI? | TISNEW-2407 |
2 | Inactive INACTIVE (statusStatus)Image Added | Users can apply a status of "InactiveINACTIVE" to a particular record or reference data field, which would mean that the record or field is made temporarily unavailable - can be applied at both record and field level
- impact of applying this to a field being used in a current record, is
- filtering may need to be applied to view the record in a list page i.e. To show both current and inactive records
- drop downs for reference tables will not display anything that has been made with an inactive status
- records containing inactive data will not be flagged, but editing may present errors to the user
- assessment records may become legacy, and no editing will no longer be possiblepossible (AR 16/08: Don't understand what this means)
Example: People records (People / Sensitive Data / Manage Record / Status) | - People
- Programmes
- Posts
- Curriculum
- Rotations
- Reference
| No error message displayed | TBC In Intrepid, this meant the applicable field/record would need to be activated (made current) before it could be used in TISin a record
Applicable to fields in ref table and records
Reversible | - "INACTIVE" should be a Status that can be applied to to reference data and all records in column 4.
- By making a record "INACTIVE", it should remove the ability to create/edit a record using an INACTIVE value
- However existing links to an INACTIVE value should not stop a user from editing the record for other details. E.g. 'University of Newcastle' is INACTIVE in reference table, but in use against Person A qualifications, an admin should be able to change the 'Date attained'.
- On edit, system should flag where there are records using/linked to this data that have a status of “current”. E.g. When making a Post INACTIVE, system should flag if there are
- Display which records are linked or using the data, line by line TBC if this is possible and how (Matt Leech (Unlicensed) to review the best approach)
- It should be possible to change the status of the records from INACTIVE back to CURRENT.
Matt UX: No need for design work. This can be done at Dev level. | TISNEW-2409 |
3 | Trash canImage Added | Users can click on the trash can next to a field and permanently remove data from TIS - this functions as a hard delete
- removes existing linkages relationship with records and other fields. e.g. The Placement is removed which represents the relationship between a Person and a Post, but the actual Person and Post records remain intact.
- No audit trail is kept of for the deleted record/field
Example: Placement record (People / Placements / Placement list) | Minus- People: Placement
- People: Programme Membership
| "Are you sure you want to delete?" displayed | 4 | - Assessment (new development)
| No error message displayed | N/A | - The trashcan interaction should be applied to all Placement record types, i.e. CURRENT, PAST as well as FUTURE.
- To be consistent with list views deletions, the trashcan interaction to be applied to Assessments.
- This should act as a soft delete, and render the record/field as follows
- remove the record completely from view in the FE
- apply status “DELETE” in the BE for audit purposes
- Display the deletion in audit log against the relevant user/record - this should also allow user to undo deletion
- Do not allow deletion where linked child records / fields
- Send deleted fields to NDW in segregated area to support reporting
- Consideration of warning message
- Impact assess implications to ESR which currently relies on the trashcan interaction to create Notifications to be sent in the TIS-ESR interface.
Example applicable scenarios - accidental creation of a record
Matt UX: An example of the 'Delete' notification/prompt prototyped below on InVision. Use the hotspot links to view each option for the removal denial due to Child relationships.
https://invis.io/EANNM8F6YHM
Option 1 ) A notification prompt with links to the child areas which need to be changed (Status) so the user can remove the item
Option 2) A link to a generic notification informing the user that this item has child records associated to it so cannot be removed. This would require the user to find the child items themselves to make the changes they need before they can delete the item.
We may need to investigate this with POs if we feel that the user needs to 'Speak with a Data lead' to authorize the deletion?
| |
4 | MinusImage Added | Users can click on the minus sign next to a field and record and in some cases additionally click on 'Save/Update' button to permanently remove it from TIS, generally: - this functions as a hard delete
- removes existing linkages relationship with records and other fields. e.g. Programme membership which is a relationship between a Person and a Programme is removed, but the actual Programme and Person record are intact.
- No audit trail is kept of for the deleted record
/field
Example: Curricula (Programme / Curricula) | QualificationsPeople: Programme MembershipPosts: Other specialtiesPosts: Sub-specialtiesPosts: Other gradesPosts: Other sitesPosts: Programme namesProgramme: Curricula | No error message displayed | 5 | X button | Users can click on the X sign next to a field and permanently remove it from TIS - this functions as a hard delete
- removes existing linkages with records and other fields
Example: Roles field (People / Sensitive Data / Manage Records / Roles) | | No error message displayed | 6 | Dates from/to | Users can specify an end date, which would make the related record or fields Inactive after that date has elapsed - this functions as a hard delete
- removes existing linkages with records and other fields
Example: Post funding (Posts / Post record / Funding) | - People: Registration dates
- People: Inactive date
- People: Programme membership
| No error message displayed | 7 | Archive | Not currently implemented in TIS | N/A |
Data implications
In terms of data being passed down to NDW, it is assumed that hard delete data is not passed on, but soft delete data is.
To Be << to be discussed and agreed with data leads
In order to consolidate the way that the concept of deletion is used across TIS, the following rules should be applied:
Delete status
- remove “delete” as a status that can be applied from FE across all fields and records
- apply delete status in the BE only, in certain scenarios (see below)
- display the deleted status in the audit log and
- Allow NDW reporting
Applicable scenarios
N/A - see Trash Can
Conversation
- need back end reporting function for deleted records
Inactive status
- this should only be applied to the following to reference data fields and all record types
- remove ability to link to new records
- flag where there are records using/linked to this data that have a status of “current”
- display which records are linked or using the data, line by line
Applicable scenarios
- records and fields that need to be temporarily retired
- Reference data
Trash can (button)
- this interaction type should be applied to all record types and certain fields
- this should act as a soft delete, and render the record/field as follows
- remove the record or field completely from view in the FE
- apply status “deleted” in the BE for audit purposes
- display the deletion in audit log against the relevant user/record
- Do not allow deletion where linked child records / fields
Applicable scenarios
- accidental creation of a record
- accidental input of a "multiple-entry" field e.g programme membership
Minus
- this interaction should enable the removal of sub-sections to a record
- this should act as a soft delete
- remove the data from the UI
- apply status of Delete in BE
- keep a record of the change in the back end (accessible via audit logs)
- do not allow deletion where there are linked records
Applicable Scenarios
- accidental addition of a placement or assessment to a Person record
- accidental addition of a curriculum to a Programme
X (button)
- this interaction allows the removal of fields against a record
- it should act as a soft delete
- remove the data from the UI
- apply status of Delete in BE
- keep a record of the change in the back end (accessible via audit logs)
- do not share deleted records with NDW
Applicable scenarios
- removal of roles against a person record*
- sites against a Post?
- others???
Dates From/To
...
User clicks on Minus and confirm with on the prompt message with a Yes to hard delete. User has to click on Minus and Save button which result in the hard delete. - Placements:Other Specialties
User has to click on Minus and Update button to remove the relationship of the additional specialties. User has cannot remove the first Other specialty once added. - Placements: Clinical/Educational Supervisors
User cannot currently remove a clinical/educational supervisor using the minus button. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. User has to click on Minus and Save button to remove the relationship. | - People: Programme Membership
"Really delete programme?" displayed for:Image Added - No error message displayed for the rest.
| N/A | - Minus button should enable the removal of sub-sections to a record
- This should act as a soft delete
- remove the data from the FE
- apply status of DELETE in BE
- To keep a record of the change in the back end
- To display the deletion in audit log against the relevant user/record - this should also allow user to undo deletion
- Do not allow deletion where there are linked records. System should flag when:
- a) removing a curriculum against a programme where there are child associations, e.g. curriculum attached to an assessment or a programme membership
- b) removing the curriculum from the programme membership, where there are assessments attached
- c) removing a programme against a trainee where there are active Placements attached.
- Any other scenarios else to consider here? (Devs to consider an other linked data)
- Send deleted fields to NDW in segregated area to support reporting
- The use of Minus and Save/Update in some places to be reviewed for the best UX approach (Matt Leech (Unlicensed) see As-Is column)
Example applicable scenarios - accidental addition of a sub-section (e.g. placement or assessment to a Person) record
accidental addition of a curriculum to a Programme
Matt UX: On reviewing the multiple option for soft delete I feel that we should have 2 sets of delete/removing options.
A) The 'Trash can' in table lists will always be a hard delete as discussed in the row above.
B) Removing the 'Minus sign' from all UI elements where we have the option of soft delete and replace with a 'Cross in the circle' to indicate this is a deletion/removal not as some users may assume is a 'close or hide' function. By doing this we will have consistency across the System for all 'Soft delete' items, be it Tags, Filters, Fields or even sections of forms' the Icon will remain the same 'A cross' in a circle or a 'Cross' within the actual element as with Tags and Filters.
The soft delete will only be actioned when that UI has been 'Saved/Updated'. If the users choose to navigate away, forgetting to 'save/update' their actions they will be prompted to either
a) Go back to the UI and save/update to action the soft delete and any other tasks they performed
b) Ignore the deletion and continue with their work (if they made a mistake this gives them the opportunity to leave the UI without saving/updating'.
The reason behind this decision is that some of the soft deletes/adding and removing fields of data and small changes would be frustrating for the user to update/save after each action. If they have multiple tasks within one form, for example, they should be able to perform these tasks and save/update at the end. If they make a mistake they can go back and change things, if however, they are happy with their input they can save/update at the end.
Example below:
https://invis.io/5RNRVW2A6K3#/316984227_Soft_Delete_In_Placements | TISNEW-2413 |
5 | Image Added Image Added | Users can click on the X sign next to a field and permanently remove it from TIS and in some cases have to confirm the prompt message to complete the deletion. - this functions as a hard delete
- removes existing relationship with records. e.g. the role is removed from the Person record, but the actual Role is available to be used against new person records.
Example: Roles field (People / Sensitive Data / Manage Records / Roles) | - People: Roles
- Document: Tags
- Document
| Image Added - No error message displayed for Roles and Tags
| N/A | - This interaction allows the removal of "multi-add" fields against a record
- remove the data from the UI
- AR 16/08: Joanne Watson (Unlicensed) Alistair Pringle (Unlicensed) - Don't think this is straight forward to make a soft delete as it would mean that we should maintain in TIS at field level all possible Roles, whereas currently Roles is just one field which holds comma separated values in the table. One to be discussed...
- keep an audit of the change in the back end, i.e. which role,tag,document was deleted/changed by who and when.
- display the deletion in audit log against the relevant user/record
- Send audit logs of deleted/changed fields to NDW in segregated area to support reporting
Matt UX: No design work needed
| TISNEW-2415 |
6 | Dates from/to | Users can specify an end date, which would make the related record or fields 'INACTIVE' after that date has elapsed - this functions as an automatic soft change of the Status
- status of the records automatically changed from CURRENT to INACTIVE and vice-versa
Example: Post funding (Posts / Post record / Funding)
| - People: Registration dates
- People: Inactive date (Has been hidden in the Front End)
- People: Programme membership
| No error message displayed | Applied in addition to any status of current, inactive or delete - purely informational | - This interaction should trigger automatic status change to "INACTIVE" or "CURRENT" dependent on when the dates lie in relation to "today's date"
- It should act as a Status change only
- make record "INACTIVE" when 'Date To' exceeds today's date
- make record "CURRENT" where today's date reaches 'Date from'.
- keep the record in view within UI and searchable when relevant filter applied
- keep a record of the change in the back end (accessible via audit logs)
|
...
Applicable scearios
...
- Can be overridden manually by status change,
Example applicable scenarios: - Joanne Watson (Unlicensed)/ Alistair Pringle (Unlicensed) - AR 16/08: I can't think of any current scenario on TIS where this is currently available. It was previously here witihin People > Sensitive data > Inactive date , but the Inactive date is hidden from the FE currently.
- supervisor approvals (not on TIS, to consider when this is available)
- GMC/GDC/PH number validity
|
...
Archive
...
Matt UX: No design work needed
08/11: Discussed with AP,This is not required. |
|
7 | Archive | Not currently implemented in TIS |
| N/A | Archiving paper/guidance: View file |
---|
name | Intrepid_ConsolidationDataRetention_Proposal V4.docx |
---|
height | 150 |
---|
|
View file |
---|
name | V10 Consolidation project - archiving proposal (draft) 29.9.16 (1) (1).docx |
---|
height | 150 |
---|
|
| Requires further discussion with Joanne Watson (Unlicensed) / Ray / IG - This is required to enable permanent retirement of record types e.g. when a trainee record falls outside of the data retention period
- this should be an automated process that triggers the following:
|
...
...
- Back End that removes "Inactive" trainees after a defined duration has elapsed e.g. 7 years from their programme end date
|
...
- Remove view of the record in
|
...
- the Front End and should not be searchable/accessible via any means from the UI.
- Notify users in bulk of records that have been archived
|
...
- - AR 29/08: What does this mean and entail ???
- Apply status of "Archive/Suppressed"
- All archived data should be retrievable via NDW - AR 29/08: Has this been verified if compliant with IG?
Applicable scenarios - where data needs to be retired relating to Trainee records (after 10 years have elapsed)
|
<data flows>
# | Question | Comments |
---|
1 | Other than reference date and records (forms), is there anywhere else, or data type, that it should be possible to apply inactive as a status? | 2 | Other than within record, are there other scenarios you might want to delete (trashcan) a data entity? for example, particular fields? | 3 | Deleting programme membership or curriculum membership current behaviour. Think these are hard deletes too, should they be? If so, do we currently audit the deletion of these? Requires technical design guidance as to what a consistent delete on TIS should be. | 4 | What are archiving rules regarding elapsed time and what can/cannot be stored? | 5 | What data will need to be accesible (GDPR) and for how long? | 6 | Are there any notifications we need to provide to users / trainees regarding the editing/deleting/archiving of their data? 08/11 : Archiving to be reviewed as a separate requirement from deletion in its own confluence section. Archiving - V10 v.s. TIS (DRAFT) | TISNEW-257 |
8 | Bulk Upload/Update | Users able to bulk change the statuses (People) or hard delete (Placements) of multiple records at once using the bulk import facility in TIS. - Functions as a soft change to the Status for People to either INACTIVE/DELETE/CURRENT
- Functions as a hard delete for placements, which is currently only available to data leads to use.
| | N/A | N/A | Joanne Watson (Unlicensed)/ Alistair Pringle (Unlicensed): - Is there a requirement to bulk add 'Inactive date' to People records, if we are going to make it visible in the FE? - 08/11 Not applicable
- Should we remove the ability to change the People records to 'DELETE' via bulk but keep the ability to make them INACTIVE or CURRENT so that deletions can be undone in bulk? - 08/11 Removing the status column from the people import template.
- The current restricted bulk delete placement which is only available to data leads does hard delete, should we make this a soft delete to be consistent with #3 (trashcan To-Be)? - 08/11 - Move the bulk placement delete so soft delete
- Should we consider audit logs for bulk - 08/11 - Same as FE for Placements
| TISNEW-2416 |
Jira Tickets
Jira Legacy |
---|
server | System JIRA |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status |
---|
maximumIssues | 20 |
---|
jqlQuery | "Epic Link" = TISNEW-2408 |
---|
serverId | 4c843cd5-e5a9-329d-ae88-66091fcfe3c7 |
---|
|