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

+64 3 423 0358

deborah....@lincoln.ac.nz

ltl.lincoln.ac.nz

 

––––––––––––––––––––––––––––––––––

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."

[Julia Gilmore]

Hi Deborah, 

I know this is an older post but it almost exactly matches a question/desired behaviour we have as well - that is, hiding the display of admin-only bitstreams in the UI (i.e., no bitstream name in the file list, instead of showing the file name with a lock icon). We are curious to know which approach did you end up going with? 

Thanks! 

Julia

[Matyas F. Bajger]

Hello Julia and whole dCommunity!

I wonder what solution have found Deborah for this case, but let me share also the ours. Besides ORIGINAL bundles/bitstreams that we publish according to their license, we also like to have archive copies in pdf/a that are available to admins only. When adding this archive copy we simply create a new bundle named ARCHIVE (or could be any other name like "audit") and upload bitstream to this. This ARCHIVE bundle has no definition or setting anywhere in dSpace. The behavior is like this that only dSpace or collections admins can see it, when click on edit item and tag bitstreams. It's never displayed to anonymous or other users, it isn't on simple or full item view as it is not defined. This works well for as as we have expected.

Best!

Matyas Bajger

Dne 23.02.2026 v 19:48 Julia Gilmore napsal(a):

--
All messages to this mailing list should adhere to the Code of Conduct: https://lyrasis.org/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/b61faf23-a37a-403a-b9da-7b084df6db7fn%40googlegroups.com.