Richard,
I think that some of the work we may be planning around The Advanced
Embargo contribution might be of benefit in this area in the future.
Namely, we need to allow more control for policy setting in sword,
submission, workflow, ItemImport and so on. Installitem's heavy-handedness
on setting policies will need some improvement so that more granular policy
setting may be allowed in the deposit manifest.
Maybe a good question for you... Are there any mechanisms in APP for
assigning rights on attachments or a post in general? My current thoughts
on the DSpace SWORD side would be the use of METS and PREMIS Rights
statements.
Mark
On Thursday, May 17, 2012, Richard Jones wrote:
>
>
> On Thu, May 17, 2012 at 12:02 PM, Richard Jones
> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>
> > wrote:
>
>> Hi Folks,
>>
>> I'm working on an issue that I have here to do with ingesting complex
>> content into DSpace via SWORD. The hard problem I need to solve is that
>> the incoming object contains administrative content as well as public
>> content, and the admin content is stored in bundles which are to be secured
>> via the DSpace authorisation mechanism from public access.
>>
>> I can set resource policies on the bundles when the item is first
>> ingested, but this happens when the item is still in the workspace. When
>> the deposit is complete the item is injected into the workflow and
>> ultimately into the archive. The problem arising is that InstallItem
>> overwrites all permissions on the item with the collection's default
>> policies, which - in this case - is making all those files open again. I
>> need to find a solution to this, and it would be ideal if that solution
>> avoided patching the DSpace core; here are some things that I've been
>> thinking about:
>>
>> 1/ Collection default policy set up: this seems like the intended
>> approach in DSpace, but I don't have a single set of policies which I can
>> apply to the item as a whole. For example, I need the ORIGINAL and LICENSE
>> bundles to be Anonymous READ, but require the SWORD and METADATA bundles to
>> be Administrator READ only. Perhaps there are more cunning ways that I can
>> set up the collection policies so that they cascade appropriately onto my
>> item?
>>
>> 2/ Adding an event consumer which listens for the Item+Install event and
>> sets the policies explicitly. This looks very promising, although I notice
>> that the event itself is constructed and added to the context's event list
>> before the collection's policies are applied. I'm new to the event system,
>> and I don't know whether this means the synchronous event will run before
>> the collection policies are set (making everything that I do in my consumer
>> irrelevant) or whether it will run at the very end of the request.
>>
>> Any tips on the best way to push access privileges through InstallItem
>> would be very helpful.
>>
>
> I've answered my own question which is that (2) is the only way to do
> this, and the event runs after the install has fully completed, so it
> doesn't clash with the policies being set by install item.
>
> Cheers,
>
> Richard
>
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
