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

case 4579 - Windows installers: program folder no longer writable by all users

Browse Source 
Both installers drop users-modify from the program folder (and local-postgres
in the single-user installer) and run icacls to remove the Users group's own
grants (by SID) from the program folder after copying files, so upgrades over
8.2.4 lose them too. The data folder keeps users-modify and config.json stays
readable by local users (the running account is not known at install time);
both documented in the single-user and LAN install pages. Changelog updated.
F2 fixed (write access), the rest accepted. Deferred: report on a missing
record fails with a generic error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
John Cardinal
2026-10-25 14:39:00 -07:00
parent c04de33af2
commit e9b79242fd
7 changed files with 18 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -224,7 +224,7 @@ John's "next release" cases for AyaNova (exported 2026-10-24). Each is its own s
| 4628 | Deleting a work order tied to a CSR gives a raw server error | 1, bug |
| 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. **Next (plan proposed 2026-10-24, awaiting John's approval):** remove `Permissions: users-modify` from `{app}` (both installers) and `{app}\local-postgres` (standalone); after install run `icacls` to remove the Users group's granted rights (by SID `*S-1-5-32-545`, not the localised name) from `{app}` (and `local-postgres` with `/T`) so upgraded installs lose them too; keep `users-modify` on `{commonappdata}yanova` (the running account is unknown at install time), recorded as accepted with a manual note. Nothing writes to `{app}` since 8.3.0 (data paths, signing key, report browser all under ProgramData; the launcher writes only there). Proof on John's sandbox: fresh install and upgrade over 8.2.4 of each installer, login, report render, backup, attachment, standalone PostgreSQL start/stop, `icacls` shows no Users (M) on `{app}`. Changelog: "Windows: the installers no longer give all local users write access to the AyaNova program folder." |
| 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 |
Sockeye cases (exported 2026-10-24): 4710 (also in the table above) and 4681. 4681 predates the review: a trial request with a made-up address made Sockeye send its verification email, which bounced to support@ (Fastmail notice, 2026-10-16).
@@ -273,6 +273,7 @@ Found during the port, out of scope. One line each.
- Linux desktop manual (`ops-install-linux-desktop.md`), pre-existing, same in 8.2.4: `sudo mkdir ~/.ayanova-data` creates the folder in the user's home, but `sudo ./AyaNova` runs as root, so `AYANOVA_DATA_PATH` `~/.ayanova-data` resolves to `/root/.ayanova-data` and the user's folder is never used (data, logs and backups end up under `/root`). Found in the 8.3.0 desktop zip test. Fix the manual (absolute data path, or not running as root) after the release
- **Own case after the port (John):** the subscription server setup script is hard-coded in `biz-subscription-server.vue`, so every change needs a new Sockeye client build. Make it editable without a rebuild
- **Improvement, own case after the port (John to create):** bring back logging of JavaScript error details from report page console errors, as Sockeye's port did. AyaNova logs only `ERROR: {message text}`; the per-argument detail (`arg instanceof Error ? arg.message : arg`) is commented out at `biz/ReportBiz.cs:873-876` since case 4586, because `IJSHandle.ExecutionContext` was removed. Sockeye 8.1.0 (`server/biz/ReportBiz.cs:575`) evaluates on the handle instead: `args.Message.Args.Select(arg => arg.EvaluateFunctionAsync("(arg) => arg instanceof Error ? arg.message : arg"))`, which also needs the console handler to be `async` again
- Pre-existing, same in 8.2.4 (found in the 4579 sandbox test, John: Deferred): rendering a report for a record that does not exist (e.g. work order ids 1 and 2 in a trial without sample data) fails the job with a generic `ArgumentNullException` ("Value cannot be null. (Parameter 'o')") from `JObject.FromObject` in `WorkOrderBiz.GetReportData` (`WorkOrderBiz.cs:1030`), instead of skipping the missing record or saying it is not found. Other object types' `GetReportData` likely do the same
## Log