This is closed as outdated, but has it been addressed? Or is there a better thread for discussing this issue?
I'm experimenting with an assistant using a locally run LLM and RAG database (ollama, mistral, milvus). I can't see how to force the assistant to run the rag actions. Checking the "Enable RAG actions" and then tweaking the pre-prompt and instructions seems to make it more likely that it'll run a RAG action, but I'm still only seeing embedding queries based on the RAG action run about 30% of the time.
I'm I correct in thinking there is currently no way to ensure that an action like a RAG lookup will happen? It is left up to the LLM to decide what actions to take? It goes into AiAssistantApiRunner::process and then only runs actions like a RAG lookup if actions are returned from the initial interaction with the LLM? Maybe I'm thinking too old school, but I'm having a hard time wrapping my head around the idea that a developer can't ensure that a particular action occurs at a certain point in the process, we just have to plea nicely with the LLM to do what we want.
The scenario I'm trying to address is building a chatbot that answers users' questions based primary on information found on the current website. That seems like it'd be a pretty common use case and one that requires treating the RAG data as authoritative.
I'm not sure if this is the same issue or not, but as far as I can tell metatag_page_manager isn't working (in the sense of "I never see my configured metatags on my page manager page").
The metatag_page_manager_metatag_route_entity method looks for the variant as a routeMatch parameter.
if ($variant = $route_match->getParameter('page_manager_page_variant')) {
At least in the work I am doing on D10.3 setting up a page with a couple of variants on a new path, I never see that parameter set. Instead I have to look at defaults:
$variant_id = $route_match->getRouteObject()->getDefault('_page_manager_page_variant')
My knowledge of the way Page Manager loads Pages and PageVariants is extremely superficial, so this may not be smart or secure, but with this change I do see my metatags loading on my page instances.
@alfthecat the patch does not apply to beta 4 but it applies to the current dev branch fine.
Here is a first pass at this.
Just adding ^11 was enough to get it to work for me today in a vanilla D11 install. I tried a handful of barcode formats on a short text field and they worked fine, then I tried running the tests where I got the same failure as I get under D10. Obviously not exhaustive testing, but an option for folks (like me) with simple use cases.
Thanks for your work on the library upgrade.
This patch seems to be all that is necessary to get barcode working under D11.
There is one test failure, but I see that test failing in D10 too. The error:
Drupal\Tests\barcodes\Functional\BarcodeBlockTest::testBarcodeFormat with data set "PNG display format." ('PNG', '023130', '')
Behat\Mink\Exception\ExpectationException: The string "" was not found anywhere in the HTML response of the current page.
Could we get a D11 compatible release soon?
MR in comment #14 tested on v4.0.4. It fixes the issue.
Can confirm the same as #23 on the actual release of 10.2: the patch from MR !37 + removing that the parent: menu.active_trail line clears the error.
Switching to "Needs Review"
In the commit from comment #5 was an extra space before the key "url" being added that caused the yml parser to fail with the following error:
Drupal\Core\Asset\Exception\InvalidLibraryFileException: Invalid library definition in modules/contrib/views_slideshow/views_slideshow.libraries.yml: A colon cannot be used in an unquoted mapping value at line 33 (near " url: https://opensource.org/licenses/MIT"). in Drupal\Core\Asset\LibraryDiscoveryParser->parseLibraryInfo() (line 367 of core/lib/Drupal/Core/Asset/LibraryDiscoveryParser.php).
I've updated the branch associated with MR !8 to remove the extra space.
This issue also appeared in the 2.x branch in release 2.2 and makes it so users cannot accept invitations.
As far as I can tell, it's just a one line change to fix it.
+1 on confirming this fixes an infinite redirect on sites with language prefixes. Please roll this into a release soon.
The config change and javascript from comment 9 work great but AFAICT the QuickTabsInstanceEditForm does not save or reflect the remember_last_clicked_tab value from the config.
The attached patch makes explicit the saving of that value.
The patch on #7 is working for me with Subgroup 3.0. Thank you!