anjaliprasannan ā made their first commit to this issueās fork.
Changes done:
- Adds a āDisable Automatorā checkbox to AiAutomatorTypeForm
Ensures disable state is:
- Stored on the automator entity
- Reflected in automator type settings
- Synced across all attached automator types
Finalizes AiChainForm to:
- Separate enabled and disabled automators
- Persist divider position via config
- Render rows in correct order
- Disable automators based on divider position
- Keep execution order (weight) and visual order consistent
Keep all automators unless they are explicitly marked as disabled in their settings.
I agree this is the right direction for 2.x, and I also think itās worth having the discussion precisely because Automators are so widely used.
The benefits of structured output clearly outweigh the downsides in the long term. A major version feels like the correct place to make this shift.
The main risk I see isnāt correctness but behavioral change: longer automator chains may implicitly rely on model quirks that structured output will eliminate. In most cases that will be positive, but it does mean outcomes may change even when prompts stay the same.
To make this safer, it would be good to:
- Clearly document this as a breaking behavioral change, not just a technical one.
- Validate provider/model support early and fail loudly when structured output isnāt available.
With those guardrails in place, Iām strongly in favor of making this the default in 2.x.
@marcus_johansson
Iām noticing several changes in AI Automators 2.0 compared to when I last worked on it. The AI Automators tab now appears instead of AI Automator Order at
/admin/structure/types/manage/article/automator_chain.
There is also an Add automators button on this page, which helps add field automators and redirects to
/admin/config/ai/ai-automators/fields.
It looks like the same UI is now being used in both places:
/admin/structure/types/manage/article/automator_chain
/admin/config/ai/ai-automators/fields
Additionally, I no longer see a weight field in the AI Automators UI.
Given these changes, Iām unsure how the disabled automator functionality should be handled now.
Should this feature be implemented in both locations, or is there a single canonical place where this logic should live?
anjaliprasannan ā changed the visibility of the branch 3542602-use-an-exiting to hidden.
Yeah I just saw that issue and its working fine.
Hence marking this as RTBC
@mErilainen Can you add the steps to test the fix.
Steps I followed.
- Created a new entity reference field (tried with content, taxonomy, list, others)
- I already had a entity reference field.
- Checked enabled ai automator
In Choose AI Automator Type I only had LLM: Entity reference and LLM - taxonomy, LL List in respective cases. There was no "Use existing entity"
Can you guide with proper steps if I am missing any.
anjaliprasannan ā made their first commit to this issueās fork.
Tested the patch and it fixes the requirement. Attaching the screenshot.
Created MR out of patch
Moving to RTBC.
anjaliprasannan ā made their first commit to this issueās fork.
@svendecabooter I have tested your patch and it works fine for the ckeditor plugins.
settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_help
settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone
settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate
where undefined before the fix
and post fix their types has changed to ckeditor5.plugin.ai_ckeditor_ai.ai_ckeditor_*
But I see settings.plugins.ai_ckeditor_ai.plugins.ai_automators_ckeditor is undefined. should n't we apply the same fix for ai_automators.schema.yml?
Reviewed and optimized the code. pipeline is failing due to composer issue.
anjaliprasannan ā made their first commit to this issueās fork.
@marcus_johansson Once you confirm I can merge the PR.
Thanks
Uploading a patch out of the MR for my project use.
Adding patch for SharedTempStoreFactory $expire variable
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
Please review the code.
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
I have reviewed. its working fine. Code also LGTM.
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
@mglaman Code LGTM. Added a suggestion.
anjaliprasannan ā made their first commit to this issueās fork.
Great work! @Sijumpk. I have reviewed and the menu agent is working fine. Only thing is you no need to specify to install drupal cms in steps to reproduce, we can test in drupal core as well.
Steps followed:
- Run the database updates to register the new agent configuration:
- drush updb
- Edit the AI Assistant configuration settings.
- Under "Agents Enabled", enable the Menu Agent by checking the corresponding checkbox.
- Open the Drupal Agent Chatbot prompt.
- Tried creating or editing menus and menu links using natural language commands (e.g., "Create a menu Cities with terms as metro cities in India", "You can add Delhi, Chennai, kochi, Bangalore, Mumbai", Add a home page link to the Footer menu with title Home").
Cities menu got created and terms where added. Home page link to the Footer menu with title Home was added.
SS attached
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
@mandclu
I could not reproduce the issue, I was able to create fields and content type using the ai chatbot. Also there was no error loged
Attaching the screenshots of fields created.
@binoli instead of raising new mr you can run git rebase -i HEAD~n n being the number of other commits, remove the commits and push.
Appolozise I was just checking if pipeline passed and did not notice the extra comits added. My bad
@binoli instead of raising new mr you can run git rebase -i HEAD~n n being the number of other commits, remove the commits and push.
Appolozise I was just checking if pipeline passed and did not notice the extra comits added. My bad
@bisonbleu
I am trying to improve the saveFormValues() in AutomatorBaseAction like,
protected function saveFormValues(array &$form, string $form_key, $entity, ?int $key = NULL): array {
if (is_null($key)) {
// If not key is provided, we should iterate through all items.
foreach ($entity->get($form_key) as $index => $item) {
$value = NULL;
if (is_array($item)) {
if (isset($item[$this->formElementProperty])) {
$value = $item[$this->formElementProperty];
}
}
elseif (is_object($item) && method_exists($item, 'get')) {
if ($item->get($this->formElementProperty)) {
$value = $item->get($this->formElementProperty)->getValue();
}
}
if ($value !== NULL) {
$form[$form_key]['widget'][$index][$this->formElementProperty]['#value'] = $value;
}
}
}
else {
if (isset($entity->get($form_key)[$key])) {
$item = NULL;
foreach ($entity->get($form_key) as $index => $item) {
if ($index === $key) {
break;
}
}
$value = NULL;
if (is_array($item)) {
if (isset($item[$this->formElementProperty])) {
$value = $item[$this->formElementProperty];
}
}
elseif (is_object($item) && method_exists($item, 'get')) {
if ($item->get($this->formElementProperty)) {
$value = $item->get($this->formElementProperty)->getValue();
}
}
if ($value !== NULL) {
$form[$form_key]['widget'][$key][$this->formElementProperty]['#value'] = $value;
}
}
}
return $form[$form_key];
}
the method now correctly handles both array and object field items. This means that most plugin-level overrides of saveFormValues() are no longer necessary unless they add widget-specific logic.
I recommend removing the redundant saveFormValues() methods from individual FieldWidgetAction plugins and letting them inherit the base implementation. If that is allowed I can move further.
Thanks
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
Hi @andrewbelcher,
Before proceeding with implementation, I wanted to clarify the intended purpose and use case of exposing AI Agents in the ai_ckeditor plugin.
- Should this allow editors to invoke an agent inline (e.g., generate content, classify text, summarize)?
- Should it support inserting content into the editor based on the agent response?
- Are we targeting general-purpose agents (like OpenAI chat), or also structured agents like: Node content agents, Taxonomy agents, Field-specific agents ?
anjaliprasannan ā made their first commit to this issueās fork.
AiSearchSetupMySqlTest is marked as old. in the codebase. should that be reverted? I have added test to AiSearchSetupMySqlTest but since this was named old I am reverting back. Once its confirmed, I will proceed.
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā made their first commit to this issueās fork.
Reviewed the fix. Code LGTM.
Fix is working fine.
Created MR for the patch.
anjaliprasannan ā made their first commit to this issueās fork.
anjaliprasannan ā created an issue.
I have checked the code and LGTM
I have reviewed this after the fix in š Create Context upcaster for complex data types Active and its working fine. Hope this ticket can be closed now.
anjaliprasannan ā made their first commit to this issueās fork.
I have tested. its working as expected.
Discussed after discussing with @riyas_nr over slack and retesting the changes with OpenAI - dall-e-2 provider the image generation is done successfully. attaching the screenshot.
@bisonbleu Have moved the resort and save logic together.