🇧🇪Belgium @lammensj

Hi,

I created two MRs for the 2.x and 2.1.x version of the module.

Important to note that both changesets are the same, and that they include a version bump of the required Drupal version (at least 10.5, see release notes: https://www.drupal.org/project/drupal/releases/10.5.0 → ).

Release note for the change of CKEditor: https://ckeditor.com/docs/ckeditor5/latest/updating/guides/update-to-45....

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

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

Yes, the ECA-submodule of AI will be deprecated in favor of this one.

Hi gbyte,

This module is the successor of the submodule inside the AI module. There are open issues to mark that one as deprecated and provide an upgrade path to this one. We're almost there, just crossing the last t's.

See https://www.drupal.org/project/ai_integration_eca/issues/3505623 💬 Uninstall ai_eca Active

@britt.vdl, thank you for the contribution! I do have a couple of remarks:
- Can you open a MR using Gitlab? There are some checks in place that are being executed on that platform (think phpcs etc.)
- Can you change the version to 3.0.x?
- The proposed changes should be moved to a new submodule, with a dependency on grapqh. It's not my intention to make the main module dependent in it.
- If possible, could you a kernel test?

My 12 points go to:
- Joris Vercammen (borisson_)
- Nico Grienauer (grienauer)

Good luck!

borisson_ → credited lammensj → .

I incorporated the mentioned remarks.

About the need for that second event: when I render the View with one of the default pagination options (mini or extensive), the same "issue" is visible: the next page contains the amount of items that was specified in the settings, and not how what it was actually rendered. This says to me that that setting is not passed between the consequential ajax calls.
Only when disabling ajax, that overwritten amount of items is "retained". I put that between quotes because it's another render event that triggers the build of that View, with that separate value for the amount of items.

So I'm assuming that, even without ECA, you would still have to use the pre-build hook to overwrite the amount of visible items. And some "initial" render code, but that's specific to this implementation. So yes, the change to the "Views"-action of the eca_render-module (specifying the amount of items) could be left out of this PR and replaced with a guideline: "if you want to change the amount of visible items per page, use the pre-build event to specify it".

lammensj → created an issue.

Thank you for the quick resolution! I can confirm that it's fixed on the project that I was working on. See attached screenshot of logs.

The one with red line is wrong, in my opinion; it's showing the context of an action within the eca_views.pre_execute-event, but with the data of the eca_render.entity-event. Both logs within the squares start with "Start [event name]... for event eca_views.pre_execute".

lammensj → created an issue.

Summary of the latest changes:
- [eca_render]: Refactored the way the configuration key is translated to a value (either a token or a regular string)
- [eca_render]: Added update-hook to update existing and their config
- [eca_views]: Added eca_views_set_pagination_values-action to keep the pagination setting across different http-requests. The "issue" mentioned above, with views_infinite_scroll, was not related but did send me in the right direction. Overwriting the pagination via the eca_render_views-action works, but only for the initial rendering. When using ajax pagination, Views falls back to the setting of the View itself.
So I had to tackle this from another angle: hooking into the pre-execute or pre-build event of that View. So I've created a "copy" of the eca_views_set_filter_value-action, and changed it so it sets the pagination- and offset-config.

For my particular use-case (see screenshot) this approach now works: in one model, you render the View and alter it via the pre-build event. There's only one bug, not sure if it is one, and that's data of the event that is available. See separate issue.

vrancje → credited lammensj → .

Thank you for your contribution!

I had to create a new MR because the previous one didn't include the necessary changes to the output schema of the ToolsCall-function.

lammensj → created an issue.

lammensj → created an issue.

lammensj → created an issue.

@flyke, this should indeed be fixed in this module. Do you want to create the patch? I believe you already have a system in place where you could test it, right?

@marcus_johansson, the PRs for the related modules are done. Let me know how you want to address this in terms of timing (when I should create new releases etc.).

lammensj → created an issue.

lammensj → created an issue.

lammensj → created an issue.

Yeah, no problem. I should have thought about that when I registered it in the first place... #facepalm

I have some time tonight, I hope I get it done.

It seems to be more complicated than the providers: I made the mistake of registering a contrib module with the same name as the submodule. When the submodule is enabled, and composer downloads the new one, Drupal automatically uses the contrib one, without uninstalling the original. This means you can't run hook_update from the submodule or hook_install from the contrib one.

Perhaps it's easier if I register a new contrib module, something like "ai_integration_eca" and then apply the provided example...

For reference, this is how the Views Block plugin is overriding the items_per_page config item: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views.... The ECA Action is doing the same thing.

I've implemented your remarks, thank you for the feedback.

Regarding the items being returned for the second "page", I believe it's an issue coming from Views Infinite Scroll. I'll link the ticket. But this shouldn't stop this particular feature request.

Aha, that's very useful, thank you!
I'll take a look and create something similar.

lammensj → created an issue.

wouters_f → credited lammensj → .

lammensj → created an issue.

However... Testing the change now... When I set the items per page on the View-object, it works when it's rendered initially. But the second page just loads the amount of items that is configured in the View itself...

It depends a bit on how flexible you want it to be. If you search for "function set" on this page: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21ViewExe..., you'll get a list of all the items you can alter/set before executing the View.

For now, I'm just limiting it to the arguments (already there) and the items per page.

lammensj → created an issue.

@tijsdeboeck, could you check if the provided solution works for you?

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

@jurgenhaas, the fix was surprisingly easy! Can you do QA?

@yautja_cetanu, your question regarding the desired schema, that's one for @marcus_johansson, right?

In my opinion, and by my (yet) limited knowledge of the MCP module, I believe a schema needs to be created either way. Whether it's developed for the "separate" implementation of function calling in the AI module, or for MCP, an LLM still needs something that it should adhere to.

To make it more tangible; I'm going to experiment with the Typed Data model I created for the ECA Agent and see how it fits in that MCP plugin type. I believe I can re-use A LOT but just need to split up some things. Like create a separate "tool" for requesting all models, creating a model and editing one. But in the end, the LLM should still generate JSON based on the Schema that I created for the "original" Agent.

I hope this makes sense :)

Hi @socialnicheguru, I'm the maintainer of the standalone contrib module. And yes, it's a duplicate of the submodule, but with extended capabilities (the ECA Agent).
I created/copied it to ensure that the main AI module doesn't need to depend on ECA, because that has its own roadmap with major and minor versions. I'm still in discussion with @marcus_johansson on how we can mark the submodule as deprecated in favor of the contrib one.

I was here (always wanted to write that somewhere :p )

Hi @michaellander, I’m indeed working on an integration for AI, more specifically an AI Agent.
At the moment, it can do 3 things
- Answer questions about existing models and available components (actions, events etc.)
- Create new models
- Edit an existing model
The only thing that’s holding me back of creating a stable release, is one issue where an edit of a model by AI doesn’t result in a valid config item.

Another part are operation types (chat, text_to_image etc.) as Actions.

https://www.drupal.org/project/ai_eca →
https://www.drupal.org/project/ai_eca/issues/3481307 📌 Add AI Agent Active

For the ECA agent, I used the Typed Data API and Schemata for generating a JSON Schema that the AI should follow. Once config validation is in core and there's support for Schema-generation, this becomes obsolete.
For non-entity data structures, something like this approach could be beneficial, no?

JSON Schema generation: https://git.drupalcode.org/project/ai_eca/-/merge_requests/1/diffs#288ae...

lammensj → created an issue.

lammensj → created an issue.

phenaproxima → credited lammensj → .

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

@jurgenhaas, I've adjusted the existing kernel test and added a couple of nightwatch tests. You can see the results of the conversion and the auto-layout here: https://git.drupalcode.org/issue/bpmn_io-3484063/-/jobs/3400559/artifacts/browse/web/core/reports/nightwatch/screenshots/Tests/bpmn_io/.

Is there anything else? Do you require more manual testing?

@jurgenhaas, I was able to adjust the Converter and clone the original ECA-entity when it doesn't use the fallback modeller. I'm using the "createDuplicate"-method of the ConfigEntityBase-class. However... The protected $id-property of the ECA-entity doesn't allow null-values, hence the failure in the pipeline. Can this be changed in the ECA-module or should I look for another way of cloning it?

Btw, this can be manually QA'd already, just follow the same steps as above. Just don't forget to temporarily allow null-values for that $id-property.

@jurgenhaas,

1. Do you prefer "convert"? Might capture the intention better... I guess it's a matter of semantics
2. I wasn't aware of the fallback-modeller, so yes, I will definitely make sure that the AI Agent is is generating one that uses that fallback. I wasn't planning on giving the LLM the option to choose.
3. Now that were working towards multiple modellers being able to alter the same ECA-config, the question rises if the admin UI should be altered/optimised? Because you would have multiple rows, concerning the same ECA-config, but different modellers which aren't kept in sync.

Summary

- Added an additional route and controller which preprocesses the given the ECA-config entity and passes certain mappings via drupalSettings to Javascript
- Registered this new route as entity operation of ECA
- Created an additional Javascript class which processes the mapping by creating "Elements" (events, gateways, tasks and conditions) for the root (the Process) and then properly orders them in the BPMN.io-UI

QA

- Use the fork of this module
- Download the package of this ECA-sample: https://ecaguide.org/library/simple/add_role_to_inserted_or_updated_user/
- Unzip it
- Alter the "eca.eca.eca_lib_0007.yml"-file (this the ECA-config file, not the model) by changing the modeller to "core"
- Install the dependencies of this sample (see "dependencies.yml") and the ECA Classic Modeller ( https://www.drupal.org/project/eca_cm → )
- Import the altered config file via the UI
- Go to the overview of ECA-models, you should notice that it was added
- On the right, select "Edit with BPMN.io"

TODO

- e2e-test with Nightwatch

Using bpmn-auto-layout is also working! Now for some more testing...

I just got a working POC where I was able to "clone" an existing ECA-config by opening it in the BPMN.io-modeler and use underlying modeler to create the necessary elements and connect them to each other.
Now focussing on the auto-layout... Would be cool to show this on DrupalCamp Berlin :-D

Looking at it further, it might even be that we don't need that cli-plugin but use the modeler-instance directly. See example: https://github.com/bpmn-io/bpmn-js-examples/blob/main/modeling-api/src/snippets/introduction.js

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

How could I have missed that...

Thank you for the patch!

lammensj → created an issue.

breidert → credited lammensj → .