🇮🇳India @abhisekmazumdar

Nicee  🎉

Thank you for resolving the mystery. I can take care of the rest changes.

Thank You for the review. This is merged now.

abhisekmazumdar → created an issue.

Functionally, it resolves the issue. Code changes are also good.

This is back for review now.

@nikro
I just review the https://git.drupalcode.org/project/ai_provider_dropsolidai/-/commit/38ae... changes.

The code changes look good, and they work fine locally. I see the LangFuse module not installed warring message, and if it’s not configured, it ask to configure it.
So a RTBC for me.

Thank You @jurgenhaas for the quick feedback.
I missed the ai_integration_eca_install hook I reverted those suggested changes and made some improvement.

I followed the steps mentioned in comment #13 by @littlepixiez (thanks for the steps, that saved a lot of time to figure out the issue)

I feel we should keeping the plugin ID as eca_ai_trigger_agent rather than changing it to follow the ai_integration_eca_* pattern.

I made come changes and added a commit to it.
The changes basically add support for migrating ai_eca_agents submodule too

I realized we were only handling the main ai_eca submodule and I feel that we need need to do that for
ai_eca_agents. So added migration support for that submodule as well.

Also cleaned up the code a bit, instead of having separate loops for each
submodule, I made it use an array so it's easier to maintain.

The eca_ai_trigger_agent plugin stays the same since it doesn't start with
"ai_eca_" so it won't get touched by the migration anyway.

I will try to test this now.

I see that no release was made which covers these changes. I'm making on right now 3.0.0-beta6

I see this was merged. Marking this as Fixed.

I made some updates for the phpcs and phpstan issues. Created a deprecation take care issue as well: www.drupal.org/project/mautic_eca/issues/3550474

abhisekmazumdar → created an issue.

@nikro Thank You for the inputs.

Here what I'm thinking and have started working on a POC as per the suggestion you gave:

- A contrib module 'AI Experience Wizard' sounds good to me.
- But yes we need to write a single install task to hook into the installer so that this custom module is the next thing a user sees after a site is installed or a form for the selection of the providers.
- After the installer does it job of getting the provider name this custom module can kick in and use package manager to pull the required module and set it up.

I will work on this concept and let you know what is possible and what is not. I currently have some confusion, but it will be resolved as I begin working on this.

abhisekmazumdar → created an issue.

The code changes looks good to me.

abhisekmazumdar → created an issue.

Also unassigned the issue from @arisha so that anyone else can pick this up for review.

This shouldn't be marked as fixed. It should be marked as needing review so that the maintainer and others are aware that it requires attention before the MR can be merged.

I will try to move this forward.

Just one phpstan error. I don't see any issues with the code.

I'm not sure what I'm missing here:

 ------ -------------------------------------------------------------------- 
  Line   modules/field_widget_actions/src/Hook/FieldWidgetAction.php         
 ------ -------------------------------------------------------------------- 
  38     Attribute class Drupal\field_widget_actions\Hook\Autowire does not  
         exist.                                                              
         🪪  attribute.notFound                                              
 ------ -------------------------------------------------------------------- 

Working on the suggestions.

Working on the comments.

abhisekmazumdar → created an issue.

The new changes done by @a.dmitriiev is good and something we should have in this action.
Thank You for the improvements. I hope this get merged soon :-)

Thank You for the inputs I have merged this and created a new release.

Nice, made me so excited to test this.

I needed to pull the "drupal/modeler_api": "1.0.x-dev" as ai_agents needs that.

Rest I see that I was able to Overrides a existing AI agent by following the mentioned steps:

I have few question:

We add a new Config setting page for this ?
Or keep it under the existing config page: https://git.drupalcode.org/project/chromium_tool/-/blob/1.0.x/chromium_t...

That form will have a selection option for different image styles available in the site.

image style on installation that scales on height or width to <1500px on the largest one.

This will be a default config for this module

Current Industry Standards after comparing few providers

OpenAI

• auto (default): The model decides whether to call functions and which ones to use
• none: Disables function calling, ensuring text-only responses
• required: Forces the model to call at least one function
• function: Forces the model to call a specific function by name

Then there is Parallel tool calls. Not sure how can do / or will do this ?

Groq

• auto: Model decides tool usage autonomously
• none: Text-only responses, no tool calls
• required: Mandates tool usage

Anthropic

• auto: Equivalent to OpenAI's auto mode
• any: Similar to OpenAI's required mode
• tool: Forces specific tool usage

OpenRouter

• auto: Let model decide (default)
• none: Disable tool usage
• function: Force specific tool

LiteLLM

• It has something similer to OpenAI itself: auto, none, required
• It also can do Parallel tool calls

I have updated the MR. Please review.

I'm also unsure about the #9 from @murz. I'll leave it to @marcus_johansson to decide if we still need a library here.

abhisekmazumdar → created an issue.

I see that the comment #18 was addressed in the latest commit. I see everything else has already been reviewed and approved, so I'm moving this to RTBC.

I will put something up for this.

This is reviewed and merged. Thank you.

This is up for review now.

Yes, I like the new approach. Both make the summer preview in a Slack link more useful and readable.

I will try to get this merged next week. Cleaning the linting issues is good to have.

Thank you all for moving this forward. I have created a new release: field_validation 3.0.0-beta5.

Thank You

With some AI assistant coding, I tried to find the possible cases that needed to be tested. Please review.

abhisekmazumdar → made their first commit to this issue’s fork.

abhisekmazumdar → created an issue.

abhisekmazumdar → created an issue.

I can take care of that. Yes, I agree the test cases should be more broader.

Can someone review this.

Thank You for clearing my confusion. I tested it again and it looks good to me.

I merged these changes on top of 📌 Use a different model for LLM evaluation Active

Here what I see when running the drush command:

Command: ddev drush agetes --group_id=1 --uid=1 --eval_provider=openai --eval_model=o3 --detailed

 [notice] Running tests as user: admin
 [notice] Running test group: Basic Pages Test Group
 [notice] Overriding LLM evaluation model: openai/o3
 [notice] Running test 1 of 3: Test ID 1 (nomic-embed-text:latest)
 [error]  Error invoking model response: "nomic-embed-text:latest" does not support chat 
 [notice] Running test 2 of 3: Test ID 2 (nomic-embed-text:latest)
 [error]  Error invoking model response: "nomic-embed-text:latest" does not support chat 
 [notice] Running test 3 of 3: Test ID 3 (nomic-embed-text:latest)
 [error]  Error invoking model response: "nomic-embed-text:latest" does not support chat 
 [notice] Test group completed. Results available at: /admin/content/ai-agents-test/group/result/9
 ------------- --------- ---------------------- -------------------------------------------------------------------------- 
  Id            Result    Label                  Message                                                                   
 ------------- --------- ---------------------- -------------------------------------------------------------------------- 
  test_1        Error     Is Basic Page          Error: Error invoking model response: "nomic-embed-text:latest" does not  
                          content type sticky    support chat, Line: 309, File:                                            
                          by default             /var/www/html/web/modules/contrib/ai/src/Plugin/ProviderProxy.php         
  test_2        Error     Is Basic Page          Error: Error invoking model response: "nomic-embed-text:latest" does not  
                          content type           support chat, Line: 309, File:                                            
                          promoted by default    /var/www/html/web/modules/contrib/ai/src/Plugin/ProviderProxy.php         
  test_3        Error     Is Basic Page          Error: Error invoking model response: "nomic-embed-text:latest" does not  
                          content type           support chat, Line: 309, File:                                            
                          published by default   /var/www/html/web/modules/contrib/ai/src/Plugin/ProviderProxy.php         
  group_total   Failure   Group: Basic Pages     0/3 tests passed | Duration: 0s | Group Result ID: 9 | Success rate:      
                          Test Group             0.00%                                                                     
 ------------- --------- ---------------------- -------------------------------------------------------------------------- 

Forgot to update the status

I think I can move this at least with the initial work. Then later on, we can decide about the validator thing.

Added some inline comment over the MR.

I see the new Agent Evaluation section. It opens a section which has the checkbox, and when the checkbox is unchecked, it shows the available module list to select from. It runs the test with the selected model.
Financially, the changes look good to me.

abhisekmazumdar → created an issue.

I have made the final changes, added the document and test. I also made some changes to the CSS and cleaned up the other parts of the code. This is now up for review.

Example usage:

$form['conversation'] = [
      '#type' => 'chat_history',
      '#title' => $this->t('Conversation'),
      '#default_value' => [
        [
          'role' => 'user',
          'content' => 'What is the weather like?'
        ],
        [
          'role' => 'assistant',
          'content' => 'I can check that for you.',
          'tool_calls' => [
            [
              'tool_call_id' => 'call_1',
              'function_name' => 'get_weather',
              'function_input' => '{"location":"Oslo","unit":"celsius"}',
            ],
          ],
        ],
        [
          'role' => 'tool',
          'content' => '{"temp":25,"condition":"sunny"}',
          'tool_call_id_reference' => 'call_1'
        ],
      ],
    ];

I made the update to the Draft changes: https://git.drupalcode.org/project/ai/-/merge_requests/719/diffs?commit_...

This includes added Tool call section for the Role Assistant which has the above said fields.
And Role Tool has a tool called Reference ID

Example use of the element:

$form['conversation'] = [
      '#type' => 'chat_history',
      '#title' => $this->t('Conversation'),
      '#default_value' => [
        [
          'role' => 'user', 
          'content' => 'What is the weather like?'
        ],
        [
          'role' => 'assistant',
          'content' => 'I can check that for you.',
          'tool_calls' => [
            [
              'tool_call_id' => 'call_1',
              'function_name' => 'get_weather',
              'function_input' => '{"location":"Oslo","unit":"celsius"}',
            ],
          ],
        ],
        [
          'role' => 'tool', 
          'content' => '{"temp":25,"condition":"sunny"}', 
          'tool_call_id_reference' => 'call_1'
        ],
        [
          'role' => 'user', 
          'content' => 'Can you also check the time?'
        ],
      ],
      '#chat_history_add_more' => TRUE,
      '#rows' => 2,
    ];

preview:

Sharing my work in progress here to ensure I'm heading in the right direction.

I updated the MR and added a comment.

I got the gist of it and will give it a try
My understanding is this chat_history FormElement will need the following changes next:

- A existing / new section of assistant is created it should have the following as string as of now

• tool_call_id
• function_name
• function_input

- And for tool add a field tool_call_id_reference.

I feel there is a bug in the logic how the form handle the Automator Base Field value. Event if we select Advanced Mode (Token) the value for Automator Base Field get stored in the config. Which result it making the Placeholders context work in some cases. In theory Placeholders context shouldn't be need for the advance mode.

I feel the solution here will be to remove the placeholder for the advance mode and manage the value of Automator Base Field addConfigValues() to only save the value when the mode is Base Mode.

// Only persist base_field when Base mode is selected; otherwise clear.
$aiConfig->set('base_field', ($formState->getValue('automator_mode') === 'base') ? ($formState->getValue('automator_base_field') ?? '') : '');

Advanced Mode is intended to be used only with tokens, that's how I feel.
Changing this needs review, as it requires input from the maintainer of the module regarding the logical implementation standpoint for this functionality.

I attempted to clean up the direct calling of services in the RuleBase file and quickly realized that it would be a significant task. The RuleBase has been extended by many other classes, each with its own dependency injection for the services included in the RuleBase. I will create an issue for this cleanup since I have completed the current task.

Working on the feedback

Made the required remaining changes listed by @scott_euser. Thanks for that! That made things easy for me to quickly jump in and add them.
Update the test. It looks like it is working now. I see a few failed cases for AiSearchSetupMySqlTest, but they are mostly annotation deprecation warnings and a few others that are not related to the changes included in this MR.

I can try to add the missing things here.

I tested it again. It looks like it's working for me.

I made some improvements to the MR and added a commit to the MR: https://git.drupalcode.org/project/ai/-/merge_requests/612/diffs?commit_...

abhisekmazumdar → made their first commit to this issue’s fork.

Thanks @b_sharpe and @admitriiev for the suggestion. I have update the MR and also added test coverage.

The failed CI job says something wrong with Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibrary Not sure if that related to my changes.

Other then that its open for review.

abhisekmazumdar → made their first commit to this issue’s fork.

valthebald → credited abhisekmazumdar → .

@himanshu5050

I tried the following steps

1. Installed the module ai_ckeditor
2. Config Basic HTML in Text formats and editors to have the "✨ AI CKEditor" button to the active window.
3. In the same config form AI tools tab enable Fix spelling, Modify with a prompt, Tone and few others.
4. Edit a basic page with has a Basic HTML format field.
5. I tried using few of the AI tools as shown in the below.

As you can see, I can't reproduce the issue. Can you help me identify if I'm missing anything?

So there the code: https://gitlab.com/dropsolid/drupal_ai_cms_installer

This is a modified version of the drupal_cms_installer. It adds two install tasks: one to select an AI provider of choice (a form) and another to use the package manager to pull the said module into the codebase and set up the key config with the selected AI provider.

This was just a proof of concept, and we need to clarify how we manage different AI provider configs.
Let me know your thoughts on this POC if this can be the solution we want?

Here the demo for what I have been working on: https://www.loom.com/share/5df4b8feae5f43f2858edcf660a84454?sid=0f739b10...

The code is very rough right now and needs to be cleaned up a little. I'll share the modified drupal_cms_installer from Drupal CMS in a repo. In brief, here is what I've done:

- Added two install tasks after the site installation.
- The first task is to show a form for users to select their required AI provider and then require the module using Package manager.
- The second install task sets up the key and the selected AI provider config.

Some limitations are:

We still need to write specific code for each module.
For example, the module ai_provider_google_vertex requires its key to be in the config file. Other AI provider modules accept the key in the config as well. Therefore, a custom solution will be needed to add a specific AI provider. Alternatively, maintainer of the AI provider module can follow a standard config structure.

Yes, the inspiration for adding an extra form in the installer came from the drupal-starforge repository. I have mostly copied the same form.

Regarding the BYO keys module, I too believe it would be beneficial to have, but at the same time, my intention is to resolve the issues with the existing AI provider modules. Therefore, the approach of using the package manager after the site can address that.

abhisekmazumdar → created an issue.