Answers.Body: <p>This was posted a while ago, but I thought I should post the solution I finally found to the problem (which still exists in my version 4.7.29 install)</p>
  
  <p>The solution to this problem was an API call. 
  While the value of $participant_status_id shows the value PRIOR to update, with this Smarty code added somewhere near the top of the template:</p>
  
  <pre><code>{crmAPI var='partinfo' entity='Participant' action='get' event_id=$event.id contact_id=$contactID}
  {foreach from=$partinfo.values item=participant}{/foreach}&lt;/p&gt;
  </code></pre>
  
  <p>I can then use the variable $participant.participant_status_id which will contain the correct status value reflecting the update made in the "Edit Event Registration" screen.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-03-23T17:17:32.003Z
Answers.LastActivityDate: 2018-03-23T17:17:32.003Z
Answers.UserDisplayName: Jeff Wood
Body: <p>Using version 4.6.9 on Drupal 7.  I'm working on a revision to our email template for event registrants, and in our environment, it's important to distinguish between individuals who are awaiting administrative approval (status 8), those with completed registration (status 1), and those assigned to the waitlist(status 7). I thought the variable $participant_status_id would meet my needs, but emails generated after an update to participant status show the previous value for $participant_status_id, not the updated value. Is this how it's supposed to work? What smarty variable do I use to check the updated status?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T01:09:10.947Z
Comments.Text: Are the emails triggered right after changing the participant status? There's a scheduled job which takes care of  updating the statuses for Waitlist and Awaiting Approval so if the email is triggered right after registration and the __Update Participant Statuses__ scheduled job runs say every 15 minutes, then you have an email with inaccurate data, your smarty variable is correct by the way. Does that clarifies things?
Comments.UserDisplayName: Andrei
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T06:35:44.627Z
Comments.Text: Yes, it's a system-workflow message triggered by checking the "send confirmation" box on the update screen and then saving an update, but I don't think a scheduled job could be updating the statuses because if, after making a change and triggering and email, I immediately return to the record and save it triggering a second email, whether or not I make any additional change to the record, the data will then reflect the new status, regardless of how little time has elapsed. It appears as though the participant status is being read from the DB by smarty too early, before the update takes effect
Comments.UserDisplayName: Jeff Wood
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T13:03:14.070Z
Comments.Text: I just had a look at Civi's default template for online registration, and I was wrong, sorry, the smarty variable is __$participant_status__ so you would do `{if $participant_status eq 'Awaiting Approval'}Awaiting Approval{elseif $participant_status eq 'Registerd'}Registered{/if}`. Regarding your workflow, I'm not sure if I understand what you mean with 'I immediately return to the record and save it triggering a second email...'
Comments.UserDisplayName: Andrei
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T14:00:07.403Z
Comments.Text: I can imagine this case: participant registers with status __Awaiting Approval__, he/she receives and email acknowledging their status, admin change his/her status to __Pending from Approval__, participant then receives a second email to confirm his/her place and proceed to payment if applies and then participant receives a 3rd email with confirmation and payment receipt. Where does you __Status fail to update__ in this workflow?
Comments.UserDisplayName: Andrei
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T23:06:01.670Z
Comments.Text: Thanks for all your attention. I don't see $participant_status in my debug output at all. Is this a new variable in the 4.7 version? In any case, the way this is causing trouble in our scenario is as follows: Participant registers online for a free event that is open to faculty. The status is assigned as **Awaiting Approval** (which is participant_status_id 8) and an email from the online template is generated saying that the request will be reviewed within some number of hours.
Comments.UserDisplayName: Jeff Wood
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T23:16:07.050Z
Comments.Text: A staff member then reviews and edits the registration assigning it  to either **Registered** (id 2) or **Waitlist** (id 7), checks the "send confirmation" box and saves the changes.  An email is generated using the 'off-line' workflow template, but when my code checks the value of $participant_status_id it still returns an '8' as though no change had been made. If a staff member then open the registration for editing again, without making any changes, clicks the "send confirmation" box and clicks save, a third email, with the correct $participant_status_id will be generated.
Comments.UserDisplayName: Jeff Wood
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-23T23:26:50.963Z
Comments.Text: If you navigate to __Administer-Communications-Message Templates- System Workflow Messages__ you'll se the template __Events - Registration Confirmation and Receipt online__ among others, that's the first email is triggered when a participant registers for the event, click on edit or view default, you should see how the status is checked with `$participant_status`, this applies for v4.6
Comments.UserDisplayName: Andrei
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-24T00:16:54.437Z
Comments.Text: I see what you're referring to. It's on line 34 and if $participant_status isn't present it falls back on the $isOnWaitlist variable, but when I run {debug} in the template I have yet to see an instance when $participant_status is actually set. $isOnWaitlist is accurate but doesn't provide the specific status. It lumps people who are assigned to the waitlist and those awaiting approval together as "true". Could this be a bug that was fixed after 4.6.9? I can run an upgrade, but it will take a while, with testing and all.
Comments.UserDisplayName: Jeff Wood
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-24T00:58:46.333Z
Comments.Text: Not sure if is a bug, I still believe is tied to the Update participant status scheduled job, I'm not very sure now, I can deploy an instance of 4.6.13 on my test server tomorrow and report back. I just noticed that status fails only when the email is triggered with __Send Notification__ and not with __Send Confirmation__, now I understand what you meant with 'return to the record and save it...'. Can you confirm this behavior? Changing that status from Awaiting approval to Pending from approval, untick Send Notification and tick Send Confirmation.
Comments.UserDisplayName: Andrei
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-02-24T17:10:37.690Z
Comments.Text: Tested as you suggest. After a **new** registration (online or offline) the {debug} from a confirmation email shows that both $participant_status_id and $participant_status are unset. After an offline status change is made, the confirmation email has the $participant_status_id from before the change, while $participant_status is still unset. One thing that might be at issue: In our setup "Use a confirmation screen?" is set to "No" because our events are free. Are these variable perhaps dependent on the confirmation screen being displayed? If so, they probably shouldn't be.
Comments.UserDisplayName: Jeff Wood
Tags: <civievent><message-templates><smarty><system-workflow-messages>
Title: $participant_status_id shows previous value in email template
ThreadText: # $participant_status_id shows previous value in email template
  
  (Asked by: username_0 on 2016-02-23)
  
  Using version 4.6.9 on Drupal 7. I'm working on a revision to our email template for event registrants, and in our environment, it's important to distinguish between individuals who are awaiting administrative approval (status 8), those with completed registration (status 1), and those assigned to the waitlist(status 7). I thought the variable $participant\_status\_id would meet my needs, but emails generated after an update to participant status show the previous value for $participant\_status\_id, not the updated value. Is this how it's supposed to work? What smarty variable do I use to check the updated status?
  
  **Tags:** civievent, message-templates, smarty, system-workflow-messages
  
  > **Comments:**
  > **username_1**: Are the emails triggered right after changing the participant status? There's a scheduled job which takes care of  updating the statuses for Waitlist and Awaiting Approval so if the email is triggered right after registration and the __Update Participant Statuses__ scheduled job runs say every 15 minutes, then you have an email with inaccurate data, your smarty variable is correct by the way. Does that clarifies things?  
  > **username_0**: Yes, it's a system-workflow message triggered by checking the "send confirmation" box on the update screen and then saving an update, but I don't think a scheduled job could be updating the statuses because if, after making a change and triggering and email, I immediately return to the record and save it triggering a second email, whether or not I make any additional change to the record, the data will then reflect the new status, regardless of how little time has elapsed. It appears as though the participant status is being read from the DB by smarty too early, before the update takes effect  
  > **username_1**: I just had a look at Civi's default template for online registration, and I was wrong, sorry, the smarty variable is __$participant_status__ so you would do `{if $participant_status eq 'Awaiting Approval'}Awaiting Approval{elseif $participant_status eq 'Registerd'}Registered{/if}`. Regarding your workflow, I'm not sure if I understand what you mean with 'I immediately return to the record and save it triggering a second email...'  
  > **username_1**: I can imagine this case: participant registers with status __Awaiting Approval__, he/she receives and email acknowledging their status, admin change his/her status to __Pending from Approval__, participant then receives a second email to confirm his/her place and proceed to payment if applies and then participant receives a 3rd email with confirmation and payment receipt. Where does you __Status fail to update__ in this workflow?  
  > **username_0**: Thanks for all your attention. I don't see $participant_status in my debug output at all. Is this a new variable in the 4.7 version? In any case, the way this is causing trouble in our scenario is as follows: Participant registers online for a free event that is open to faculty. The status is assigned as **Awaiting Approval** (which is participant_status_id 8) and an email from the online template is generated saying that the request will be reviewed within some number of hours.  
  > **username_0**: A staff member then reviews and edits the registration assigning it  to either **Registered** (id 2) or **Waitlist** (id 7), checks the "send confirmation" box and saves the changes.  An email is generated using the 'off-line' workflow template, but when my code checks the value of $participant_status_id it still returns an '8' as though no change had been made. If a staff member then open the registration for editing again, without making any changes, clicks the "send confirmation" box and clicks save, a third email, with the correct $participant_status_id will be generated.  
  > **username_1**: If you navigate to __Administer-Communications-Message Templates- System Workflow Messages__ you'll se the template __Events - Registration Confirmation and Receipt online__ among others, that's the first email is triggered when a participant registers for the event, click on edit or view default, you should see how the status is checked with `$participant_status`, this applies for v4.6  
  > **username_0**: I see what you're referring to. It's on line 34 and if $participant_status isn't present it falls back on the $isOnWaitlist variable, but when I run {debug} in the template I have yet to see an instance when $participant_status is actually set. $isOnWaitlist is accurate but doesn't provide the specific status. It lumps people who are assigned to the waitlist and those awaiting approval together as "true". Could this be a bug that was fixed after 4.6.9? I can run an upgrade, but it will take a while, with testing and all.  
  > **username_1**: Not sure if is a bug, I still believe is tied to the Update participant status scheduled job, I'm not very sure now, I can deploy an instance of 4.6.13 on my test server tomorrow and report back. I just noticed that status fails only when the email is triggered with __Send Notification__ and not with __Send Confirmation__, now I understand what you meant with 'return to the record and save it...'. Can you confirm this behavior? Changing that status from Awaiting approval to Pending from approval, untick Send Notification and tick Send Confirmation.  
  > **username_0**: Tested as you suggest. After a **new** registration (online or offline) the {debug} from a confirmation email shows that both $participant_status_id and $participant_status are unset. After an offline status change is made, the confirmation email has the $participant_status_id from before the change, while $participant_status is still unset. One thing that might be at issue: In our setup "Use a confirmation screen?" is set to "No" because our events are free. Are these variable perhaps dependent on the confirmation screen being displayed? If so, they probably shouldn't be.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2018-03-23. Score: 3 | Accepted answer
  
  This was posted a while ago, but I thought I should post the solution I finally found to the problem (which still exists in my version 4.7.29 install)
  The solution to this problem was an API call. 
  While the value of $participant_status_id shows the value PRIOR to update, with this Smarty code added somewhere near the top of the template:
  {crmAPI var='partinfo' entity='Participant' action='get' event_id=$event.id contact_id=$contactID}
  {foreach from=$partinfo.values item=participant}{/foreach}
  
  I can then use the variable $participant.participant_status_id which will contain the correct status value reflecting the update made in the "Edit Event Registration" screen.
  
  
  ---
  
  