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):
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
On Tuesday, 15 August 2023 at 23:04:14 UTC-4 Fitchett, Deborah wrote:
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 <tel:+64%203%20423%200358>
[email protected]
ltl.lincoln.ac.nz <http://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."
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dspace-tech/b61faf23-a37a-403a-b9da-7b084df6db7fn%40googlegroups.com
<https://groups.google.com/d/msgid/dspace-tech/b61faf23-a37a-403a-b9da-7b084df6db7fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/dspace-tech/a3944f2a-cd0e-4155-b43f-32a1f740e655%40seznam.cz.
