User Provisioning

Registration is source-defined as a form and provisioning workflow, not as a confirmed reachable endpoint. The registration content declares organizational and role inputs, while imspr/novusoft/include/pages/registration/custom/submit.php source-declares division resolution, credential derivation, user-record assembly, persistence, and a JSON-style completion operation. No retrieved evidence binds the handler to a route, caller, include dispatch, or successful runtime execution.

Source-defined flow

flowchart TD
    f["registration content.php<br/>named fields"] -.->|handoff unresolved| p["$_includeHelper::arrangePost()"]
    p --> q["getRow: tbl_division count"]
    q --> b{"finddiv == 0?"}
    b -->|yes| n["insert: tbl_division"]
    n --> ni["div_id = res[id]"]
    b -->|otherwise| e["div_id = postData[div]"]
    ni --> a["assemble d"]
    e --> a
    a --> c["create_hash_key(8)<br/>SHA-256 password"]
    c --> r["role 1 → 3<br/>other roles → 2"]
    r --> u["insert: tbl_users"]
    u --> s["res[success]"]
    s --> j["jsonexit(res)"]

The registration form is declared in imspr/novusoft/include/pages/registration/content.php. The submit source obtains a post-data collection through $_includeHelper::arrangePost(); the evidence does not prove that the form content is wired to this handler at runtime.

At the division checkpoint, getRow source-declares a count lookup on tbl_division using bound ? placeholders for submitted div and dept values. The handler uses ucwords on the submitted division value for the tbl_division insert and carries either the inserted record's id or the submitted division identifier forward as $div_id. The lookup does not establish a uniqueness guarantee, transaction boundary, or persistence-failure translation.

The handler then source-declares a $d user payload mapping submitted username, full name, email, department, role, designation, and the resolved division identifier to the user record. It requests an eight-unit key through create_hash_key, applies create to the submitted password with that key, and stores both the derived password and generated key in $d. Submitted role 1 maps to user_role_id 3; every other submitted role maps to user_role_id 2.

In source order, the assembled payload is passed to an insert for tbl_users. The handler then derives $res['success'] from the truthiness of $res and passes $res to jsonexit. This is a source-defined response operation, not evidence of a successful user creation or a stable machine-facing API contract.

Registration inputs

The registration content declares these controls:

These are source-declared names and values. The retrieved evidence does not establish field validation, requiredness enforcement, or the runtime handoff from the content file to the post-data collection.

Boundaries before relying on the workflow

[!WARNING] The retrieved source does not establish a registration-specific route, caller, include dispatch, authorization or ownership check, duplicate-user check, or explicit validation. Submitted values are mapped into division and user persistence payloads, so safe rejection of malformed, duplicate, or conflicting registrations is not proven. The generic Startup filter's permission lookup and rejection branch is conditional on the module/json predicate, and the retrieved evidence does not prove that branch guards this registration handler. The credential path uses SHA-256 with a generated hash key; no password policy, credential upgrade path, or successful provisioning record is established.