Filter resource instances by authenticated user / group

[Brett Ferguson]

Hi all -

I'm currently trying to figure out  the best way for certain user groups to only be able to view and edit their own resource instances (ie resource instances they created).

We have a use case that requires:

1) that a user group be able to create and edit resource instances for submission to an authority , but not be able to view / edit other users' resource instances. 

2) once a resource instance has been submitted, the user group should be able to view the submitted resource (for submission tracking purposes) but no longer be able to edit it.

I'm just wondering if anyone has implemented this type of functionality or has any insight on the best approach before I head off into the weeds.

For #1, I'm thinking that a search filter might be a good way to do that. The filter would only be applied to certain user groups. I'm just wondering if that seems like the right approach or if I'm way off base.

For #2 I'm guessing some sort of dynamic authorization would be necessary, based on a resource tile value. I haven't wrapped my head around how might be done yet, but once again wondering if someone has already implemented this type of functionality.

Thanks so much!

Brett

[Adam Cox]

Hi Brett,

I have implemented a system kind of like this for the Heritage Monitoring Scouts program at the Florida Public Archaeology Network (hms.fpan.us). There are two types of filters: 1) "Scout" users are granted access to specific archaeological site resource instances via "assignment" by administrators, and 2) various categories of "Land Manager" users are given access to subsets of archaeological sites--all sites located within their state park, for example. Ultimate, the filtering is done by a custom search filter component that is applied behind the scenes to node values in the archaeological site resource instances. In 1, administrators update a node in the instance to hold the Scout's username and the search filter runs a match on that, and in 2) the filter matches location-derived attributes in the instances with properties of the Land Manager's user profile. I can give you a lot more information on this if you want (feel free to e-mail me directly), especially in May and June as I'm planning to finish some in-progress upgrades on the system at that time.

That said, as you're probably aware, Arches does have some advanced permissions capabilities built in now (which weren't there when we first designed the HMS system), as well as the provisional editing capabilities. Building off of those functionalities as much as possible will likely be the best way forward, but Arches is also now well-suited to creating a custom search component.

Adam

--
-- To post, send email to arches...@googlegroups.com. To unsubscribe, send email to archesprojec...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en
---
You received this message because you are subscribed to the Google Groups "Arches Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to archesprojec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/archesproject/630b0b5c-6c1c-4f0f-8d91-41282763f72an%40googlegroups.com.