GSOC 2019: OpenMRS Atlas 3.1

[burke (Burke Mamlin)]

@heliostrike

One change I would like would be to have a mail column in the auth table. This would make it easier to display co-owners’ mails on a marker’s info window, and while sending mails notifying that a marker is fading. Making an LDAP call to get the user’s email when creating an auth rule will save us a lot of LDAP calls later on. But it would also consume a bit of space (unless we create another table for emails), so I’m not entirely sure. What do you think of this?

Marker’s can have optional contact information (name & email). We only want/need one point of contact per marker and we shouldn’t presume that this will be the email address of the creator or even a particular individual’s email address (e.g., an organization might want to put their company’s contact email here). So, don’t worry about displaying email addresses in marker’s beyond the optional contact email we already have (atlas.email). Also, don’t assume the atlas.email is the address to send notifications for the creator. Instead, we want to send to the creator’s primary email on file within LDAP (which may differ from the marker’s contact email).

Ideally, notifications would go to the primary address on file with OpenMRS ID. While we could cache an email address from LDAP, we might send to the wrong address if someone has updated their email with OpenMRS ID. I understand & appreciate the goal of avoiding lots of LDAP calls… but perhaps we could accomplish this through batching the LDAP – i.e., instead of separate calls for every user, ask LDAP (in one request) for email for all users we need to notify. These events (a marker fading or changed) are going to be relatively rare (likely averaging less than one event per day for the entire Atlas).

@heliostrike

I was looking at ATLAS-168. I could successfully send mail through smtp, and was wondering how to update a marker on the click of a link. I assume we’ll send links of the kind of base-link.com/token=abcde , then we have a table mapping the token to the marker id. We’ll have a scheduled task to clear older entries.

One option would be, as you describe, to create temporary authentication tokens that would update the marker regardless of who made the request. Since we can assume a user is activating this link in a browser, we could avoid the need for a temporary token and, instead, use a URL that forces authentication. In other words, imagine a URL like atlas.openmrs.org?update={id}

• If the user is already authenticated to the Atlas server and an owner for the marker, the Atlas page would load with the marker’s bubble open and the last updated date already updated.
• If the user wasn’t authenticated to the Atlas server, they would be redirect to /login?redirect=%3Fupdate%3D{id}, which would prompt them to login and then redirect them to /?update={id}.
• If the user was already authenticated but not an owner of the marker, then the Atlas would load with the given marker’s bubble displayed and a popup alert saying “You are not authorized to update this marker.”

On a related note, ALL emails sent to users should contain an unsubscribe link at the bottom that, if clicked, will prevent future emails. So, for ATLAS-168, we’ll probably want to support /?email=subscribe and /?email=unsubscribe URLs that behave similar to what I’ve described for updating but, in this case, control whether or not the user gets notifications. Perhaps an email_unsubscribe table with a list of OpenMRS IDs would suffice (i.e., we never send notifications to someone if their ID is in this list and these URLs would add/remove their OpenMRS ID from that table).