Profile forms -- membership

[lcdweb]

When creating a profile set with the membership type, should you be able to access all the membership-related fields? Currently only custom fields associated to memberships are available.

[Dave Greenberg]

Prior to "Batch Update via Profile" being available for Memberships - it didn't make sense to allow Membership fields (other than Source and "custom fields") to be included in a Profile. All the other fields are controlled programmatically in the context of online membership signups (which is the only place you could use a profile w/ membership fields).

Given that we now have "batch update ... " - it probably makes sense to expose the remaining membership fields (as we do for Participant and Contribution). However - there may be unexpected consequences of changing some of these. AND I'm still not sure there are any valid use cases for exposing them in a profile WITHIN an online contribution / membership signup page.

What are you specifically hoping to do w/ membership fields in a profile?

[lcdweb]

You're probably right that as it stands, there's little use for profiles with membership fields. But I could see some useful functions down the road:

1) Batch updates (as you've mentioned)
2) Search profile (custom listing for search results)

-Brian

[petednz]

An organisation using civiCRM decides to modify its membership structure eg introducing a Youth Category and wants to use Batch Update profile to change the membership of those contacts under 18?

[Dave Greenberg]

Allowing Batch Update of core membership fields like Membership Type, End Date, Status.... has processing implications which we're not inclined to deal with until or unless a real need is demonstrated. EXAMPLE: If you change the membership type, and the new type has a different duration - should you also adjust all the end dates, or leave them as is, or ask the user what they want to do?

[lcdweb]

I concede the point.

However, it would be great to have the ability to create memberships for multiple records, similar to how you can do a search and then register multiple contacts for an event.

I thought there was previous discussion about this, but I can't seem to find an issue in Jira for it.

[Dave Greenberg]

Brian - Batch create for memberships is on the 2.2 roadmap. We will be trimming that list down a bit but I think we'll get that one in.

[lcdweb]

That's great. Probably not a super-high priority item, but I've definitely run into several situations where it would be useful to handle batch memberships.

Back to the original topic re: membership fields in a profile --

I just ran into a situation today where that capability would be useful. I'm creating some frontend pages using profile searches. Specifically, a profile page that allows users to search the list of current members. No problem attaching the profile to a smart group so that I'm only looking at current members -- however, there's no way for me to include the membership type in the search results, or even add the membership type as a search field.

In this case, the org has 3 main membership types, and they represent very different types of members. So it would be useful to be able to query based on the type, or at least display the membership type in the results. I could create three separate profile forms, one for each type, but that's not very efficient.

[Dave Greenberg]

We actually don't expose ANY component record fields to Profile-driven search (e.g. contribution, participant, membership) - so this is a much larger nut to crack. I think writing a custom search is the way to solve this one for the time being.