Add Variables JSON to Mailjet Batch send

[marcinkoziej]

Hey N8N!
Thank you for creating such an AWESOME tool and releasing it under FLOSS license.

We wanted to send emails with Mailjet but pass all the variables instead of adding them by hand in the UI one by one - so we added this new parameter to pass variables JSON, and it will be sent as-is.

Would that be something to add to upstream?

[CLAassistant]

All committers have signed the CLA.

[marcinkoziej]

Hello, will you find time to review this proposal?

[RicardoE105]

@marcinkoziej just had a quick look at it. Why a JSON instead of a fixed collection with a key-value pair? Would it not be easier the latter?

[marcinkoziej]

Our use case is that on input we have a flat key-value list of custom fields, and we want to be able to create MJ templates which use these fields.
So for example, in one case the fields are "job_position" and "office" and we will want to use these variables in the email sent. In other case we would have a different fields.
A flat key-value pair would work, but not one with fixed keys.

[michael-radency]

Hello @marcinkoziej thank you for this PR, I did made some improvements and as I wasn't able to push them to your fork I did create new PR #2966

[RicardoE105]

@marcinkoziej can you provide an example that would not work with the current key-value pair approach? You know that you can provide an expression in the value and make whatever you want, right? for example, { categories: [ 'a', 'b' , 'c'] }

[marcinkoziej]

Example:

This workflow is triggered when a new "confirmation request" is generated in the system. This means that a pending operation is created in the system (there are a few types of operation, like: "confirm request to join team by user").
The workflow will unpack the JSON of the confirm, will check if it has an email of person to allow the operation. If it's not set, it will do a graphql lookup on a relevant team of coordinators, and all of them will be emailed.
Each operation carries a set of different fields, which we want to place in the email. For example, the "confirm request to join team by user" will have their name, social media profile picture, job position, and organization that they are working for. A different operation confirmation will carry different fields, and we will use another template utilizing these different fields.

Does it sound more clear?
With fixed key-values configured in UI we would have to create a copy of this workflow and hard-code all the fields, which would be less maintainable for us, as any change in workflow would require to modify all the copies (and not make a mistake). Also when we introduce a new field to operation confirm payload, we add it to the system generating the event, and to the mailjet template. With fixed key-values in n8n, we would have another place to add the field.

[marcinkoziej]

@marcinkoziej can you provide an example that would not work with the current key-value pair approach? You know that you can provide an expression in the value and make whatever you want, right? for example, { categories: [ 'a', 'b' , 'c'] }

@RicardoE105 perhaps I am missing something? I see that I can add values like this:

and indeed I can use macro language to set both key and value, but I need to know in advance how many fields are there, for example, and I if i want to send {"category": ["a", "b", "c"]} to Mailjet, I would have to set first key to "category" and the value to {{$node.json["category"]}} or similar.. But here I need to hardcode the variable name "category". Or is there a way to just pass a Javascript Object to be used as key-value for Mailjet?

[RicardoE105]

@marcinkoziej yes, that makes sense. Ideally, every fixedCollection and collection parameter could be transformed to a JSON input out of the box. That way, when encountered with the scenario you described we do not have to extend the node. I Will discuss it internally.

I made the following changes to your PR:

1 - Added a top-level parameter JSON Parameters that when set to true, shows the variables (JSON) parameter. Else, we would have 2 parameters that set the same value which makes it confusing.
2 - Added credentials verification.
3 - Added the sandbox parameter to the credentials for easy testing.

Thanks very much for your contribution. We will let you know when it's released.

[janober]

Thanks a lot for your contribution @marcinkoziej. Got merged with #2987.

Just, fyi. n8n is not OSI-approved open-source. Rather fair-code licensed. You can also read more about it in our blog and FAQ.

[janober]

Got released with n8n@0.169.0