Answers.Body: <p>CiviCRM uses the registered_by_id to link multiple participants together. Since the CiviEvent registration page doesn't allow you to register others without also registering yourself for an event, an fk to participan_id makes sense.</p>
  
  <p>However, some use cases (e.g. summer camps) have different requirements, where a parent registers 1 or more children (but not themselves). Implementing this today in CiviCRM presents 2 challenges:</p>
  
  <ol>
  <li>The UI doesn't support this use case</li>
  <li>The schema doesn't support it either</li>
  </ol>
  
  <p>If you're using Drupal, Webform-CiviCRM Integration solves the first problem very well. I've used a custom contact reference field to work around the 2nd.</p>
  
  <p>Going forward, I agree the schema needs to be more flexible, but it's not as simple as changing that field to point to contact_id. Yes we need a better way to point directly to the registering contact, but we also need to keep the functionality of being able to group participants together in a single registration. Possible solutions could be:</p>
  
  <ul>
  <li>Alter the registered_by_id field to point to the registration <em>activity</em> instead of the participant record.</li>
  <li>Add a second field to point directly to the registering contact, and leave the existing one as well.</li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-04-11T15:44:48.583Z
Answers.Text: Throwing another use case into the pot. In workshops it'd be useful to track who marked participants as having attended. We're working on (yet another?) QR code attendance "kiosk" and would like to know which authenticated user set it up for the particular event (i.e. was in charge of recording attendance.
Answers.UserDisplayName: wil_SRQ
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T02:27:51.007Z
Answers.Text: I posted the question initially to see if the FK was the desired use case or a bug. Sounds like it's not a bug, so I'll mark this as the answer. I've been working a lot through events API over the last couple of weeks, and stumbled upon a spec for an order API for 4.7. When it's time to decouple participants (and other items) from payments and connect them independently to an order, I think this FK would change. I work extensively in big event ticketing systems where everything is order-based, so I think I just need to reframe my thinking to the way that Civi does it.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-05T02:15:04.390Z
Answers.LastActivityDate: 2015-05-05T02:15:04.390Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>I think there is some of the code related to payment processing that assumes the registered_by_id is the participant under whom payment has been made. Any changes to the schema would need to account for that. Thats probably the primary reason the FK is to civicrm_participant</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-06T17:13:45.487Z
Answers.Text: Seems like this improvement being suggested is similar to the existing CiviCRM feature that allows for gift memberships to be purchased.  Should the architecture/schema be consistent when someone is paying/registering on behalf of someone else? ( ie a parent is buying a membership for their child, or a parent is registering/paying for an event for their child)
Answers.UserDisplayName: Sarah Poger Gladstone
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-04T03:03:21.217Z
Answers.LastActivityDate: 2015-05-04T03:03:21.217Z
Answers.UserDisplayName: Donald Lobo
Body: <p>While troubleshooting for a different question, I noticed that <code>civicrm_participant.registered_by_id</code> is an FK back to <code>civicrm_participant.id</code>. Since it's a common use case for one contact to register others and not him/herself (e.g. buying event tickets as gifts for friends), should this be an FK to <code>civicrm_contact.id</code>?</p>
  
Tags: <database><architecture>
Title: Should civicrm_participant.registered_by_id be an FK to civicrm_contact?
ThreadText: # Should civicrm_participant.registered_by_id be an FK to civicrm_contact?
  
  (Asked by: username_0 on 2015-05-03)
  
  While troubleshooting for a different question, I noticed that `civicrm_participant.registered_by_id` is an FK back to `civicrm_participant.id`. Since it's a common use case for one contact to register others and not him/herself (e.g. buying event tickets as gifts for friends), should this be an FK to `civicrm_contact.id`?
  
  **Tags:** database, architecture
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-05-05. Score: 1 | Accepted answer
  
  CiviCRM uses the registered\_by\_id to link multiple participants together. Since the CiviEvent registration page doesn't allow you to register others without also registering yourself for an event, an fk to participan\_id makes sense.
  
  However, some use cases (e.g. summer camps) have different requirements, where a parent registers 1 or more children (but not themselves). Implementing this today in CiviCRM presents 2 challenges:
  
  1. The UI doesn't support this use case
  2. The schema doesn't support it either
  
  If you're using Drupal, Webform-CiviCRM Integration solves the first problem very well. I've used a custom contact reference field to work around the 2nd.
  
  Going forward, I agree the schema needs to be more flexible, but it's not as simple as changing that field to point to contact\_id. Yes we need a better way to point directly to the registering contact, but we also need to keep the functionality of being able to group participants together in a single registration. Possible solutions could be:
  
  * Alter the registered\_by\_id field to point to the registration *activity* instead of the participant record.
  * Add a second field to point directly to the registering contact, and leave the existing one as well.
  
  > **Comments:**
  > **username_0**: I posted the question initially to see if the FK was the desired use case or a bug. Sounds like it's not a bug, so I'll mark this as the answer. I've been working a lot through events API over the last couple of weeks, and stumbled upon a spec for an order API for 4.7. When it's time to decouple participants (and other items) from payments and connect them independently to an order, I think this FK would change. I work extensively in big event ticketing systems where everything is order-based, so I think I just need to reframe my thinking to the way that Civi does it.  
  > **username_2**: Throwing another use case into the pot. In workshops it'd be useful to track who marked participants as having attended. We're working on (yet another?) QR code attendance "kiosk" and would like to know which authenticated user set it up for the particular event (i.e. was in charge of recording attendance.  
  
  ---
  
  ### Answer by username_3 on 2015-05-04. Score: 1
  
  I think there is some of the code related to payment processing that assumes the registered\_by\_id is the participant under whom payment has been made. Any changes to the schema would need to account for that. Thats probably the primary reason the FK is to civicrm\_participant
  
  > **Comments:**
  > **username_4**: Seems like this improvement being suggested is similar to the existing CiviCRM feature that allows for gift memberships to be purchased.  Should the architecture/schema be consistent when someone is paying/registering on behalf of someone else? ( ie a parent is buying a membership for their child, or a parent is registering/paying for an event for their child)  
  
  ---
  
  