Status and Approval

Status handling is split across presentation controls, submit-time update preparation, and custom status-count/BAC includes. The source defines these relationships, but it does not establish that UI role restrictions are enforced server-side or that a database write succeeded in a deployed runtime.

Status relationships

flowchart TD
    ui["approval-section.php: PENDING, APPROVED, DISAPPROVED, CANCELED"] --> submit["non-delete status submit preparation"]
    submit --> posted["pr_status = posted status"]
    submit -. "PPMP status absent" .-> pending["pr_status = PENDING"]

    disapproved["current pr_status = DISAPPROVED"] --> rerequest["non-empty rerequest_remarks"]
    rerequest --> pendingAgain["pr_status = PENDING"]
    rerequest --> reapproval["consolidated = FOR RE-APPROVAL"]

    approved["pr_status = APPROVED"] --> consolidate["consolidated = FOR CONSOLIDATE"]

The status assignments are prepared by the submit includes and handed to the generic component submission flow, where postProcess receives the update for the selected record. This is a source-defined handoff, not evidence of a successful persistence operation.

Status-count variants

All four custom includes read the posted year, filter to rows where deleted = 0, group by pr_status, normalize the grouping key to lowercase, and count pr_catalog_id. Role 1 uses all matching rows; other roles add a user_id_created filter equal to the session user ID.

Each include places the keyed counts in statuscnt, sets success to true, and exits through the include JSON response path. No exact HTTP route, client caller, or deployment reachability binding was established, so these are not documented as stable machine-facing API contracts.

The role-based query branch is a data filter. It is not proof of complete authorization or resource-ownership enforcement.

Approval and re-request handoff

imspr/novusoft/include/pr/view/approval-section.php renders the approval section only when the editor is in edit mode and the current role is not 3. The section exposes these posted status values:

• PENDING
• APPROVED
• DISAPPROVED
• CANCELED

It also exposes status_remarks.

The re-request section has a narrower UI predicate: edit mode, current pr_status equal to DISAPPROVED, and current role not 1. It displays the existing disapproval remarks and accepts rerequest_remarks.

The submit consumers then handle those fields differently for non-delete submissions:

• imspr/novusoft/include/ppmp-management/submit.php uses the posted status when present and otherwise assigns PENDING.
• imspr/novusoft/include/pr-catalog/submit.php assigns pr_status directly from posted status when present; it defines no fallback status.
• In both submit paths, a non-empty rerequest_remarks value overrides the status to PENDING, sets consolidated to FOR RE-APPROVAL, and records the status actor, timestamp, and session user ID.
• When the resulting pr_status is APPROVED, both paths set consolidated to FOR CONSOLIDATE.
• In the purchase-request catalog path, the assignments for status_remarks and account_desc are commented out. Those posted values are therefore not populated by that path.

[!WARNING] The approval UI predicates control what the editor renders; the inspected status-submit paths do not show a corresponding role, ownership, or status-allowlist check around the posted assignments. Do not treat the visible options or hidden sections as a complete server-side authorization contract.

BAC action boundary

imspr/novusoft/include/view-ppmp/custom/bac-action.php reads posted id and action, then updates tbl_ppmp where ppmp_id equals the posted ID:

• APPROVED maps to approved_1 = 1 and rev = 2.
• Every other action value maps to approved_1 = 2 and rev = 1; unknown values are not rejected by an action allowlist.
• The active audit write targets tbl_mother_ppmp_log.
• The legacy tbl_ppmp_log insert is commented out.

[!CAUTION] The inspected BAC path does not establish a role, ownership, or action-allowlist condition before the update. The source declares the update and audit handoff, but no execution record proves that either write succeeded in a running deployment.