[Dspace-general] locking down bitstreams - authorisations?

[Ingrid Mason]

Hi there,

 

Anyone that can wrestle with the authorisations in DSpace is welcome to
offer their wisdom!

 

We want to enable a user with either Workflow Step 2 or Collection
Administrator access to a collection with the ability to 'lock down' a
bitstream in an item that is going through the workflow or even after
the dang thing is in the archive.  

 

Workflow S2 has ADD/REMOVE

Collection Admin has COLLECTION_ADMIN

 

Only the overall administrator seems to have the power to 'lock down' 1+
of the bitstreams in an item - which is a bit of a bind if you want to
decentralise some control over how digital objects are submitted and
managed at collection level.  

 

We have seen the Embargo on Bitstream that the University of Leiden have
introduced, which might offer an alternative:
http://wiki.dspace.org/index.php/Embargo_on_Bitstream.  But.. we'd like
to be sure that we aren't missing any way of working with the
authorisation as it currently stands.  

 

Any thoughts welcomed.

 

Regards, Ingrid

 

Ps. why do we want to lock 1 bitstream down and leave the other open - 1
of the bitstreams is a signed permission form (we haven't rolled out
user submission at this point) the other is the thesis or academic
output that we want to be openly available.  

 

 

Ingrid Mason
<http://www.vuw.ac.nz/staff-directory/PhoneDetails.aspx?VMID=6844> 

Digital Research Repository Coordinator

ResearchArchive at Victoria <http://researcharchive.vuw.ac.nz/>  

Victoria University of Wellington

 

ph: 64-4-463 6844

em: ingrid.mason at vuw.ac.nz <mailto:ingrid.mason at vuw.ac.nz>  

 

Location: Kelburn Campus, Rankine Brown, RB501A

 

- - research deposited in in ResearchArchive at Victoria can be found
within 1 day via the national research hub nzresearch.org and within 2-3
days via the search engine Google - - 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/dspace-general/attachments/20080108/7c72252e/attachment.htm