|Project Owner: CTO and Intweb Development Team|
|Project Location: https://intweb.at.hive13.org|
|Where to contribute: https://github.com/Hive13/HiveWeb|
|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
- Buzzkill input and management
- Member Storage
- Access Log, displays, heatmap
- Certification Log - Access to Equipment control
New Member Sign-Up Process
- The link to submit an application is shown to anyone who is not any of the groups
- Once someone submits an Application, that user is added to the
pending_applicationsgroup and the alert e-mails are sent out.
- If the application is updated, another e-mail is sent out (this includes attaching photos, submitting applications, and so on)
- An application cannot be accepted unless a photo is attached to the new Member's profile and a signed application has been scanned in.
- Once acted upon, an e-mail is sent out to Leadership
- If accepted, the pending Member can access payment links.
- Once PayPal notifies us of the new Member's first payment, that Member is added to the
membersgroup, and an e-mail is sent to Leadership and that member.
||Board and Officers|
||All active Members|
||Will eventually be people certified on the laser|
||Members who respond to storage requests|
||People with outstanding applications|
||Members who are late on payment|
||Members who have confirmed cancellation and will be automatically removed when their Membership expires|
||Groups for the three late payment reminders|
||People whose application has been accepted - they will me moved to |
||Members who have been alerted as to their storage slot expiring|
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
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_modifyare completely ignored.
subscr_cancelis when the user deliberately cancels the subscription. This queues an action to send an "Are you sure?" e-mail to that member.
subscr_failedis 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_paymenttriggers 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.)
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.