feat: UI Report type filter for roles

[ErikPre]

No description provided.

[Y4nnikH]

Deep review

Reviewer: OpenAI Codex (GPT-5 family). The runtime did not expose the exact served minor revision or the primary reasoning-effort setting; those settings are therefore reported as unavailable rather than guessed.

Findings

#	Criticality	Status	Subject
F1	high	new	Visible can expose a report that the configured role cannot execute
F2	high	new	Visible does not override a globally disabled report type
F3	low	new	The new feature is missing from whats_new_facts
F4	low	new	Newly added inline array arguments violate the repository standard

F1 — Visible can expose a report that the configured role cannot execute

UserConfig.CanUseReportType treats an explicit Visible override as sufficient even when the role has no standard access to that report category (UserConfig.cs:276-284). For example, the new test at ReportTypeVisibilityTest.cs:113-123 explicitly makes Rules visible to a pure modeller. The report page then immediately calls SetBestRoleForReport (Report.razor:414-415), but the fixed role list for device-related reports does not contain modeller (ApiConnectionRoleScopeExtensions.cs:139-142). The real GraphQlApiConnection consequently throws when none of the fixed roles is held (GraphQlApiConnection.cs:174-180). The same mismatch affects any role/report pair newly enabled outside the old category sets; workflow-only roles are additionally excluded by the static reporting-page and REST-controller authorization lists.

This makes a supported configuration appear valid but fail during page initialization or report generation. Please either provide an execution/permission path for every role/report pair that can be set to Visible (while preserving owner and tenant constraints), or prevent unsupported pairs from being configured as visible. Add a test that follows CanUseReportType through real role selection for a formerly ineligible role.

F2 — Visible does not override a globally disabled report type

The accepted plan in issue #5039 says the global setting is the fallback for Inherited, so an explicit Visible value must be able to override it. However, Report.razor:395-398 starts the chooser from userConfig.AvailableReportTypes and only then applies CanUseReportType. A report removed from the global list therefore never reaches the per-role override and cannot be restored with Visible.

Please combine global availability and the per-role tri-state in one central visibility decision, build the chooser from the complete selectable report-type set, and cover both combinations: globally disabled plus role-visible, and globally enabled plus role-not-visible.

F3 — The new feature is missing from whats_new_facts

This is user-facing functionality, but the PR does not update the German and English whats_new_facts lists in roles/database/files/sql/idempotent/fworch-texts.sql:532-560, as required by the repository contribution instructions. Please add synchronized entries for the current 9.4.x feature list.

F4 — Newly added inline array arguments violate the repository standard

The PR adds inline array/collection arguments at SettingsReportGeneral.razor:123 (Except(new[] { ... })) and in ApiConnectionRoleScopeExtensionsTest.cs:77,96 ([Roles....]). The repository instructions explicitly prohibit new[] { ... } and [ ... ] inline arguments in C# production and test code. Please move these values to appropriately named static readonly collections.

Summary and validation

Fix F1 and F2 before merge because they break advertised Visible configurations. F3 and F4 are small required cleanups. No prior numbered human findings, reviews, or review threads existed, so numbering starts at F1 and no earlier rating was changed.

Review depth: deep. Capability: direct two-pass correctness/quality and security review using the FWO review, RBAC, schema-propagation, and installer/upgrade checklists, followed by exact-head validation. The security pass checked authorization/role selection, injection boundaries, secrets, unsafe deserialization/SSRF/TLS changes, and tenant isolation; no separate direct security vulnerability was verified beyond the role-enforcement mismatch described in F1.

Validation on head aea9adbc3f0a66c3971fe52d2a63986fa763a847:

• dotnet format roles/FWO.sln --verify-no-changes --no-restore — passed
• dotnet build --configuration Debug roles/FWO.sln --no-restore — passed with 0 warnings and 0 errors
• dotnet test roles/tests-unit/files/FWO.Test/FWO.Test.csproj --no-build --configuration Debug — 5,318 passed, 17 skipped, 0 failed

Reduced-tier delegation: GPT-5.6 Luna at low reasoning collected the diff/changed-file list/prior review history and performed mechanical coding-guideline, localization, help, whats-new, and test-presence scans. All security analysis, finding verification, severity, reconciliation, and this comment were handled on the primary model.

The environment exposes no subscription-usage meter, so the 25% ceiling could not be measured directly. The review completed within the observable proxy limits: two reduced-tier dispatches, one escalation from standard to deep, one diff/history collection, and analysis restricted to changed files plus direct callers/contracts/tests.

[Y4nnikH]

F1 can be accepted, this is not a real regression. If a report type is allowed globally and then for a role which cannot use it it is set to 'inherit', it will not show (just like before).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud