sort request tasks option in api call + settings

[abarz722]

No description provided.

[tpurschke]

F1 (high) — inventory/group_vars/all.yml:2:

bumps product_version 9.3.4→9.3.5 while develop is already at 9.4.0 (branch is 81 commits behind). upgrade-database.yml only runs files >= installed_version, so roles/database/files/upgrade/9.3.5.sql never executes on systems already at 9.4.0 and the reqCreateRequestTaskSortConfig seed never lands; if the version regression survives the merge, the whole upgrade filter matches nothing.

F2 (high) — roles/middleware/.../Services/CreateRequestTaskSorter.cs:42:

the group_modify split keeps only create/addAfterCreation and delete elements and silently drops every unchanged/modify element. Real group_modify tasks always carry the unchanged members (ModellingVarianceAnalysisObjectsForRequest:401-414; consumed by CheckPointTicketTask:169 / SCTicketTask:219), so a split emits groups missing all retained members.

F3 (medium) — CreateRequestTaskSorter.cs:92:

CloneTask copies Id, Title, AdditionalInfo and re-wraps the same Approvals/RemovedElements into both halves — duplicate ids, duplicated approvals/removed elements, two indistinguishable tasks.

F4 (medium) — Services/FlowRequestService.cs:178:

middleware GlobalConfig is a startup snapshot without subscription (Program.cs:57) and FlowRequestService is a singleton (Program.cs:101), so priority changes made in the new dialog only take effect after a middleware restart.

F5 (medium) — roles/ui/.../CreateRequestTaskSortConfigPopup.razor:92:

Confirm() writes to the DB with no try/catch and no success/error message, unlike every sibling handler in SettingsCustomizing; an API failure kills the Blazor circuit and the admin is never told.

F6 (medium) — CreateRequestTaskSortConfigPopup.razor:72:

nothing stops the admin ordering access before group_create; the sorter honours it (and a unit test asserts it), producing tickets whose access rules reference groups created by later tasks.

F7 (medium) — CreateRequestTaskSorter.cs:15:

FlowRequestService only ever emits group_create and access tasks, so 5 of the 7 orderable rows and the entire allow_task_split flag are unreachable; with defaults, sortTasks:true is a no-op.

F8 (low) — CreateRequestTaskSorter.cs:10:

hard-coded DefaultPriority = 7 only means "last" while priorities stay in 0..6; with wider values (as in the tests) unhandled task types sort near the front.

F9 (low) — roles/ui/.../SettingsCustomizing.razor:111:

new label/button injected into the "API ticket initial state" row, so the Edit button inherits the H5546 tooltip and the row packs 10 grid columns of two unrelated settings.

F10 (low) — .agents:1:

unrelated submodule gitlink bump (recurring in this repo; should be dropped).

F11 (low) — documentation/revision-history.md:611:

changelog mentions only the upgrade seed, whats_new_facts not updated in either language, and the 9.3.5 heading conflicts with develop's 9.4.0 section.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[tpurschke]

Review — standard depth

Finding	Criticality	Status	Subject
F1	high	fixed	Upgrade version and seed coverage
F2	high	fixed	Split group-modify tasks retain existing members
F3	medium	fixed	Split task cloning isolates persisted task data
F4	medium	still open	Changed sort configuration is not observed by middleware
F5	medium	fixed	Settings-save errors are handled in the UI
F6	medium	fixed	Invalid dependency order is rejected in the UI
F7	medium	still open	Most exposed sort settings have no effect for this endpoint
F8	low	fixed	Unknown task types sort last regardless of configured values
F9	low	fixed	API-state tooltip and settings layout
F10	low	still open	Unrelated .agents submodule update
F11	low	fixed	Version history and localized release notes

Open findings

F4 — medium — middleware does not reload the changed configuration

Program.cs creates the singleton GlobalConfig with GlobalConfig.ConstructAsync(apiConnection, true), which leaves withSubscription at its default false. FlowRequestService retains that singleton and reads ReqCreateRequestTaskSortConfig when each request is built. The settings dialog writes the new value to the database, but an already-running middleware instance keeps the startup value, so new API requests continue using the old order until the service is restarted.

Subscribe or reload this configuration in the middleware, and add an integration-level test that changes the value after service construction and verifies the next create-request call uses it.

F7 — medium — five configuration rows and task splitting are unreachable

The only production caller, FlowRequestService.BuildTicket, builds tasks exclusively through BuildGroupTasks and BuildRuleTasks. Those methods emit group_create and access tasks; they never emit group_modify, group_delete, rule_modify, or rule_delete. Consequently, the dialog exposes five sort priorities and allow_task_split that cannot affect any request accepted by this endpoint. The explanatory comment in CreateRequestTaskSorter acknowledges this, but users can still configure no-op settings.

Limit this UI/configuration to task types the endpoint can currently create, or extend the endpoint to construct the advertised task types before presenting these controls as functional.

F10 — low — unrelated submodule bump

The .agents gitlink changes from 6ec355b6... to a073b509..., with no related functional change in this PR. Please drop it or explain why this feature requires that specific submodule revision.

Verification and residual risk

The previous F1–F3, F5–F6, F8–F9, and F11 were checked against head 847af594; the current diff adds the 9.4.1 upgrade seed, preserves retained group members while splitting, clones data before persistence, handles dialog errors, validates dependency order, uses an unbounded default priority, and supplies localized help/release text. No new security issue was found in the added configuration parsing, REST request field, or persistence path.

GitHub CI is green, including the Ubuntu installation test, Python checks, SonarQube, and GitGuardian. I did not run the C# test suite locally because the PR head was not checked out; that is the remaining validation gap. GitHub currently reports this PR as conflicting with develop, so it must be rebased/resolved before merge.

Recommendation: address F4 and F7, remove or justify F10, then resolve the merge conflict. Review depth was standard: primary review covered correctness and the security checklist; changed-file/history collection and scoped conformance checks were delegated to a reduced-tier agent. Usage percentage was not observable, so the review used the skill proxy limits (one delegation and standard depth).