HomeSuper Admin › System Settings

System Settings

Platform-wide settings form for super-admin staff — edits the portal home page title/notes, five configurable menu sections, and SEO meta tags (stored at journal_code = 0). Legacy entry: main/adm.php?_action=main, dispatched into class/adm.class.php's JournalAdmin::sysAdminComments.

Page Status E2E Enhanced Legacy Ref Route Roles
Home Page & Meta Settings Full Yes validation main/adm.php?_action=main /adm?_action=main Super Admin
Audit Logs New Yes /en/super-admin/system-settings/audit-logs Super Admin
Change Password New Yes /en/super-admin/system-settings/change-password Super Admin

Features

FeatureStatusE2EDescription
Admin can edit the portal home page title and rich-text home page notes Full Yes Title is a plain text field, notes a rich-text body rendered on the public portal home page.
Admin can edit the platform Contact Us content Full Yes Rich-text Contact Us block stored in the platform-wide settings row.
Admin can configure up to five custom menu sections (title plus rich-text content) Full Yes Five menu slots feed the public portal's configurable menu sections.
Admin can dynamically add and remove menu sections, with remaining menus reflowing to fill the gap New Yes Removing a menu clears its fields and shifts later menus down so slots stay contiguous.
Admin can edit platform-wide SEO meta description, keywords, and tags Full Yes Split out of the legacy combined form into its own SEO Settings screen.
Admin can maintain the home page, menu, and SEO settings separately per locale (fa/en/ar) Basic Per-locale editing existed in legacy; the ported forms silently edit only the en rows.
Admin sees inline validation errors before saving and cannot save an unchanged form New Yes Save is only enabled when values differ from the loaded originals and pass schema validation.
Admin is warned before navigating away with unsaved settings changes New Navigation-away protection prevents silently losing edits to the page-management form.
Admin gets toast confirmation or error feedback when settings are saved Full Yes Legacy printed a plain saved-message string into the page; the port surfaces success/failure toasts.
Admin can browse a paginated audit trail of system actions New Yes Net-new accountability surface listing who did what, when, and in which journal.
Admin can filter audit logs by action type, journal, date range, and free-text search scope New Yes Advanced filter panel with individually removable active-filter chips.
Admin can export the filtered audit log with background progress tracking New Export runs in the background and reports progress rather than blocking the page.
Admin can change their own password with a live requirements checklist New Yes Submit stays disabled until the current password is entered and the new password meets all displayed requirements.
This module is genuinely a single screen — verified by tracing, not assumed.
The brief's suggested anchors (class/config.class.php, view/country.view.php, custom.lables.view.php, regform.setting.view.php, review.questions.view.php) were traced end-to-end: CountryManager, CustomLables, RegFormSetting, and ReviewQuestionManager are instantiated only from manager.php (ROLE_6, "System Admin") and mng_assist.php — the Publishing Workflow segment's manager/management-assistant role portals — and every one of their queries filters by the *current* journal's journal_code, not the platform-wide journal_code = 0. apps/legacy/spec/admin/user-management/customize-expressions.md confirms this directly: "All operations are scoped to the current journal." main/adm.php (the actual Super Admin dispatch per this segment's source) never references any of these four classes. They are correctly out of scope here.
Action-name collision with the tenant-admin dispatch.
main also exists as an _action value in mainm/adm.php and mainn/adm.php (the tenant-admin dispatch, Journal Admin segment), dispatching to the exact same JournalAdmin::sysAdminComments/::saveSysComments methods — but since neither tenant entry file's link nor the form itself ever passes the orgs parameter those methods check for, this path also reads and writes journal_code = 0, the identical platform-wide row this Super Admin page edits, not a tenant-scoped copy. The Legacy Ref above is qualified with main/adm.php to disambiguate the entry file only, not the data scope.
Borderline overlap with Content Management.
The fields this form edits (home page title/notes, menu section title+body, meta description/keywords/tags) are page *content*, which could plausibly sit under the sibling Content Management module. It is kept here because the legacy UI itself labels the nav entry "تنظیمات سامانه" ("System Settings") and renders it as one settings form rather than an itemized content CRUD list (unlike FAQ/glossary/static pages/sections, which are Content Management's list-style screens).
Dead link, not a row.
main/adm.php's default dashboard menu (Dashboard Overview module) links to adm?_action=emails ("مدیریت نامه ها"), but the dispatch switch has no "emails" case — the request falls through to the default dashboard with no distinct render. Not enumerated as a page per the row-identification method (no materially different screen).
New pages (stage 2)
system-settings/change-password has no legacy predecessor in the System Settings single-screen scope; the same change-password form is also embedded in the super-admin/profile Security tab — a Phase C consolidation candidate.