🇪🇸Spain @gxleano

Thanks @pmelab!

BTW, the latest changes look good to me @pmelab.

Just waiting until branch 1.2.x is created, then we can move it to RTBC.

Yes, in order to avoid breaking changes, we should create 1.2.x branch, then just point the changes on this MR to there.

This issue should be tested with MR https://www.drupal.org/project/ai/issues/3526390 ✨ Improve the AI Search recursive retrieval of a specific quantity of results Active , from where some new methods are coming.

Changes include the logic to handle the limitations of recursive vector search in scenarios involving:

• Large content split into many small chunks
• Numerous access-controlled nodes
• Insufficient retrieval due to 10-iteration (maxAccessRetries) cap

At the meantime, I've also added related changes in https://www.drupal.org/project/ai_vdb_provider_milvus/issues/3526393 ✨ Make use of Milvus' Grouping functionality Active .

It should be tested/reviewed after changes from https://www.drupal.org/project/ai/issues/3532517 📌 Remove AiDataTypeConverterPluginManager from Base class and load via trait Active are added to 1.2.x, then we would need to update this issue with 1.2.x

After adding latest change related with RagTool, everything works fine from my side.

In the meantime, I'm testing the recent changes, but previous updates to RagTool are breaking my testing scenario.

Previously, everything was working fine with the default Umami version. After searching for an existing recipe, it correctly returned the expected content. However, after applying the latest changes included in version 1.2.x, RagTool can no longer return any results when performing a search. Instead, it simply reports that no matches were found.

If we test with RagTool code coming from 1.1.x, everything works as expected.

It will be included in the next release 1.2.41

Thanks @lazzyvn!

I've added an extra validation to avoid Undefined array key "fieldDefinition" error.

Strange that no body report this issue before...I think that maybe it is related with some specific configurations.

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

Thanks @bobooon for report and fix.

The fix will be included in the next release 1.2.41

Thanks @huzooka and @idimopoulos to work and review it.

The fix will be included in release 1.2.41

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

Then let's wait until Dan review and test it.

Thanks to check it Marcus.

Another addition would be to have a link at the top like "Try it", "Try Drupal AI" or something pointing to https://www.drupalforge.org/template/drupal-cms-ai-demo, where users can "easily" test the Drupal AI features.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

gxleano → created an issue.

Once this issue is ready to go, we would need to also create follow up tickets on every provider in order to clean up the openai-php/client library from them.

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

gxleano → created an issue.

Thanks @svendecabooter!

The fix will be added in the next release!

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

Thanks @andreasderijcke and @mrdalesmith for the effort here.

The fix will be included in the next release.

Thanks @andreasderijcke and @mrdalesmith for the effort here.

The fix will be included in the next release.

Thanks @jofitz @anjaliprasannan

The fix will be included in the next release.

Moving this issue to fixed as it has been already released into 1.1.0-rc1

Thanks @ayrmax and @scott_euser!

I've been testing the issue and it seems to be working as expected, so moving to RTBC.

@mtalt

Yes, you are totally right. Sorry to not double check it.

gxleano → created an issue.

Or maybe we should specify that we should only update it if the default provider is not selected.

Same issue than https://www.drupal.org/project/ai_provider_openai/issues/3528590#comment... 📌 Add update hook for Chat with Tools and Chat with Structured Output Active

    // If its set, we just return false.
    if (!empty($default_providers[$operation_type])) {
      return FALSE;
    }

This piece of code is not doing what we are expecting, right now it is detecting $default_providers[$operation_type] as not empty even when the model_id is not selected, we should check:

    // If its set, we just return false.
    if (!empty($default_providers[$operation_type]['model_id'])) {
      return FALSE;
    }

Because the provider_id will be always there, see:

After testing the changes, I’ve identified two important points:

1. The index has become approximately twice as long compared to the previous version.
2. The number of items indexed depends on the value set in the "batch" option. For example, if it's set to 5, indexing stops after 5 items. In my opinion, this is not an optimal solution—indexing should works as usual by default, while batching should be handled in the background without needed to re-run after each batch is finished.

See evidences:

I find the behavior of the index during the processed items progress bar quite misleading. In the default version, it’s clear when the index begins processing content, what exactly it’s processing, and when it finishes. However, in the current version, the process is more complicated and it’s harder to understand what’s actually happening.

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

marcus_johansson → credited gxleano → .

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

Reviewed latest changes, everything works as expected.

See evidences:

Deepchat chatbot configuration

Chatbot verbose response

After following the testing steps on #6 ✨ Add Javascript orchestration for each loop in the Chatbot/Assistants API Active it is duplicating the Deepchat form creation.

Testing stack:
- Drupal 11 (latest) with Umami
- Drupal AI modules (all modules)
- OpenAI provider
- Issue branch

I've been testing this issue on 1.1.x-dev and everything works fine now when Allow history option is enabled.

See evidences:

The response also appears immediately in https://www.drupal.org/project/ai/issues/3526074 🐛 Deepchat response not displayed until page reload when stream option is enabled Active , the problem is that the FE doesn't show the answer until the page is reloaded

I think that both issues are reporting the same problem https://www.drupal.org/project/ai/issues/3526074 🐛 Deepchat response not displayed until page reload when stream option is enabled Active , adding it as related.

I believe Drupal's navigation is a special case and shouldn't be handled the same way as other components. Its structure is unique, and supporting the before/after/no text options could introduce inconsistencies.

Looking at the UI Icons Menu logic, I noticed that the icon is currently wrapped inside <span class="toolbar-button__label">, which doesn't align well with the new navigation requirements. For it to work correctly, the icon should be placed outside this <span>. The previous implementation introduced by @plopesc seems more appropriate here, as this behavior is specific to the Navigation component.

Thanks @mogtofu33 for the feedback.

I've been testing the latest changes but it is breaking down the logic, we come back to the current "buggy" state.