Author Topic: Strict membership typing? (Read 2168 times)

criticny · November 04, 2007, 09:46:48 pm

I have a civicontribute page associated with a HOUSEHOLD membership type. Yet, an INDIVIDUAL contact appears to be able to obtain this HOUSEHOLD membership.

This seems like bad behavior to me.

Shouldn't CiviCRM enforce the membership type? Perhaps allow the individual contact to select a household (of which they're a member) for membership, rather than granting household membership to an individual?

Am I missing something?

criticny · November 05, 2007, 12:43:23 am

People are reading this but not responding. Let me clarify and amend it:

Clearly memberships are passed through a household to its individual members, but if membership in an organization (say) is a HOUSEHOLD membership shouldn't it ONLY be allowed through that (or another) HOUSEHOLD? and not independent of any household whatsoever? Indeed, even be revoked (or whathaveyou) upon leaving the household through which membership was initially acquired???

Anyone?

lcdweb · November 05, 2007, 08:05:19 am

I agree with your observation and assessment. Membership types are not limited to a specific contact type, though I think it would be very useful for them to be. I have a similar situation where I have 4 membership types that organization-based and 1 that is individual based. I know they are defined as such, but there's no control in CiviMember that allows me to "lock" the definition, to avoid having an individual become a member of an organization type, or vice versa.

Sorry, no fix. Maybe it can be added to the wishlist for future releases.
-Brian

Donald Lobo · November 05, 2007, 09:19:23 am

yes, we do not limit contact creation to a specific type based on the relationship restriction. It could be considered a missing feature.

You could either submit a fix for this / hire a developer to do the needful and/or add it to the civimember phase 2 requirements wiki page (http://wiki.civicrm.org/confluence/display/CRM/CiviMember+-+Phase+2+Specifications). I suspect we'll be upgrading civimember in a 2.x release

lobo

chrism · December 02, 2007, 02:32:44 am

Here is a related thread from the developer mailing list a while back:

-----------------------------------------------------
On 6/21/07, Christopher Mott wrote:

This is more architecture question than developer, but I thought I'd
solicit feedback before posting this as an issue:

Memberships that have a relationship type defined, where the
relationship type specifies a specific type of contact (i.e. not an -
any - type), can be granted to any type contact regardless of whether
they fit can fit the relationship.

e.g.
- 'Member of household' relationship links Households to Individuals.
- A 'Family' membership type is defined with relationship type 'Member
of household'
- If a household is given a Family membership then the household and any
individuals in the household get the membership status.
- *but* an Organization can also be given the Family membership,
although it can never have any household members.

There would be a design case to be made for enforcing consistency with
relationships, but maybe keeping the memberships flexible has advantages
too?

Chris

-----------------------------------------------------
On 22-Jun-07, at 10:42 AM, Dave Greenberg wrote:

Chris -
Our idea in implementing the Relationship Type property for Membership
Types was to "allow" those memberships to be extended to the related
contacts. We weren't thinking that all members of that type needed to
take advantage of / be eligible for that option. Hence the
flexibility.

If we get feedback over time that this is problematic - and limiting
"eligibility" would be useful across the board - then we'd be happy
to revisit.

...dave

lcdweb · December 03, 2007, 06:04:41 am

I added a description of the issue to the Wiki page Lobo referenced. Others may want to take a look and edit.

In my view, this is not a huge issue, as it currently only affects backend users. It's a situation that "could" be overcome through policy and procedures. The problem is that the absence of a strict rule in the tool's functionality leaves the door open for staff/admin users to misapply a membership to the wrong contact type.

We had the potential for this problem with one of the organizations I work with. 5 of 6 membership categories are organization-specific. The 6th is individual-specific. I had to take care to train staff and make sure they understood how to handle this. Of course they understood how the organization's membership categories were structured -- the problem is that although membership is organization based, there's usually one person who is the primary contact for the organization, and it's tempting to look up the person, not the organization, and apply the membership to them.

Where this issue may become more important is with some previous discussion regarding how to expose organization contact information and memberships to the front end, and how to define organization administrative access to certain individuals. At that point, it may become more important to restrict membership types. This can be done manually since profile/contribution pages for membership allow you to define which membership categories are exposed. But it would be useful to create these rules at some point.

Anyway, I'm rambling.

CiviCRM Community Forums (archive)

News:

Author Topic: Strict membership typing? (Read 2168 times)

criticny

Strict membership typing?

criticny

Re: Strict membership typing?

lcdweb

Re: Strict membership typing?

Donald Lobo

Re: Strict membership typing?

chrism

Re: Strict membership typing?

lcdweb

Re: Strict membership typing?