Page History
...
Important warnings - read before enabling
Warning | ||
---|---|---|
| ||
If you are using the AIP Backup and Restore functionality to backup / restore / migrate DSpace Content, you must be aware that the "Item Level Versioning" feature is not yet compatible with AIP Backup & Restore. Using them together may result in accidental data loss. Currently the AIPs that DSpace generates only store the latest version of an Item. Therefore, past versions of Items will always be lost when you perform a restore / replace using AIP tools. See DS-1382. |
Warning | ||
---|---|---|
| ||
With version 6 the way DSpace crates Handles for versioned Items was changed. If you want to keep the old behavior of DSpace 4 and 5 you have to enable the |
Enabling Item Level Versioning
By default, Item Level Versioning is disabled in DSpace 3, 4, 5 and 6.
Info |
---|
Starting from DSpace 4.0, Item Level Versioning is also supported in JSPUI. |
Steps for XML UI
If you wish to enable this feature, you just have to uncomment the "Versioning" aspect in your [dspace]/config/xmlui.xconf
file (and restart your servlet container):
Code Block |
---|
<!-- =====================
Item Level Versioning
===================== -->
<!-- To enable Item Level Versioning features, uncomment this aspect. -->
<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" /> |
Steps for JSP UI
If you wish to enable this feature, you just have to edit the versioning.enabled
settings in your [dspace]/config/modules/versioning.cfg
file. Alternatively, you may override it in your local.cfg config (see Configuration Reference).
...
| |
Item versioning is not fully available in DSpace 7.0. While you can view existing item versions, it is not possible to create new versions. Full support for item versioning is scheduled to be restored in a later 7.x release (currently 7.1), see DSpace Release 7.0 Status. |
Warning | ||
---|---|---|
| ||
If you are using the AIP Backup and Restore functionality to backup / restore / migrate DSpace Content, you must be aware that the "Item Level Versioning" feature is not yet compatible with AIP Backup & Restore. Using them together may result in accidental data loss. Currently the AIPs that DSpace generates only store the latest version of an Item. Therefore, past versions of Items will always be lost when you perform a restore / replace using AIP tools. See DS-1382. |
Warning | ||
---|---|---|
| ||
Starting with 6.0, the way DSpace crates Handles for versioned Items was changed. If you want to keep the old behavior of DSpace 4 and 5 you have to enable the |
Enabling Item Level Versioning
By default, Item Level Versioning is disabled in DSpace.
As Item Level versioning is not yet supported in DSpace 7.0, documentation will be coming soon.
Initial Requirements
The Item Level Versioning implementation in DSpace 3.0 builds on following requirements identified by the stakeholders who supported this contribution: Initial Requirements Analysis
...
In DSpace 4 and 5 only the strategy using canonical handles (one handle that always points to the newest version) were implemented. In DSpace 6 the strategy of creating a new handle for each version was implemented. With DSpace 6 this new strategy become the default. The strategy using canonical handle still exists in DSpace but you have to enable the VersionedHandleIdentifierWithCanonicalHandles
in the file [dspace]/config/spring/api/identifier-serice.xml
for each version was implemented. With DSpace 6 versioned DOIs were introduced using the strategy that every new version gets a new DOI (extended by a dot and the version numbers for versions >= 2). To use versioned Handle you have to enable DOIs, you have to use DataCite as registration agency and this new strategy become the default. The strategy using canonical handle still exists in DSpace but you have to enable the VersionedDOIIdentifierProvider
VersionedHandleIdentifierWithCanonicalHandles
in the named configuration file .
You can configure which persistent identifiers should be used by editing following XML configuration file, deployed under your dspace installation directory:
[dspace
_installation_dir]/config/spring/api/identifier
-service.xml
No changes to this file are required to enable Versioning. This file is currently only relevant if you want to keep the identifier strategy from DSpace 4 and 5 or if you want to enable DOIs or even versioned DOIs.
Version History Visibility
By default, all users will be able to see the version history. To ensure that only administrators can see the Version History, enable versioning.item.history.view.admin
in the [dspace]/config/modules/versioning.cfg
OR in your local.cfg
file.
Code Block |
---|
versioning.item.history.view.admin=false |
Allowing submitters to version their items (JSPUI only)
-serice.xml
. With DSpace 6 versioned DOIs were introduced using the strategy that every new version gets a new DOI (extended by a dot and the version numbers for versions >= 2). To use versioned Handle you have to enable DOIs, you have to use DataCite as registration agency and you have to enable the VersionedDOIIdentifierProvider
in the named configuration file.
You can configure which persistent identifiers should be used by editing following XML configuration file, deployed under your dspace installation directory:
[dspace_installation_dir]/config/spring/api/identifier-service.xml
No changes to this file are required to enable Versioning. This file is currently only relevant if you want to keep the identifier strategy from DSpace 4 and 5 or if you want to enable DOIs or even versioned DOIs.
Version History Visibility
By default, all users will be able to see the version history. To ensure that only administrators can see the Version History, enable versioning.item.history.view.admin
in the With DSpace 6.0 it became possible to allow submitters to create new versions of their own items. This currently works in JSPUI only and is switched off by default to keep the same behavior as XMLUI. The new versions are going through the normal workflow process if the collection is configured this way. To allow submitters to create new versions of Item they originally submitted, you have to change the configuration property versioning.submitterCanCreateNewVersion
and set it to true
.It is part of the configuration file [dspace]/config/modules/versioning.cfg
but can be overridden OR in your local.cfg
too.
Identified Challenges & Known Issues in DSpace 4.0
Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefore it has been accepted into DSpace 3.0 as an optional feature and it is still an option feature in DSpace 4.0. Following challenges have been identified in the current implementation. As an early adopter of the Item Level Versioning feature, your input is greatly appreciated on any of these.
Only Administrators and Collection/Community Administrators can add new versions
There is currently no configuration option to allow submitters to create new versions of an item. This functionality is restricted to Administrators and Collection/Community Administrators. In a context where original submission of DSpace items is done by non-administrator users, it might also make sense to allow them to create new versions. Especially given the fact that new versions have to pass through the workflow anyway.
Conceptual compatibility with Embargo
Lifting an embargo currently does not interact with Item Level Versioning. Additional implementation would be required to ensure that lifting an embargo actually creates a new version of the item.
Conceptual compatibility with Item Level Statistics
Both on the level of pageviews and downloads, different versions of an item are treated as different items. As a result, an end user will have the impression that the stats are being "reset" once a new version is installed, because the previous downloads and pageviews are allocated to the previous version.
One possible solution would be to present an end user with aggregated statistics across all viewers, and give administrators the possibility to view statistics per version.
Exposing version history
The version history is added on the bottom of a versioned item page. A repository administrator can either decide to show this to all users, or restrict it to admins only. If it is shown to admins only, an end user will have no way to find the way to an older version. Since DSpace 6 you can also configure if the submitter's name and email address should be part of the version history or if they should be hidden. To show the submitter might actually be useful if the editor account is always a generic institutional email address, but may conflict with local privacy laws if any personal details are included.
Hide Submitter details in version table
In either the [dspace]/config/modules/versioning.cfg
configuration file or your local.cfg
, you can customize the configuration option versioning.item.history.include.submitter
. By default this is set to false, which means that information about the submitter is only viewable by administrators. If you want to expose the submitters information to everyone (which be useful if all submitters uses generic institutional email addresses, but may conflict with local privacy laws if personal details are included) you can set this configuration property to true.
Code Block |
---|
# The property item.history.include.submitter controls whether the name of
# the submitter of a version should be included in the version history of
# an item.
versioning.item.history.include.submitter=false |
Credits
The initial contribution of Item Level Versioning to DSpace 3.0 was implemented by @mire with kind support from:
- MBLWHOI Library
- Woods Hole Oceanographic Institution
- Marine Biology Laboratory, Center for Library and Informatics, History and Philosophy of Science program
- Arizona State University, Center for Biology and Society
- Dryad
...
file.
Code Block |
---|
versioning.item.history.view.admin=false |
Allowing submitters to version their items (JSPUI only)
With DSpace 6.0 it became possible to allow submitters to create new versions of their own items. This currently works in JSPUI only and is switched off by default to keep the same behavior as XMLUI. The new versions are going through the normal workflow process if the collection is configured this way. To allow submitters to create new versions of Item they originally submitted, you have to change the configuration property versioning.submitterCanCreateNewVersion
and set it to true
.It is part of the configuration file [dspace
]/config/modules/versioning.cfg
but can be overridden in your local.cfg
too.
Identified Challenges & Known Issues
Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefore it has been accepted into DSpace as an optional feature. Following challenges have been identified in the current implementation. As an early adopter of the Item Level Versioning feature, your input is greatly appreciated on any of these.
Only Administrators and Collection/Community Administrators can add new versions
There is currently no configuration option to allow submitters to create new versions of an item. This functionality is restricted to Administrators and Collection/Community Administrators. In a context where original submission of DSpace items is done by non-administrator users, it might also make sense to allow them to create new versions. Especially given the fact that new versions have to pass through the workflow anyway.
Conceptual compatibility with Embargo
Lifting an embargo currently does not interact with Item Level Versioning. Additional implementation would be required to ensure that lifting an embargo actually creates a new version of the item.
Conceptual compatibility with Item Level Statistics
Both on the level of pageviews and downloads, different versions of an item are treated as different items. As a result, an end user will have the impression that the stats are being "reset" once a new version is installed, because the previous downloads and pageviews are allocated to the previous version.
One possible solution would be to present an end user with aggregated statistics across all viewers, and give administrators the possibility to view statistics per version.
Exposing version history
The version history is added on the bottom of a versioned item page. A repository administrator can either decide to show this to all users, or restrict it to admins only. If it is shown to admins only, an end user will have no way to find the way to an older version. Since DSpace 6 you can also configure if the submitter's name and email address should be part of the version history or if they should be hidden. To show the submitter might actually be useful if the editor account is always a generic institutional email address, but may conflict with local privacy laws if any personal details are included.
Hide Submitter details in version table
In either the [dspace]/config/modules/versioning.cfg
configuration file or your local.cfg
, you can customize the configuration option versioning.item.history.include.submitter
. By default this is set to false, which means that information about the submitter is only viewable by administrators. If you want to expose the submitters information to everyone (which be useful if all submitters uses generic institutional email addresses, but may conflict with local privacy laws if personal details are included) you can set this configuration property to true.
Code Block |
---|
# The property item.history.include.submitter controls whether the name of
# the submitter of a version should be included in the version history of
# an item.
versioning.item.history.include.submitter=false |