Page History
...
| 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 |
...
Disabling Item Level Versioning
By default, Item Level Versioning is enabled in DSpace 7.1. You may choose to disable it by updating this configuration in your local.cfg:
| Code Block |
|---|
versioning.enabled = false |
Additionally, you will need to make the following changes to disable all versioning-related features:
Switch to using the basic "HandleIdentifierProvider" in your
[dspace]/config/spring/api/identifier-services.xml. Make sure to comment out the "VersionedHandleIdentifierProvider" and replace it with this:Code Block <!-- This HandleIdentiferProvider should be used when versioning is disabled --> <bean id="org.dspace.identifier.HandleIdentifierProvider" class="org.dspace.identifier.HandleIdentifierProvider" scope="singleton"> <property name="configurationService" ref="org.dspace.services.ConfigurationService"/> </bean>Remove the "versioning" consumer from the list of default Event Consumers in either your dspace.cfg or local.cfg. Look for this configuration:
Code Block # Remove the "versioning" entry in this list # (NOTE: Your list of consumers may be different based on the features you've enabled) #event.dispatcher.default.consumers = versioning, discovery, eperson # For example: event.dispatcher.default.consumers = discovery, eperson
Once these changes are made, you will need to restart your servlet container (e.g. Tomcat) for the new settings to take effect.
Initial Requirements
The Item Level Versioning implementation builds on following requirements identified by the stakeholders who supported this contribution: Initial Requirements Analysis
...
An overview of the version history, including links to older versions of an item, is available at the bottom of an Item View page. The repository administrator can decide whether the version history should be available to all users or restricted to administrators. Since DSpace 6 the repository administrator can decide whether all users should be able to see the version submitter/editor or if this information is restricted and can be seen by administrators only. As this may expose data that my be considered personal (name and email address of the submitter), we encourage everyone to leave the default setting and reveal those information to administrators onlyBy default, this information is available to all users. Information displayed includes the version number, Submitter/Editor name (only if enabled), date, and summary/description. As necessary, you may change the visibility of this table or the "Editor" column using the "Version History Visibility" configurations below.
Architecture
Versioning model
...
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-sericeservice.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.
...
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 |
|---|
# Setting this to "true" will hide the entire "Version History" table from # all users *except* Administrators versioning.item.history.view.admin=false |
Hide Editor/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 |
|---|
# This property controls whether the name of the submitter/editor
# of a version should be included in the version history of an item.
# Set to "true" to show the submitter to all users who have access to the table.
# Set to "false" to hide the submitter information from everyone except Administrators
versioning.item.history.include.submitter=false |
Allowing submitters to version their items
...
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.
...
version
...
.
...
Overview
Content Tools