From Hive13 Wiki
Revision as of 12:36, 23 June 2019 by Greg J Arnold (talk | contribs)
Jump to navigation Jump to search

Hive13 Project
Status: Active
Project Owner: Greg Arnold
Project Location:
Where to contribute:
Start Date: 2/24/2017

This is the central web interface for managing member information, group membership and badge access. Started in February 2017 to replace the old "door" system, it went into effect in April 2017.

Intweb Documentation to-do list

  • New Member Sign-Up process
  • Buzzkill input and management
  • Member Storage
  • Voting
  • Access Log, displays, heatmap
  • Certification Log - Access to Equipment control

Payment Handling

PayPal provides us with IPN messages when certain events occur. First step is to take in the message, store it as-is in the DB, and acknowledge to PayPal that we have received it in HiveWeb::Controller::PayPal.

We then handle a small subset of them in HiveWeb::Schema::Result::IPNMessage. First step is to match the e-mail address to a member. We first look try to find a match with a Member's e-mail address. If that does not work, we look at Members' PayPal e-mail addresses. If we find multiples here, we log the duplicate and don't guess. After finding which Member it belongs to, we update the IPN message's member_id field. Then, we process each message type:

  • subscr_signup and subscr_modify are completely ignored.
  • subscr_cancel is when the user deliberately cancels the subscription. This queues an action to send an "Are you sure?" e-mail to that member.
  • subscr_failed is when a payment has not gone through. This queues an action to send an e-mail to the Member. Apparently PayPal doesn't send any sort of alert in this case.
  • subscr_payment triggers the payment handling logic.

The payment logic simply creates another row in a new table to record actual payments. This is one of the few places data is de-normalized in the database. If, at this time, the member is in the pending_payments group, a welcome e-mail is queued, a Slack invite is sent, and the member is moved to the members group. (Any linked members have the same group membership changes as applied to the master by default.)

Background Tasks

Each background task is ran by cron and has its own script.

  • The queue runner watches the queue for e-mails to send.
  • The membership expirer looks at all members overdue, determines if it should queue a reminder or terminate access, and does so.
  • If anyone changes any PayPal e-mail field, a PayPal refresh is queued. The PayPal refresher then comes by, tries to associate any IPN message that's not attached to a member again, and processes it.
  • There is a process that runs and deletes any orphaned uploaded images.
  • There is a process that queues e-mails when a member needs to renew a storage slot.