| **Scenario** | Admin user wants to access admin panel and define user roles |
| **Given** | User with admin privileges can access the admin panel through a clearly define 'admin' button on the homepage |
| **When** | User can define or edit access levels for different user roles |
| **Then** | System provides a clear interface for setting permissions based on user roles, changes should be savable and immediately effective across the WMS |
| ##### | ##### **Good When** | ##### | ##### **Bad When** |
| The interface for defining user access levels clearly categorises different permissions and roles. | | Admins cannot define roles as the system doesn't allow for these edits to be made. |
| Administrators can easily access admin panel, add, remove, or modify user roles and their corresponding access levels. | | Admins cannot access the admin panel from the homepage as there is no 'Admin' button. |
| The system implements changes immediately across the platform. | | There is a delay in the implementation of changes across the platform, **or** they are not made at all. |
| ##### **Completed When** |
| An 'Admin' button is present at entry level, and an admin-level user can login in and edit user capability and access levels across the whole WMS platform. |
| ##### **Start When** |
| When purchase order has been issued to the client. |
| ##### **Feature Priority** | - [x] ##### **High Priority** - ##### **Medium Priority** - [ ] ##### **Low Priority** |
| ##### **Client Approves Feature** | - [ ] **Approved** *Once approved, inform us by email, we will close the feature checklist and begin the process.* |
| ##### **Agreed Timeline** | Once approved the process will continue as - Create mock ups of the feature within 14 days of 'Start When' - Schedule of the project will be agreed within 14 days of ‘Start When', - Development of the feature once mocks up have been approved. - Q/A and delivery 7 days after development cycle Estimated development time for this feature would be **X days**, |