Answers.Body: <p>Another approach worth considering is the use of custom fields on the Relationship. You can add a Custom Field for Proxy Shopper, on to the Household Member relationship, and if Willow lets you know that Jerry is 'safe' to be a Proxy Shopper then you have that information without need for potential code and complexity</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-20T00:22:40.287Z
Answers.Text: Since we don't have household memberships (just individual memberships), the volunteer or staff who assigns proxy shopper to an individual would have to remember that proxy shoppers must belong to the same household as the individual member. And there's no way to guarantee every volunteer and staff will remember that, which would make the proxy shopper program prone to administrative errors. However, I'm not familiar with household memberships, and now that they've caught my attention, it seems I need to do a little research and learn more about them. Maybe we should convert our memberships.
Answers.UserDisplayName: Prónay
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-20T00:33:55.963Z
Answers.Text: Sorry i think my answer should have said, add the field to the Household Relationship. will alter it
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-16T19:17:46.530Z
Answers.LastActivityDate: 2017-10-20T00:34:10.317Z
Answers.LastEditDate: 2017-10-20T00:34:10.317Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>To handle this, you would have to write an extension.  I would use <code>hook_civicrm_pre</code> on the Relationship entity (operation is "create", maybe "edit" too if households tend to shift?).</p>
  
  <p>Do two API calls to the Relationship API to get the Household(s) of both contacts.  Compare to make sure at least one value is identical in both; if not, cancel the save.</p>
  
  <p>For a better UX, I'd call the same function from <code>hook_civicrm_validateForm</code>.  The form validation can give a friendly message to the backend users - but the <code>pre</code> hook will ensure that you also can't create the relationship via the API or some other way.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-20T00:24:19.953Z
Answers.Text: In the interest of finishing it this century, I'm not about to write the extension myself. To those of you who are competent in this area, what would you charge to write, test and deploy it?
Answers.UserDisplayName: Prónay
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-20T17:06:51.170Z
Answers.Text: @Prónay Hit me up on Mattermost? Username is junglebird.
Answers.UserDisplayName: Jon G - Megaphone Tech
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-10-18T06:21:19.570Z
Answers.LastActivityDate: 2017-10-18T06:21:19.570Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>Our food co-op site uses relationships, e.g. Household Member. We have a custom relationship type: <strong>Proxy Shopper</strong>. We're interested in making Proxy Shopper conditional so that no individual can get Proxy Shopper status <strong>unless</strong> both individuals are Members of the same Household.</p>
  
  <blockquote>
    <p><em>Example:</em></p>
    
    <p>Jerry and Willow are Members of the Ortega Household. Willow
    owns a co-op membership with which she can shop at our store, and
    Jerry does not own such a membership. However, Willow has designated
    Jerry as a Proxy Shopper so he'll be able to shop on her behalf.</p>
    
    <p>Willow's mother Sabrina, however, is a member of the Sturm household
    (not Ortega), so Sabrina should not be a proxy shopper for Willow,
    even though Willow wants to send her mother to the co-op.</p>
  </blockquote>
  
  <p>In short, <strong>we're looking for a way (possibly through an extension) to condition the Proxy Shopper relationship type upon membership in the same Household</strong>.</p>
  
  <p>Worth noting that while belonging to the same Household should be required for setting a Proxy Shopper relationship, Household membership should not predict a Proxy Shopper relationship. In other words, no Household Member should become a Proxy Shopper unless someone sets that relationship via the admin interface.</p>
  
  <p>What's the best way to do this -- beyond just telling backend users that they shouldn't make anyone a Proxy Shopper unless that individual belongs to the same Household as the second individual?</p>
  
Tags: <civimember><relationships><condition>
Title: Conditional relationships?
ThreadText: # Conditional relationships?
  
  (Asked by: username_0 on 2017-10-16)
  
  Our food co-op site uses relationships, e.g. Household Member. We have a custom relationship type: **Proxy Shopper**. We're interested in making Proxy Shopper conditional so that no individual can get Proxy Shopper status **unless** both individuals are Members of the same Household.
  
  > *Example:*
  >
  > Jerry and Willow are Members of the Ortega Household. Willow
  > owns a co-op membership with which she can shop at our store, and
  > Jerry does not own such a membership. However, Willow has designated
  > Jerry as a Proxy Shopper so he'll be able to shop on her behalf.
  >
  > Willow's mother Sabrina, however, is a member of the Sturm household
  > (not Ortega), so Sabrina should not be a proxy shopper for Willow,
  > even though Willow wants to send her mother to the co-op.
  
  In short, **we're looking for a way (possibly through an extension) to condition the Proxy Shopper relationship type upon membership in the same Household**.
  
  Worth noting that while belonging to the same Household should be required for setting a Proxy Shopper relationship, Household membership should not predict a Proxy Shopper relationship. In other words, no Household Member should become a Proxy Shopper unless someone sets that relationship via the admin interface.
  
  What's the best way to do this -- beyond just telling backend users that they shouldn't make anyone a Proxy Shopper unless that individual belongs to the same Household as the second individual?
  
  **Tags:** civimember, relationships, condition
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-10-16. Score: 3
  
  Another approach worth considering is the use of custom fields on the Relationship. You can add a Custom Field for Proxy Shopper, on to the Household Member relationship, and if Willow lets you know that Jerry is 'safe' to be a Proxy Shopper then you have that information without need for potential code and complexity
  
  > **Comments:**
  > **username_0**: Since we don't have household memberships (just individual memberships), the volunteer or staff who assigns proxy shopper to an individual would have to remember that proxy shoppers must belong to the same household as the individual member. And there's no way to guarantee every volunteer and staff will remember that, which would make the proxy shopper program prone to administrative errors. However, I'm not familiar with household memberships, and now that they've caught my attention, it seems I need to do a little research and learn more about them. Maybe we should convert our memberships.  
  > **username_1**: Sorry i think my answer should have said, add the field to the Household Relationship. will alter it  
  
  ---
  
  ### Answer by username_2 on 2017-10-18. Score: 3
  
  To handle this, you would have to write an extension. I would use `hook_civicrm_pre` on the Relationship entity (operation is "create", maybe "edit" too if households tend to shift?).
  
  Do two API calls to the Relationship API to get the Household(s) of both contacts. Compare to make sure at least one value is identical in both; if not, cancel the save.
  
  For a better UX, I'd call the same function from `hook_civicrm_validateForm`. The form validation can give a friendly message to the backend users - but the `pre` hook will ensure that you also can't create the relationship via the API or some other way.
  
  > **Comments:**
  > **username_0**: In the interest of finishing it this century, I'm not about to write the extension myself. To those of you who are competent in this area, what would you charge to write, test and deploy it?  
  > **username_2**: @username_0 Hit me up on Mattermost? Username is junglebird.  
  
  ---
  
  