Event Rule Action Data passed to Script

[renatoalmeidaoliveira]

NetBox version

v3.7.0

Feature type

Change to existing functionality

Proposed functionality

Currently EventRules passes a serialized version of the model as data to the linked Script, I think it would be better if the Action Data was processed like the Body Template of Webhoocks and passed to the Script.

Use case

It would allow users to build Script to react NetBox changes with the change context, currently the user cannot get directly the changelog. And by passing a parsed data with Event Data gives the plugin developer a lot of flexibility to build automations

Database changes

None

External dependencies

None

[jeremystretch]

I don't think we have a mechanism in place within a script right now to accept this data. Could you please expand your proposal above to specify exactly how a script would receive this data, in addition to the form data it currently accepts?

[renatoalmeidaoliveira]

In the current implementation the EventRule passes a serialized version of the instance as data to the script., so it isn't possible to pass any input to the Script using the EventRule. For example: The user wants that for every interface change a Script runs and perform Napalm checks on the interface, to implement that the user might need the Interface, the Device and the changes performed by the end user. But in the current implementation is only receives the changed object and the way it is passed to the Script it can't even be used as Script Inputs. The feature request aims to give the user an interface to setup what data should be passed to the Script when the changes happens

[renatoalmeidaoliveira]

In run_script data is passed as a dict where the keys are the Script Input, but when the Job is schedules in process_event_rules it passed as built in enqueue_object, (the serialized model) and that way it ain't gonna pass the expected dict to the Script since its expecting a dict with keys as the Script Inputs. I think that the Action Data (or any other field) could be used similar as the Templete body of webhooks using something like rende_body

[DanSheps]

I think I get what this is saying.

Basically, you can define your data template for what is passed to a script.

This is originally what I thought "action data" wass for.

[renatoalmeidaoliveira]

@DanSheps I thougt that it was the purpose of "action data" too. And when I look to the rest of the implementation it makes sense for me change the context injected to the template body in the webhook to whatever the user wants to setup inside the action data

[jeremystretch]

I've assigned this to @renatoalmeidaoliveira with the understanding that its scope is limited to passing the action_data associated with an event rule directly to the script being executed, as if it were user input.

[jeremystretch]

@renatoalmeidaoliveira are you still planning to work on this?

[renatoalmeidaoliveira]

@jeremystretch yes, I've talked with @arthanson in slack and waiting for some guidance to move on

[renatoalmeidaoliveira]

From the Script Developer point of view I think that Action Data should be passed to the Script the same way as the Input Form and REST API. That means the only sending the blob JSON isn't a good idea

[jeffgdotorg]

@renatoalmeidaoliveira I notice your PR got robo-closed. Do you anticipate having time to work on it soon, or should I let it go?

[misch42]

I'd like to see that feature, too.

[renatoalmeidaoliveira]

@jeffgdotorg I think we need to discuss a bit more about that PR, because the maintainer team wants the sent the data field as is without Jinja2 processing but IMO that isn't very usefull for the end user since if he wanna a static field he could just hard code in the Script. And IMO the Script interface should remain the same independent of what calls it meaning that data passed to the script should be processed and parsed by the Script form. I have time to work on that PR, but I would like to wait for a consense before giving more effort to it.

[molusk]

I can see at least 2 reasons to do it even if the parameters are static :

• be able to reuse a script not meant to be triggered by event rules : they may require parameters that are available for scheduling, being able to pass them in the event_data could be useful.
• be able to handle event types without multiplying scripts and only multiplying event rules until event_type is included by default in the parameters passed to the script.

Today I have to maintain 2 almost identical scripts, the first one to handle objects creations and modifications and another one to handle deletions. A simple parameter in action data passed to the script would be a lot better.

Of course, dynamic parameters could be a plus but we can also start with static ones and negotiate later for Jinja2 templates.