Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

An item that is under submission and active edit by an authorized user. The workspace item is visible only to the submitter and the system administrators.  (Currently there is no simple way to find/browse such items other than with the direct item ID or to use the supervisor functionality). Using the supervisor functionality, a system admin can allow other authorized user to see/edit the item in the workspace state.

...

  • Quality control
  • Improvements to the bibliographic record (metadata available in workflow can be different than those asked of the submitter)
  • Check of policy / copyright

 


Withdrawn item

It is the removal of an Item from the archive. However, a withdrawn item is still available to Administrative users (and may optionally be restored to the archive at a later date). A withdrawn item disappears from DSpace (except from Administrative screens) and the item appears to be deleted.

...

  • Staging area for item to be removed when copyright issues arise with publisher. If the copyright issue is confirmed, the item will be permanently deleted or kept in the withdrawn state for future reference.
  • Logical deletion delegated to community/collection admin, where permanent deletion is reserved to system administrators
  • Logical deletion, where permanent deletion is not an option for an organization
  • Removal of an old version of an item, forcing redirect to a new up-to-date version of the item (this use case is not currently implemented out-of-box in DSpace, see )

Private item

...

  • )

By design, withdrawing an item is reversible. As an administrator, you can reverse the withdrawing of an item, through the action "reinstate". As a mechanism to support this, a resource policy state "WITHDRAWN_READ" was introduced.

When as item is withdrawn, all READ policies associated with the item and its underlying bundles and bitstreams, are changed into WITHDRAWN_READ policies. This achieves 2 things:

  1. The READ policy information in itself is still preserved, and can get switched back to normal READ policies if the item gets reinstated.
  2. As long as the item is withdrawn, those WITHDRAWN_READ policies should not give any users or groups read rights. 

WITHDRAWN_READ was introduced in DS-3097 after it was observed that even though an item was withdrawn, the related bitstreams were still accessible. 


Non-Discoverable item (also known as Private item)

A non-discoverable (or "private") item is one that is simply hidden from all search/browse/OAI results, and is therefore only accessible via direct link (or bookmark).

...

  By default, all Items are discoverable, meaning they will appear in search/browse/OAI results.

It's important to clarify that non-discoverable items may or may not be access restricted.  It is possible for an Item to be anonymously visible, but non-discoverable, so that you can only access the item if you are given a link to it.

This state should only refer to the discoverable nature of the item. A non-discoverable (or "private") item will not be included in any system that aims to help users to find items. So it will not appear in:

...

If the metadata of the item should be visible only to a specific group of users, it is possible to define an embargo policy also for the ITEM itself.  A READ policy for a specific group will mean that only the users in that group will be able to access the item splash page. Note that currently only some UIs (JSPUI/XMLUI) are fully the DSpace REST API & UI is fully rights aware (see Discovery documentation for more information, especially the section on "Access Rights Awareness").  This means that in different UIs, some metadata of a restricted item could be exposed to unauthorized users. When you need to work with UIs not fully rights aware, a workaround can be to use the "Private Item" flag to make the item undiscoverable so that metadata will be not exposed to unauthorized users. Please note that this workaround has several major limitations:

  • No one, not ever authorized users,  is able to find the item by browsing or searching the repository.
  • You need to manage externally a schedule that alerts you when the embargo is expired so that you may re-enable the discoverable nature of the item.

 , meaning that an embargoed item is hidden automatically until the embargo expires.