The auth table described in ATLAS-166, shouldn’t it also contain the marker, for the secret token to be associated with a marker? Also, how are entries added to the auth table? I assume an entry would be added during the creation of a marker. How is the secret token set? (I’m starting to think that we may need a page to manage the table)
Looking over Atlas tickets, here’s a rough prioritization…
-
Promote use & awareness of OpenMRS Atlas
-
Make it easier for sites to maintain their markers
-
Enhancements that are less urgent or with workarounds
1 Like
Yes. The auth table has an id for the row and atlas_id as a foreign key to the marker.
When the module is used, it should generate its own secret (by generating a UUID) and pass that to the server when the marker is created or when an existing marker is linked to the module’s OpenMRS instance. The Atlas server should create a salted, one-way hash from the secret using bcrypt (so you couldn’t infer the secret even if you had the server’s database). When we allow multiple users to maintain marker, the users other than the creator would have an auth entry pointing to the marker with their username as the principal and an empty token (we’d rely on ldap for authentication).
1 Like
How would their privileges be defined?
About ATLAS-168, I’m assuming we’ll have to use a scheduled task for it? We would also probably need a table mapping marker ids to the last time they were notified. Would do you think?
I looked at ATLAS-168 yesterday. I combined node-schedule (for the scheduler) with nodemailer (for sending smtp mails), but while the mails were being sent successfully, they weren’t being received on the receiver’s side. I’ll continue looking at it. 
Also, could you please provide me a link to an RSS feed website to serve as an example? Thank you.
There is a varchar attribute for privileges that we can store whatever we want to represent privileges. We’d at least need three levels (ping from a module, editor to help maintain, and owner to have all privs equivalent to creator). The server would automatically set the ping privilege when linking a module to a marker. We’d need to add fields in the UI for a creator/owner to manage privileges for others.
Yes. That sounds right. While we’d certainly log notifications, we would need to track notifications (at least the last one) to avoid sending duplicates. While a last_notified timestamp on the atlas could suffice, it would be good to build the feature so it could be extended later (e.g., to support notification of marker changes made by others)… so, perhaps a notifications table with timestamp, target, and type would be better.
Are you using Gmail or some other service for SMTP? If you’re sending directly, that could be your problem. There is so much spam and emails these days that setting up an SMTP server properly can be complicated. We have a service for sending mail, so you can assume that SMTP credentials will be provided through environment variables. For testing, use a Gmail account.
There’s an rss link on the OpenMRS main website: OpenMRS.org
You can also find an rss feed at: planet.openmrs.org
I’m assuming npm’s RSS library would be a good choice.
1 Like
So would you suggest that we have a page for a creator to manage a specific marker?
I’d rather not send the average user away from the map if we can avoid it. I was thinking of one more field in the marker bubble form – e.g., Co-owners:
as an optional token input where each token is an OpenMRS ID. A first pass could rely on manual input of exact OpenMRS IDs (rather than searching LDAP) and focus on co-owners (ignoring the role of “editor” – able to edit but unable to delete or assign other owners – which is less important to support this summer). We’d probably want to avoid letting a co-owner remove themself (maybe by filtering their username from the list of co-owners) and limit the number of co-owners to a small number (e.g., 2-3).
1 Like
Real quick announcement, atlas 3.1 is deployed to production
If you need smtp, that’s also available as environment variables.
2 Likes
Awesome! Thanks @cintiadr. Does this mean we can promote new artifacts to production through CI (as long as they don’t depend on manual db or config changes)?
Once we have eliminated significant bugs and have confirmed that LDAP integration is working as expected, we’ll make an announcement asking people to update their markers.
@heliostrike, I discovered a bug that appears to be the result of some invalid data in responses from the server. I’d suggest prioritizing this:
2 Likes
Yes! If it needs new environment variables or DB changes, we’d need to do manually/via ansible, but updating the image is literally clicking in CI
2 Likes
I think atlas_version being a date is due to the entries in db/data.sql . I got NULL values for the markers I created because I wasn’t giving atlas_version any value. 
If atlas_version refers to version of atlas in which the marker was created, I think a constant could be used to save it. Why would we need SQL for it?
I was tricked by the attribute name too at first. I think it’s supposed to be the version of the atlas module that sent the ping (in case the format of data changes in subsequent versions).
To correct/clear bogus (legacy) values in the server’s database.
1 Like
Got it! So would the markers created on the webapp (and not pinged from the module) have atlas_version as NULL?
Yes. That attribute’s sole purpose in life is to let the server know how to parse the data json. It might make more sense if this attribute was atlas_data_version and changed only when/if the schema for data changed.
1 Like
I wrote the filterMarkerIds function about a month ago to hide marker ids from unauthorized users, but now that we’ve established a fair amount of security around modifying markers, I think it can be removed. What do you think?
function filterMarkerIds(req, markers) {
for(var i = 0; i < markers.length; i++) {
//If user not is signed in or authenticated user is not the creator of a marker
//then hide the marker's id
if(req.session.user == null || markers[i].created_by != req.session.user.uid) markers[i].id = i;
}
}
Would you suggest that we store permissions as a string (like ‘110’) or as an int (like in unix)?
Agreed.
Given we only need a few privileges (actually, just two for the foreseeable future: update & all) and we want to make things easy for future devs to maintain, I’d suggest just using the text “update” and “all”. A principal with “update” privilege could only post an update (i.e., this is what a module would have) and someone with “all” privilege could do anything (i.e., equivalent to being the marker’s creator).
1 Like
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?
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.
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).
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).
1 Like
I just realized that production Atlas doesn’t have any ‘versions’, making it impossible to edit an existing marker (because of the NOT NULL constraint). How do we solve this? I think a null check when saving to database should fix it. We could also simply add a few OpenMRS versions using the admin UI.