Skip to content

Business rules for managing membership status and membership fee payment

Patrick Bolger edited this page Oct 30, 2017 · 24 revisions

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 == waiting_for_payment.
    2. When User pays membership fee:
      • application status is not automatically changed.
      • Admin can now move application to accepted status.
        • User is automatically (done by app, not Admin) set to Member status
      • Admin can also move other applications (from same User) from under_review directly to accepted 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

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.

Clone this wiki locally