[
https://jira.duraspace.org/browse/DS-740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=19578#action_19578
]
Tim Donohue commented on DS-740:
--------------------------------
This issue was discussed in the Developers Meeting on March 23, 2011:
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740]
Allow media filter to set non-default permissions on derivative bitstreams -
DuraSpace JIRA
[20:03] <kshepherd> idea is good, no patch..
[20:04] <mhwood> Shouldn't that rather be an attribute of the collection?
[20:04] <richardrodgers> i agree, needs a sponsor since it's really a feature
request
[20:04] <mhwood> Anyway it does expose a problem.
[20:05] <stuartlewis> A slightly related thing was chatted about on here
yesterday - the ability to change en-masse authorizations (e.g. 'I've updated
the default perms of this collection, now re-apply it to all items in this
collection')
[20:05] <tdonohue> +1 to further analysis here...needs a volunteer
[20:05] <tdonohue> stuartlewis -- that sounds like a different feature request
:)
[20:06] <tdonohue> (but also a good idea, I think)
[20:06] <PeterDietz> is the problem that ORIGINAL is restricted, thus so is
THUMBNAIL, and on browse pages, they try to use the THUMBNAIL and it makes you
login to browse
[20:06] <kshepherd> no, the opposite i think
[20:06] <kshepherd> the ORIGINAL is restricted, because nobody is supposed to
see it
[20:06] <kshepherd> but the THUMBNAIL is generated with open access
[20:06] <stuartlewis> Yes, different, but could be used to tackle the same
problem if it were possible to assign default perms for thumnails.
[20:06] <kshepherd> and copyright is broken, or whatver
[20:07] <mhwood> So a container needs 1 default ACL for original bitstreams and
another for derived bitstreams. Maybe they should be tagged with bundle
names....
[20:07] <kshepherd> it does raise the question of what should happen when an
anonymous or unauthorised person tries to look at, say, a browse page
[20:07] <mdiggory> thats a strong assumption that thumbnails should be open
access
[20:08] <tdonohue> sounds like we are unsure about DS-740... needs volunteer,
further analysis, and suggestions on best way to fix
[20:08] <kshepherd> a redirect to a login page would be confusing if someone
thinks they're just browsing a collection to see titles/authors or something
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-740 ] - [#DS-740]
Allow media filter to set non-default permissions on derivative bitstreams -
DuraSpace JIRA
[20:08] <mdiggory> your really going violate someones privacy for the sake of a
thumbnail?
[20:08] * aschweer ([email protected]) has joined #duraspace
[20:08] <tdonohue> any volunteers for 740?
[20:10] <kshepherd> *tumbleweed*
[20:10] <tdonohue> OK -- moving on, spent too much time already. Please add
comments to 740 if you have any thoughts on best route forward.
...
[20:10] <mdiggory> If the bitstream is restricted, so should the thumbnail, and
the UI should detect that and not show it in search/browse (use a placeholder
instead)
[20:10] <kshepherd> mdiggory: yep that sounds best
> 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:[email protected]]
> Sent: Wednesday, November 03, 2010 9:39 PM
> To: [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
