SendRazorEmail - Access Workflow Settings from Template

[c9mb]

ParseWithRazorView is a tough read, and not sure if this is doable, but basically I'd like to be able to make decisions in the custom Razor template, based on the WorkFlow settings - even if that info is only available as a viewData object.

e.g. Should I display anything in the custom razor email for upload fields if the 'Attach Uploads' was checked on the Workflow settings.

[AndyButland]

Hi @c9mb - am just looking at this. It seems that probably the only setting you might want to use in the template itself is the one you've identified, the Attachments one.

So I'm thinking it might be cleanest to add this as a new property on the view model used for the email (i.e. on FormsHtmlModel).

So you could then do if (Model.MessageCanIncludeAttachments) {} or similar.

How does that sound to you?

[c9mb]

Hi @AndyButland - that would certainly address the specific issue, although the semantics suggest that "MessageHasAttachments" should perhaps be something more like "MessageAttachmentsEnabled" as a more accurate description?

However, I guess that a more expansive solution would be something like - Model.Workflow. - where the workflow properties could be added.

example... I could also foresee the possible need for a notice on an email something like:

"Note: This message was sent to @Model.Workflow.EmailAddress.GetValue() because it is registered as the Contact-Notifications recipient - if this is not correct please contact your administrator"

etc etc.

[AndyButland]

Yes, that sounds good, and you're right, there perhaps are other use cases for other settings.

I'm thinking now to make available on the model:

public IDictionary<string, string> WorkflowSettings { get; set; } = new Dictionary<string, string>();

And populate that with all the settings and their values (with placeholders parsed).

There is a concern with that was that these settings are all strings, so if you do want to use them for other types you'll need to handle converting them. And an implementer might have to do a bit of digging to get the keys, as they will match the property names used for the settings. My code above for determining if message attachments are enabled would then be something like:

if (Model.WorkflowSettings["Attachment"] == true.ToString()) { } 

So whilst this probably isn't as good as having proper strongly typed properties, it does at least make this information available in the Razor view if people want access to it. It has a benefit of being more maintainable (i.e. if we add a new setting, it'll automatically be available). And means if anyone has a custom workflow building the same model, and custom settings can be included.

Again, I'd appreciate your thoughts before we commit to this.

[c9mb]

Sounds great to me, and I'm not phased by the need to research and find the correct type to convert to.

While I have no issue with the key values being string type for the current application, perhaps a more flexible option might be:

public IDictionary<string, object> WorkflowSettings { get; set; } = new Dictionary<string, object>();

This is basically analogous to using a ViewDataDictionary - which uses string,object Key/Value types.

The conversion requirement remains the same - albeit perhaps slightly less performant - but it may perhaps give a bit more flexibility to the automatic Key/Value pair creation of future settings or custom-workflow settings, which might involve more complex types ?

[AndyButland]

OK, thanks again, will go ahead with this - though I think still with string as the dictionary's value type. The reason is that all settings are stored and defined as strings, even if they actually store information more suitable for a bool or int, or a more complex type like the field mapper used in the "Send to URL" workflow.

E.g. the one we are talking about for indicating whether attachments are included is defined like this:

[Setting("Attachments", Description = "Attach file uploads to email", View = "Checkbox", DisplayOrder = 100)]
public string Attachment { get; set; } = string.Empty;

To my understanding, and at least for all defined in Forms itself, these are always strings.

Hence it seems like it's better to expose that, as for many settings it's correct to be one, and for those that aren't they can be parsed into an appropriate primitive or deserialized into an object. If provided as objects, you wouldn't be able to just cast them anyway, other than to a string.

[c9mb]

Ok, that makes sense then - and sounds good to me.

[AndyButland]

This update will be included in the next minor release of Forms 10+.