It looks good to me Scott!
But we would need to wait merging until the problem with AI Search package is resolved.
gxleano → created an issue. See original summary → .
Yep, as mentioned by Valery in #11 ✨ Change namespace for Field Widget Actions module Active , it still point to the Drupal AI repo.
See:
composer show --available drupal/ai_search
name : drupal/ai_search
descrip. : Offers an implementation of the Search API that uses a Vector DB server for indexing content.
keywords :
versions : 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.2.0-rc2, 1.2.0-rc1, 1.2.0-beta1, 1.2.0-alpha2, 1.2.0-alpha1, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.1.0-rc1, 1.1.0-beta1, 1.0.x-dev, 1.0.6, 1.0.5, 1.0.4, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 1.0.0-beta7, 1.0.0-beta6, 1.0.0-beta5, 1.0.0-beta4, 1.0.0-beta3, 1.0.0-beta2, 1.0.0-beta1, 1.0.0-alpha8, 1.0.0-alpha7, 1.0.0-alpha6, 1.0.0-alpha5, dev-1.0.x
type : metapackage
license : GNU General Public License v2.0 or later (GPL-2.0-or-later) (OSI approved) https://spdx.org/licenses/GPL-2.0-or-later.html#licenseText
homepage : https://www.drupal.org/project/ai
source : []
dist : []
names : drupal/ai_search
support
source : https://git.drupalcode.org/project/ai
requires
drupal/ai *
drupal/search_api *
drupal/core ^10.4 || ^11I've been considering the possibility of bringing this back, so I’ll reopen the issue and try to dedicate some time to implement a working version of the re-ranking feature, which seems to have been neglected for a while.
After we have included this hook https://www.drupal.org/project/ai/issues/3556016 ✨ Add hook_ai_search_results_alter() to allow other modules to modify or re-rank AI search results Active on AI Search module, I think that could be nice to have the possibility to re-rank results.
So,re-ranking acts as a “second pass” that fine-tunes results to make them more relevant, personalized, or optimized for specific goals.
Facing same issue while I was using Ollama provider.
When going to /admin/config/ai/providers/ollama, I go the next error:
Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "model_id" for route "ai.edit_model_settings_form" must match "[^/]++" ("thinkverse/towerinstruct:latest" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 223 of core/lib/Drupal/Core/Routing/UrlGenerator.php).
After setting up the MR the error is gone, so the problem is solved.
Thanks Kevin and Stefan.
Thanks Scott to provide more details in description.
I've been testing carefully the fix, and it is working as expected.
The doSearchWithIteration() method now correctly:
- Detects when access checks reduce results below the limit
- Iterates to fetch more results from Milvus
- Replaces filtered nodes with accessible alternatives
- Returns the full requested number of results
Moving to RTBC, so feel free to merge it.
@harivansh
Check the failing pipelines, when everything is ready just move the issue to Needs review, please.
Hey Kirsten,
Not sure if this is what we are expecting here, but https://git.drupalcode.org/project/ai/-/merge_requests/1009/diffs#f091c4... chatConsumer documentation was already added inside AI Core docs.
I've been checking the code implemented by @unqunq and it looks really promising, thank you very much!
But, as Marcus comment on
#6
🌱
Add ChatbackendInterface
Active
make more sense to move the main logic to the AI Core module. So, this will decouple the plugin architecture from the chatbot UI implementation, allowing any module to create custom ChatConsumer plugins without depending on ai_chatbot.
I will add a MR with this change in a while.
Follow-up issue in AI Search https://www.drupal.org/project/ai_search/issues/3557077 📌 Add testProviderVdbListingPageProviderAccess() to AI Search tests Active
Definitely, I will create a follow-up issue on AI Search module.
testProviderVdbListingPageProviderAccess() already depend on ai_search, search_api and test_ai_vdb_provider_mysql which is a test module in AI Search with the corresponding dependencies, so on my eyes, it should just be removed from AI Core.
Seems like Search API's behaviour after adding fields has changed in latest version.
Previously, when you were clicking on "edit-done" kept users on the fields form page, so tests could immediately interact with the new field elements, but now it redirects to the index overview page instead, so those form fields no longer exist on the current page, causing the test to fail.
I've just updated the test to work with the updated version.
As far as I was checking, this won't be an issue on 2.0.x where deleteItems() is now abstract.
So, for me the change that was added by @mediabounds, totally make sense only for version 1.2.x
The test testTagifyFacets() is failing, so we would need to check/fix this.
Yep, we should avoid this kind of BC. So, we would need to try the way to filter by name (maybe) and just remove entries which were created by Tagify (tagify and tagify_user_list).
I will try to add this change to the MR, so Darko you could test it and tell us if this is basically "skipping" the BC in your side.
Hey @ruby232!
Thanks to discover and point this out.
You were in the right direction, but you added the changes directly to the 1.2.x branch, I have just moved your changes to a proper branch and made some changes.
Feel free to have an eye on this and check if everything works fine in your side.
In this case, as @herved mentioned, we would need to implement the isApplicable() method to the Tagify BEF filter plugin, then just allow this filter to be applicable to "textfield" types.
In order to understand why textfield is the type we would need to check the TaxonomyIndexTid class which is the views filter plugin for taxonomies, there we have:
$form['type'] = [
'#type' => 'radios',
'#title' => $this->t('Selection type'),
'#options' => ['select' => $this->t('Dropdown'), 'textfield' => $this->t('Autocomplete')],
'#default_value' => $this->options['type'],
];
This is something that would be only applicable for taxonomy entity.
When you try to add a filter criteria using another entity reference field of type node or user, it would not be applicable, you won't have the selection type option.
If we would like to also support select, we would need to create an issue to request this new feature.
In order to have a bunch of icons to test this new implementation, I have provide the iconsets using
https://www.drupal.org/project/iconify_icons →
2.0.x, in this case we would just need to:
1. Enable the module
2. Go to /admin/config/iconify_icons/settings and enable the iconsets which we would like to use.
It can be even tested with core iconsets, like navigation. In this case, we would just need to enable the Navigation module and it will be available to be used in the icon_autocomplete form element
In order to test this implementation, we would need to create a new element like:
$form['icon_element'] = [
'#type' => 'icon_autocomplete',
'#title' => $this->t('Icon element (NEW 🎉)'),
'#description' => $this->t('Search and select any icon from all available icon packs.'),
'#default_value' => '',
'#required' => FALSE,
];
Evidences:
Artem thanks for the progress there, just a minor thing, I would point this to 2.0.x instead of 1.2.x then you could even try what Scott is suggesting
I don’t see any issue with including this field among the default indexed metadata. In fact, capturing the language of each item is valuable for filtering or language-aware queries. So, I’d support adding it by default.
So, if you are agree Scott, we could move it to RTBC, it looks good to me.
It looks good to me.
Thank Artem and everyone involved!