Skip to content

fix: pass 'column' argument to CreateAction mutateDataUsing#124

Merged
ManukMinasyan merged 3 commits into
relaticle:4.xfrom
eduardoribeirodev:fix/create-action-column-argument
May 12, 2026
Merged

fix: pass 'column' argument to CreateAction mutateDataUsing#124
ManukMinasyan merged 3 commits into
relaticle:4.xfrom
eduardoribeirodev:fix/create-action-column-argument

Conversation

@eduardoribeirodev
Copy link
Copy Markdown
Contributor

What does this PR do?
This PR fixes an issue where the column argument was missing from the $arguments array in the CreateAction's mutateDataUsing method.

Why is this needed?
The package documentation implies that when triggering a CreateAction from a specific column in the BoardResourcePage board, the developer should be able to capture the column's identifier to automatically assign the status/column ID to the new record.

Without this fix, $arguments['column'] is undefined, requiring workarounds.

Example of what is now possible:

CreateAction::make()
    ->mutateDataUsing(function (array $data, array $arguments) {
        if (isset($arguments['column'])) {
            $data['task_status_id'] = $arguments['column'];
        }
        return $data;
    })

Checklist:

  • I have tested this code in my own project.
  • The code follows the existing style of the project.

eduardoribeirodev and others added 3 commits May 11, 2026 22:17
According to the documentation, the CreateAction should receive the 'column' identifier inside the $arguments array in the mutateDataUsing method. This fix ensures the column argument is properly passed down to the action, allowing developers to know which column triggered the creation.
…ctions

Reproduces issue relaticle#124: a CreateAction registered via columnActions() on a
BoardResourcePage previously dropped the wire:click `column` argument, so
mutateDataUsing() callbacks received an empty arguments array. The fix in
0a7df87 now mirrors upstream InteractsWithActions::resolveActions() and
propagates arguments via mergeArguments().

Adds:
- TestResource + TestBoardResourcePage fixtures
- SchemasServiceProvider registration in TestCase (needed for
  assertSchemaExists macro)
- Pest test using Filament's TestAction macro to call the column action
  with column=in_progress and assert the created Task lands in the right
  column
mutateFormDataUsing was deprecated in Filament 5 in favour of
mutateDataUsing. Both go through the same code path, so this is a pure
naming swap.
@ManukMinasyan ManukMinasyan merged commit 74a4e54 into relaticle:4.x May 12, 2026
3 checks passed
@ManukMinasyan
Copy link
Copy Markdown
Contributor

Thanks @eduardoribeirodev! Merged and shipped in v4.0.12. Added a regression test on top so the column argument stays wired up.

ManukMinasyan added a commit that referenced this pull request May 12, 2026
)

* fix: pass 'column' argument to CreateAction mutateDataUsing

According to the documentation, the CreateAction should receive the 'column' identifier inside the $arguments array in the mutateDataUsing method. This fix ensures the column argument is properly passed down to the action, allowing developers to know which column triggered the creation.

* test: cover column argument propagation on BoardResourcePage column actions

Reproduces issue #124: a CreateAction registered via columnActions() on a
BoardResourcePage previously dropped the wire:click `column` argument, so
mutateDataUsing() callbacks received an empty arguments array. The fix in
0a7df87 now mirrors upstream InteractsWithActions::resolveActions() and
propagates arguments via mergeArguments().

Adds:
- TestResource + TestBoardResourcePage fixtures
- SchemasServiceProvider registration in TestCase (needed for
  assertSchemaExists macro)
- Pest test using Filament's TestAction macro to call the column action
  with column=in_progress and assert the created Task lands in the right
  column

* docs: use mutateDataUsing in column action examples

mutateFormDataUsing was deprecated in Filament 5 in favour of
mutateDataUsing. Both go through the same code path, so this is a pure
naming swap.

* ci: open changelog PR instead of pushing to protected branch

The release-triggered Changelog workflow was pushing the CHANGELOG.md
update directly to 4.x via stefanzweifel/git-auto-commit-action. Branch
protection on 4.x ("Changes must be made through a pull request") rejects
that push, so every release since v4.0.10 has shipped without its
CHANGELOG entry.

Swap the commit-and-push step for peter-evans/create-pull-request, which
opens a PR from chore/changelog-<tag> with the skip-changelog label, then
enable auto-merge (squash) so the PR lands without human intervention.
4.x has no required status checks and 0 required reviews, so auto-merge
clears immediately.

Also tag the PR with skip-changelog so it's excluded from the next
release's auto-generated notes (per .github/release.yml).

---------

Co-authored-by: Eduardo Ribeiro <eduribeiro.films@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants