Open flag (unresolved in Phase B): admin/utility screen riding the role-portal router — not a manuscript-lifecycle step. Nearly every row above dispatches into the exact same manager-style classes (SubjectManager, TypeManager, CountryManager, LinkManager, IndexManager, FAQManager, GlossaryManager, AdsManager, NewsManager, CheckListManager, ReviewQuestionManager, EDBManager, RoleManager, ContactImport, JournalCampaign, JUPaymentReport) as the sibling Manager module — kept as its own module only because mng_assist.php is its own role-portal entry point, gated on ju_contact_role._role = 16 rather than manager.php's _role = 6.

CountryManager and GlossaryManager hard-code action="manager" in their views (view/country.view.php, view/glossary.view.php); LinkManager, FAQManager, AdsManager, and NewsManager default their internal fileName/actionFile property to "manager", and mng_assist.php's dispatch — unlike its subject/edb/type/index/checklist/revQ cases, which explicitly reassign the property — never overrides it. manager.php's own top-of-file gate requires a ju_contact_role row with _role = 6 specifically (the same class of bug the Import Users from Excel spec confirms below), so a contact holding role 16 but not role 6 can open Countries, Related Links, FAQ, Glossaries, Ads, and News & Announcements from this page, but every save is silently redirected away and rejected. The Financial Report row has a milder version of the same issue: only its Modern-theme filter/export form hard-codes action="manager?_action=py_report" (the Classic-theme form submits back to itself).

Per apps/legacy/spec/admin/user-management/import-users-from-excel.md's Inconsistency States: "the feature is exposed through both manager and mng_assist, but the rendered forms submit back to manager, and the cancel link also points to manager?_action=import_cn" — a role-16 (not role-6) contact can open the Upload File screen above, but Match Columns and Preview & Confirm both fail once submitted. The same wizard is separately cataloged as a fully working role-6 flow at Journal Admin › Users.

(manager.php, role 6). Unlike the rows in the previous two notes, these four have no render/save split: their data mutations run through request/manager.ajax.php, which independently gates on _role IN (4, 6, 16), so all four work fully whether reached from manager.php or mng_assist.php.

(manager.php, role 6). mng_assist.php's edb case explicitly reassigns $edb->actionFile = "mng_assist" before calling EDBManager::manageEDBActions — and view/edb.view.php builds every link and form action off that property — so, like the Note 4 rows above, both screens render and save correctly end-to-end whether reached from manager.php (role 6) or mng_assist.php (role 16), with no render/save split.

The top-of-file excel/py_excel query params stream an Excel file and exit() before any page renders. _action=imps instantiates Contact_Manager (class/contacts.class.php, per mng_assist.php's own case block at lines 390-394) and calls ->impersonateAsUser($_REQUEST) — but Contact_Manager (and its parent JU_Config) defines no such method anywhere in the codebase; only ContactAdmin (class/cn.adm.class.php:591), which is what manager.php (line 556) and editor.php (line 426) correctly instantiate for their own imps cases, has it. Calling it here throws a PHP fatal error (call to undefined method) instead of performing the redirect, so it's excluded as broken/unreachable rather than as a working no-render redirect. _action=userList and _action=resetpass have page-title mappings in the switch above the content dispatch, but their case blocks in the actual content-dispatch switch are commented out — dead, unreachable code. _action=journal_s, email, sms, backupDb, section, and subscription likewise only set a page title; with no matching case in the content-dispatch switch, they silently fall through to the Dashboard row above instead of rendering a distinct screen.