Page History

...

The Item Level Versioning implementation in DSpace 3.0 builds on following requirements identified by the stakeholders who supported this contribution. : Initial Requirements Analysis

...

Creating a new version of an item

Administrators en and collection/community administrators can create new versions of an item from the Item View page.

...

The Cleanup method has been modified to retain the file if another Bitstream record point to it (the dotted lines in the diagram represent a bitstream deleted in the new version), in other words the file will be deleted only if the Bitstream record processed is the only one to point to the file (count(INTERNAL_ID)=1).

...

DSpace Item Versioning will be encapsulated as an Extensible Service that may be reimplemented by the local repository maintainers to produce alternate versioning behaviors and Identifier Schemes. Versioning Services layer on top of IdentifierServices dedicated to Encoding, Resolution, Minting and Registration of Identifiers for specific DSpace Items and Bitstreams.  It It is through this highly extensible layering of functionality where local developers can alter the versioning behavior and introduce their own local enhancements.  The DSpace Service Manager, based on the Spring Framework, provides the key leverage for this flexibility.

...

The Versioning Service will rely on a generic IdentifierService that is described below for minting and registering any identifiers that are required to track the revision history of the Items.

public interface VersioningService {

    Version createNewVersion(Context c, int itemId);

    Version createNewVersion(Context c, int itemId, String summary);

    void removeVersion(Context c, int versionID);

    void removeVersion(Context c, Item item);

    Version getVersion(Context c, int versionID);

    Version restoreVersion(Context c, int versionID);

    Version restoreVersion(Context c, int versionID, String summary);

    VersionHistory findVersionHistory(Context c, int itemId);

    Version updateVersion(Context c, int itemId, String summary);

    Version getVersion(Context c, Item item);
}

...

1. Resolution: IdentifierService act in a manner similar to the existing HandleManager in DSpace, allowing for resolution of DSpace Items from provided identifiers.
2. Minting: Minting is the act of reserving and returning an identifier that may be used with a specific DSpaceObject.

3. Registering: Registering is the act of recording the existence of a minted identifier with an external persistent resolver service, these services may reside on the local machine (HandleManager) or exist as external services (PURL or DEZID DOI registrations services)

   Code Block
   language java
   public interface IdentifierService { /** * * @param context * @param dso * @param identifier * @return */ String lookup(Context context, DSpaceObject dso, Class<? extends Identifier> identifier); /** * * This will resolve a DSpaceObject based on a provided Identifier. The Service will interrogate the providers in * no particular order and return the first successful result discovered. If no resolution is successful, * the method will return null if no object is found. * * TODO: Verify null is returned. * * @param context * @param identifier * @return * @throws IdentifierNotFoundException * @throws IdentifierNotResolvableException */ DSpaceObject resolve(Context context, String identifier) throws IdentifierNotFoundException, IdentifierNotResolvableException; /** * * Reserves any identifiers necessary based on the capabilities of all providers in the service. * * @param context * @param dso * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void reserve(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * * Used to Reserve a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void reserve(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; /** * * @param context * @param dso * @return * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void register(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * * Used to Register a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @return * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void register(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; /** * Delete (Unbind) all identifiers registered for a specific DSpace item. Identifiers are "unbound" across * all providers in no particular order. * * @param context * @param dso * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void delete(Context context, DSpaceObject dso) throws AuthorizeException, SQLException, IdentifierException; /** * Used to Delete a Specific Identifier (for example a Handle, hdl:1234.5/6) The provider is responsible for * Detecting and Processing the appropriate identifier, all Providers are interrogated, multiple providers * can process the same identifier. * * @param context * @param dso * @param identifier * @throws org.dspace.authorize.AuthorizeException * @throws java.sql.SQLException * @throws IdentifierException */ void delete(Context context, DSpaceObject dso, String identifier) throws AuthorizeException, SQLException, IdentifierException; }

...

Item Level Versioning has a substantial conceptual impact on many DSpace features. Therefor Therefore it has been accepted into DSpace 3.0 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.

...

The version history is added on the bottom of a versioned item page. A repository manager 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. On the other hand, if a repository administrator does decide to expose version history to all users, the name and email address of the editor are exposed as well. This might actually be useful if the editor account is a generic institutional email address, but may conflict with local privacy laws if any personal details are included in this account.

ThereforTherefore, discussion has illustrated that there is a usecase for an intermediate exposure of version history that hides the Editor column.

You can join the discussion or contribute a new code here:
JIRA DS-1349 - Item Level Versioning exposes personal data 

...