Difference between revisions of "Intweb"
(To Do) (Tag: Visual edit) |
|||
| Line 14: | Line 14: | ||
* New Member Sign-Up process | * New Member Sign-Up process | ||
| − | |||
* Buzzkill input and management | * Buzzkill input and management | ||
* Member Storage | * Member Storage | ||
| Line 20: | Line 19: | ||
* Access Log, displays, heatmap | * Access Log, displays, heatmap | ||
* Certification Log - Access to Equipment control | * 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 <code>HiveWeb::Controller::PayPal</code>. | ||
| + | |||
| + | We then handle a small subset of them in <code>HiveWeb::Schema::Result::IPNMessage</code>. 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 <code>member_id</code> field. Then, we process each message type: | ||
| + | * <code>subscr_signup</code> and <code>subscr_modify</code> are completely ignored. | ||
| + | * <code>subscr_cancel</code> is when the user deliberately cancels the subscription. This queues an action to send an "Are you sure?" e-mail to that member. | ||
| + | * <code>subscr_failed</code> 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. | ||
| + | * <code>subscr_payment</code> 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 <code>pending_payments</code> group, a welcome e-mail is queued, a Slack invite is sent, and the member is moved to the <code>members</code> 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. | ||
Revision as of 12:36, 23 June 2019
| Hive13 Project |
|---|
| Intweb |
|
| Status: Active |
| Project Owner: Greg Arnold |
| 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
- 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_signupandsubscr_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.)
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.
