Those two files (and main/adm.php) also expose _action=register (a users list) and _action=roles (a role-assignment form) with near-identical markup, but they instantiate class/adm.role.class.php's AdmRoleManager under the platform Super Admin session ($_SESSION['juAdmUser__'], via class/adm.class.php's JournalAdmin) and every query is scoped to ju_contacts.journal_code = 0 — a platform-wide "Editorial Office" staff list, not this journal's own users. That variant does not fit this segment's "one journal's staff" remit and is not claimed here; it is an open gap for a Super Admin sibling module.

manager.php's own top-of-file check only requires a ju_contact_role row with _role = 6 in any journal (no _journal filter) before rendering any row above. Users List, Reset Password, and Manage Roles' save step then separately call ContactAdmin::checkAdminSt(), which is scoped to the current journal and accepts roles 4, 6, or 16 — so a role-6 admin from a different journal can open these screens here, but the underlying save/query still requires role 4/6/16 specifically in this journal. Import Users from Excel and Merge Duplicate Users have no such secondary check at all and rely solely on the page-level gate. The AJAX dispatcher (request/manager.ajax.php, used by Manage Roles/Assign Subjects/Campaign/Merge) applies its own top gate of roles 4/6/16, again with no journal filter.

Per apps/legacy/spec/admin/user-management/admin-email-to-user.md, journal/email.ed.php's own authorization check accepts any authenticated contact with at least one ju_contact_role row — no specific role value is enforced at that endpoint itself (only the Users List link that opens it is gated by manager.php's role-6 check). Recipient lookup still scopes to the current journal.

Per import-users-from-excel.md, role 16 (Editorial Office) can also reach this wizard, but only via the separate mng_assist.php entry point (Publishing Workflow › management-assistant), since manager.php's own page gate is role 6 only. The same spec notes the rendered forms still submit back to manager, so a role-16-only user who starts the wizard from mng_assist fails partway through — an existing legacy inconsistency, not a design choice, and not something this row's Legacy Ref/Route claims.

Unlike Import Users from Excel's broken role-16 variant above, mng_assist.php's role, reviewer, campaign, and merge_dup case blocks (apps/legacy/js/mng_assist.php lines 273–299) are live, uncommented dispatches into the identical RoleManager / JournalCampaign / ContactImport classes used here — unlike its userList and resetpass case blocks (lines 357–377), which are commented out and dead. These four have no render/save split: their save step runs through request/manager.ajax.php, which independently gates on _role IN (4, 6, 16), so all four work completely whether opened from manager.php or mng_assist.php. See Publishing Workflow › Management Assistant, which separately catalogs these same four screens as its own rows and cross-links back to this page.

Per admin-user-list.md's own note, "Editors may have access to a similar user list when the ju_journal_setting value for setting_field = 'eic_custom_opt' includes user_list" — live at editor?_action=userList (apps/legacy/js/editor.php lines 405–423; UI link at view/index.editor.view.php line 585) and, for the Excel variant, at editor?excel=1 (same file, lines 48–58, intercepted before the row-based gate and routed to the identical ContactAdmin::getContactList). Campaign Email to Users is likewise reachable at editor?_action=campaign when eic_custom_opt includes campaign (lines 395–404; UI link at index.editor.view.php line 582). Users List and Campaign Email to Users are separately cataloged as their own rows under Publishing Workflow › Editor-in-Chief (gated role 4); the Excel Export variant via editor.php is not separately cataloged there and is noted only here. Reset Password is also reachable at editor?_action=resetpass — unconditionally, with no eic_custom_opt flag: editor.php lines 69–71 gate role 4 (roles 1/4/9/14 only for track/print/imps), and its case block at lines 429–433 dispatches to the identical ContactAdmin::resetUserPassword; the per-row action link in view/cn.adm.view.php is built from ContactAdmin::mngActionFile, which editor.php sets to "editor" at line 416, so the icon really does point at editor?_action=resetpass when the list is rendered from there. This Reset Password path is separately cataloged as its own row, "Reset User Password (confirmation panel)", under Publishing Workflow › Editor-in-Chief.

Impersonate (manager.php?_action=imps → ContactAdmin::impersonateAsUser) immediately switches the session and redirects to the impersonated user's own contacts?_action=profile (Journal segment) with no admin-side render of its own. Delete (AJAX task=deleteUsr → ContactAdmin::deleteContact, called from the Users List row) swaps a status string into the existing list panel with no navigation. Per this inventory's row-identification rule, pure redirect/AJAX handlers with no distinct rendered screen are not counted as rows, so both are documented here only as behavior of the Users List row's action column (per impersonate-user.md / delete-user.md), not claimed as pages. The same impersonate handler is also reachable at editor?_action=imps for roles 1/4/9/14 (editor.php lines 69–71, 424–428, with an independent UI link on the corresponding-author row in view/manu.view.php line 1624) — same redirect-only behavior, so likewise not claimed as a row there either.

manager.php?_action=reg_form (Registration Form field configuration) sits in the same legacy sidebar group as this table's rows, but it configures the journal's own registration form rather than staff/user management, so it is left to the Account sibling module. Separately, class/cn.adm.class.php defines a blockUserForm/blockUserSave block-user screen (ju_contacts.cn_disabled), but no manager.php action, AJAX task, or link anywhere in the app calls it — it appears to be dead/unreachable code and is not claimed as a row.