Home › Publishing Workflow › Response
Response
Legacy entry: response.php, view: view/index.response.view.php. A menu-less payment bridge — renders the author's manuscript-fee payment screen and doubles as the return/callback target for every configured online bank gateway (class/payment.class.php's JUPayment); it has no navigation entry of its own in any role's menu.
| Page | Status | Workflow | E2E | Enhanced | Legacy Ref | Route | Roles |
|---|---|---|---|---|---|---|---|
| Manuscript Fee Payment | Pending | — | — | — | response.php?manupm=... | /response?manupm=<manuCode>[&pr_py=<paymentCode>] | Author (manuscript owner intended; requires sign-in — redirects to contacts?_action=loginForm otherwise; ownership not server-enforced, see note) |
| Manual Payment Receipt Upload | Pending | — | — | — | response.php?manupm=... | /response?manupm=<manuCode>[&pr_py=<paymentCode>] | Author (manuscript owner intended; requires sign-in; ownership not server-enforced, see note) |
| Online Payment Gateway Bridge | Pending | — | — | — | response.php | /response | Author (manuscript owner intended; requires sign-in; ownership not server-enforced, see note) |
Features
| Feature | Status | E2E | Description |
|---|---|---|---|
| Author can open a manuscript-fee payment screen showing the editor-assigned fee amount, currency, the editor's note, and the journal's payment instructions | Pending | — | response.php?manupm=<manuCode> looks up the latest pending payment (payment_status=1, or a specific pr_py code) for the manuscript and renders the fee, currency label, reviewer_note and the journal's configured payment_note text; no apps/web counterpart exists. |
| Author can pay a manuscript fee online through the journal's configured bank gateway (~19 supported providers) and the system verifies the gateway callback and records the transaction | Pending | — | JUPayment::checkOnlinePaymentOptions dispatches to the gateway chosen by the per-journal online_py_option setting, with response.php hardcoded as every gateway's return/callback URL and saveTransaction persisting the confirmed transaction code. |
| Author must click an explicit Start Payment confirmation button before being redirected to the online gateway (payment_type=1), while card payments (payment_type=3) go straight to the gateway | Pending | — | managePaymentActions case 1 renders a fee summary plus a go_py confirmation form and only invokes the gateway after Start Payment, while case 3 calls checkOnlinePaymentOptions unconditionally with no confirmation-guard step. |
| Author can upload a manual (bank-transfer) payment receipt file with an optional note, which marks the payment as awaiting admin confirmation | Pending | — | JUPayment::manualPaymenForm renders a CSRF-tokened upload form (payment_type=2) and saveManualPayment validates file type/size, sets payment_status=3, stores the note, and advances the manuscript to status 43 with a tracking entry. |
| Manuscript status automatically advances to payment-received (manu_status 43 / pstatus 42, wait-for-response) with a tracking-history entry when a fee payment is confirmed | Pending | — | saveTransaction (online) and saveManualPayment (manual) both update ju_manuscript and call ManuManager::saveManuTracking, recording the transaction code or the author's payment note in the manuscript history. |
| Author is emailed a payment-receipt confirmation when an online fee payment is confirmed | Pending | — | saveTransaction sends the after_payment email template via EmailManager::emailsToAuthor with the transaction code and fee amount (payment.class.php:2887-2890). |
| Reserve reviewers are automatically activated after payment confirmation: their assignments switch to active, due dates are recalculated from today, and invitation emails go out | Pending | — | checkForReserveReviewers (payment.class.php:2998) runs after online-payment confirmation when the journal's reserve_rv setting is enabled, flipping assign_status 3 to 1, setting manu_status=4, and emailing each reviewer (manu_to_reviewer / chief / revised variants). |
| Author paying a submission-step fee online is routed back into the submission wizard after confirmation instead of the generic success notice | Pending | — | For payment_source=6, saveTransaction/saveManualPayment set ju_manuscript.l9=1 and render a link back to author?_action=submit&nst=9 so the author resumes the wizard's payment step. |
| A payment that is already confirmed cannot be charged or processed again — the author sees a one-line already-confirmed notice with the transaction code | Pending | — | Both the session-tracked payment_code guard in managePaymentActions (payment_status=2 short-circuits before checkOnlinePaymentOptions) and the duplicate check at the top of saveTransaction display MANU_PAYMENT_CONFIRMED_PREV instead of reprocessing the callback. |
| A signed-out visitor hitting the payment screen is redirected to the login form and returned to the exact payment URL after signing in | Pending | — | response.php stores the full query string in $_SESSION['pLoc'] and redirects to contacts?_action=loginForm; the only access gate is any signed-in session — ownership of the manuscript is not server-enforced. |
| Author sees an awaiting-payment bucket on the dashboard/manuscripts list with a Continue Payment link for fees the editor has assigned | Basic | — | The list/bucket side is ported, but completing the payment still requires the un-ported legacy response screen — a deliberate bridge, not a full port. |
| Reader can purchase paid article access through the response screen (article_code branch) and get an immediate PDF download link on confirmation | Dropped | — | The capability itself lives on in the jufile module; within response it is unreachable dead code and is deliberately not counted as a page row. |
Open flag.
This module appears dead/unused in legacy (a single action, no clear caller found). Kept for completeness; expected to be dropped rather than ported.
Tracing note (qualifies the open flag above).
response.php's own _action switch really does define only one case (guide), and no role menu links to the file directly — matching the "1 action, no clear caller" framing. However the file is not orphaned in the sense of never being reached: it is hardcoded as the return/callback URL for every one of the ~19 online-payment gateways in class/payment.class.php (JUPayment::checkOnlinePaymentOptions and its per-gateway *Form/*Confirm methods), and view/submit.manuscript.view.php links an author's manuscript row directly to response?manupm=... to pay an editor-assigned fee. So it is reachable — just never from a menu, only as a generated link/callback target — which is consistent with it being a thin bridge screen rather than a proper role portal.Dead code inside the module.
The
guide case in response.php's _action switch only sets a breadcrumb label (MENU_GUIDE_FOR_AUTHORS) — it is a copy-paste leftover from the working guide case in author.php/reviewer.php, but here it changes no rendered content and no link in the codebase ever constructs response?_action=guide. Likewise, view/index.response.view.php is required only by response.php, which always passes $FUNCTION = 'breadcrumb' — so the file's modal, default (a mng_assist-style options panel), and startScript branches are never invoked and are not counted as rows.The
article_code branch of JUPayment::managePaymentActions (reader article-purchase payment) is not counted as a row here: no code path in the app constructs a response?article_code=... link — that flow is served through jufile.php, the payment class's other caller, instead."Payment Already Confirmed" (shown when a session-tracked
payment_code is already at payment_status = 2) is a guard branch inside the Online Payment Gateway Bridge row above, not a separate row — it short-circuits before checkOnlinePaymentOptions runs and shows a one-line confirmation notice instead of re-processing the gateway callback.Roles caveat.
"Author (manuscript owner)" above describes UI-reachability, not a server-enforced restriction.
response.php's only gate is $_SESSION[SESSION_NAME_ID] (any signed-in contact, no role check), and JUPayment::managePaymentActions()'s manupm query (class/payment.class.php lines 95–102) filters only by manu_code (+ optional pr_py / payment_status = 1) — no contact_code ownership predicate. The response?manupm=... link is only ever printed on the author's own manuscript list (view/submit.manuscript.view.php line 425), which is why "Author" holds in practice even though nothing server-side enforces it — the same session-only gating pattern appears in sibling files like author.php.