Business rules for managing membership status and membership fee payment

Model design aspects

Production migration strategy

Basic process:

---

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 - one day Ex: If membership started on 1 February 2018, the last day is 31 January 2019

• Notes:

  • from Susanna in the Slack channel (5 Jan 2019):

    • Regarding renewals and uploading qualifying documents:
      • [As a member] ...If I do something in march I upload it in march. Then I'm fit to be renewed whenever ...[R]enewal will eventually be restricted so that you have to upload something to make the button visible. [But this feature] doesn't need to be approved until late 2021

  • from Patrick B in the Slack channel (6 Jan 2019):

    “The start date for the renewal term is day after the previous term expires” - this question implies that the previous term (or payment) has expired. In that case, the start date is the date of the next payment.

    If the previous payment has not expired, the start date for the next payment (if occurs before expiration) is the day after expiration of the previous (“current”, and still in effect) payment. we had decided that we won’t won’t penalize people for a later payment (remember the woman who paid 6 months after prior payment expired and only received another 6 months of membership - which started that whole conversation)

    If the rules change because of policy around reviewing re-qualification documents - well, that’s something we’ve never discussed and certainly is not applicable to how we operate today.

Scenario: Member pays renewal fee before the previous membership term expires:

Scenario: Member pays renewal fee on or after the previous membership term expires:

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)