Loading
fix: #3621957 Fix attachment displays saving with no 'displays' value
Summary
An Attachment display's displays option (naming which display(s) it
attaches to) had no case in ViewsAgentHelper:: getViewDisplayOptionsConfigSuggestions(), so asking the tool what to set
it to returned empty "existing" and "available" values for both - no hint
that real display IDs like page_1 were valid, or that the value is a
keyed map. A live-tested attachment display saved cleanly, passed
validate(), and was completely inert: ViewExecutable::attachDisplays()
found nothing to attach to.
Changes
src/Service/ViewsAgent/ViewsAgentHelper.php: adds a'displays'case to the suggestionsmatch(), returning the View's other real display IDs (via a newgetOtherDisplayIdsSuggestion()method), keyed by themselves - the exact shape the option expects.config/install/ai_agents.ai_agent.views_agent.yml: adds a "Common Workflow: Add An Attachment Display" system prompt section, spelling out the exact{"page_1":"page_1"}value shape and the need to confirm the real target display ID first.tests/src/Kernel/Plugin/AiFunctionCall/UpdateViewPluginsTest.php: addedtestDisplaysOptionSuggestsOtherDisplayIds().
Test plan
- New regression test confirmed failing before the fix (both "existing" and "available" values empty) and passing after.
- Full test file passes on this branch in isolation: 15/15 tests, 126 assertions, no failures.
-
phpcs --standard=Drupal,DrupalPracticeandphpstan analyse(module config, level 1) clean on both changed PHP files. - Retested live against the real agent after the fix: a fresh
attachment-display prompt naming a target display produced the
correct
displaysvalue on the first attempt, and the target display's owngetAttachedDisplays()genuinely listed the attachment back.
Closes #3621957
AI-Generated: Yes (Used Claude Code to identify the bug while testing attachment-display prompts against the shipped Views Agent, diagnose the root cause, implement the fix, write the regression test, and retest live end to end.)