Hiding "audit" bitstreams / creating new bundles
Fitchett, Deborah
Kia ora koutou,
We have a bunch of files that we need to keep for auditing purposes – in some cases to do with copyright permissions, in others proof that a conference did actually take place – but we don’t want the files or even the filenames to be visible to users as the filenames weren’t written for public consumption. I don’t think any would *actually* breach privacy, but – it’s not ideal.
In DSpace 5.8 we left them in ORIGINAL, manually edited the auth policy for these bitstreams to restrict access to Admin-only, and I did some messy hacking with xsl to hide admin-only items from display. But we’re needing to use DSpace 7.* in a more out-of-the-box way.
We can’t restrict the bundle ORIGINAL as a whole because there are other files that are open access so need to remain visible.
Options I can see:
- If the bitstream is in the ORIGINAL bundle (our practice to date) then the filename displays on the item simple view page. This is the default behaviour I’m trying to avoid.
- If we add the bitstream to the LICENSE bundle instead then the filename doesn’t appear on the simple view page but does appear in the expanded view. This is a slight improvement but starts being a bit of an abuse of the “LICENSE” terminology and still isn’t ideal.
- In the Edit > Bitstreams > Upload I see the option to create a new bundle. If I create a bundle AUDIT and upload a file to it, this bitstream doesn’t appear anywhere publically, which is excellent. (It does seem to be created with an Anonymous READ policy so we’d still want to edit this to be safe.) OTOH I also don’t see the bitstream (or the AUDIT bundle itself) appear in Edit > Status > Authorisations. So I’m not sure if this is the most robust approach.
Are there any unobvious ramifications of creating a new bundle in this last way / for this purpose?
Is it a bug that a newly created bundle isn’t visible in Edit > Status > Authorisations? (I can log this if so.)
Are there any ways to move a bitstream from one bundle to another so that we can fix up items retrospectively? So far my best guess is either
- to mess in the database – but I’ve only got direct access to that for a couple more days and we have no way to programmatically identify the affected bitstreams, so this isn’t feasible; or
- to download each one from ORIGINAL, delete it, then upload it to LICENSE or AUDIT, which would obviously be painfully timeconsuming.
Or does anyone have any other better ideas for how to deal with this problem?
Deborah
––––––––––––––––––––––––––––––––––
Deborah Fitchett (she/her) MLIS, RLIANZA
Associate University Librarian, Digital Scholarship
––––––––––––––––––––––––––––––––––
Learning, Teaching and Library – Te Whare Pūrākau
PO Box 85064, Lincoln University
Lincoln 7647, Christchurch, New Zealand
––––––––––––––––––––––––––––––––––
Lincoln University
Te Whare Wānaka o Aoraki
––––––––––––––––––––––––––––––––––
"The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system."