[FND-169] Create primerized list showing all root types in a project

[dfriquet]

Ticket

https://community.openproject.org/wp/FND-169

What are you trying to accomplish?

Replaces the legacy work package types table in project settings with a Primer list of the type families active in the project, matching the model where a project uses exactly one member per family.

• Border box list of active families, one row per family, the active variant named behind its parent type
• Primary action opens a dialog to activate a type or one of its variants
• Row action deactivates a type, refused — with a link to the offending work packages — while any still use it
• Replaces the two read-only checkmark columns with inline indicators, so the row carries the information without a table:
  • Milestone needs no column of its own — the type icon already renders milestones as a diamond. It now carries a text equivalent instead of relying on shape alone, which also fixes the other three screens using that icon.
  • "In roadmap" reads as muted text on the row
• All four Work packages settings tabs now get a reverse-breadcrumb browser title (Types | Work packages | Project settings | <project> | OpenProject); previously every tab rendered the same <project> | OpenProject
• Gated behind the type_variants flag; with the flag off the legacy checkbox table is unchanged, apart from its form posting to an explicit bulk_update action

Out of scope: switching which member of an already-active family a project uses (FND-187 / FND-188). The dialog only offers families with no active member, so the conflict is unreachable by construction rather than by validation.

Screenshots

What approach did you choose and why?

• Wired the UI to Projects::Types::AddService / RemoveService — the migration UpdateProjectsTypesService documented itself as waiting for. The bulk service now only serves the flag-off table.
• Made the routes RESTful, with the legacy bulk save moved to a bulk_update collection action. The plural collection helper is spelled like the old singular one, so the tab nav and the /settings/types redirect are untouched.
• Family display order lives on Type#sorted_variants / Type#family, read by both this dialog and the admin family list so the two cannot drift.
• The milestone and roadmap indicators are each their own commit, so either can be dropped without touching the rest. Worth a look in review: is_in_roadmap defaults to true, so the indicator currently marks the majority of types rather than the exception.
• Two pre-existing defects found on the way are written up as separate WPs rather than folded in here: Type's default_scope silently defeats callers' .order(...), and ConfigurationLinks::SourceForm labels variants ambiguously.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc) — n/a, new components are outside the namespaces the preview cop covers
• Tested major browsers (Chrome, Firefox, Edge, ...) — Chrome only so far

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #24483, linked for reference only):

- `rspec ./spec/features/projects/lists/filters_spec.rb[1:6:1]`

Treat this as a standalone task, unrelated to PR #24483. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #24483 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @dfriquet to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @dfriquet, and request a review from @dfriquet.
On every commit, set @dfriquet as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Caution

The provided work package version does not match the core version

Details:

• Work package URL: https://community.openproject.org/wp/FND-169
• Work package version: not set
• Core version: 17.8.0

Please make sure that:

• The work package version OR your pull request target branch is correct

[github-actions]

Deploying openproject with ⚡ PullPreview

Field	Value
Latest commit	d718e0f
Job	deploy
Status	✅ Deploy successful
Preview URL	https://pr-24483-fnd-169-primerize-ip-128-140-89-31.my.opf.run:443

View logs