marcus_johansson → created an issue.
marcus_johansson → created an issue.
Thank you, it fixes the bug and works well! Getting merged into 1.1.x
marcus_johansson → created an issue.
This was false, closing this
marcus_johansson → created an issue.
marcus_johansson → created an issue.
marcus_johansson → created an issue.
marcus_johansson → created an issue.
marcus_johansson → created an issue.
marcus_johansson → created an issue.
Thanks Michael - looks good, getting merged into 1.1.x
marcus_johansson → created an issue.
Looks good, getting merged to 1.0.x and 1.1.x. Thanks
Thanks @joshhytr - I have done a change in the MR, please recheck.
Yes, that would be great to have another person working on this - and you are already co-maintaining stuff.
If you use Slack, reach out to me there "Marcus Johansson", if you have ideas of roadmap etc.
marcus_johansson → created an issue.
Added some comments what needs to be done.
The problem is not the AI Providers, they should for now be backward compatible. (Though 1.1.x-dev branches are coming with function calling and some other goodies)
You have a vector search engine somewhere. In that case there has been a breaking change. If its Postgres or Milvus they already have 1.1.x-dev branches, for Pinecone the issue is here: https://www.drupal.org/project/ai_vdb_provider_pinecone/issues/3512384 📌 Interface changes for 1.1 branch Active . I'm just waiting for it to be reviewed and merged by Scott.
marcus_johansson → created an issue.
Thanks @andrewbelcher for review. Getting merged.
I did a minor update for the new structure of the inputinterface. This now is merged with 1.1.x - thanks everybody!
w01f - video is here: https://www.youtube.com/watch?v=rUi-Z2QckOM&ab_channel=FreelyGive
This is no testable by using 1.1.x-dev releases from AI, AI Agents and OpenAI provider. More providers coming soon.
An initial version of this has gone into 1.1.x-dev. It can so far be tested with OpenAI provider 1.1.x-dev, but more to come.
Right you are @michaellander - This is merged into 1.1.x-dev!
Getting merged to 1.1.x. I think we will backport this as well, if we release an 1.0.6 bug fixes branch. Thanks both.
There should be a Milvus 1.1.x-dev release with the latest interface available.
marcus_johansson → created an issue.
ah @robertragas - we just merge in a breaking change into the 1.1.x-dev release. I will update Milvus and Pinecone with 1.1.x releases as well.
It should be done by end of day.
marcus_johansson → created an issue.
Sorry, the calculation is correct. It seems to be giving back lower numbers then Milvus, I'm not sure why, but the calculation seems sound.
Sorry, not correct calculation
marcus_johansson → created an issue.
marcus_johansson → created an issue.
Thanks @joshtyr - this is going into 1.1.x-dev, that will have this breaking change. We will update the Milvus and Pinecone providers to also have 1.1.x releases fixed to the 1.1.x release of AI module.
This means that you can have a requirement to 1.1.0-dev for now and later 1.1.0 and hopefully the vdb provider should work as expected.
So there was a general known issue with Drupal core, that if no sessions is started the csrf token simply does not work, see 🐛 CSRF check always fails for users without a session Needs work .
I have added so when the chatbot is created, it will generate a session if it doesn't exist, and then generate a new csrf token in the same call. This will then via js reset the connect parameter to use this.
Performance wise this makes it possible to remove the complete none-cache of the block and set it per user instead, but this also means that a new session will be created for any anonymous user where the block is loaded.
I did fix a minor bug issue here as well connected to loading styles, that got fixed here as well.
Please test and review the code.
Thank you guys, getting merged.
marcus_johansson → created an issue.
Thank you, getting merged into 1.1.x-dev.
This is fixed and will be merged here ✨ Allow other modules to provide styles for Deep Chat Active
Thanks guys - looks good, I also added so it checks the themes. I will merge this with 1.1.x-dev for the first 1.1.0 release.
marcus_johansson → made their first commit to this issue’s fork.
marcus_johansson → created an issue.
Changed some in the description and made it a two step process.
I just started looking at this and setting up so you can set a default provider in the form, makes litte if any sense. The idea with default providers is that you can switch them out when you feel like something else is better/cheaper/more secure etc, but this is not true for the vdb providers.
If you index with one vdb provider, and change the default value, the new one will not be able to do lookups against the vdb provider unless they happen to have the same dimensions.
So for recipe instead, it makes more sense to have a custom plugin to install a server, but this plugin sets the default embeddings provider and its dimensions as fixed values in the configuration.
marcus_johansson → created an issue.
Thanks for finding, getting merged.
Sure, do you have an example where you have used twig approach?
I have from earlier companies I worked with the Automators, I can't expose there exact prompts, but something like:
Could you write an explanation for each of these rating categories and description of this tweet, how well it aligns with the company statement for {{ company_name }} given below.
{% if image %}
An image was also given in the tweet, make sure to look at before you take your decision.
{% endif %}
The following rating categories are important for this content:
{% for category in categories %}
* {{ category.name }} - {{ category.description }}
{% endfor %}
The company statement is:
{{ company_statements[company_id] }}
How might I test if it works with ECA? I imagine it should work anywhere given its ultimately just a form element like any other.
BPMN.io has limited forms that works currently, specifically around ajax functionality. Autocomplete won't work for instance when I was testing integration with the Automators. And since BPMN.io is the main tool being used for controlling ECA, we should test or set it up so it works. You can see an discussion here for instance: https://drupal.slack.com/archives/C0287U62CSG/p1740848222472139?thread_t...
Added a comment @vakulrai
This is awesome @scott_euser!
I don't have that much to add, the things I can think off, but they are also part of possible future todos (and not that thought through yet):
- Some places will have a lot of prompts, so we might need an ajax pager on the table select.
- Allowing twig (with wrapper around tokens). There are places where conditionals or traversing of the variables in prompt is really nice to have.
- Minor and I might even be wrong that its needed - but if its not working with ECA, have a simpler fallback form element that works in BPMN.io, so it works at least with selecting inside ECA.
- Mention style editor would be awesome as you mention - when working with technical writers/editors etc, they always found tokens to hard to work with.
If you need help with the editor or something else, let me know.
There is another discussion to be had here I think, and that is that we are now adding configurable agents in AI Agents, which is basically a system prompt, some metadata and (optional) tools. You can see the entity here: https://git.drupalcode.org/project/ai_agents/-/blob/configurable-agents/....
The question is if it makes sense to merge efforts here, or just have the agents extend this entity type.
Getting merged, thanks @abhinesh
Thanks, maybe we should split it up in two issues actually.
1. Is setting default VDB providers and being able to setup a server/index via recipes when this exists.
2. Is using recipe to setup the VDB Provider itself.
For your question on #2 - this would have to be in the recipe, you can have help texts and other information in there for both console and form. But that is defined by whoever creates the recipe. Check here for the AI recipe for instance: https://git.drupalcode.org/project/drupal_cms/-/blob/1.x/recipes/drupal_....
That's why if we can solve this in the Key module, I don't think the AI module needs to do anything for this to work.
#3 - will talk to seogow.
Looking good, thank you, getting merged.
Thank you, getting merged
I think the issue is my description of this checkbox is bad and a missing description written by a native speaker might be part of a bug issue.
What the checkbox is suppose to do, is to look at any context field that exists and see if they got changed - then the automator should run again.
So if you have a article text field and you have a summary field that is automatically populated with automators. If this is checked, the idea is that if you change the article text field, then the summary should be recreated.
Having it run everytime a node gets updated would be bad, if you have automatic updates of nodes for whatever reasons, since it can end up costing you a lot of money.
I'm thinking if we should even hide this on advanced mode, since it would be quite hard to check if token values have changed?
I'll set this issue to active again. Sorry about the confusion.
Thank you both, getting merged.
Very edgecasy, but anything that can be fixed is good :D Thanks both.
Thank you, getting merged.
marcus_johansson → created an issue.
One minor comment and then I'll merge.
marcus_johansson → created an issue.
Hey @michaellander - I've been checking this internally and also reading up on the Context/DataType API and this definitely makes sense as long as we can map everything correctly and just give some good warning nudges with what natural data_types you can use!
The thing I'm missing from the ContextDefinition that is important for (AI) context is example values and I'm trying to figure out how to get that in there, without creating some ugly solution of setting it as a custom constraint. Any idea?
Also, how would it work with something like a complex type like Entity? Should there be some abstraction to map these specific for function calling, since the providers only will give back natural types - like a string of node:1:en or something like and then upcasting it?
E-mail and others that are based on a primitive base would be simple to just map to its primitive - with some mapping like float and decimal to number, integer to int etc.
Thank you srees for the bug find and fixed. Its tested and getting merged.
Merged, thanks Artem!
I wonder if we should set a max-height of 100%, outside of the manual height you can set. I can't see a use case where you want a fixed modal to be taller then the viewport?
@vakulrai - could you retry this and see if you can still replicate it. If you can replicate it, can you export or check the configuration for you ai_automators.ai_automator.{entity_type}.{type}.{filed_type}.{name}.yml file and check if there is a config dependency missing or existing to the field configuraiton.
If it exists, something is wrong with how your Drupal is deleting dependencies, if its missing its a bug on the Automators side.
Yup @mrdalesmit - moving it.