Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send notice for unscheduled closures #151

Closed
charlesbrandt opened this issue Apr 25, 2018 · 8 comments
Closed

Send notice for unscheduled closures #151

charlesbrandt opened this issue Apr 25, 2018 · 8 comments
Milestone

Comments

@charlesbrandt
Copy link
Contributor

When an unscheduled closure occurs, it would be useful to be able to send a notification to a select list of emergency contacts.

This would require:

  • a custom field to add notes about the event
  • a way to mange who is on the emergency contact list

Related, but different from #144
This feature would be manually triggered by staff. #144 would be automatically triggered for all new events.

@charlesbrandt charlesbrandt added this to the 1.2 milestone Apr 25, 2018
@charlesbrandt charlesbrandt changed the title Feature to send notice for unscheduled closures Send notice for unscheduled closures Apr 25, 2018
@inghamn
Copy link
Member

inghamn commented Apr 27, 2018

I don't know if it makes sense to set up additional google groups for new, arbitrary, sets of email addresses to notify. Rather, inRoads should send the emails directly to a set of email addresses that we configure.

This and #144 are the same, in that inRoads will be sending emails directly to individual email addresses. Are the emergency email addresses going to be people already in the system? Or, should they be configured in site_config?

@charlesbrandt
Copy link
Contributor Author

charlesbrandt commented Apr 27, 2018

For this issue, the contacts to receive the message may not be in the system in any other way. Beyond that, I'm not sure where the best place to configure those would be.

@inghamn
Copy link
Member

inghamn commented May 1, 2018

The email addresses that Bloomington wants to send emergency closure notices to is a mix of individual and group accounts. I could kind of see having people sign themselves up for the emergency notifictions. However, treating the group accounts as people is probably not the best.

I think we're going to need a configured list of email addresses to notify. What user roles should be able to maintain that email list? It seems like something that should be editable through the web interface?

@inghamn
Copy link
Member

inghamn commented May 1, 2018

I think we probably want both: users should be able to subscribe themselves as well as a list of additional emails configured by an Admin or Staff person.

inghamn added a commit that referenced this issue May 3, 2018
We're going to need a seperate flag for each type of
notification we want to send out.

Updates #144
Updates #151
@inghamn
Copy link
Member

inghamn commented Jun 18, 2018

How does this differ from just sending an email to a list of people? If I displayed a list of emergency contact emails, would that be enough?

As I was about to build it, it was just going to be a text box for a user to type a message. The inroads server would be responsible for emailing the message to all the email addresses on the contact list. Rather than having the system send the email, can we let the user do this in their own email client?

@inghamn
Copy link
Member

inghamn commented Jun 18, 2018

@charlesbrandt and I talked about it, and decided there should be a preset message that goes out. We want there to be a checkbox on Add Event screen for sending this notification out. The system should already know what the message is, and notify everyone on the list about the newly-added event.

There should also be a button on the view event screen to send this notification out for any event in the system.

@inghamn
Copy link
Member

inghamn commented Jun 22, 2018

With the desire to manage the notification lists in the web interface, the previous storage method was too confusing and compilcated. I should redo it so that we just have two lists (probably tables) of email addresses. A Person is gets notifications if their current email address is in that list.

That way, there can be email addresses that are not People and we only have a single place to look for notifications of a certain type.

The only additional complexity this would add is during Person::save() where we would need to update the email address in the notification list, if the Person has changed their email.

@inghamn
Copy link
Member

inghamn commented Oct 15, 2018

This is a prerequisite for #193

@inghamn inghamn modified the milestones: 1.2, 1.2.3 Oct 15, 2018
@inghamn inghamn closed this as completed Oct 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants