Why is there only one contact per region?

[kfogel]

@OhMcGoo, is there some reason why the Smoke Alarm Portal should permit only one contact per region?

Remember that 'contact' is different from 'administrator', although in practice the contact person for a region is often also one of the administrators for that region.

Right now the code enforces there being only one contact, although there can be (and often are) multiple admins. @frankduncan is implementing the user management feature (see #263) and he realized that on the screen where one manages user accounts, there could be a checkbox to make a particular user be not only an admin for a given region but also a contact for that region.

Right now, if you were to check that hypothetical checkbox, it would have to uncheck whoever else is set as a contact for that region, since there can only be one contact.

So we started to wonder: "Hmm, why should there only be one contact?"

Now, maybe it's actually good to have exactly one contact per region: it unambiguously focuses responsibility for handling notifications of incoming smoke alarm installation requests. If you think it's better for us to keep it to one-contact-per-region, we can.

Thoughts?

[jim-mcgowan]

The short answer is there is no reason why there can't be multiple contacts AND admins. Ideally, and I emphasize ideally, Regions should be able to designate a number of contacts and actually specify, by ZIP Code (or County), which requests go to which contact.

[frankduncan]

The way the current system works is that each region has a contact name and contact email, and those are not formally associated with actual admins of the system.

So, we have a few paths moving forward in the short term (without the ideal world of more granular specification of notifications):

• Have a region configuration page that allows you to change these textual fields
• Have a region configuration page where you set an admin to a region (and so you need to create an admin if one isn't already created)
• Have the account administration have checkboxes for designated contact, and allow multiple contacts per region that are all notified.

There are other implementation options (like allowing you to add multiple free form contacts) that seem less optimal than these three solutions, but we can explore those if none of these fit the bill.

What's the best line of attack?

[kfogel]

Okay, @frankduncan and I chatted on the phone. Here's what we're going to do:

The user administration page (that is, the page a Site Admin uses to administer multiple other users) will offer two distinct things you can do for a given user with respect to a given region: set/unset that user to be an admin for that region, and set/unset that user to be a contact for that region.

(My guess is the interface will be some kind of grid-like thing, therefore.)

Note that this makes it possible to have aliases as region contacts. The Red Cross could set up an address like WISC-contacts@example.com that actually goes to several different Wisconsin-related Red Cross folks. The site user created with that address would be a regular user and just happen to have no admin access on any regions (there's no reason for it to have admin access even to WISC -- of course, the individuals to whom that email alias points are likely to have their own accounts on the site and those accounts probably would have admin access on the WISC region). However, that WISC-contacts user would be designated as a contact user for the WISC region. It might even be the only contact point -- maybe the other users who have admin access on WISC don't get set as contacts; that way all notification emails flow through the WISC-contacts address, which might make certain things more convenient.

Anyway, that's just one way to set things up. You could also have each user who has admin access to a given region also be a contact. It's now a management choice -- the software will be flexible enough to accommodate either way.

@OhMcGoo, your dream of zip-code-routed emails won't be happening in this iteration. It's certainly something we can do; we can discuss it later. First I owe you an estimate on adding a new region though, as per your email yesterday; let me do that first :-).

[frankduncan]

One note as we do this. There will be a small manual step of migrating the data from default contact to selecting the user in production. The number of regions is small enough that this should just be done manually rather than trying to do so through the migrations and fancy selects.

[frankduncan]

Another wrinkle appears! In the activeRegions table, there is a contact_name, contact_email, and contact_phone. The first two are used to construct the email, the phone number is not populated for anyone in the database, and the code to text that number appears to be dead.

As we move to linking to User, we need to replicate at least the name in order to construct the email. However, there is an unlinked to page (on which work has been done, see #172), where a user can set their own contact information and name and whatnot, but is done via going to /account after logged in, which is not accessible from the main login page (it is accessible after you use the signup link that is turned off in production). No one appears to have ever set any account information.

So, we have a lot of pieces here, and we need to decide what to do going forward. A few options:

• Add in a link to the "modify account settings page" for people who are logged in, so that they can set up their own name
• Duplicate that account information in the User table, and most likely disable that page that no one uses, and let a Site Admin update the information.
• Don't use the information at all, and just send it to their email address with their username as the <name>

Probably some more I haven't thought of. Until we have a conversation about what to do, I'm defaulting to option 3 because it commits the least amount of resources to any path.

[kfogel]

@frankduncan Let me answer this in two steps -- the back-end step, and the front-end step.

On the back end, it really feels like we should do a reorganization/cleanup/normalization -- something like this:

• Consolidate all User information in the User table, which means adding a phone-number column to that table (i.e., adding a phoneNumber field with appropriate DataType in models/User.js, I guess).
• Fix activeRegions to refer to a User by primary key instead of duplicating User-specific columns.
• Update all the code accordingly :-).

(If the above is what we were already planning to do, then great! I might have forgotten some previous discussion. But if it wasn't what we were planning to do, then let's change our plans.)

On the front end, I don't think we need to make a big investment right now in providing users the ability to edit their own names and phone numbers... but if a Site Admin is going to be able to do that anyway, then it's only epsilon more work to re-use that same page to let the user edit their own record, right?

I guess for the front-end issues I need more context: what capabilities do we already have, which new capabilities were we already planning to implement, and what new new capabilities are you proposing/asking about here?

[frankduncan]

With #280 being merged and in production, closing this out