2

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?

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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?
    – Prónay
    Commented Oct 20, 2017 at 0:24
  • @Prónay Hit me up on Mattermost? Username is junglebird.
    – Jon G - Megaphone Tech
    Commented Oct 20, 2017 at 17:06
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

Improve this answer
2
  • 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.
    – Prónay
    Commented Oct 20, 2017 at 0:22
  • Sorry i think my answer should have said, add the field to the Household Relationship. will alter it
    – petednz - fuzion ♦
    Commented Oct 20, 2017 at 0:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.