Compare menu and catalog
Collect sidebar paths. Read every menu path in Sidebar/index.tsx, including items inside a group. This is the list of screens a person can see in the side menu.
Collect screens.json paths. Read every path in the role catalog. This is the list the Roles page can tick under Screen access.
List missing menu items. A sidebar path that is not in screens.json never appears as a tick, so Save role cannot grant it. The menu hides it for every role.
List screens that have no menu item. A catalog path with no sidebar item can still be ticked and can still block a direct URL. Leave it in the catalog. It is not a missing menu item.
Register missing paths
Add each missing screen. Add the sidebar path to screens.json with the same path. After a backend restart, that label shows in a group on Screen access. Nothing is granted yet.
Check ids and routes. id is what gets stored in screenIds when you tick and save. routes must include that same path, or the menu check and the URL check will not match the tick.
Leave defaultRoles.json unchanged. That file runs only the first time a company gets screen-rbac. Existing companies keep their saved ticks. New labels start unticked.
Restart and confirm the labels appear. Restart the backend, open Roles & Screen Access, and confirm each new name is in its group. Selected only stays empty for that screen until you tick it.
Add one new screen
Build the page and route. The new page needs a URL on the dashboard, the same way Roles & Screen Access is /settings/roles.
Add the sidebar item. Use that same path in the side menu. The menu shows it only after the active role has that path ticked.
Add the catalog entry. Put the same path in screens.json. That is what makes the name appear under Screen access.
Restart. The backend reads screens.json at startup. Until it restarts, the new name will not show on the Roles page.
Tick it on a role and save. Select the role, tick the new screen, and click Save role. That writes the screen id into screen-rbac for that role only.
Prove that role
Open it with the tick. Sign in as a user who has that role. The side menu shows the new item and the page opens. This uses the same menu check already used for every other ticked screen.
Block it without the tick. Sign in as a user whose role does not have the tick. The item is hidden, and opening the URL directly is blocked. This is the existing screen guard, not a new check.
Check the Users role list. On Users, the role dropdown shows only the roles that person is allowed to assign. Assign user roles plus Roles this role can assign already do this. Manage roles and permissions still shows every normal role.
Delete a role onto a replacement. Delete a test role, choose the replacement, and confirm that user then sees the replacement role's screens. Delete role and Delete and move users already do this.