Administration › User management
Early draft — still to be defined. User management for the MVP is not agreed yet: sign-in runs on the identity server, and how workers, groups and stores are administered is an open design conversation with Tunstall. Expect the final page to look and work differently.
User management
Workers who sign in to the Service Manager
Workers
0| Worker ApplicationUser.DisplayName | Reference ApplicationUser.ProviderReference | Groups ApplicationUser.Groups | Roles ApplicationUser.Roles | Stores ApplicationUser.Stores | Work day ApplicationUser.WorkDayStartOn/EndOn | Status ApplicationUser.IsDeleted |
|---|
One row per
ApplicationUser. The person behind the login is a Person record; sign-in itself is the identity server (IsIdentityUser) — credentials are not managed here.Administration › Roles & permissions
Early draft. The role list and permission model are real —
Role × Operation via RoleOperation, already populated in production (static data, 14 Sep) — but how workers are administered for the MVP is still an open conversation with Tunstall (sign-in runs on the identity server). Expect the worker side to change; the permissions side is the backend as it is.Roles & permissions
Who is allowed to do what — the 16 production roles and the operations each one is granted
Roles
0| Role Role.Name | Portal role Role.IsPortalRole | Members ApplicationUser.Roles | Grants RoleOperation |
|---|
Permissions are not a gap (static data, 14 Sep): the production database holds
Role (16 rows, IsPortalRole) × Operation (196 named UI-level grants such as Access Inventory Section, Cancel Request, Approve Stock Order) joined by RoleOperation (497 mappings). The 16 roles above are the real ones; Permissions… edits a role's operations. (The ARC's Permission / RolePermission governs ARC operators, not SM workers.)Permission matrix
Role × Operation → RoleOperation0One column per role, one row per operation grouped by section — a representative subset of the 196 operations (the full list is in the static-data reference). Click a cell to toggle the grant; Permissions… on a role edits the same data as a checklist. ✓ = a
RoleOperation row exists.Administration › Store network
Store network
Main stores and their secondary stores — vans included
Stores
0| Store Store.StoreName | Kind Store.ParentStoreId | Belongs to | Location Store.Location | Engineer ApplicationUser.Stores | Items – live, from Inventory count of StockItem.CurrentLocation |
|---|
Grouped by main store — a store with a
ParentStoreId is a secondary store (a van, a lockup). ⚠ Store has no type column, so main-vs-secondary is read from the parent link, and the engineer is the worker whose Stores list holds the van — not a store column. A store can only be deactivated when it is empty.Administration › Default tasks › Task types
Task types
The kinds of work a request can contain — each with its colour and expected duration
Task types
0| Type TaskType.Name | Description TaskType.Description | Colour TaskType.Colour | Duration TaskType.Duration | Arrival SLA TaskType.ArrivalWarningSLA / ArrivalBreachSLA | Completion SLA TaskType.CompletedWarningSLA / CompletedBreachSLA | Actions |
|---|
One row per
TaskType in this group (TaskType.GroupId). Colours drive the Scheduling board and My work; the duration is copied onto a new task; the four SLA columns (arrival / completion × warning / breach) are hidden for now (only 21 of 384 production rows set one). Types in use can be archived (TaskType.IsArchived), not deleted. The tasks a new request starts with are set on Default tasks, which this page is reached from.Administration › Default tasks
Default tasks
The tasks a new request is created with, for each request type
One set per request type for this group DefaultTask.Group · DefaultTask.RequestType. Tasks appear on a new request in the order listed (reordering comes in a later release); each task takes its type's duration and colour. Changing a set only affects requests created from now on. This is the list the New request popup shows under “Tasks this request will start with” (Requests · Service users).
Administration › Manufacturers & products
Manufacturers & products
The catalogue behind the Inventory — who makes what we install
Products
0| Product Stock.ModelName | Manufacturer Stock.Manufacturer | Type Stock.StockType | Characteristics StockCharacteristic | Status Stock.IsDeleted |
|---|
| Manufacturer Manufacturer.Name | Products | Status |
|---|
Products are created and archived here; the Inventory's Products page is the operational view. ⚠
Stock has no part-number, reorder-level, unit-value or warranty columns — extra product facts ride on StockCharacteristic name/value rows. Archiving a manufacturer needs a reason and leaves its installed base untouched.Administration › Static data
Static data
The look-up lists the other pages feed from — sections are added as the pages get built
Look-up lists
| List | Backing table | Entries | Used by |
|---|
Every list is an existing SM look-up table. Task types opens here as the worked example; the rest follow the same pattern as their pages are built — per the breakdown note, more sections will appear during the build.