Home › Journal Admin › Profile
Profile
The journal admin's own profile — view and edit. Legacy entry: contacts.php (shared Contact_Manager self-service dispatcher), reached from within the admin back office via the "Profile" link in themes/admin/back/objects/headerMenu.php / quickMenu.php.
| Page | Status | E2E | Enhanced | Legacy Ref | Route | Roles |
|---|---|---|---|---|---|---|
| My Profile | Full | Yes | tabbed | contacts.php?_action=profile | /contacts?_action=profile | Journal Admin (self only — see scope note) |
| Edit My Profile | Full | Yes | validation | contacts.php?_action=edit&_tc=... | /contacts?_action=edit&_tc=<own_contact_code> | Journal Admin (self only — see scope note) |
Features
| Feature | Status | E2E | Description |
|---|---|---|---|
| Admin can view their own profile (name, email, avatar, join date, general/academic/preference details) | Full | Yes | Replaces the legacy read-only contacts.php?_action=profile view; view and edit are one combined page in the port. |
| Admin can edit their general details (title, first/last names, degree, position, phone/mobile/fax, address, city, postal code, country, homepage, alternate email) | Full | Yes | Consolidates the legacy edit form fields into the General tab; country remains a journal-configured dropdown per legacy rules. |
| Admin can edit academic information (specialty subjects, specific field of study, ORCID, affiliation) | Full | Yes | Legacy two-level subject picker semantics (fav_spc=2 user favorites only, manager-assigned rows untouched) must be preserved on save. |
| Admin can set preferences: reviewer availability and news/promotions email opt-in (alert status) | Full | Yes | Legacy shows reviewer_agreed only on self-edit; the port's Preferences tab is inherently self-only since this page is self-edit only. |
| Admin can change their own password from the profile (Security tab and dedicated page) | Full | — | The legacy capability (contacts.php?_action=chpass) is catalogued under Journal > Contact & Auth; surfaced here because the port embeds it in the profile. |
| Admin can upload, replace, or delete their avatar with instant preview and client-side type/size validation | Full | Yes | Legacy avatar was gated by the need_avatar journal setting, stored as filename in ju_contacts.cn_avatar with 512KB / jpeg-png-gif limits. |
| Profile form fields' visibility and required state follow journal configuration (req_fields, no_req_fields, cn_disabled_fields, national code, conditional country dropdown) | Full | Yes | Legacy per-journal setting matrix (including the odd exception fields that clear-on-save but stay visible) is delivered as a server-fetched config DTO. |
| Journal-defined custom profile fields are rendered and saved | Full | — | Legacy custom_fields journal-setting JSON (stxt/ltxt/list types, req flag) stored into ju_contacts.cn_custom_field; used by at least one production journal. |
| Bilingual journals expose second-language name/address/city fields on the profile | Full | — | Legacy required-ness of *_2 fields depends on primary locale not being English plus no_req_fields; labels carry [language] suffixes. |
| Admin cannot change their own email/username from the profile (rendered read-only) | Full | Yes | Legacy showed an editable email input whose value was ignored on self-edit; the port makes the restriction visible instead. |
| Validation errors on hidden tabs are surfaced: error dot on the tab, alert summary, and auto-switch to the first errored tab on save | New | Yes | No legacy predecessor — needed because the port splits one long form across tabs; prevents silent save failures on non-visible fields. |
| Active profile tab is synced to the URL for deep-linking and back/forward navigation | New | Yes | No legacy equivalent; the legacy page was a single untabbed form. |
| Admin can see and switch between their assigned roles from the tenant shell around the profile | New | Yes | Loosely descends from the legacy profile view's clickable role navigation links (self-view only), but is redesigned as shell chrome rather than a profile-page feature. |
| Forced re-entry of name/phone when the contactEdit flag is set on the contact (pre-cleared fields), with reserved-name validation and flag clearing on save | Pending | — | Legacy contacts.class.php pre-clears first/last names and phone when cn_adm_comment.contactEdit=1 for any editor; validation and flag clear run only for admin editors, so on pure self-edit the flag persists (spec 'Inconsistency states'). |
| Profile edits are recorded in contact action history when the journal enables action tracking (save_cn_action) | Pending | — | Legacy writes ju_contact_actions with cn_action_type=3 for self-edit (8 for admin-edit of another contact); no apps/web counterpart found for this background side-effect. |
| CRM sync is triggered after a profile save by a System Admin when crm_url is configured | Dropped | — | Legacy-only hook; deliberately not carried since the setting is never written and unused in production. |
| E-signature image upload alongside the avatar (edb_sign_file setting) | Dropped | — | Legacy stored the e-sign filename in the same cn_avatar column with a _|_ separator; dead in production, no web counterpart. |
| Custom note (register_page_note) displayed above the profile/registration form | Dropped | — | Journal-setting-driven HTML banner atop the edit form; unused legacy capability with no web counterpart. |
| Timezone (cn_timezone) editable on the profile | Dropped | — | Backend read/wrote cn_timezone but no form ever exposed it; nothing user-facing existed to port. |
Scope: only the "view/edit my own record" screens, on a script shared by every role.
contacts.php is the same self-service dispatcher used by authors, reviewers, and every other contact type to view/edit their own record — it isn't admin-specific code. This module claims only the vantage point of a journal admin (a contact holding ju_contact_role._role = 6 for the journal) reaching it via the admin back office's own "Profile" menu item, per apps/legacy/spec/admin/user-management/edit-profile.md. Correction: that menu link (themes/admin/back/objects/headerMenu.php / quickMenu.php) only exists when the journal's theme_back setting is literally "admin" — the default back-office skin is "old" (Classic, per class/theme.class.php's fallback), which has no equivalent header/menu link, so the dek's phrasing should not be read as implying this is the general/default path. The routes themselves remain directly reachable regardless of theme (e.g. via the in-page Edit link at view/contacts.view.php:136) — only the chrome/menu-link visibility is theme-gated.Known duplication with Publishing Workflow › Contacts — flagged, not force-resolved from this page alone.
Both rows above trace to the exact same dispatch/view code as the "My Profile" / "Edit Profile" rows already catalogued in full under Publishing Workflow › Contacts (
Contact_Manager::manageContactAction → ::showContactInfo for the bare _action=profile route; ::addEditContactForm for _action=edit, including the identical form used when an admin edits another user's profile via that user's _tc). Journal Admin › Users carries no row for either screen — its own "Impersonate" note routes the resulting contacts?_action=profile screen to "(Journal segment)", not Users or Journal Admin, so the admin-edits-another-user case does not belong to the Users module as an earlier version of this note claimed (corrected here). Per this inventory's "exactly once" rule this is a genuine unreconciled cross-module duplication — left as an open Phase C/D triage item, the same way the naming-collision and open-flag cases elsewhere in this inventory are flagged inline rather than unilaterally re-homed from a single page.Change Password, 2FA enrollment, and reader extras are deliberately not claimed here.
The same
contacts.php dispatcher also serves Change Password (_action=chpass) — already listed under Journal › Contact & Auth — plus 2FA enrollment (_action=enable2fa), saved manuscripts (_action=records), saved searches (_action=search), and favorite subjects (_action=favsubs), which that page's notes leave as an open Phase C/D triage gap rather than force-fitting into a segment. This module sticks to the two screens the assigned spec anchor actually documents (profile view + edit)."Edit My Profile" is not really self-edit under the hood.
Per the spec, backend behavior branches on whether the requester holds an admin role (
ju_contact_role._role 4/6/16 for the journal) — ContactAdmin::checkAdminSt() — not on whether the edited contact differs from the session contact. So when a journal admin edits their own record here, several "admin-edit" behaviors still apply (e.g. the submitted email address is actually written, and the contactEdit reserved-name check/flag-clear runs) even though it reads as a self-edit screen. Noted here as a genuine implementation nuance, not a page split.