Hi Richard, One other thing to consider (though this might be too complex for your scenario). If you transmitted DSpace AIPs via SWORD than you could submit authorization permissions in the AIP itself (in METS).
In other words, the AIP Backup & Restore feature allows DSpace permissions to be translated into the METSRights Schema, as described here: https://wiki.duraspace.org/display/DSDOC18/DSpace+AIP+Format When an AIP is restored, it actually will be assigned the authorization settings as detailed in METSRights (this is controlled by the METSRightsCrosswalk). Again, not sure if this is really what you are looking for or not, but it's something to be aware of. - Tim On 5/17/2012 7:38 AM, Richard Jones wrote: > > > On Thu, May 17, 2012 at 12:02 PM, Richard Jones <[email protected] > <mailto:[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 > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
