admin/raven
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

case 4602 - record

Browse Source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
John Cardinal
2026-10-26 10:11:41 -07:00
parent a9be1ba9e7
commit a715c3913c
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
devdocs/modernization/NET10-PORT.md
View File

@@ -225,7 +225,7 @@ John's "next release" cases for AyaNova (exported 2026-10-24). Each is its own s
| 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. **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 |
| 4602 | Logo upload UI: hide Upload and Delete until usable | 1. **Done** (raven-client: logo form shows file choosers only with change rights, Upload once a file is chosen, Delete only for an existing logo; John added the attachment control's Upload, now shown once files are selected. Import, report template and translation uploads already did this. Checked by John as BizAdmin and BizAdmin restricted. No changelog) |
| 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) |
| 4690 | .NET 10 port umbrella case | 1 |