[
https://jira.duraspace.org/browse/DS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19586#action_19586
]
Steve Swinsburg commented on DS-740:
------------------------------------
What we need is more control over the permissions applied to the derived
bitstreams. It wouldn't be sufficient to group all derived bitstreams into one
ACL and then use another ACL for the originals. The reason being is that we
want the thumbnails and branded previews to be public, but then the originals
to be protected. However it should be possible for the thumbnail to be public
and the branded preview and original to be protected.
In summary, the ability to set the permissions on the bitstreams individually.
> Allow media filter to set non-default permissions on derivative bitstreams
> --------------------------------------------------------------------------
>
> Key: DS-740
> URL: https://jira.duraspace.org/browse/DS-740
> Project: DSpace
> Issue Type: New Feature
> Components: DSpace API
> Reporter: Stuart Lewis
>
> At present, derivative bitstreams created by filter-media all take on the
> authZ policies of their parent item. In some cases, such as locked images,
> the thumbnail could still be open.
> From a recent thread on dspace-tech. It seems as if this would make a useful
> feature if we can agree on a set of requirements:
> Hi George,
> Thanks for your reply. Do you have open access to any of your content or is
> it all restricted? We have a mix which makes running the filter-media etc
> scripts interesting.
> Ideally the solution would be to set permissions at a collection level for
> each of the types of bundles. The item permissions would then inherit from
> the collection, or override if policies are set on individual items.. I don't
> seem to be able to do that (1.5).
> For reference, heres the (cutdown) SQL. This will update all thumbnail
> bitstream policies and set them to anonymous. We only had to do it for one
> group though. If you want to update intermediates, change THUMBNAIL to
> BRANDED_PREVIEW.
> update resourcepolicy
> set epersongroup_id=0
> where policy_id in (
> select
> rp.policy_id
> from
> resourcepolicy rp,
> bundle2bitstream bb,
> bundle b
> where
> b.name='THUMBNAIL'
> and b.bundle_id=bb.bundle_id
> and bb.bitstream_id=rp.resource_id
> );
> cheers,
> Steve
> On 04/11/2010, at 11:59 PM, George Stanley Kozak wrote:
> Steve:
> This is the way that thumbnails have worked for me at my site (we have been
> using DSpace since 2003). It can be frustrating. Your solution is
> interesting. I never thought about going into SQL to update the policies on
> the thumbnail bundles. I am not sure if there are any other solutions.
> George Kozak
> Digital Library Specialist
> Cornell University Library Information Technologies (CUL-IT)
> 501 Olin Library
> Cornell University
> Ithaca, NY 14853
> 607-255-8924
> -----Original Message-----
> From: Steve Swinsburg [mailto:steve.swinsb...@gmail.com]
> Sent: Wednesday, November 03, 2010 9:39 PM
> To: dspace-t...@lists.sourceforge.net
> Subject: Re: [Dspace-tech] thumbnails restricted if main item is restricted
> We've fixed this up with some carefully crafted SQL to update the policies to
> the Anonymous group for the bitstreams in the thumbnail bundles, but it would
> be interesting to know if this is actually how things are meant to work, ie
> inherit the permissions from the parent item when generating the thumbnails.
> regards,
> Steve
> On 04/11/2010, at 10:53 AM, Steve Swinsburg wrote:
> Hi,
> We have a situation where some items in a collection are restricted, ie you
> need to login to access the full version. However we want the thumbnails and
> branded previews to still show up for the general public.
> When we run the thumbnail generator, it seems to inherit the permissions from
> the main bitstream, which means if the bitstream is protected, the thumbnail
> doesn't show up unless you are logged in and have the appropriate permission.
> Is this a common situation? We've inherited this instance so it might be a
> change made by people before us, but if anyone has addressed this, it would
> be great to hear from you.
> thanks,
> Steve
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.duraspace.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
