Home › Super Admin › Profile
Profile
The super-admin's own account screen — reached from the "Change Password" link on the Admin Dashboard. main/adm.php's _action=pass case instantiates class/contacts.class.php (Contact_Manager) directly and calls changePasswordForm/changePasswordAction on it; class/adm.class.php (JournalAdmin, instantiated earlier in main/adm.php for the file's other _action cases) plays no role in this screen — it has no reference to Contact_Manager anywhere in its source.
| Page | Status | E2E | Enhanced | Legacy Ref | Route | Roles |
|---|---|---|---|---|---|---|
| Change Password | Full | Yes | tabs | main/adm.php?_action=pass | /adm?_action=pass | Super Admin |
Features
| Feature | Status | E2E | Description |
|---|---|---|---|
| Super-admin can change their own password from the Security tab of their profile page | Full | Yes | Reached from the super-admin area; replaces the legacy adm?_action=pass standalone form. |
| Current password is verified before the change; a wrong current password is rejected with an error | Full | — | Mirrors legacy oldPass check against ju_contacts._password. |
| New password must differ from the current password | Full | — | Same-password reuse is blocked server-side in both stacks. |
| New password strength policy is enforced with a live per-requirement checklist | Full | Yes | Legacy validated only on POST and re-rendered with changeErr; the port shows requirement state as the user types and disables submit until all pass. |
| Confirmation password must match the new password | Full | — | Mismatch shows an inline field error instead of a full-page re-render. |
| User gets success/error feedback and the form resets after a successful change | Full | Yes | Toast-based feedback replaces the legacy 'changed' success screen. |
| Password changes are recorded in the contact action-history audit log | Full | — | Invisible-at-page-granularity side-effect preserved by the port. |
| Super-admin can see their own profile details (name, email, username, join date) on a General tab with a profile hero header | New | Yes | Designed from scratch so the super-admin's account screen is a real profile page, not just a password form; note the profile form hook is disabled for super-admin (enabled: !isSuperAdmin) and no save footer renders on General, so it is effectively display-only. |
| Active profile tab is synced to the URL for deep-linking and reload persistence | New | — | No legacy predecessor; supports linking directly to the Security tab. |
| Two-factor authentication (TOTP) setup from the super-admin profile | Dropped | — | Recorded so Phase E does not re-scope 2FA into this module. |
Only one distinct screen exists under this module.
Tracing every branch of
main/adm.php's _action switch (assign_doi, login, newj, main, preprint, roles, pass, register, report, py_report, revTrack, news, ads, editj, journal, default) turns up exactly one that renders the super-admin's own account UI: pass → Contact_Manager::changePasswordForm() (form) / ::changePasswordAction() (POST handler, same view, no separate route — re-renders with a success/error state via $_PARAMS['changed'] or $_PARAMS['changeErr']). There is no super-admin action that shows a read-only profile view or an editable profile/contact-details form (that flow — addEditContactForm / showContactInfo in contacts.view.php — is only wired up for journal-scoped contacts, e.g. Journal Admin's own "Profile"/"Account" modules).The suggested
gauthenticator.class.php anchor does not apply here — verified, not assumed.class/gauthenticator.class.php (Google-Authenticator TOTP) is only wired to a rendered screen via contacts.php?_action=enable2fa → Contact_Manager::enableTwoFactor() → the enableTwoFactorForm branch of view/contacts.view.php. contacts.php is a standalone, journal-domain-scoped entry file (its default journalCode resolves from the requesting journal's domain), separate from the main/adm.php super-admin dispatch — it is already catalogued under Publishing Workflow's "Contacts" module. Although a super-admin session shares the same $_SESSION[SESSION_NAME_ID] value used by enableTwoFactor(), main/adm.php has no route that reaches it (no enable2fa/twofactor case in its switch, and no link to contacts.php from the admin dashboard), so 2FA setup/disable is not part of the Super Admin Profile module as actually implemented. request/gauthenticator.ajax.php is a pure AJAX/JSON endpoint with no rendered screen of its own, so it is not a row regardless.