| # | Type | As-Is - Functional description on TIS | Where used in TIS | Warning/error messages in TIS | Comments | To-Be | Jira tickets |
|---|
| 1 | DELETE (Status)
| Users can apply a status of "DELETE" to a particular record, which would mean that the record would be hidden from the front end - applied at record level
- this acts as a soft delete
- remove the record from the front end
- does not remove 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 | In intrepid, this flagged the 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 deleted item in Audit trail
TIS Admin UI - UX Enhancement - Removing delete status from all fields with Audit example of removed data - Allow NDW reporting for records with "DELETE" status
| TISNEW-2407 |
| 2 | INACTIVE (Status)
| Users can apply a status of "INACTIVE" to a particular record or reference data, which would mean that the record is made temporarily unavailable - can be applied at record
- 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 possible (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 | In Intrepid, this meant the applicable field/record would need to be activated (made current) before it could be used in 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 can
| 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 relationship with records. 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
Example: Placement record (People / Placements / Placement list) | - People: Placement
- People: 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 | Minus
| Users can click on the minus sign next to a 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 relationship with records. 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
Example: Curricula (Programme / Curricula) | - People: Programme Membership
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: - 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 | 
| 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
| 
- 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)
- 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
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: 
%2029.9.16%20(1)%20(1).docx?version=1&modificationDate=1534494485661&cacheVersion=1&api=v2&viewType=fileMacro)
| 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:
- Change of status in 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)
|
|
| 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 |
Add Comment