Upload Token System

This is the authoritative reference for the generic public upload-token product implemented in skyhawk_site_fixes.

Architecture

Public route: /upload/{token}.
Admin route: /admin/skyhawk/upload-tokens.
The public route is owned by UploadTokenForm.
Drupal core managed_file owns file selection, AJAX transfer, validation, and temporary file entities.
Files are stored under private://uploads/[token]/.
No custom synthetic mouse event or parallel direct-upload controller participates in the live product.

Token Lifecycle

A token is valid when it exists, has status active, and has not expired.
Generated tokens have a minimum lifetime of seven days.
A token may be used for multiple upload sessions until expiry or explicit administrative revocation.
A successful upload does not consume or invalidate the token.
uses_count records cumulative finalized files for administrative information only.
uses_allowed = 0 is retained as the unlimited-until-expiry/revocation sentinel for schema compatibility.

Upload Rules

Multiple files may be selected.
Maximum individual file size is 511 MiB (535,822,336 bytes).
The hosting transport ceiling remains 512 MiB for an HTTP POST, so exceptionally large batches may need to be selected/uploaded separately even though each individual file is legal.
After Drupal receives temporary managed files, final submission makes them permanent, records each file in skyhawk_upload_file, increments cumulative file accounting, and sends the configured batch notification.
Completion notifications contain only the files finalized in that batch, not every historical file associated with the token.

Administration

The admin form creates reusable tokens and sends the upload URL by email.
The admin form can explicitly revoke an active token.
Existing contact and purpose data are reused.
The current history table remains operational; conversion to a Drupal View is a later Views-first improvement, not part of the uploader replacement.

Replacement State

The public and admin upload forms were replaced in toto after a discovery audit found contradictory one-use lifecycle logic, a redundant unrouted direct-upload controller, and a custom mobile workaround that duplicated Drupal core behavior.

The old UploadTokenController and upload_token_mobile_fix.js are retired into the timestamped replacement backup rather than destroyed during initial acceptance testing.

Functional acceptance remains pending until the Pixel test verifies: legal multi-file upload, final submission, private storage, history rows, notification, reuse of the same token, explicit revocation, expiry rejection, and oversize rejection.

Current Functional Failure

The replacement public form is live and Chatgpt 4 renders as an active, reusable token. Server-side route, PHP/YAML, database-state, and rendered-page checks are not functional acceptance.

Current Pixel regression result: selecting three legal video files of approximately 56.84 MB, 52.91 MB, and 120 MB (about 229.75 MB total) returns to the upload form with the managed-file field cleared to No file chosen and a red validation state. Final submission therefore cannot begin.

Earlier discovery proved that prior small-file attempts created temporary Drupal file entities under private://uploads. That proves that at least some earlier managed-file transfers reached Drupal; it does not prove the current replacement-path failure occurs at the same stage.

Current diagnostic boundary: token validity, route ownership, and rendered replacement UI are closed branches. The next work must inspect only the transition from Pixel file selection through Drupal managed-file validation/AJAX return and determine the first failing stage. No product rewrite or token redesign is authorized by this failure.

Current Regression Token

Chatgpt 4 remains the regression token while it is active and unexpired. Do not generate another token merely because an upload test fails.