Configurable email body

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Configurable email body

James Newcombe
I'm trying to build a solution that needs to send about 6 different categories of email, each of which can be in one of three languages.

I spent some time looking through the source to try to work out how this should work, and I'm pretty sure I can do what I need to do in an XML Pipeline (or several), which I can call as a process from a button action. I think I also understand how to build the conditional statements that the action will use to determine which process to call.

All of the email processing I need appears to be handled by email-form.xpl, and having spent some time looking through it I came to the conclusion that I don't need half of what it does, so I should build my own custom email-form.xpl and override the built in one (I don't want to email the documents or attachments anywhere, I just want to send notifications with links to the documents, so users have to come back to Form Runner and login to look at them).

I can't figure out where email-form.xpl gets the body of the email message. It's clearly picking up something here, and the code seems to be able to distinguish between the various languages (although I want to use the language of the person who will receive the email, defined in a field in the form with their email address, not the current language of the form), but I can't work out if it's a file, generated from somewhere else, or it's even just a place-holder that will later be replaced.

Is there a configuration property that I can set to tell the email engine where to pick up the body of the email or did I just miss something obvious in the code ?

What I'd like is to have a set of predefined email templates in each language in a resources directory, each containing placeholders for the form data I need to put into the emails.

Any suggestions welcome.
Reply | Threaded
Open this post in threaded view
|

Re: Configurable email body

Aaron Spike
I think the email body is defined in an xml file:

https://github.com/orbeon/orbeon-forms/blob/master/src/resources/apps/fr/i18n/resources.xml#L104

At least some resources can be overridden in the properties files:

http://wiki.orbeon.com/forms/doc/developer-guide/configuration-properties/configuration-properties-form-runner#TOC-Overriding-resources


Aaron Spike

This electronic communication, including any attached documents, may contain confidential and/or legally privileged information that is intended only for use by the recipient(s) named above. If you have received this communication in error, please notify the sender immediately and delete the communication and any attachments. Views expressed by the author do not necessarily represent those of Martin Luther College.

--
You received this message because you are subscribed to the Google Groups "Orbeon Forms" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: Configurable email body

James Newcombe
Thanks Aaron.

I've managed to create my own resources.xml and email-form.xpl, and followed the appropriate instructions at http://wiki.orbeon.com/forms/doc/developer-guide/admin/overriding-adding-resources to create my own resources directory tree to override the standard Orbeon resources. I'm sure the server is picking up my changes, although I have to restart Tomcat every time I modify email-form.xpl for it to pick up those changes. I've attached both of those files

email-form-jn.xpl
resources-jn.xml
orbeon.log

I think the XPL is functional - unfinished, but it should produce some results to show me if I'm on the right track - and I've filled it with debug so I can see when it enters and exits the various pipelines. I can see that it is outputting my debug from the attached log snapshot.

It runs, but it seems to run into the long grass right around line 30, where it says it is storing the input  as a request attribute so that persistence-model.xml picks it up. I see it enter and exit that code, and then nothing happens; it just exits email-form.xpl. Form Runner tells me I sent an email, but it doesn't. No errors are reported, and the form is saved. If I replace my customised email-form.xpl with the original, commented for debug, I can see it working through the various pipelines and it produces an email. My changes are all in the 'create email subject/body' parts, so I'd have expected it to get that far before it fails in my xpl, but it doesn't.The form is the same for both tests, and the resources are the same. Only the XPL changes.

The entire thing is hung off the email button for testing, so I haven't created any special process to drive this.

What I'm trying to do is select the body of the form and the set of people to whom the email will be sent based on the status of the form. I also scan the body of the email to do a kind of 'mail merge', replacing placeholders with values from the form.

So, Requestor submits the form, an email should be generated to them to tell them it was successfully submitted. An Assessor (client calls them Originators) is emailed to tell them to go read the form and add some internal info. When they save it, an email should be generated to one or more approvers to tell them to go do their thing. Once it's approver, it goes to a data entry clerk to update the client ERP, then everyone gets emailed to inform them that it's closed. At each stage the form status gets updated after someone edits it and after emails are sent. In order to distinguish between the different classes of email recipient, I added my own class name in the 'Custom CSS class' section of the form designer detail dialog for each email control. Orbeon seems to ignore it because it's not valid CSS, but it looks like it should be picked up by the p:has-class test in the XPL.

Ideally I'd have used a workflow engine like Activiti to manage the state, but I've been forbidden from doing that. I've had to settle for using a form status field instead.

I'm looking for ideas. I can't see where the code is going when it finishes processing my form. It seems to have decided it was successful and exits the processor without bothering to finish preparing the email, but I don't understand why that would be the case.

Oh and this is forms 4.8.0.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Configurable email body

Erik Bruchez
Administrator
I think that things won't run because your XSLT transform with id `message` is not read by anybody.

Pipelines run lazily, so if nobody reads the output of a transformation, the transformation won't run.

The original pipeline runs because, it generates dynamically an `oxf:email` processor, which reads the message.

So to send the email, you need to hook up an `oxf:email` after the message. Or if you just want to log the output of the transformation, add:

    <p:processor name="oxf:null-serializer">
        <p:input name="data" href="#message"/>
    </p:processor>

-Erik
Reply | Threaded
Open this post in threaded view
|

Re: Configurable email body

James Newcombe
Thanks Erik.

Much better. It still doesn't run, but now it's telling me why it doesn't run.
Reply | Threaded
Open this post in threaded view
|

Re: Configurable email body

James Newcombe
I don't know if this is the right way to do this or not, and I know it isn't elegant, but:

In trying to manage the email process, I have created a process that is hung off the 'send' button. The idea is that when a user presses 'SEND', the status of the form will be checked to see if it has been submitted or not (and ultimately I'll run a series of checks for different statuses).

I have a hidden field on the form called ShadowStatus, in a NotesSection, that has an initial value of 'NOTSUBMITTED', and allows me to track the state of the form. There is a separate Status that allows me to show the state of the application process in business terms on screen, and in the form summary page.

The result of the snippet below that I'm looking for is :
if form not submitted
          validate it
          set the document ID as the submission reference in the form
          set the shadow status to SUBMITTED
          save it
          email the requestor to thank them for their submission
          set the shadow status to PENDINGORIGINATOR (to indicate that a reviewer has to look at it)
          set the application status to 'Pending Originator' to show the state of the application
          save it
          trigger the email process to now email the originator to tell them to go look at it
          Take the user back to the form summary page

No matter how I check the value of the element, the process always says the form has already been submitted. I can only assume it isn't finding the element I told it to check, and therefore evaluating the condition to false. I've enabled debug, but it doesn't appear to have an option to dump the information that the condition is evaluating. The condition is highlighted in bold below.

So far I've tried :
if ("instance('fr-form-instance')/form/NotesSection/Nt-ShadowStatus = NOTSUBMITTED ")
if ("//NotesSection/Nt-ShadowStatus = NOTSUBMITTED ")
if ("//NotesSection/Nt-ShadowStatus = 'NOTSUBMITTED' ")


<property as="xs:string"
                  name="oxf.fr.detail.process.send.customer.*">
                  if ("instance('fr-form-instance')/form/NotesSection/Nt-ShadowStatus = NOTSUBMITTED ")
                  then
                     (require-valid
                      then xf:setvalue(ref="//NotesSection/Nt-ShadowStatus", value="SUBMITTED")
                      then xf:setvalue(ref="//SubmissionSection/SU-Reference", value="xxf:instance('fr-parameters-instance')/document")
                      then save
                      then email
                      then xf:setvalue(ref="//NotesSection/Nt-ShadowStatus", value="PENDINGORIGINATOR")
                      then xf:setvalue(ref="//NotesSection/Nt-Status", value="PENDING ORIGINATOR")
                      then save
                      then email
                      then success-message(message="Thank for submitting your request")
                      then navigate(uri="http://localhost:8080/orbeon/fr/customer/CustomerServiceRequest/summary"))
                  else
                      error-message(message="This form has already been submitted")
        </property>


I'm looking for ideas for how I :
1. Get the process to throw debug trace so I can see what the process is evaluating (I've enable debugging for process following the instructions here: http://wiki.orbeon.com/forms/doc/developer-guide/xforms-logging but I get nothing from inside this process, only the result of it.
2. Get to the element to evaluate and then set/reset it.

I'm sure I'm doing something dumb, but I can't see what flavour of dumb it is.