What is the point of "Restricted"? ...

[re...@rbkphoto.com]

I know this has been discussed numerous times here but wanted to bring it up again with a specific case.  

Here is the scenario:  

Two tiers of users - Admins and Staff (arbitrary names)

Both groups have access to an internal system with the ability to edit and download and essentially utilize all features equally.  Both groups have the 'e0' (edit access to workflow Open) and the 'ea0' (edit access to Active) permissions.  The admin group has in addition the 'v' (can download restricted) permission and the full 'ea1' thru 'ea3' permissions allowing unrestricted editing and access regardless of resource state. OK

Arbitrarily, some usage embargoed images get uploaded by an admin user and they want to RESTRICT the download/edit capability of other staff, but it is important for the whole company to know they exist (not confidential/classified).  Naturally the logical idea would be to RESTRICT access to the aforementioned images. OK

Under these conditions, which IMO are pretty standard non-corner-case conditions (as far as permissions), the RESTRICT functionality does nothing.  Those newly restricted images are still downloadable by the Staff group.  The only way I can seem to get the restrict concept to work is if the 'e0' permission is removed (unchecked) from the Staff group of users.  But now, nothing is editable in any access state by that group. Not OK 

Going a step further, in an effort to find some solution for these users, we marked the resources 'confidential' and that works great, just as advertised and all-in-all inline with the verbiage of the permission bits.  Why is the 'restricted' state so different and not so great?

Seemingly there is some overlap and misunderstanding/misuse of the entire 'e' range of permissions.  I read the discussion from 2013 about somehow editing maybe == downloading, this could be same issue, but 2016 version.

Full permission setup nothing overriding in config.php or elsewhere. This particular install is on svn7450, but has been tested with the same results on svn7667. In the system setup, manage sizes: allow restricted download is unchecked.

Admin: s,v,g,q,f*,e-2,e-1,e0,e1,e2,e3,c,i,n,h,j*,t,r,R,Ra,o,m,u,k,a,e

Staff: s,g,q,f*,e0,ea1,ea2,ea3,d,n,dtu,j*

Any ideas and commentary more than welcome.

[re...@rbkphoto.com]

And obviously thanks in advance for any tips/help the devs have on this topic!

[Allison M Stec]

To my knowledge, this is still a case of the edit=download scenario. This was never really resolved a few years back and continues to be as it was.

I've always been unhappy with this (I was actually the one who brought it up back in 2013). I ended up modifying the code to break the edit=download conditions.

I will say back then the logic behind this connection made more sense then it does now. There are more robust permissions around editing, downloading, and setting access.

Since being able to edit metadata no longer means access can be edited, I'd say RS is ready for this change.

Is there any reason not to?

On 02/11/2016 11:23 PM, re...@rbkphoto.com wrote:

And obviously thanks in advance for any tips/help the devs have on this topic!

--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.org
---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
--
ResourceSpace Developer
Reseller of Colorhythm's Prismpoint Portal DAM

Ask me about ResourceSpace AWS Plugins

[Bruce Harper]

On Thursday, February 11, 2016 at 11:22:36 PM UTC-5, re...@rbkphoto.com wrote:

Seemingly there is some overlap and misunderstanding/misuse of the entire 'e' range of permissions.  I read the discussion from 2013 about somehow editing maybe == downloading, this could be same issue, but 2016 version.

I raised this issue in the past for the same reasons you offer. We have a group of people in the department who schedule photo sessions for images for stories and articles. They have edit access to keywords and captions so they can add additional details about a photo that the photographer might not know (names, details about a location, etc.). Most of these photos have Open access making them available to the department group and the university group as a whole (public access is restricted for all images). There is the occasional case where images from a photo shoot are embargoed or have limits on their use due to terms of a research grant. The images need to be available to the person who requested them and may be available for other use (such as a Virginia Tech Magazine article) with permission. The "Restricted" access is perfect for that, because the images can be seen but are watermarked and must be requested.

But we have the same situation, allowing the department group edit access breaks the restricted function -- viewing the resource makes it available for download even though it is "Restricted" and should still be watermarked. Taking away edit ability solves this but hampers the ability to improve details on open images. The "Propose Change" function is also broken, it's throwing an error when I try to use it:

/Library/WebServer/Documents/resourcespace/pages/edit_fields/2.php line 12: Undefined index: node_options

This is under build 7538.

It would be nice if the "e" permissions were expanded/fixed as suggested so that "Open" access items could be edited while "Restricted" items were fully restricted.

Bruce in Blacksburg

Virginia Tech Webmaster

 

[Allison Stec]

I've committed a config option that prevents automatically granting open access when edit permissions are given to active resources in -r7709. It's off by default, but please try it out and let me know how it works for you.

[Bruce Harper]

On Monday, February 22, 2016 at 10:03:39 AM UTC-5, Allison Stec wrote:

I've committed a config option that prevents automatically granting open access when edit permissions are given to active resources in -r7709. It's off by default, but please try it out and let me know how it works for you.

Excellent! Works as advertised now. With the config set to "true" my group that is affected sees a watermarked "Restricted" image and can only request it from the resource view. They do however have the ability to edit the fields they have access to (both for open and restricted images), which is what is expected. Thanks for the fix (one minor nit, in the comment about this config, it says "Pevent" instead of "Prevent" -- but it's right in the actual config line).

[Allison M Stec]

thanks for the spelling catch...which is fixed in 7712

--
ResourceSpace: Open Source Digital Asset Management
http://www.resourcespace.org
---
You received this message because you are subscribed to the Google Groups "ResourceSpace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to resourcespac...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[re...@rbkphoto.com]

Awesome, works great with restrict functions/perms behaving as expected. Many thanks Allison!