Roles and permissions field definitions

Roles and permissions field definitions

What this is

A reference for every role and permission in mywork, what each one unlocks, and how a user actually gets one. Use this article as the canonical source whenever a process guide says "X requires the Y permission" — the meaning of that permission lives here.

The model has three independent dimensions, plus two derived statuses. Skim the section that matches your question:

• Roles / permissions — what kind of action you can perform. (§1)

• Areas — where in the warehouse you can act. (§2)

• Products — which products you can transact on. (§3)

• Department manager — derived from a foreign key, not a permission. (§4)

• Stand-in / temp manager — date-scoped fall-back routing. (§4)

A user is allowed to do something only if all the dimensions that apply to that action say yes — having MOVE_ORDER_USER does not let you move stock in a warehouse area you do not have access to.

1. Roles and permissions (the AppPermission enum)

How a user gets a permission

A user's effective permission set is the union of grants from five sources, all merged on login into a UserAccessProfileDTO:

• Legacy user_role table (one-by-one direct grants) — retired (2026-06-13). All direct system-permission grants were cleared; this source is now empty. Permissions come through the role / group / job-position sources below, never one permission at a time.

• user_app_role table — direct assignment to an AppRole; the role brings its full set of AppRolePermission rows.

• user_app_group membership — group → group's app roles → permissions. Groups are managed on the Groups tab of Admin ▸ Roles & Permissions.

• Active job position (via HrJobHistory) — the job position carries app roles that cascade permissions. HR-managed; assigning someone to a new position automatically grants the matching permissions.

• Per-warehouse / per-area / per-product permission tables — user_warehouse_permission, user_area_permission, user_product_permission.

Role-only access — how you actually grant something. You no longer give a single permission to a person. Assign them an Application Role (or a Group, or set their job position) and the role carries the permissions. To make someone a full administrator, assign the System Admin role (it carries ADMIN) — never hand-grant ADMIN/Administrator to a user directly. In Admin ▸ Roles & Permissions ▸ System Permissions, the "Who has it" button lists the roles that grant a permission (that is the only path). Exception: area / warehouse / product access is a separate per-area scheme and is still granted directly on the user's admin profile (see §2–§3). See Roles and permissions (RBAC) for the how-to.

Permissions cache for the session. If an admin grants you a new role mid-session, you have to log out and back in for it to take effect.

Site Admin — the umbrella

ADMIN is the global override. SecurityController.has() short-circuits to true when sessionBean.isAdmin() is true, regardless of which specific permission is being checked. Use sparingly, and assign it through the System Admin role rather than a direct ADMIN grant; almost every documented capability below is also reachable through a more granular role.

HR module

• HR_READ — read-only access to employee profiles, documents, and HR-side reports.

• HR_WRITE — also create and edit profiles, upload documents.

• HR_DELETE — also delete documents/profiles. HR_DELETE is also the role that means "HR Admin" — SecurityController.isHrAdmin() returns true exactly when the user has HR_DELETE.

• HR_SALARY_READ / HR_SALARY_WRITE — view / edit salary data. Separate from the rest of HR so payroll-restricted users can be barred from rates without losing profile access.

Attendance module (leave, OT, time-tracking)

• ATTENDANCE_VIEW — view attendance pages and reports.

• ATTENDANCE_CREATE — create or approve attendance records, schedule changes, manual adjustments.

• ATTENDANCE_DELETE — delete attendance records.

• ATTENDANCE_ADMIN — full module access (all of the above plus configuration).

• REMOTE_ATTENDANCE — clock in / out remotely from the dashboard (instead of from a fixed terminal).

• ATTENDANCE_SELF_MANAGE — excuse, edit or approve your own attendance. A separation-of-duties override for executives with no manager above them; grant nowhere else.

Department managers also get read access to their team's leave without holding any ATTENDANCE_* permission (SecurityController.canViewTeamLeave()).

Work Orders

Work Order access has two layers, and only the first is a permission:

• Generic permissions across every type — WO_ADMIN (umbrella, full access), WO_CREATE, WO_READ, WO_WRITE, WO_DELETE, WO_RELEASE (release a DRAFT to the floor), WO_FORCE_COMPLETE and WO_FORCE_RESUME (high-risk supervisor overrides), WO_DASHBOARD (open the Work Orders dashboard and its New Work Order button) and WO_TYPE_ADMIN (define Work Order types and grant per-type access).

• Per-type access is data, not a permission. It is granted per Work Order type on the Work Order Types page (Work menu). The old WO__READ / _WRITE / _CREATE / _DELETE / _RELEASE / _ADMIN constants still appear in the catalogue but are marked PARKED and grant nothing (ADR-051, 2026-09-01). Do not build a role on them.

Both the web pages and the REST API answer "may this person do X to a work order of type T" through one shared resolver (WoTypeAccess), so the two surfaces cannot drift apart. The detail of the Work Order gates is covered in the Work Order guides, not here.

Stock & inventory

• MOVE_ORDER_REQUEST — create and accept your own Move Orders (the requester surface, Warehouse ▸ Move Orders).

• MOVE_ORDER_USER — perform Move Order stock moves.

• MOVE_ORDER_MOVER — the warehouse mover: collect and drop for a delivery, accept for a collection. Grants the Bulk Pick screen and Stores area access.

• MOVE_ORDER_MANAGER — the Move Order board (Warehouse ▸ Move Orders — Manage): see every order, assign or clear movers, oversee the floor.

• MOVE_ORDER_ADMIN — assign Move Orders and reach the Move Order reports.

• MOVE_ORDER_BROWSE_CATALOG — when creating a delivery, browse the full product catalog rather than only what is in stock at Stores.

• MY_STORE — browse the Stores catalog and order items for delivery via the My Store basket.

• STOCK_TRANSFER / STOCK_TRANSFER_DIRECT — transfer between warehouses; the _DIRECT variant skips the request workflow.

• STOCK_COUNT_ADMIN — create stock counts from stock on hand, assign them to a counter, delete them and read their results, in the areas you have access to.

• STOCK_COUNT_USER — perform the counts assigned to you, in the areas you have access to.

• STOCK_COUNT_REPORT — the read-only, org-wide stock-count reports and dashboard tiles.

• STOCK_COUNT_ADJUST_CASE — make adjustments from count results (write-down or write-up).

• VIEW_ALL_PRODUCTS — see every product, ignoring per-product gating.

• CREATE_LOCATION / LOCATION_PRINT — create / print warehouse-location labels.

• LOCATION_MANAGEMENT — the location and area admin console (Warehouse ▸ Location Management). Metadata only, no stock moves; a non-admin alternative to full ADMIN for warehouse managers.

• CUSTOM_ASSEMBLIES / ASM_ADMIN — assembly creation and admin.

• REQ_ADJ_* — separate request-adjustment permissions for FIXED_ASSET, PERSONAL_INV, PERSONAL_CONS, CONSUMABLES, PACKAGING, plus REQ_ADJ_APPROVE and REQ_ADJ_CHECK on the accounting side. Each gates a different adjustment reason. REQ_ADJ_DAMAGED is deprecated — damaged goods now use the dedicated DAMAGED_GOODS_MARK family.

• UNLEASHED_ADJUSTMENT — senior role: push an adjustment through to Unleashed (the upstream system) directly from mywork.

Sales, purchases, repairs

• SALES — general access to sales-related pages.

• SALES_ORDERS_ADMIN — full access to Sales Orders.

• PURCHASE_ORDER_USER — view and process purchase orders.

• SALES_SHIPMENT_USER / STOCK_SHIPMENTS_USER — sales-shipment / stock-shipment access.

• CREDIT_NOTE_USER — credit-note workflows.

• LOCAL_RECEIPT_USER / LOCAL_RECEIPT_RECEIVE — Local Receipts: open, create, edit and delete (the manage gate) / receive stock inbound. Role-based equivalents of the per-area CREATE_LOCAL_RECEIPT and PROCESS_LOCAL_RECEIPT grants; either confers access.

• LOCAL_SHIPMENT_USER / LOCAL_SHIPMENT_DISPATCH — Local Shipments access and dispatch.

• EXTERNAL_SERVICE_USER / _DISPATCH / _RECEIVE / _ADMIN — External Services (goods sent out for service) access, dispatch, receipt and admin.

• RO_CREATE — create repair orders (RMAs).

• RO_APPROVE — approve repair orders.

• RO_RECEIVING / REPAIR_RECEIVING — receive incoming repairs.

• REPAIR_ADMIN — approve repair orders at the workflow level.

• REPAIRER — perform actual repair tasks (the floor side of repair WOs).

Other module-specific

• PRODUCT_READ / PRODUCT_WRITE — product master-data.

• BOM_READ / BOM_WRITE — bill of materials.

• MARKETING_READ / MARKETING_WRITE / MARKETING_DELETE — marketing content.

• QMS_ADMIN / QMS_CREATE — QMS doc module.

• CHAT_USE / CHAT_GROUP_CREATE / CHAT_MODERATOR — internal chat.

• ACCOUNTING — accounting menu access; also the universal approver on classification cards.

• DEVELOPER / TESTING — internal-only roles for build/staging access.

• ASSEMBLER — low-level assembler floor access.

2. Areas (warehouse zones)

Areas are physical zones in a warehouse — Production, Stores, Goods Receiving, Dispatch, etc. Stock moves, stock counts, and product-location operations are gated per area.

• A user's allowed areas are loaded into UserAccessProfileDTO.activeAreaIds from user_area_permission and from any AppRole that includes area grants.

• Operations on a location filter by area: SecurityController.canAccessArea(areaId) is checked before the user can pick an item or post a count there.

• Site Admin and VIEW_ALL_AREAS-style permissions bypass the gate.

Area grants are made per user on Admin ▸ Users, on the user's Area Permissions tab.

If a user has the right action permission but the wrong area, the action will fail with a "no access to this area" message — don't troubleshoot it as a role problem.

3. Products

Products can be gated per-user in the same way as areas — a user might have full stock-count permissions but only see specific product lines.

• Loaded from user_product_permission and role-based grants into UserAccessProfileDTO.activeProductGuids.

• Checked via SecurityController.canAccessProduct(productGuid).

• The most common use is restricting a contractor or reseller-staff account to only their assigned product range.

4. Department manager and stand-in (derived, not permissions)

Manager status is not an AppPermission. It is computed from foreign keys on HrDepartment:

• HrDepartment.manager (FK to HrProfile) — the permanent department manager.

• HrDepartment.tempManager (FK to HrProfile) — the temporary cover for today only. The 06:00 scheduler sets this when the real manager goes on approved leave; it auto-clears when their leave ends.

• HrDepartment.tempManagerDate — the date the temp assignment is valid for. SecurityController checks this against today; tomorrow's stand-in does not see today's queue.

A user is "any-department manager" if they manage at least one department directly or one of its parents recursively, or they are HR Admin. That status unlocks the manager-only views:

• Pending Approvals — the unified leave + OT + OT-cancel inbox for everyone in the chain (reached from the dashboard).

• Team Schedules — view and edit shift templates for the team.

• Team Organigram — the org tree with the user's branch highlighted.

• Create Leave for Employee — submit auto-approved leave on behalf of a team member.

Stand-in routing is automatic: when a leave / OT request is submitted and the direct manager has a tempManager set for today, the request routes to the temp manager instead. See Manage your team's leave for the chain-manager detail.

5. Reading the gates in the wild

When a process guide says "this action requires X permission", find the actual gate:

• For a view — open the backing bean and look for @PostConstruct calls to security.enforce…(). The arguments list the exact AppPermission values that unlock the page.

• For a button — search the XHTML for rendered="#{securityController.has(...)}" or rendered="#{userOldView.hasRole('…')}". The first form names an AppPermission; the second is a legacy string-named role.

• For a service-side action — follow security.has(...) calls in the EJB. Often a single permission gates both the button and the underlying service call.

If you find a gate that is not described in this article (or in a process guide that uses it), update this article and the relevant guide in the same change.

6. Common gotchas

• HR_DELETE is HR Admin — that's the actual check isHrAdmin() performs. There is no separate "HR Admin" permission row.

• Site Admin bypasses everything — including soft gates like "only the assigned counter can complete a count". Be careful when an admin acts on behalf of a regular user; some workflows record the actor and the record will say Admin rather than the team member.

• Legacy vs new check styles — older view beans use sessionBean.containsRole("MoveOrderUser") (string name); newer code uses security.has(AppPermission.MOVE_ORDER_USER) (enum). They reach the same underlying grant table but the strings can drift. If a permission seems to work in one view and not another, that mismatch is usually why.

• Permission cache — set on login; only clearCache() (logout + login, or admin-triggered) refreshes. "I just got the role and it doesn't work yet" always means a cache issue.

• Job-position cascade is one-way — assigning a position adds permissions; the same permissions stay if the user later moves to a position that doesn't have them. To revoke, use the explicit role tables.

• Area + product gates are AND, not OR — having permission in Area A and access to Product X does not let you transact Product X in Area B. Both gates evaluate independently for each row.

7. Quick reference — what unlocks what

For each screen, the minimum permission set to enter the main page (additional permissions gate specific buttons inside). The old My Stuff and Operations menus no longer exist: personal shortcuts are quick-link cards on the Dashboard, and the warehouse screens sit under Warehouse, Shipping & Receiving, Procurement & Logistics and Locations.

• Dashboard ▸ My Leave — none beyond a normal account; needs an HrProfile to render the form.

• Dashboard ▸ Pending approvals — ATTENDANCE_* permission or department-manager status (other card types route by their own rules).

• Warehouse ▸ Move Orders — MOVE_ORDER_REQUEST, MOVE_ORDER_USER, MOVE_ORDER_ADMIN or MY_STORE.

• Warehouse ▸ Move Orders — Manage — MOVE_ORDER_MANAGER.

• Warehouse ▸ Bulk Pick — MOVE_ORDER_MOVER or MOVE_ORDER_MANAGER.

• Warehouse ▸ Stock Counts — STOCK_COUNT_USER, STOCK_COUNT_ADMIN, or matching UserWarehousePermissionTypeEnum.

• Warehouse ▸ Stock Check — same visibility rule as Stock Counts.

• Warehouse ▸ Location Management — LOCATION_MANAGEMENT.

• Shipping & Receiving ▸ Purchase Orders — PURCHASE_ORDER_USER.

• Shipping & Receiving ▸ Local Receipts — LOCAL_RECEIPT_USER or LOCAL_RECEIPT_RECEIVE, or the per-area CREATE_LOCAL_RECEIPT / PROCESS_LOCAL_RECEIPT grants.

• Shipping & Receiving ▸ Local Shipments — LOCAL_SHIPMENT_USER or LOCAL_SHIPMENT_DISPATCH.

• Shipping & Receiving ▸ Sales Shipments — SALES_SHIPMENT_USER, SALES_SHIPMENT_DISPATCH or SALES_SHIPMENT_ADMIN.

• Shipping & Receiving ▸ External Services — any EXTERNAL_SERVICE_* permission.

• Locations ▸ Warehouse Locations — any logged-in user; specific actions need LOCATION_PRINT, STOCK_COUNT_ADMIN, etc.

• Locations ▸ Product Locations — PRODUCT_LOCATIONS_VIEW.

• Locations ▸ SerialNumber Location — MOVE_ORDER_ADMIN, SALES_ORDERS_ADMIN or SERIAL_NUMBER_REPORT; moves go through the picking dialog.

• Work ▸ Work Orders — WO_READ or WO_DASHBOARD for the dashboard; per-type access is granted on the Work Order Types page.

8. Where this lives in code

• src/main/java/com/solarmd/mywork/business/system/controller/SecurityController.java — the central gate (enforce…, has, manager checks).

• src/main/java/com/solarmd/mywork/business/wo/access/WoTypeAccess.java — the one shared resolver for Work Order access, used by both the web pages and the REST API.

• src/main/java/com/solarmd/mywork/business/system/entity/AppPermission.java — the enum of every permission name.

• src/main/java/com/unleashed/api/views/user/SessionBean.java — caches the UserAccessProfileDTO and exposes isAdmin(), containsRole(name), hasAreaAccess(), hasProductAccess().

• src/main/java/com/solarmd/mywork/business/system/facade/UserSecurityFacade.java — loads the five sources of permissions on login.

• src/main/java/com/solarmd/mywork/business/hr/enitity/HrDepartment.java — the manager / tempManager / tempManagerDate fields.