Closed QuincyLarson closed 2 years ago
Also, I noticed after the fact that this comment may have been better on #274. However, since the RSVP, subscribe / unsubscribe, and email notices are all intertwined I'm not sure it matters much as long as it doesn't confuse this API issue.
@allella A label is definitely the surest bet. If, and it sounds like, we will use the Subscribe component in a form alongside other elements to complete an event
sign-up, (if MVP won't have a User Account Settings page) we should treat the Subscribe switch as a checkbox using checkbox role instead. It'll get sent at form submission with the other fields.
I think "Active" color as Subscribe/unchecked status and grey/disabled for Unsubscribe/checked status would do.
Let me know if I covered this logic flow correctly:
1. User is automatically subscribed to chapter notifications on joining (assuming user email address a required field)
2. User subscription at event RSVP level:
3. User subscription at chapter level through event specific email:
(?) something to evaluate/discuss, perhaps after MVP ships
As for the user + chapter subscription relationship, autogenerate unique event keys based on userID + chapterID + eventID in new Subscription table?
Thanks, replaying the logic highlighted some potential areas of confusion with only having subscriptions toggle on / off via rsvp
or unsubscribe link.
This user story suggested getting upcoming event notifications AFTER you've attended, but with Meetup.com I believe it's possible to subscribe and get notices without ever having attended. That's a reasonable expectation too, though not explicitly an MVP story.
I guess we could also have a button on a chapter
landing page to subscribe to all chapter
email notifications whether they be reminders of upcoming events or general chapter
notifications sent by an organizer
(not an MVP that I've seen).
The question now is if subscribing and unsubscribe is connected to an rsvp
(#108 & #276). Or, are subscriptions intended for upcoming events and more general announcements?
I could see a use case for both and we already have an MVP story for both cases. If we do both then I suspect we'd need to add an rsvp.subscribed
to the schema to allow for subscribing or unsubscribing from a specific event's notifications vs non-event notifications.
To summarize, would the following be a reasonable MVP flow?
Applicable to #107 & #275 & #274
user_chapters.subscribed
would be added to the schema as a boolean to be toggled on or off by an authenticated user
via the chapter
landing page, like a "Follow / Unfollow" UI button or toggle. This would turn on notifications which are not related to a rsvp
.
Such email notifications would have a URL to allow the user
to "Unfollow {chapters.name} Notifications".
If we needed to trim the scope, then these emails could simply have a link going directly to the chapter
landing page where the Follow / Unfollow button would need to be toggled. The downside here is the user
would need to be logged in to stop receiving these notices.
Applicable to #108 & #276
rsvp.subscribed
would be added to the schema as a boolean and this field would be for notifications which are directly related to a specific rsvp
.
The user
would be able to click a "Stop Receiving Notifications for {events.name}" unsubscribe link. If we narrowed the scope here as well, then the email could direct the user to the event
landing page. Again, this more simple approach would have the downside of requiring a user
to be logged in and then toggle a button on the event
landing page to disable.
@allella @ceciliaconsta3 I have been reading your comments in both this issue and #274 and already got some questions! But I will start off with one or two...
Not sure if the user
will have a general account setting page or not, but for assumption's sake, let's say there is. There could be a page for managing subscriptions (via both notifications or emails) and for auser
to find this page in one of these two ways, which is either:
user
goes to the chapter
page that they are part of and click on the subscription setting buttonuser
goes to their general account setting page which has tabs of different types of settings and the subscription tab could be one of them.So, once the user
starts receiving emails (after going to the event) and they want to unsubscribe, they can click on the 'unsubscribe' link, which takes them to the managing subscription page.
I hope my point is relevant to this issue. If so, what is your thought on this?
@madaleneaza-design I think we've been operating on the assumption that a profile / subscription page is not a MVP feature. It's definitely a reasonable expectation to add one to the Roadmap.
So far there's been no explicit MVP user story for a profile page to do anything since authentication will be using Google. Therefore, we don't have an immediate need for users to manage their email, password, profile picture, and such.
Would you agree we can start by allowing subscribing or unsubscribing to an event or a chapter using the MVP interfaces we know are already required?
If we didn't have a profile / manage your subscriptions page, for MVP, then we can still allow users to subscribe and unsubscribe using links or UI elements on these MVP interfaces.
@ceciliaconsta3 posted suggestions on checkbox vs switch vs buttons for the UI on #274
@allella Yeah I can agree and I cannot see why not (to allow subscribing and unsubscribing using the known MVP features), as long in terms of user experience, the links/ UI elements are easier to navigate and use in the layout (which I am sure it will be).
I will hop onto #274 to post my response :)
For the more technical side of the mail sending, we had a good conversation in today's meeting on using nodemailer and SMTP with free / cheap tiers of 3rd party transactional mailing services.
@davidals brought up that we'd want a scheduled trigger to check for and send email notifications for event rsvps and other such "X days before" notifications. That's being discussed on #359.
I referred the earlier suggested schema changes to allow for unsubscribing from a specific rsvps' notifications and a specific chapter's notifications.
However, upon reviewing the talk about "Following" or "Unfollowing" a Chapter or RSVPs I found that "Following" an event may not make sense. So, here's a refined view of toggling email notifications on or off.
Toggling rsvp.subscribed
rsvp.interested
on or off
rsvp.subscribed
rsvp.interested
to TRUE or FALSE based on the form's input.rsvp.subscribed
rsvp.interested
to TRUE or FALSE. This is not the same as cancelling an RSVP.rsvp.subscribed
rsvp.interested
to FALSEToggling _user_chapters.subscribed
user_chapters.interested
_ on or off
user_chapters.subscribed
user_chapters.interested
_ is TRUEuser_chapters.subscribed
user_chapters.interested
_ to FALSEI think it's also valuable to have an account setting for that.
Something like notifications_allowed
that would override all of the subscribed
when set (And default subsequent RSVPs to false),
and when a user intentionally chooses to subscribe it would toggle the account level back to on.
@ceciliaconsta3 @madaleneaza-design @davidals @Zeko369
One other consideration is the following:
Canceling a RSVP vs Unfollowing a RSVP Toggling off the "Follow this Event" switch on an event page, for users with an existing rsvp, would not necessarily mean cancelling the RSVP.
It's likely an organizer wants to see who cancelled their RSVP, which means we'd need an rsvp.canceled
field in the schema to store that value instead of deleting records in the rsvp table. We likely only want a basic cancellation feature for MVP.
The event page would then have a "Cancel my RSVP" (button) to go along with the previously mentioned "Follow this Event" switch. It seems like a fair assumption that cancelling an rsvp would immediately sets the rsvp.canceled
to TRUE and rsvp.subscribed
rsvp.interested
to FALSE.
I was wondering if we should allow someone to follow an event without being subscribed to it, but I feel that could lead to confusion if someone clicks to follow an event and assumes that means they are RSVP'ed. That could be a real problem if people show up to an event and don't have a valid rsvp. So, it's probably best we don't show a "Follow this Event" UI switch unless the user has an active (rsvp.canceled
= FALSE) rsvp record.
Thoughts?
I think this is where language get's handy.
Instead of "follow" call it "Interested", and the toggle should say something like "Notify me of updates to this event"
Agree on canceling RSVP makes you stop receiving notifications.
If you think about Facebook Events, there are 3 options "Not going, Interested, Going". We could use a similar approach (and maybe even wording) since people should be familiar with the concept.
Sounds good.
So the "RSVP" buttons could be "Going" and "Not Going", depending on if the user already has an rsvp.
Then, an "Interested" UI slider to toggle on/off interest regardless of the rsvp status.
Here's the PR adding those fields: https://github.com/freeCodeCamp/chapter/pull/374
https://github.com/freeCodeCamp/chapter/pull/640 gives us something to work with, but it's far from a complete solution.
So the "RSVP" buttons could be "Going" and "Not Going", depending on if the user already has an rsvp. Then, an "Interested" UI slider to toggle on/off interest regardless of the rsvp status.
@allella @ojeytonwilliams Could you please let me know what work is remaining in this issue apart from the above UI changes?
@Ravichandra-C
When a new event is created by an organizer for a specific chapter, we will want to query the _user_chapterroles table_ where _user_chapter_roles.chapter_id = events.id (this will be the event id of the newly created event) AND _user_chapterroles.interested = true.
There's a basic example of the email to send to notify users about new events. We'd want to merge in values from the event and chapter tables, as indicated by the { } placeholders in the example in that link.
We have a separate issue to handle the unsubscribe links in the email footer. That issue may require more conversation and it could be somewhat complicated if we are trying to allow opt-out without being logged in. So, for now, we can keep a placeholder where the unsubscribe links will go.
Does that help?
@allella Thanks a lot for your help. I've a few questions on your comment.
When a new event is created by an organizer for a specific chapter, we will want to query the user_chapterroles table where >_user_chapter_roles.chapter_id = events.id (this will be the event id of the newly created event) AND >user_chapter_roles.interested >= true.
Currently we have the below functionality.
When a new event is created by organizer in a specific chapter, We query user_chapter_roles table where user_chapter_roles.chapter_id=chapter.id( id of the chapter in which the event is created ) and user_chapter_roles.interested = true and send an email with below text.
_user_chapter_roles.chapter_id = events.id
Shouldn't this be assigned with chapter.id instead of event.id?
There's a basic example of the email to send to notify users about new events. We'd want to merge in values from the event >and chapter tables, as indicated by the { } placeholders in the example in that link.
the basic example hyperlink is liked to schema spy. Could you please provide the text that should be used in the email ?
PFB the template of the email that we are currently Sending when a new event is created(Code is already in the repo).
const subject = `Invitation to ${event.name}.`;
const body =
`When: ${event.start_at} to ${event.ends_at}<br>` +
(event.venue ? `Where: ${event.venue?.name}<br>` : '') +
`Event Details: <a href="${eventURL}">${eventURL}</a><br>
<br>
- Cancel your RSVP: <a href="${eventURL}">${eventURL}</a><br>
- More about ${event.chapter.name} or to unfollow this chapter: <a href="${chapterURL}">${chapterURL}</a><br>
<br>
----------------------------<br>
You received this email because you follow this chapter.<br>
<br>
See the options above to change your notifications.`;
for now, we can keep a placeholder where the unsubscribe links will go.
Sure, I'll add the place holder for unsubscribe link.
@allella @Ravichandra-C I think this is largely done - we are automatically sending the notification emails already. If someone has _user_chapterroles.interested they will be emailed whenever a new event is created on that chapter. However we still need to
We should only set interested to be true if the user doesn't yet have a _user_chapterrole for that chapter.
I think that's all we need for now.
@ojeytonwilliams ,In addition to the above changes ,Should I also include these UI changes as part of this issue or will they be worked on as separate issue?
So the "RSVP" buttons could be "Going" and "Not Going", depending on if the user already has an rsvp. Then, an "Interested" UI slider to toggle on/off interest regardless of the rsvp status.
@Ravichandra-C I'll handle that in a separate PR :)
@Ravichandra-C I probably had an error above in the logic. I trust you understand what needs to be done on the technical side, so we should be good to proceed with what you have.
Thanks
@allella @ojeytonwilliams Thank you for explaining. I understood what needs to be done. I'll be working on it.
@ojeytonwilliams , For setting the user_chapter_role.interested=true when an user rsvp to an event, I'm creating a new mutation with name SetUserInterestForChapter which takes the event_id as the parameter. Could you please let me know if we already have this mutation? I searched in the repo and also the generated/graphql.tsx but I did not find it, I just wanted to make sure that I'm not adding duplicate code.
It makes sense that most users will be happy to get notified of future events for a chapter, but what if a user had previously toggled _user_chapterrole.interested=false?
It sounds like this user story would set _user_chapterrole.interested=true without asking, but a user may not want to get future notifications.
Would we want to show a toggle field on the RSVP form, set that toggle's default value to match the user's current value for _user_chapterrole.interested, but still allow them to toggle / change it when they RSVP?
There are events in my town that I might only attend once a year, or for a special occasion, but that doesn't mean I necessarily want to be forced to receive future notifications.
Thoughts?
@allella , This mutation will check if user already has a preference set in the database, if it is already set, then we are not doing anything.If it is not set then we are by default setting the user_chapter_role.interested = true. So if a user has already set his preference to false then, as we are not updating it, he will not get any future notifications.
It sounds like this user story would set user_chapter_role.interested=true without asking, but a user may not want to get future notifications.
We definitely don't want to do that and Ravi's proposed logic should work as intended.
Would we want to show a toggle field on the RSVP form, set that toggle's default value to match the user's current value for user_chapter_role.interested, but still allow them to toggle / change it when they RSVP?
Seems reasonable, yeah. We could have it default to true when _user_chapterrole.interested is not set and just mirror their settings once interested has a value.
I'm creating a new mutation with name SetUserInterestForChapter which takes the event_id as the parameter. Could you please let me know if we already have this mutation?
We don't have any mutations that change _user_chapterrole.interested, so please go ahead.
I searched in the repo and also the generated/graphql.tsx but I did not find it, I just wanted to make sure that I'm not adding duplicate code.
Cool. Just to aid any future searches: all mutations must be defined in either a queries.ts
or a mutations.ts
file (ideally the latter!), so if they're not in a file with those names they effectively don't exist.
Below are preliminary suggestions and questions regarding this #107 and #274.
The direction set forth here will also inform the text and email "mail merge" templates needed for #275 and #276.
Assumptions / Suggestions
instance
mailer configuration.instance
of the Chapter application will usually have multiplechapters
in theorganization
. The terminology on the README further explains the distinction between the Chapter application / brand name and achapter
entity in the database. So, when I say that someone 'Unsubscribes" from achapter
it doesn't necessarily mean they are turning off all notifications for a entire Chapter applicationinstance
.user
+chapter
. For example, if auser
moves to a new city they may wish to stop notices from their former city'schapter
, but still receive notifications for their new city'schapter
.user_chapters.subscribed
boolean field to the database schema to store a subscription preference for eachuser
+chapter
row. This field will be added in a new PR, or even as part of #253.instances
could easily exceed the free-tier sending limits of 3rd party transactional mailer #146 services, thus needing a paid account. For example, SendGrid allows 100 emails / day for free, but you have to pay to go over the limit.user
profile page to manage subscriptions. Rather, auser
will need to subscribe or unsubscribe when they are RSVP'ing #278 or canceling an RSVP #277 for anevent
.user
may click the "Unsubscribe" link in anevent
email notification (#275 #276) to unsubscribe from future notifications for thechapter
that created theevent
.user
cannot unsubscribe from notification for a specificevent
. When they unsubscribe they will not receive any future notifications for thatchapter
unless / until they re-subscribe to thechapter
's notices on a future RSVP.user
to be logged in for the "Unsubscribe" link to work.user_chapters.user_id
+user_chapters.chapter_id
. Not sure of the technical implementation so this will need more vetting.user_chapters.subscribed
boolean to false.user
to simply toggle their preference. The result of theuser
subscription preference will be saved inuser_chapters.subscribed
astrue
to opt-in to notices orfalse
to opt-out of notices.Questions