E-mail
This page is for the purpose of defining spec for improvements to CiviMember in future releases.
Multiple membership signup
Currently Civi only allows the selection of one membership type from the available list in membership signup/renewal pages. This should be expanded to allow the option of allowing multiple membership signup.
- All configuration occurs in the contribution page membership settings
- Users can create multiple membership "blocks," within which are selected membership types
- Option to make a block required
- Within a block, option to present the membership types as radio buttons (select one) or checkboxes (select multiple)
- Option to allow user to change their membership type (or for retaining existing) on renewal
- When contribution record is created it becomes associated (linked) to each membership type it purchased
- But for the purpose of reporting, we need to distinguish the portion of the total contribution that applied to each membership. May need to store the partial amount in the membership table?
- State membership ($50) + Region 1 ($25) + Region 5 ($35) = $110
- Contribution record = $110 with links to all three memberships
- Membership record indicates type-specific amount
- Reports reflect type-specific amount (i.e. display total received for Region 1 memberships)
- Create similar backend tools for processing multiple memberships within a single step
- When creating a membership record, change type field to multi-select
- would need to handle the org/type dependency differently, as someone could conceivably purchase memberships with different orgs at once
- since most orgs generally do not have excessively long lists of membership options, could we change that to a single multi-select field with the org name and membership type concatenated? i.e. XYZ Association » Type 1
- As with frontend forms, a single contrib record should exist with links to the types, and the specific amount broken out to each type.
- in the backend signup there's potential that the total calculated amount doesn't match the total amount received. if so, we need some way to allow the user to resolve the differences. perhaps a grid popup listing each type, amount associated, and amount allocated from the total received?
Alternate Period Calculation Method
Currently, if a user switches from one membership type to another, a new record is created with newly calculated start/end dates. However some orgs may want such transfer to be treated with some continuity rather than as completely distinct records. This may be because the organization is upselling from one type to another (e.g. move from a family membership to a supporter membership at a higher rate), or the membership types are structured around alternate payment terms (e.g. 6 mo. vs. 12 mo. memberships), or because the movement between types is a reflection of some other status (e.g. a professional society with non-credentialed and credentialed membership types). In each case, the organization wants to see the membership history, so a new membership record should be created, but does not want to penalize the member for the shift by re-setting the membership start/end dates.
For example (rolling membership structure):
- John Doe purchase 6 mo. membership to "try" the association
- After 4 mo. he decides he loves the org and wants to commit to a full year membership
- Currently if he renews his membership with a new type, the start date will be set for the day of his "renewal" -- which is actually not handled as a renewal at all, but rather a new membership
- Consequently, there are 2 months in which his new 12 mo. and existing 6 mo. memberships overlap and are "lost"
- Alternate calculation would measure his new 12 mo. membership from the end of his 6 mo. membership, so it becomes an extension
Issues/questions:
- What do we do with the previous membership record? Is it flagged as canceled? Expired? Presumably if the "remaining time" is being transferred to the new membership type, we don't want the previous type to remain active. It needs to be closed down in some way.
- Do we attempt to do a more complex pro-rated calculation (or provide as an option) -- for example, if the movement from one type to another has associated member benefits attached, the org may not want a simple date-based extension of the membership period, but rather a prorated extension. So if my existing membership is $120/yr, and I'm 6 mos into it, and the new membership type is $240/yr, at the point of transfer my new membership is extended by 3 mos -- not 6 mos -- because the $60 "balance" on my current only accounts for 3 mos in the new type.
- this would be interesting to flesh out, but I wouldn't want to see it delay development as it's likely a less-common use case
Other items:
- This would piggy-back well with the above multi-membership spec, as the contrib page setup could allow the calculation method option on a block-basis. A single form could have blocks using one calc method, and other blocks using the standard calc.
