Club Subscription Groups

[julianweng]

The subscription feature currently has limited utility for clubs. Essentially, it is a button that students press either on the search page or the club's individual page, after which their email is incremented onto a list that clubs can view at some point in time. However, there is no source attribution (both in terms of how the student found the club and if the student subscribed as a part of an active "application cycle") or ability to collect additional information about the student (e.g. if the student is interested in gbm, or a certain committee, or to learn more about a specific part of the club). These factors make on-platform subscriptions not very useful for club leaders, especially since most clubs have to maintain separate mailing lists to actually send the emails anyways. While this solution seems to be adequate for clubs, it's suboptimal for the platform because subscriptions having utility and being used would enable many features that help students. For instance, students already receive email notifications for upcoming application deadlines for clubs subscribed to. Another feature currently being worked on is a full dashboard that allows users to write and track ongoing applications, which will default to filter by clubs subscribed to.

Concretely, this will take the form of a SubscriptionGroup model. The user-facing name (and maybe the name in code) will likely be different, maybe something like "Subscription Form" that more concretely communicates the utility. Subscription objects will hold an optional reference to a SubscriptionGroup (e.g. belong to at most one). The SubscriptionGroup will take a similar shape as an Application object, to the point that we should consider making a base model that both of these can extend: both are basically ordered groups of ApplicationQuestions that users must answer. The main difference is that once a user submits an application and the club leader gives an approve decision, a membership relation is created, while once a user submits a subscription form, the user is automatically subscribed to the club instead.

Features:

• Aforementioned functionality
• Ability to set a SubscriptionGroup as a club default: if one is set, hitting the subscription button on the frontend would redirect to the form instead of instantly subscribing
• Magic link that redirects to the form, or subscribes automatically (if user is signed in) if the form has no additional questions beyond autocollected info such as class year, name, and email. Clubs should also be able to generate qr codes for these links on our platform
• Export emails in all common compatible formats for listserv-like platforms
• Deleting a SubscriptionGroup should be visual only (e.g. an archived field on the model) if it has associated subscriptions

TBD:

• Frontend details / design. Should be deliberated, as the current application management code spans multiple tabs and should be rethought in its own right. This features should have less surface area and can probably have a more intuitive ui given its smaller scope.
• Clubs could potentially use these groups as mailing lists. Would have to discuss if within scope and if we have SES budget.
• Mailchimp apparently supports programmatic access to clubs' mailing lists via OAuth, so this could be another option to sync between subscription groups and mailing lists as well