Home › Super Admin › Subject Management
Subject Management
Manages the platform-wide "Portal Subjects" taxonomy (ju_subjects.journal_code = 0) used to classify journals for portal browse/search, and the journal↔subject linking matrix. Entry files: mainm/adm.php and mainn/adm.php (super-admin dashboards), backed by class/subject.class.php / class/adm.role.class.php and rendered by view/subject.view.php.
| Page | Status | E2E | Enhanced | Legacy Ref | Route | Roles |
|---|---|---|---|---|---|---|
| Manage Subjects | Full | Yes | quick-view | mainm/adm.php?_action=subject | /adm?_action=subject | Super Admin |
| Assign Journals to Subjects | Full | — | — | mainm/adm.php?_action=sb_jour | /adm?_action=sb_jour | Super Admin |
Features
| Feature | Status | E2E | Description |
|---|---|---|---|
| Admin can view the list of platform-wide Portal Subjects | Full | Yes | Legacy flat two-column table (name + edit/delete icons) becomes a paginated list card with per-row status badges and journal counts. |
| Admin can add a new subject with English and Arabic names and an enabled/disabled status | Full | Yes | Legacy optional second-language name (shown when juLocales==2 or portal scope) is now a required Arabic name; add happens in a drawer instead of an inline form. |
| Admin gets inline client-side validation on subject names (required, English/Arabic script checks, duplicate-name detection) | Full | Yes | Duplicate and script errors surface inline per-field instead of a full-page duplicateErr banner re-render. |
| Admin can edit an existing subject (names, status) | Full | Yes | Legacy edit navigated to the same page with ?_ts=<code> pre-filling the inline form; web opens a drawer from the row's actions menu. |
| Admin can delete a subject with explicit confirmation | Full | Yes | Legacy blocked deletion only when child subjects existed (MNG_SUBJECT_RELATED_RECORD_ERR); web has no hierarchy so it instead transactionally deletes the subject's journal links then the subject. |
| Admin can drag-to-reorder subjects and persist the new order | Full | Yes | Legacy required pressing a separate Save button after jQuery-sortable dragging; web persists via server action with reorder eligibility rules. |
| Admin can enable/disable a subject directly from the list | Full | Yes | Status flip is now a one-click list affordance rather than an edit-form dropdown. |
| Admin can organize subjects in a parent-child hierarchy (main subject + indented sub-subjects) | Dropped | — | Legacy let each subject pick a top-level parent and rendered children indented under parents with their own numbering; no web counterpart exists. |
| Admin can live-search subjects by name | New | Yes | Search resets to page 1 and shows a dedicated no-results state with a clear-search action. |
| Admin can filter subjects by Active/Inactive status | New | Yes | Status filter is a menu with All/Active/Inactive options. |
| Admin can sort the subject list by order, name, or status (asc/desc) | New | Yes | Choosing a non-default sort disables drag-reorder, which the banner and tooltips explain. |
| Admin can page through subjects (10 per page) with auto-correction when the last page empties | New | — | Page state is URL-synced so paginated views are shareable/bookmarkable. |
| Admin can quick-view a subject in a side panel, including the journals classified under it | New | Yes | Gives a read-only per-subject view of journal assignments — the closest surviving trace of the legacy subject-centric sb_jour matrix. |
| Admin can set which Portal Subjects a journal belongs to from the journal's add/edit form | Full | — | Assignment direction is inverted: per-journal multi-select instead of the legacy per-subject checkbox-every-journal matrix. |
| Admin can bulk assign/unassign every journal for one subject on a single dedicated screen | Dropped | — | Legacy AdmRoleManager::saveJournalSubject did a delete-then-insert sweep of ju_article_subject for the selected subject in one save. |
| Subject create/edit/delete operations are recorded in the admin action-history audit trail | Full | — | Edit entries additionally note status transitions in the action comments — richer than the legacy comment (subject name only). |
| The 'report-only' super-admin account (contact code 3) is blocked from subject management | Pending | — | Legacy quirk: mainm/adm.php lines 63-70 short-circuit that account to report actions only, while mainn/adm.php has no such gate; no apps/web counterpart of a report-only super-admin restriction was found for this module. |
The suggested anchor
main/adm.php has no working _action=subject route — verified dead.The plainer super-admin dashboard at
main/adm.php shares class/adm.class.php's addNewJForm() with mainm/adm.php / mainn/adm.php, and that shared form always renders an "add subject" shortcut link (href="adm?_action=subject" target="_blank") next to the subject picker. But only mainm/adm.php and mainn/adm.php have a case "subject" (and case "sb_jour") in their _action switch — main/adm.php's switch has no such case at all, so following that same link from main/adm.php silently falls through to default and just re-renders the dashboard instead of opening subject management. Both rows above are therefore sourced from mainm/adm.php (identical dispatch — same case "subject" / case "sb_jour" handler classes — also present verbatim in mainn/adm.php; see below for a session-gate difference between the two files).Blocked for the "report-only" super-admin account —
mainm/adm.php only.mainm/adm.php (lines 63–70) short-circuits before entering the _action switch whenever the logged-in $_SESSION['juAdmUser__'] contact code equals 3, allowing only "", report, arst_report, act_report, and pass — so that account cannot reach either row via mainm/adm.php. mainn/adm.php has no equivalent check: the same account logged in through mainn/adm.php can reach both _action=subject and _action=sb_jour normally, since that file's dispatch has no report_only/session-gate short-circuit at all.Not claimed here — read-only consumers of the same Portal Subjects pool live in the Journals module.
The subject checkbox picker inside "Add New Journal" (
adm?_action=newj, writes ju_article_subject on journal creation) and the "Subject" filter dropdown on the Journals List (adm?_action=list / _action="") both read from the exact same ju_subjects WHERE journal_code = 0 pool this module manages, but they render inside Journals-module screens — flagging so they aren't mistakenly re-added as rows here.