Create Views Automators

@marcus Can I double check what it is you are expecting from this automator? I think you're saying an automator that can:

1. Allow a user to select a view
2. Pass the output of that view to the AI as context
3. Fill in the value of a field based on the AI output.

If that is what you're after, I *think* the existing automators should already be able to handle that if you use a https://www.drupal.org/project/viewsreference → field as your input for the automator without anything new needing coding. This would also mean the permissions on whichever view you were using would be respected.

MR dale smith,
I'd be curious to learn how to do that (maybe to demo for the AI workshop in davos).
Could you describe it to me a little more verbose how that should happen?
That would be awesome.

This always starts from a node right?
You can't start from a view where you select an automator and add it on top (tus for example summarise the data)?

@mrdalesmith - I think one of the advantages would be that you could follow the trail a lot easier if the actual output is stored in a text long field and if you want to use multiple fields.

I think one of the most used use cases would be to summarize comments, content etc. for a daily, weekly, monthly summary and its great to see right away in the node the snapshot of the view at that moment, without having to use AI Logs.

I will try your solution, we have an idea where it should be used and lets see if this makes sense. I will set to Postponed until then.

Looks like the Automators are quite picky about what types of field they'll let you pick as the base field in the basic mode, but what I have so far is:

1. Install and enable Viewsreference
2. Add viewsreference field to your node.
3. Add a text_area field to your node.
4. Enable an Automator on the text_area field: use Advanced mode (tokens) and a prompt similar to: "Summarise the following context to a description of not more than 500 words in a light and breezy tone. Context: [node:field_views]"

When you create a new node, you are able to select a view: on save, the view is rendered and passed to the AI as context to the prompt. The AI response is then added to your text_area field.

It all works as above with no code changes required: possibly we might want to make some changes so that the Basic mode will let you select an extended range of fields as context, but I'm not sure on whether the basic mode sends the plain field value (which would just be the view and display name) or actually renders it (which is what we'd need for it to work there).

Can you also pass other fields as filter or argument tokens?

The permissions working is really good, if we setup an automator there is always the risk that someone wants to show the entities summarized field, but has JSON:API or something like that setup and exposes the Views dump by mistake.

You can expose views settings as part of the viewsreference field settings - like I say, it's going to be better to handover the "views in a field" side of it to a module that's dedicated to doing it, otherwise you're just going to duplicate and/or possibly introduce issues.

So, I tried this and that works quite well, but there are still two reasons why this is needed.

Auditability - if its stored in a text field, that means we can look at a snapshot of the value at that time. If you are for instance writing a summary of all comments from the last 7 days and you think that summary is wrong, it is much easier to verify that when you have a snapshot of what it is based on.

Dynamicability for filters and args - if for instance a views takes an user id as a filter, and we have a previous step in the chain that uses RAG to find that user id, we can pass this on to a filter. This would be possible with arguments and the Views Reference Field, if we created an Automator for this field type, but filters are not available.

Also we will be able to do html to markdown very easily with this, something that is very valuble for AI.

I will do a first version of this, and try to get as many eyes on it as possible. Specifically regarding the access at the time of snapshotting.