[MAGNOLIA-2065] default workflow doesn't send e-mails when e-mail lines enabled Created: 19/Feb/08  Updated: 23/Jan/13  Resolved: 16/Jun/08

Status: Closed
Project: Magnolia
Component/s: workflow
Affects Version/s: 3.5.3
Fix Version/s: 3.6, 3.5.9

Type: Bug Priority: Minor
Reporter: Tom Jensen Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Attachments: HTML File activationNotification.html    
Issue Links:
supersession
supersedes MAGNOLIA-1953 activation workflow can not send e-ma... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Steps taken (assuming smtp server is already configured correctly):

1) Download default activation workflow
2) follow instructions in comments and uncomment lines for sending e-mail
3) upload updated workflow
4) activate the workflow (not sure if this is necessary but it was part of my steps)
5) activate a page

No e-mail is sent and an exception is thrown in the log with the following message:

Expression pathSelected is undefined on line 23, column 15 in workflowNotification.html.
The problematic instruction:
----------
==> ${pathSelected} [on line 23, column 13 in workflowNotification.html]
----------



 Comments   
Comment by Andy Pippin [ 13/Jun/08 ]

We are getting this in the deactivation workflow when moving a file, and when deleting a file.

Comment by Andy Pippin [ 13/Jun/08 ]

I have attached the activationNotification.html freemarker template we are using.

Comment by Magnolia International [ 16/Jun/08 ]

patched in trunk and 3.5 branch: removed the pathSelected variable and re-ordered some others.

Comment by Magnolia International [ 16/Jun/08 ]

Andy, I'm assuming actionRequested is a variable you're setting in your custom workflow definition. This and other variables are exposed to freemarker as regular variable and freemarker (a feature that has been debated a lot on their lists I think) chokes on unknown variables. When it is not certain that a given variable will be set or not, you can always do things like ${comment!'(none)'}, which will output none if the comment variable wasn't set.

Comment by Magnolia International [ 16/Jun/08 ]
  • actually readded the variable but it shouldn't choke anymore now.
Comment by Andy Pippin [ 16/Jun/08 ]

Correct, actionRequested is a field that is set in the workflow. It depends on what action is being requested and/or notified: request to publish, request to deactivate, successful publish, deactivation denied, etc....

Generated at Mon Feb 12 03:33:03 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.