Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Page Content

Background

The Minimum Viable Product (MVP) for User management interface has been in place for a while and we have received a number of feedback from various sources; TIS Admin Users, Tech debt feedback which arose from investigating tickets, and session with the Product Owner and Data leads. This page captures those feedback and in a suggested prioritised order from the data leads and Product owner.

Epics and User Stories

Item no.

User Story

Acceptance Criteria

Jira ticket no.

UI Changes - User Management

1

As a TIS admin
I want to the non-HEE prefixed roles to be hidden in the UI
So That Users cannot be updated either by mistake, with those roles and avoid any confusion

2

As a TIS admin
I want to have visibility and manage Audits on last logged in, when users are made inactive, when created
So That I can report on those in the National Data Warehouse and comply with Information Governance

3

As a TIS admin
I want to have the ability to have a process for and re-activate inactive accounts of different user types (admins, trusts users, trainees etc.)
So That I do not have to recreate duplicate accounts on TIS

4

As a TIS admin
I want TIS to proactively clean accidentally added extra white spaces (leading/trailing/middle extra) when a user enters account information on TIS (usernames, email address)
So That clean user accounts are created and maintained in TIS and avoid user confusion when trying to login

5

As a TIS admin
I want TIS to have an improved User Experience and User Interface for managing user accounts
So That I can manage accounts in a an intuitive and user-friendly way

- Have validations to stop invalid data from being saved into TIS
- Improvements around navigations, instead of having to remember and type the URL to .../usermanagement...
- User journeys to be prototyped and tested with the users and interatively and incrementally improve with user feedback

6

As a TIS admin
I want to have visibility of the status of an account
So That I can tell if the account is Inactive or Current

7

As a TIS admin
I want to Users with access to manage users to be able to manage (view/create/update) other users with same or less permissions than my logged in permissions
So That I can ensure permissions are managed in a hierarchical way and I cannot grant myself permissions I should not be able to have.

8

As a TIS admin
I want to have the ability to opt to Multiform Factor Authentication (MFA)
So That I have a more secure way of authenticating to TIS from multiple devices and locations

Roles - User Management

1

As a TIS admin
I want to ensure the rationalised 9 roles created for use on TIS are working as per their definitions (https://hee-tis.atlassian.net/wiki/spaces/NTCS/pages/71958539/Admin+User+Management+roles+and+permissions)
So That I can ensure that the other non-hee roles can be safely removed from the UI and from those Accounts

2

As a TIS admin
I want the non-hee roles to be removed from existing accounts
So That there is no overlap and confusion over the level of permissions a user has been setup with on TIS

3

As a TIS Admin in a local office
I want users to be able to access trainees by programmes (as per the Programme Admin/Observer role)

And trainees by Trusts (as per the HEE Trust Admin/Observer role)
So that a Trust admin who is responsible for the management of trainees both in their trust and in a local office-wide programme can see trainees from a programme and from a trust

Given the Programme Admin/Observer roles conflict with the Trust Admin/Observer role so if a user is attached to both a Programme and Trust role the result is that the user sees no trainees
When a user is attached to Programme and Trust role
Then they will see the trainees in the programme that they have access to (either in an Admin or Observer capacity) and in the Trust they have access to (either in an Admin or Observer capacity)

https://hee-tis.atlassian.net/browse/TISNEW-3245

4

As a Product Owner
I want to have a definition of the hierarchy of roles to be used for TIS`
So That I can ensure accounts permissions can be granted in a cohesive way withouth overlapping roles

5

As a TIS admin
I want to have a Post Admin role exclusively for managing posts and post fundings
So That posts and fundings are managed in a cohesive way

6

As a TIS admin
I want to have our reference data to be taxonomised
So That TIS use can be scaled/expanded to other Nations and Staff groups whilsts still having the ability to segregate views of the data

Tech debt - User Management

1

As a TIS Admin in a local office
I want users to be able to access trainees by programmes (as per the Programme Admin/Observer role)

And trainees by Trusts (as per the HEE Trust Admin/Observer role)
So that a Trust admin who is responsible for the management of trainees both in their trust and in a local office-wide programme can see trainees from a programme and from a trust

Given the Programme Admin/Observer roles conflict with the Trust Admin/Observer role so if a user is attached to both a Programme and Trust role the result is that the user sees no trainees
When a user is attached to Programme and Trust role
Then they will see the trainees in the programme that they have access to (either in an Admin or Observer capacity) and in the Trust they have access to (either in an Admin or Observer capacity)

2

As the TIS Dev Team/PO
I want to research into a mechanism for manage accounts Audits (last logged in, when users are made inactice, when created etc.)
So That we are confident to implement a solution for TIS that would be IG compliant

3

As a TIS admin
I want to accounts to be created in a seamless way without having to juggle between keycloak and User management/Profile Service to ensure that an account has been setup successfully
So That we do not end up in partial account creations which has happened on a number of occasions,
And avoid putting burden on the dev team and support team to investigate and manually fix accounts

Jira Tickets

  • No labels