[myabc]

Ticket

https://community.openproject.org/wp/AUTOWORK-285

What are you trying to accomplish?

Moves status administration dragging off the legacy generic drag controller
and onto sortable-lists. Filtered lists continue to disable reordering.

What approach did you choose and why?

Validates predecessor anchors against global status order, resolves blank
anchors to the start of the requested page, and rejects invalid moves with
422. Successful moves reconcile the list using a Turbo update morph.

Preserves the existing server-backed directional menus because they move
across page boundaries; the shared controller menus only know rendered rows.
The shared legacy controller remains available for other migration surfaces.

Validation: 110 backend examples and 16 browser examples pass, including
native Chrome dragging, pagination, persistence after reload, filtering,
and focus preservation. Changed-line Ruby lint (7 files), ERB lint, and
git diff --check pass. Browser tests used the isolated OrbStack environment
with a worktree-local frontend hostname allowlist and headless Chrome.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (uses the contract documented in [DREAM-774] Document sortable lists in Lookbook #25137)
• Tested major browsers (Chrome verified; Firefox and Edge not run)

[Copilot]

🟢 Approval recommended

The migration is cohesive and well-covered by request/component/feature specs, and the controller enforces clear validation with appropriate Turbo morph updates on success.

Pull request overview

Migrates status administration reordering from the legacy generic drag controller to the sortable-lists Stimulus suite, including server-side anchor-based validation and Turbo morph reconciliation of the list after successful moves.

Changes:

• Replace legacy “position/index” based status drag handling with list_type/list_id/prev_id anchor-based moves and 422 rejection for invalid drop payloads.
• Update the statuses index component wiring to sortable-lists (sortable-lists, sortable-lists--list, sortable-lists--item) including handle targeting and a {id} move URL template.
• Expand request, feature, and component specs to cover anchor moves, pagination semantics, morph updates, and disabled reordering when filtered.

File summaries

File	Description
spec/requests/statuses_spec.rb	Adds request coverage for anchor-based moves, pagination semantics, and invalid move rejection (422).
spec/features/admin/statuses_spec.rb	Updates browser coverage for morph-based reconciliation, focus preservation, and sortable-lists behavior.
spec/components/statuses/item_component_spec.rb	Asserts drag handle is correctly targeted for sortable-lists items.
spec/components/statuses/index_component_spec.rb	Verifies sortable-lists wiring, outlets, URL template, and absence when filtered/empty.
app/models/status.rb	Includes Lists::MoveAfterAnchor and defines the sortable list type constant.
app/controllers/statuses_controller.rb	Implements anchor-based move handling, validation, and Turbo morph update on success.
app/components/statuses/item_component.html.erb	Wires the drag handle as a sortable-lists item target.
app/components/statuses/index_component.rb	Replaces generic drag-and-drop attributes with sortable-lists controller/list/item wiring.

Review details

• Files reviewed: 8/8 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/roles/report_spec.rb[1:1]
• rspec ./spec/features/roles/report_spec.rb[1:2]
• rspec ./spec/features/roles/report_spec.rb[1:3]

🤖 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 #25223, linked for reference only):

- `rspec ./spec/features/roles/report_spec.rb[1:1]`
- `rspec ./spec/features/roles/report_spec.rb[1:2]`
- `rspec ./spec/features/roles/report_spec.rb[1:3]`

Treat this as a standalone task, unrelated to PR #25223. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25223 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 @myabc 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 @myabc, and request a review from @myabc.
On every commit, set @myabc 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.

[myabc]

@dfriquet This is Claude's attempt at a migration, without too much oversight on my part. While I'll try to give this more attention tomorrow, I hope this might be helpful. It's based on previous migrations and the controller mappings described in #25137

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]
• rspec ./spec/features/roles/report_spec.rb[1:1]
• rspec ./spec/features/roles/report_spec.rb[1:3]

🤖 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 #25223, linked for reference only):

- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`
- `rspec ./spec/features/roles/report_spec.rb[1:1]`
- `rspec ./spec/features/roles/report_spec.rb[1:3]`

Treat this as a standalone task, unrelated to PR #25223. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25223 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 @myabc 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 @myabc, and request a review from @myabc.
On every commit, set @myabc 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.

[dfriquet]

attempt at a migration

@myabc The drag-n-drop technically works. But from a UI perspective, it lacks a drop indicator. The backlog buckets have one IIRC.

With the generic implementation, the dragged item takes a faded appearance on its droppable position:

With this version, I can’t see any indicator:

Any idea?

[myabc]

@dfriquet

With the generic implementation, the dragged item takes a faded appearance on its droppable position:

generic-drag-and-drop.controller provided some built-in styling (see frontend/src/global_styles/vendor/_dragula.sass), whereas Sortable Lists does not: it only provides the behaviour.

To receive the full drag and drop treatment, you currently need to do the following:

1. use BorderBoxListComponent rather than plain Border Box.
2. apply .Box-card for an inner container around items.

The project attributes page currently does 1 but not 2: https://qa.openproject-edge.com/admin/settings/project_custom_fields

The introduction of a PlainCard (DREAM-750) should help with make 2 "just work" for most users.

BorderBoxTable should also be adapted so that implementations receive the full drag and drop treatment. We just haven't got to integrating that yet.

Is the lack of styling a blocker for you? We could try to rework styles in this PR, but I would prefer to see the Statuses table migrate to BorderBoxTable first.

My preference would be to:

1. merge this as-is.
2. make BorderBoxTable apply drag and drop styling.
3. migrate Statuses table to BorderBoxTable

D-Team will take care of 2. We can also support with, or implement 3.

/ @HDinger

[dfriquet]

migrate Statuses table to BorderBoxTable

@myabc It went smoothly. I’ll mark this PR for you to review. If that’s what you had in mind, let’s merge it.

[github-actions]

Warning

Flaky specs

• rspec ./spec/features/projects/creation_wizard/project_creation_wizard_spec.rb[1:8:2]
• rspec ./spec/features/work_packages/new/attributes_from_filter_spec.rb[1:3: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 #25223, linked for reference only):

- `rspec ./spec/features/projects/creation_wizard/project_creation_wizard_spec.rb[1:8:2]`
- `rspec ./spec/features/work_packages/new/attributes_from_filter_spec.rb[1:3:1]`

Treat this as a standalone task, unrelated to PR #25223. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25223 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 @myabc 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 @myabc, and request a review from @myabc.
On every commit, set @myabc 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.