Changing participant role of registered participant

[sykong]

Hi,

I have the following situation.

Participant 1 has registered for an event and also registered participant 2 and participant 3. If now, I edit participant 1 and change his role, the change also affects participants 2 & 3.

Is this the intended behaviour?

[Donald Lobo]

i'm pretty sure its not intended behavior (and if it is, it should be a bug, IMO)

can you reproduce this on the demo server

thanx

lobo

[sykong]

Sorry... the "bug" should be "If the status is changed, the status of the other participants are also changed".  But this behaviour does not seem to be very consistent.

http://drupal.demo.civicrm.org/civicrm/event/search?reset=1&force=1&event=8&status=true

I registered 4 participants. Then I changed the status of participant No 1 to attended. And all became attended. Then I changed participant No 1 to No show and from then on, the status does not follow

[sykong]

I just created another 4 participants.. and can't seem to duplicate what happened

... of course the status of the previous 3 remained as attended.. telling me that I did not imagine the bug

[Dave Greenberg]

I've been testing this out and there's some inconsistencies in how things work depending on HOW you update the participant status. There is logic that wants to update all "related" participants for the multiple registration case - which was designed to handle situations like:

- Participants register "pay later" and then primary participant cancels. All secondary participants should also be cancelled since payment (contribution record) has been cancelled.
- Same if primary participant record in Pending status "expires".
- And when primary participant record goes from Pending to Registered (payment received) - all others should also be updated

That said, updates from Registered to No Show (like your case) should not "cascade". I'm investigating a bit more and will file an issue shortly (and update this post).

[sykong]

I hope you manage to find the bug... I could not manage to duplicate it by creating 4 more participants!

On my own installation, I have a custom status (called "volunteer") that is triggering it... but I can't seem to duplicate it consistently either...

[Dave Greenberg]

I want to make sure we're talking about the same thing here because at different points in this thread you've used two different terms - "role" AND "status". There are two different properties of a participant. I've been assuming you are actually talking about statuses, but please confirm and also would be good to confirm the actual steps (workflow) you're using to update statuses.

There are 5 different possible workflows that will result in an update to a participant status:
- Edit Participant (from contact's Events tab) and change status in drop-down
- Find Participants -> Change Participant Status action
- Find Participants -> Batch Update via Profile
- Find Contributions -> Update Pending Contribution Status - this will also update the Participant status for "Pending pay later" registrations
- Edit Contribution (from contact's Contributions tab) - this will also update related Participant record status for Pending pay later registrations

The "correct" behavior is that participant status changes should cascade down from primary participant to additional participants whom they registered IF there is a related payment (contribution) record. For example:

Code: [Select]

- Person A registers for herself and person's B and C with "pay later" feature. All participants have pay-later status linked to a single Pending payment record.
- Person A calls up and cancels her registration. When staff sets her registration status to "Cancelled", statuses for person's B and C should also be cancelled.

However,  status changes such as Registered -> Attended, or Registered -> No-show should NOT be cascaded to the "additional participants".

I've created an issue here so you can track progress.
http://issues.civicrm.org/jira/browse/CRM-5403
 

[sykong]

I'm having problem duplicating it....

Where is the code for this? Maybe I can look at it and see what might trigger it?

[sykong]

Some more interesting discover...

Participant 1 registers Participants 2-5. When I batch edit Participant 1-3, but only change the status for Participant 1, Participants 4-5 follow the change!

Will test it out further later to see if I can get it to duplicate consistently

[Kiran Jagtap]

Participant 1 registers Participants 2-5. When I batch edit Participant 1-3, but only change the status for Participant 1, Participants 4-5 follow the change!

If I am not wrong, It is expected behavior.

When you change the status of primary participant, additional participant status automatically get changed.

But If you change status of only additional participant, primary participant status is not going to change.

kiran

[Kiran Jagtap]

Where is the code for this? Maybe I can look at it and see what might trigger it?

go to  CRM/Event/BAO/Participant.php line around 879
do check "transitionParticipants( )" function.

This function is handling :
1. Status change logic.
2. Trigger mails for status change.
3. Create activities.

kiran

[Dave Greenberg]

Kiran is correct in general, but I don't think we are being completely consistent about this AND I think there are some status changes where the secondary participants should NOT follow (inherit) change to primary participant status (notably the Registered -> Attended, or Registered -> No-show changes).

We have described the general business rule here and we are running some tests and tracking results here:

http://wiki.civicrm.org/confluence/display/CRM/Testing+Participant+Status+Updates+for+Secondary+Registrations

[sykong]

Seems like there could be 2 issues?

1. Secondary participants should not inherit some status changes

2. Based on the code in 3.0.2 that I'm looking at it seems like secondary participants would always inherit status changes... but this is not happening... From my sql records, it seems like in some cases, the updateParticipantStatus function is used instead (because register_date remains the same as the secondary participants even though the status for the primary and secondary participants are different)

[Dave Greenberg]

I've flagged your comment in the issue. Thx.