case 4628 - deleting a work order made from a service request reopens the request

The request's link to the work order item blocked the delete with a database
error (500). Deleting the item now unlinks any request accepted into it and
sets it back to Open, in the same transaction, with a history entry and no
notification. Service request manual page and changelog.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

devdocs/modernization/NET10-PORT.md

@@ -223,7 +223,7 @@ John's "next release" cases for AyaNova (exported 2026-10-24). Each is its own s
 | 4634 | Docs: custom checkbox shows nothing for older records | 1, docs |
 | 4633 | Docs: pg_dump path quoting on Windows (likely fixed by the port; confirm) | 1, docs |
 | 4632 | AYANOVA_REPORT_RENDER_API_URL_OVERRIDE breaks customer notification reports (do before or with 4719) | 1. **Done.** Cause, reproduced on a Windows Server 2025 Hyper-V VM (IIS, https-only site with a host name, as for internet access): AyaNova runs inside IIS (in-process), so nothing listens on `AYANOVA_USE_URLS`; user reports called `http://127.0.0.1:<port of the request>` (443 over https: connection reset), notification reports `127.0.0.1:7575` (refused); the override only fixed user reports, and only where the server reaches itself by its public name. Fix: under IIS the report page's requests under the API URL are intercepted (PuppeteerSharp request interception) and made by the server (`util/ReportApiRelay.cs`) to the local address and port a user's request arrived on, with its host name and scheme (IIS binding and certificate match, no DNS/router hairpin); notification reports use the latest signed-in request, else the override; the page is opened at the API origin so its calls are same-origin; outside IIS nothing changes. The notification token check no longer requires host `127.0.0.1`, only a request from this machine. Proof: VM before (both fail) and after (user report 1.6 s and notification email with PDF, https-only with and without the override); locally 22 stock reports identical with the relay forced on (temporary switch, removed); integration suite = baseline. Manual: IIS install page and override page; changelog |
-| 4628 | Deleting a work order tied to a CSR gives a raw server error | 1, bug |
+| 4628 | Deleting a work order tied to a CSR gives a raw server error | 1. **Done** (the request's `workorderitemid` foreign key blocked deleting the item, a 500 from the database; John chose: delete, unlink the request and set it back to Open, no notification. `WorkOrderBiz.ItemDeleteAsync` does that in the delete's transaction and logs a Modified event on the request; covers deleting the item alone too. Test `WorkOrderFromServiceRequest`: before 500, after 204 and the request Open and unlinked; full suite = baseline. Manual (service requests) and changelog) |
 | 4623 | Docs: migration, what is erased and what is kept | 1, docs |
 | 4602 | Logo upload UI: hide Upload and Delete until usable | 1, client |
 | 4579 | Windows installer modify rights: only the folders AyaNova writes to, only for the account it runs as (includes F2) | 00. **Done** (both installers: no `users-modify` on `{app}` or `local-postgres`; `icacls "{app}" /remove:g *S-1-5-32-545 /T /C /Q` after install removes the Users grant on upgrades too; data folder keeps `users-modify` and `config.json` stays readable by local users, accepted by John and documented in the single-user and LAN install pages. Sandbox: single-user fresh and upgrade over 8.2.4, LAN upgrade; Users modify entries under `{app}` 4632/1281 before, 0 after; trial, login, attachment, backup, report render after upgrade. Found on the way: the downloaded "8.2.4" LAN installer installs server 8.2.3, which fails its integrity check on a new PostgreSQL 18 database (E1030); gone once the 8.3.0 LAN installer is published) |