This specification is currently an incomplete draft. Section headings similar to those in the CiviContribute Specification spec have been roughed in. A data - centred view is mapped out starting at #Membership.
CiviMember Phase 1 will support the following functionality:
The following features are being considered for subsequent phases (and are NOT part of phase 1):
Similar to CiviDonate menu CiviContribute Specification#Menu / User Interface Elements but for Membership information
Represents a specific instance of an online membership form.
Here are some ideas for a CiviCRM membership model. Comments welcome.
Identifies an Organization as one for which memberships are tracked.
MembershipOrganizationID: Unique primary key for this MembershipOrganization
contact_id: FK to Organization (see CiviCRM Data Object Model)
NB: A publication can be entered in an organizational record in order to handle publication subscriptions as memberships.
Membership is a Relationship_type Data Model with the following characteristics:
description: 'Membership relationship'
It extends the Relationship entity (see Data Model. The contact_a field is the Member, and contact_b is the MembershipOrganization.
FirstMembership: date (year contact joined)
is_suspended: boolean: membership privileges suspended due to overdue payments (should be a calculated value available through API but not stored in table)
MembershipPaymentStatus: value from MembershipPaymentStatus table (see below) (should be a calculated value available through API but not stored in table)
There needs to be a way of geolocating a member to various levels of regions/jurisidictions. I suggest building separate 'groups' for this, and having a hook interface that would accept geolocating information such as an address or lat/long and return a particular value for each such geographic level (eg riding/constituency ID). We currently track FederalRiding, ProvincialRiding, and MunicipalWard. Others such as PublicSchoolWard might be useful. We don't currently have map layers or postal code lookups for all lower level jurisdictions. Associated with each level would be a table providing names of region/jurisidiction/riding/constituency for a given ID. Given the need to redistrict, it would useful for there to be a date associated with each level, so users could specify either old or new boundaries in the leadup to an election under new boundaries. Manual override of the actual geolocation is necessary to accomodate people who wish to keep their membership in ridings other than where they live.
While we do not yet have map layers for this, we do track FederalPoll, ProvincialPoll and MunipalPoll using information from voters lists.
Associated with each regional group would be some entries in an Access Control List (ACL). In particular, for us, we would want Membership Secretaries for each federal riding and provincial riding to be able to view information, enter offline membership payments for people in their riding, and run reports detailed below. Note that membership in the federal party is the same as membership in the provincial party for our purposes. Perhaps other organizations would like the ability to track membership separately for different jurisdictional levels in the same database.
Separate ACL entries would allow central provincial and federal administrators to change data in any riding.
Individuals should be able to view their own membership status. People should have the option of exposing their membership to either other members or the general public for the purposes of grassroots up organizing through events, etc. I'm not sure how fine-grained this should be: perhaps separate permissions for anonymous site email, email, IM, postal address, phone, cell, etc., with an option of setting all at once for convenience. Administrators should have option of setting the default for these permissions.
Entries (configurable by admin)
Initializing: first payment has not cleared bank
New: first year of membership
Renewed: membership has been paid for current year
Grace: membership has not been paid for current year but membership privileges still extended
Unrenewed: membership has not been paid for current year and grace period if any is over
Lapsed: membership has not been paid for current or previous year
Inactive: membership has not been for current or two previous years
Entries (configurable by admin)
Calculated value of Current status is set through admin interface. Default values for current:
Sample entries (configurable by admin)
Student / Not gainfully employed $5
Lifetime $0 - never expires
Membership: FK to Membership
Payment: FK to Contribution (http://objectledge.org/confluence/display/CRM/CiviDonate+Specification#CiviDonateSpecification-Contribution)
Set values for days through the admin interface; maybe allow creation of more categories of late payments
PaidInFull - fully paid up
PaymentUpToDate - recurrent payments up to date but full amount not yet received
PaymentLate- recurrent payments are 0 - 60 days overdue
PaymentOverdue - recurrent payments are > 60 days overdue
A member's PaymentStatus is determined by checking whether there are unpaid pledges associated with membership. These pledges need to be created when setting up memberships for pre-authorized credit card payments, pre-authorized chequing account payments, and for post-dated cheques.
Need hook(s) to do things like the following:
Family membership records must be linked to head of household record, who must have a non-Family membership type
Status of family memberships is the same as that of the head of household record
Status of lifetime members is always Renewed
Benefactors and Patrons are automatically renewed once.
In an admin interface, it would be useful to be able to set the following:
Membership Year Type: enum: rolling (default - means at date of payment), fixed
Fixed Membership Year Start: date (default January 1)
Fixed Membership Payments after this date cover following calendar year as well (default to December 31, ie no extra coverage; my organization uses October 31)
Grace period: Unrenewed membership privileges extend for this length of time, renewals in this period include grace period when calculating membership expiration date (integer: months: default 0)
It is necessary to support membership payment dates different than entry dates for payments (already in donation payment spec).
Currently a batch job is run to update membership status once all year end data has been entered and validated through returns of bank deposit data. There is a need to support year end processing where not all transactions can be entered before the end of the year. Through this period it is necessary to be able to produce reports based on a report date of either the old year (eg December 31) or the new year (eg January 10), with membership status appearing correctly. I imagine this could be implemented by having the report do some special calculations for membership status using report date, current date, and an indicator about whether year end processing was completed.
Detail Reports options:
Sort orders (sample):
last name, first name, middle name
street name, street type, street direction, street number, street number suffix, apartment number
allow odd and even number street numbers to be sorted separately for reports
group by household or not
Potential sort orders:
Membership totals and percentage by month by MembershipType
Membership totals and percentage by month by MembershipType compared to previous and second previous years
Option to include payment type (perhaps other things too) in previous reports.
Integration with email and mail and phone campaign reporting to determine success ratios for membership signups and renewals, and tracking of this into future years (eg we're having trouble renewing the tsunami inspired members, but not with all our other members).
Changes to membership information and payment information need to be tracked including the users who made them and the date.