View locality detail - permissions for private localities

[Nicole-Ridgwell-NMMNHS]

I'm trying to figure out private locality access for our operators without edit locality permission (everyone but me). These users are curators, land management partners, and interns who need access to our locality data.

Currently, they can see private locality data in a record and view private locality data in locality search results, but they cannot view the locality detail page and they cannot download locality search results. It would be helpful for our users to be able to download and view details.

Also, I'm unclear what the permissions for viewing the private localities hang on? Is it based on the collection access of the person who creates the locality?

[dustymc]

I need more information. Anyone with coldfusion_user should be able to see 'private' localities. There is no collection connection at all.

[Nicole-Ridgwell-NMMNHS]

I'm only just getting to this because I've been out of office and overwhelmed, but I am upping priority because I did not realize that private localities are visible to anyone with operator permissions. That is not private? What can we do to make these actually private? I realize localities are shared which makes things complicated, but by law I have to have a better solution here.

[dustymc]

What solution would you like?

Other than "is technically viable" I think my main concern will be sustainability - eg, I'd oppose a 'list of usernames who have access' approach because at some point they will inevitably all wander off, leaving the data locked and inaccessible to everyone. (I'm not trying to say that even some variation of that won't work, I'm just trying to get my concerns out there so they can be somehow addressed before they find a way to be problematic.)

[Nicole-Ridgwell-NMMNHS]

Would it be possible to refine the private attribute. Instead of just having one option - private - it could be a pick list of collections tied to users that have operator access to that collection?

[dustymc]

Not sure I'm following, but

attribute=private value=(some collection role)

and the check would be user has access to that collection plus some other assigned role (manage_locality or data_entry or something new or whatever)

yes??

That would mean private localities could only be used by a single collection, which probably isn't an issue given the situation.

[Nicole-Ridgwell-NMMNHS]

Essentially yes. Currently we have attribute = locality access value = private

and I am proposing attribute = locality access value = (some collection role)

If the attribute is not present, the locality is available to everyone If you want a private locality to be used by more than one collection (this would probably have to be some collection to collection arrangement since obviously the locality would not be discoverable to the other collection), you could add the attribute multiple times, one for each collection?

[dustymc]

"(some collection role)" is these things, right?

UWZM_Paleo UWZM_Teach WNMU_Bird WNMU_Fish WNMU_Mamm

add the attribute multiple times, one for each collection?

I think that's a "you tell me" but yes that should be possible (and probably the simplest approach, so I like it).

[Nicole-Ridgwell-NMMNHS]

"(some collection role)" is these things, right?

Yes. And I think access to collection or access to collection + coldfusion_user would be fine. Land management folks/curators who need to see the private locality data won't necessarily need/want edit access.

[dustymc]

Plain ol' "access to collection" would be a huge simplification for me, I'll run with that if it's acceptable to you.

[Nicole-Ridgwell-NMMNHS]

I'll run with that if it's acceptable to you

Yes! Glad that simplifies it.

[dustymc]

@Nicole-Ridgwell-NMMNHS there's no sane way I can implement handling for "add the attribute multiple times, one for each collection" such that ANY grants access - unless there's some super-compelling reason to do otherwise, this is going to go out as ALL.

On the bright side, I think that aligns with everything else in Arctos and in general - you need all required roles to perform some action, partial access is the same as none. On the potentially scary side, you can probably use that to lock yourself out of your localities - the code table is just simple values, there's no 'if you have it' filter involved in assigning, that's checked only for accessing. There's no current data where this could be a problem, and this isn't something that naive users should be messing with anyway so I think the scary bits are all entirely theoretical, but maybe better documentation or some report or something is necessary.

Please let me know ASAP if that's workable or if we need to rethink this before I make any holes any deeper.

[dustymc]

I think this is fully functional in test, testing would be very much appreciated.

[Nicole-Ridgwell-NMMNHS]

Can you make my test account an operator (username NICOLEVOLDEN) and assign edit locality user role?

[dustymc]

It's test, feel free to make as many accounts as you want and give them whatever scary rights you want - you can make agents for them or just grab a random existing agent, whatever's easier.

Here's your invite for that one - the various yous should be able to handle the rest, but let me know if you get stuck.

Hello, NICOLEVOLDEN. You have been invited to become an Arctos Operator by dlm. The next time you log in, your Profile page (http://test.arctos.database.museum/myArctos.cfm) will contain an authentication form. You must complete this form. If your password does not meet our rules you may be required to create a new password by following the link from your Profile page. You will then be required to fill out the authentication form again. The form will only be available until you have successfully authenticated. Please email dustymc@gmail.com if you have any questions, or dustymc@gmail.com,arctoslogs@mail.com if you believe you have received this message in error. See https://doi.org/10.7299/X75B02M5 for Arctos resources.

[Nicole-Ridgwell-NMMNHS]

Thanks! Once you add rights to NICOLEVOLDEN, I'll add as many other accounts as I need.

[campmlc]

Hi @Nicole-Ridgwell-NMMNHS - can I be a test agent? I'd like to understand how this works. Or don't give me rights so I can confirm I don't have access?

[dustymc]

What rights do you want? NICOLERIDGWELL claims to be happy, you should be able to use it or I'm happy to give any or all of yous whatever I have....

[Nicole-Ridgwell-NMMNHS]

I think I'll need coldfusion_user, manage_agents, manage_collection, manage_locality, and manage_records for nmmnh_paleo and nmmnh_geol. @campmlc, yes please!

[dustymc]

done

[Nicole-Ridgwell-NMMNHS]

If I have the exact url (or the locality ID to build the url) for edit locality I can still access it even if my user account does not have permissions for that collection.

Steps I took:

1. While logged into an account with NMMNH paleo and edit locality access, I copied the url of a locality with locality access = nmmnh_paleo
2. logged out
3. logged into an account with edit locality and only NMMNH geol access
4. pasted the url and successfully got to the edit page for that locality.

This is a loophole that is very unlikely to be exploited, but a loophole nonetheless. I also tested this with the locality detail page and my NMMNH geol account was not able to see the detail page. The loophole only exists for edit locality.

[dustymc]

Yep, that's intentional. Without some drastic RLS-based revamp of the entire locality model or something, the alternative to that scenario is

1. Edit your locality
2. Pick some collection you don't have access to
3. Save-and-panic as you realize what you've done
4. Panic some more because there's nothing else you can do, the locality is no longer accessible to you

I'm happy to flipflop things around and doing so is easy enough, but I think the current setup is least-evil.

[Nicole-Ridgwell-NMMNHS]

Yep, that's intentional

I can accept that.

Thank you for taking care of this so quickly!

[Jegelewicz]

re-opening - needs documentation

[Jegelewicz]

added to documentation (How To).