Skip to content

Cover update and a withheld attribute for block-form permit_params - #21

Merged
lloydwatkin merged 1 commit into
mainfrom
issue-18-additive
Sep 21, 2026
Merged

lloydwatkin merged 1 commit into
mainfrom
issue-18-additive

Conversation

@lloydwatkin

Copy link
Copy Markdown
Member

Follow-up to #19, which fixed all four findings in #18. This closes two gaps in the e2e coverage of the block-form permit_params shape, and documents two behaviours #19 changed but did not describe. No library changes.

1. update was not covered

resolve_permitted gates update as well as create, and #19 added only a create example against Assignment. Reverting the fix in RecordWriter leaves the new update example failing, so the second call site is now covered by something that can actually see it.

2. Nothing proved the block filters

Both branches of Assignment's block — %i[name notes] and %i[name] — permit only columns the fixture already writes, so every example passed whether the block's result was honoured or ignored entirely.

secret_note is a new column neither branch permits, and an example asserts a write never reaches it. Mutating the block to permit secret_note fails that example and no other.

3. Two behaviours left undocumented

The README now says that an associated record's fields are reported under nested whether declared with has_many or with inputs for:, and that a form block declaring no inputs of its own is described from permit_params — both changed by #19, neither described. It also notes that a block-form permit_params is evaluated as the authenticated MCP user.

Testing

rake e2e — 69 examples, 0 failures (67 on main, plus 2).

Both new examples were verified against two separate mutations:

  • reverting resolve_permitted to @config.controller.new fails both;
  • leaving the fix in place but adding secret_note to the block's permitted list fails only the withholding example.

Note on #20

I had an in-flight branch fixing all four findings independently, opened as #20 before #19 landed. Its library diff turned out to be line-for-line equivalent to #19's, so rather than resolve the conflicts and re-land a duplicate, #20 is closed and this carries only the part that was not already covered.

🤖 Generated with Claude Code

Follow-up to #19, which fixed the four findings in #18 but left two gaps
in the e2e coverage of the block-form `permit_params` shape.

`resolve_permitted` gates `update` as well as `create`, and only `create`
had an example. Reverting the fix leaves the new update example failing,
so the second call site is now covered by something that can see it.

Both branches of `Assignment`'s block permitted only columns the fixture
already wrote, so no example could tell a block that filters from one
whose result is ignored. `secret_note` is a column neither branch
permits, and an example now asserts a write never reaches it. Mutating
the block to permit it fails that example and no other.

The README gains the two behaviours #19 changed but did not describe: an
association's fields are reported under `nested` whether declared with
`has_many` or `inputs for:`, and a form block declaring no inputs of its
own is described from the permitted params.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@lloydwatkin
lloydwatkin merged commit 2d981da into main Sep 21, 2026
3 checks passed
@lloydwatkin
lloydwatkin deleted the issue-18-additive branch September 21, 2026 08:50
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.

1 participant