Budgets: store payment files with the private status and delete them with their request - #2086

Why

A budget request's files (the invoices and receipts on a reimbursement or vendor payment request) are classified by their parent. privacy.php decides who may see a file by resolving its post_parent to a live request, and the attachment itself is stored as inherit, like any other upload. So the file's classification lives on a different row than the file, and it holds only as long as that row does.

wp_delete_post() doesn't delete a post's attachments, it points them at the deleted post's own parent, which is 0 for these types, and from then on they are ordinary unattached media. That happens more often than a manual delete suggests: Core purges auto-draft posts older than 7 days, and the Files metabox uploads against the auto-draft the Add New screen opens with, so a request that is never saved leaves its files behind a week later. Cloning a site for a new year copies the media library without the requests and does the same thing in bulk. A census from the sandbox confirmed both shapes exist on the network.

The fix is the same one #1992 applies to sponsor agreements: record what a file is on the file itself, as it is created, and store it private so it doesn't inherit whatever its parent happens to be. The parent rule stays only for files created before this change, until a one-time backfill has marked them.

Two smaller things in the same code. Files on an auto-draft request are missed by the second-pass rules, because get_payment_file_parent_ids() looks requests up with post_status => 'any', which excludes auto-draft. And wp_ajax_get_attachment() resolves by ID and checks upload_files alone, so the media details it hands to JavaScript were never run through the rules the XML-RPC ones already were.

What changed

• A request's files are deleted with the request. before_delete_post on both request types, so Delete Permanently, the trash purge and the auto-draft purge all take the files. Trashing keeps them, and restoring brings them back attached.
• A file uploaded onto a request is stored private, with a _wcorg_budget_file marker and the random suffix, in the request that creates it (wp_unique_filename, wp_insert_attachment_data, add_attachment). An auto-draft request counts.
• A file attached to a request later, through the Files metabox field or the Media Library's Attach action, gets the marker and the status as it is reparented.
• privacy.php reads the marker first and falls back to the parent for files created before this change. read_post is decided alongside edit_post, since private maps it to read_private_posts, which every organizer has. The readers are unchanged: uploader, requester, site admin.
• wp_prepare_attachment_for_js runs through the same redaction as xmlrpc_prepare_media_item.
• The Files metabox names the statuses it queries, so a requester who is only an Author still sees a co-organizer's private upload on their request (WP_Query would otherwise gate it on read_private_posts).
• The SQL guard in exclude_others_payment_files() is two LEFT JOINs instead of a correlated NOT IN subquery.
• A one-time WP-CLI command, wp wc-budget-files scan and backfill, gives existing files the marker and the status. Database only, one site per run, safe to re-run. scan walks wp_blogs by table prefix without loading sites and prints a ready-to-run backfill line per site, with the copies it matched across sites. backfill writes _wcorg_budget_file_backfilled on each file and _wcorg_budget_file_delete on copies, as work lists for later steps; it deletes nothing. The command and its tests get removed after the run.

Nothing here renames or moves a file, and nothing touches the sponsor agreement work in #1992.

Testing

20 new tests in --group budgets, 60 in the group, all passing. The three cascade paths (manual delete, trash purge, auto-draft purge), both attach routes and both upload cases fail against production and pass with the change; trash-and-restore and "an ordinary post is left as Core leaves it" pass both ways by design.

Compatibility: an upload against an ordinary post is untouched (inherit, no marker, no suffix). A co-organizer's upload on an Author's request stays visible to that Author and the submit check still passes. A file from before this change, inherit and unmarked, is still scoped by its parent. Deleting a request as a co-organizer who can't see another organizer's upload on it still takes that upload.

Deployment: scan and backfill --dry-run run on the sandbox before merge, read-only. After deploy, backfill once per listed site (central needs --yes-main-site), then the command gets deleted.

One thing found on the way and left alone: an organizer can't trash their own draft request, because set_request_status() clamps trash out of the requester status set. The trash tests run as a network admin for that reason. Separate ticket.

🤖 Generated with Claude Code