# WP2 — Precise fixes: dangling `hrm.training` gate + missing `*.settings.manage`

## Goal
Two independent, surgical fixes: (A) the `hrm.training` menu gate matches NO real permission (dot-boundary rule) → the HR Training menu is visible only to super-admin; retarget it to a real permission. (B) 8 modules lack a `<module>.settings.manage` permission, so their settings fall back to `core.settings.manage`; seed the missing ones so each module's settings can be gated by its own permission (prerequisite for WP5).

## Part A — fix the dangling menu gate (FE)
- **Files:** `/home/moonui2/public_html/moon-erp/src/app/core/config/nav-items.config.ts` (~line 312, the Training item `permissions:['hrm.training']`) and `/home/moonui2/public_html/moon-erp/src/app/layout/sidebar/sidebar.component.ts` (~line 470, same gate).
- **Fix:** replace `'hrm.training'` with a real permission that unlocks the screen. Verify the real key in `RolePermissionSeeder` — it is one of `hrm.training-programs.view` / `hrm.training-sessions.view` / `hrm.training-enrollments.view`. Use the primary VIEW permission of the screen the menu opens (check the route the Training menu item points to and use that screen's `.view`). If the menu covers multiple training screens, use an array of the `.view` perms.
- **Verify:** grep the codebase to confirm no other place relies on the literal `hrm.training` prefix gate.

## Part B — seed missing `<module>.settings.manage` (BE)
- **File:** `/home/moonui2/moon-erp-be/Modules/Core/database/seeders/RolePermissionSeeder.php` (`permissions()`).
- **Add** `<module>.settings.manage` (and `<module>.settings.view` if the module already has a settings screen) for the 8 modules missing it: **accounting, inventory, crm, nphies, einvoicing, pos, production, clinic**. (Present already for core, cmms, hrm, lis, purchases, qms, sales — do not duplicate.)
- Keep it additive and idempotent (the seeder is re-run via `local-deploy.sh`); follow the exact style of the existing `*.settings.manage` entries.
- **Seed into dev:** after editing, run the permission seeder against `moonui2_dev_be` (the additive seeder — NOT `migrate:fresh`) so the new permissions exist for live dev testing. Then `chown moonui2:moonui2` any root-written files and `bash local-deploy.sh`.

## Interfaces
- **Exposes to WP5:** the 8 new `<module>.settings.manage` permissions exist → WP5 can gate each module's settings write path by its own `<module>.settings.manage` instead of coarse `core.settings.manage`.
- **Exposes to WP1/WP3:** `hrm.training-*` menu now grantable → appears correctly in the roles screen.

## Acceptance criteria
- [ ] HR Training menu becomes visible to a non-super-admin who holds the retargeted `hrm.training-*.view` permission (and hidden without it).
- [ ] All 8 modules have `<module>.settings.manage` in the seeder; re-running the seeder is idempotent (no duplicate-key error).
- [ ] New permissions seeded into `moonui2_dev_be`.

## Tests
- BE: `AdditiveRolePermissionsTest`, `SetupPermissionTest` stay green; extend one to assert the 8 new `*.settings.manage` keys exist.
- FE: `ng build` green. (Deploy `/app` after the FE nav change — owner tests live.)

## Flags
- **[FIN]** — no (permission plumbing only, no money path).
- **Migration:** no (seeder only). Serialize: BE part is a BE writer; FE part is a FE writer — do the BE seeder edit and FE nav edit as ONE WP but respect one-writer-per-repo (they're different repos, fine).

## Out of scope
- Do NOT wire the settings write path to the new permissions yet — that's WP5.
- Do NOT redesign the roles screen (WP3).