Business rules for managing membership status and membership fee payment

Model design aspects

Production migration strategy

Scenario: User becomes Member (first time or after losing membership)

• Background
  1. User has submitted one (or more) membership applications.
• Business Rules
  1. User can pay membership fee only if an application status == accepted.
  2. When User pays membership fee:
     • User is automatically (done by app, not Admin) set to Member status
  3. Expiration date for new membership (set automatically):
     • Until the end of 2017:
       • expire_date = end of 2018
     • Starting on January 1, 2018:
       • expire_date = current_date + one year - 1 day

Scenario: Member renews membership

• Background
  1. Current membership is nearing end of expire_date
• Business Rules
  1. Member can renew membership at any time (by clicking appropriate button)
  2. Membership status is shown to Member with different styling, based upon time remaining to expire_date (for example: green by default, yellow is within one month, red if current_date is on or after expire_date)
  3. If membership expires, Member status is not automatically set to non-member status
  4. Expiration date for renewed membership (set automatically upon renewal):
     • Until the end of 2017:
       • expire_date = end of 2018
     • Starting on January 1, 2018:
       • new expire_date = old expire_date + one year

Scenario: Admin manages membership status

• Business Rules:
  1. Admin can change these Member attributes at any time:
     • expire_date
     • member status

  This allows the admin much flexibility, such as:

  1. Allow a member whose expire_date has passed some additional time to pay membership fee
  2. In the above scenario, if the member is one month late in renewing membership, the new membership period is back-dated to begin one month in the past, and thus has only 11 months remaining. If the admin wanted, they could override this and set the expire_date to be a year after the date of renewal.
  3. Mark as member, and (Re)set expire_date, for a member who chooses to pay offline

Model design aspects

Added model Payment

This represent a user payment for either a membership_fee or a branding_fee. This belongs_to a user (who paid the fee, and, optionally, a company (for which a branding_fee was paid).

Payment status will follow the associated HIPS order status, with status generally progressing from created > pending > paid.

A payment also has attributes start_date and expire_date, which delimit the duration of the membership (or branding) period for the payment.

Payment history will be maintained (that is, records are added, not overwritten).

Extended User model

Added association has_many :payments.

Production migration strategy

In the migration file that adds start_date and expire_date to the payments table, all current members will have a Payment instance added to the DB, with start_date == Jan 1, 2017, and expire_date == Dec 31, 2017. This reflects how SHF has been tracking memberships as concurrent with the calendar year.

So, the migration process in production consists of:

1. Run the DB migrations. All current members have a current, non-expired membership.

2. For new members (who joined on or after October 1, 2017), the SHF admin can reset the payment expire_date to Dec 31, 2018. (this can be done from the user show view when logged in as admin)