Intweb

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

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

User Guide

New Member Sign-Up Process

• The link to submit an application is shown to anyone who is not any of the groups members, pending_applications, or pending_payments.
• Once someone submits an Application, that user is added to the pending_applications group 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 members group, and an e-mail is sent to Leadership and that member.

Developer Guide

Group Assignments

Group Name	Description
board	Board and Officers
wardens	Wardens
members	All active Members
laser	Will eventually be people certified on the laser
storage	Members who respond to storage requests
pending_applications	People with outstanding applications
pending_cancellations	Members who are late on payment
pending_expiry	Members who have confirmed cancellation and will be automatically removed when their Membership expires
late_payment_40	Groups for the three late payment reminders
late_payment_60
late_payment_80
pending_payments	People whose application has been accepted - they will me moved to members upon payment
needs_storage_renewal	Members who have been alerted as to their storage slot expiring

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.