Getting Started How-To

Homepage Overview

• For example: http://demo.dspacedirect.org/
• Provides a good overview of the basic features DSpace offers:
  • Content Area
    
    • Introductory Text (customizable)
    • Search bar (on this page, searches the entire repository)
    • "Top-level" Community listing (just displays the very top of the hierarchy)
    • Recently Added Items

Communities & Collections

• For a browsing example: https://demo.dspacedirect.org/community-list
• It is important to understand the difference between Communities and Collections.
  
  • Communities only contain Collections (they CANNOT contain Items)
  • Collections only contain Items (works or documents). In other words, you always add an Item to a Collection.
  • Communities are used to "organize" Collections.  Communities can contain other Communities (sub-communities) and Collections (but CANNOT contain Items).
    
    • Often Communities are used to "mirror" the organizational structure within an institution (colleges, departments, research units, etc).
    • Communities can also be used to assign rights to specific groups (for example, giving a department control over their own Community)
• How-To: Create a new Community
  
  • See also the DSpace instructions for creating Communities
  • Login; unless you are a full Administrator in your system, you will likely have limited or no options for creating Communities
  • Navigate to the administrative sidebar menu on the lefthand side
  • Click the "+ New" icon and then "Community" - you can create a new top-level community or search for and create a new sub-community within an existing Community from this pop-up menu.
  • Community-level metadata (only the "Name" is required, as demonstrated by the *) - Any of this information can be edited/changed at a later time: 
    
    • Logo: Optionally, a Community can have its own logo.
    • Name*: the name of the Community (REQUIRED)
    • Short Description: A short "blurb" about this community (only displayed during search/browse as a very basic description)
    • Introductory text:  A longer description about the Community displayed on its homepage (may include basic HTML if you want to add formatting, e.g. bold text, hyperlinks, etc.)
    • Copyright text: If this Community needs a special note regarding copyright, one can be added (may include basic HTML). For example, if all works in this Community are copyrighted by a particular publisher/department, that can be noted here.
    • News: Optional news section that will be displayed below the introductory text.
  • Click "Save"
  • Once created, you are immediately moved to the new Community page. You can click on "Edit this community" from the pencil icon in the right corner of the screen, so that you can assign roles, provide access controls, etc.
    
    • For Communities, the only "Role" is Administrator.  An "Administrator" has full rights (add/update/delete) on this Community and any Sub-Communities, Collections, or Items that are contained within the hierarchy under this Community.
• How-To: Create a new Collection
  
  • See also the DSpace instructions for creating Collections
  • Click the "+ New" icon and then "Collection." You can search for and select an existing Collection if you're creating a Sub-Collection or just select "New collection."
  • After selecting a Community, you will be taken to the "Create a Collection for Community <Community Name>" screen
    • There is a breadcrumb trail at the top of the screen to remind you about your hierarchical context
  • Collection-level metadata is nearly identical to the fields available for Community metadata, with one addition:
    
    • License: If this Collection requires its own custom deposit license (i.e. it needs to be different from the site-wide deposit license), you can enter that license text here. It will be displayed during the deposit process instead of the normal deposit license.
  • Click "Save"
  • Again, once created, you are immediately moved to the new Collection, where you can click on the Edit button (pencil icon) to assign roles, map items from other collections, set up access controls, etc.
    
    • Assign Roles: Collections offer additional Roles (all are optional):
      
      • Administrators - people who have full rights (add/update/delete) on this Collection and any Items contained in this Collection
      • Submitters - people who can deposit new content to this Collection
      • Default item read access - people who can view metadata about any new content added to this Collection (not retroactive - changing this does NOT automatically change view rights on existing items in the Collection). DSpace defaults to Anonymous/anybody can view
      • Default bitstream read access - people who can view/download files (bitstreams) added to this Collection (again, changes to this role are NOT retroactive). DSpace defaults to Anonymous/anybody can download
      • Reviewer roles: There are three roles available for reviewing newly deposited content before it becomes publicly available. All are optional.  If you enable multiple steps, they will always occur in the order that they are listed here (and people added to that step will receive an email whenever new content is added that needs review)
        
        1. Review: Accept / Reject step
        2. Editor: Accept / Reject / Edit Metadata step
        3. Final editor: Edit Metadata step (cannot reject)
    • TIP: start with the smallest number of roles possible and only add if and when needed by your workflows!
    • Content Source:
      
      • Optionally, a Collection can be setup to "harvest" all of its content from an external location (via OAI-PMH and/or OAI-ORE).  This is typically used when your DSpace repository is aggregating content from other locations. 
    • Curate:
      
      • This tab offers some basic "curation" / reporting scripts that can be run across your content from the staff interface. Use caution on this screen; we recommend contacting your Hosting support team if you want to run scripts across all your content in your DSpaceDirect site. 
        
        • Profile Bitstream Formats : Report what file formats are contained in Items within this Community/Collection
        • Check for Required Metadata : Double check all Item metadata, ensuring all required fields are filled out.
        • Check Links in Metadata : Double check all URLs in Item metadata, ensuring all links are still valid (and none throw a 404 Not Found error)
•  How-To: Hide a Community or Collection from Public View/Restrict Access to an Existing Community/Collection

  • By default, Communities/Collections always appear in Browse by Community/Collection. However, you can access restrict a Collection to Administrators, so no one else can access the Collection homepage, etc. We have an example at https://demo.dspacedirect.org/handle/10673/337 (must be logged in with an administrator account to see this page)

  • To create a Collection only visible to Administrators, you'll need to edit the Policies on the Collection

    • See also the DSpace instructions for Editing a Collection or Editing a Community

    • Click "Edit" - "Collection" or "Edit" - "Community"

    • Click "Authorizations" and then click "Edit Policy" for an existing policy or click "Add" to create a new policy 

    • You can add/revise a name and add a description for the policy, but these fields are not required. Policy type (Submission, Workflow, Inherited, or Custom) and action type (read, write, remove, admin, delete, withdrawn_read, default_bitstream_read, default_item_read) are both required with dropdown selection options as listed here. For example, you might choose a Custom Policy Type with Read action. 

    • Make sure you have "Search for a group" selected (instead of "Search for an ePerson") and type "Administrator" in the search bar. After hitting the "search" button, the screen will reload with the group(s) meeting your search criteria; you will be able to hit Select for the "Administrator" group and then click on Save.

    • You can make sure you correctly set your policies by copying and pasting the Community or Collection handle to an incognito browser window. You should get a "No item found" message, rather than seeing the Community's or Collection's metadata.
  • NOTE: This change is NOT retroactive to existing items in a Community or Collection. To restrict access to Items within an existing Community or Collection, follow the steps above and then follow the steps described elsewhere on this page for "Bulk/Batch Permissions Changes (Advanced)"

Adding/Submitting Items

• Items are what you and your users will be working with the most after setting up Communities and Collections.  Items contain metadata and, optionally, bitstreams (or files).
• There are two ways to submit an Item to a Collection:
  
  • From your "Submissions" page when logged in and navigating to "My DSpace"–you can upload a file on this screen or click the + icon next to the Drag & Drop option to start the submission process. The system will bring up the pop-up search for the Collection to which you wish to add an Item.
  • OR, click the + icon in the lefthand sidebar menu and select New --> Item. Again, the pop-up search menu will appear asking you to indicate in which Collection you wish to deposit your Item.
  • You will see results for Collections to which you are eligible to add Items. (Administrators will see all results.)
• How-To: Submit an Item
  
  • See also the DSpace instructions for adding Items
  • Note that you can save for later OR deposit at any time during the submission process. You will see all Items you've submitted in the "My DSpace" area; items that you've saved for later will have an option to Edit.
  • You do not have to attach files, or bitstreams, as part of the submission process.
  • For screenshots of the submission screen, see Submission Process and Default Metadata Fields
  • The only required fields for depositing an Item are Title, Date of Issue, and Type (a dropdown menu listing record/format types, such as article, book chapter, data set, etc.).
  • There are several other optional fields you can fill in that will make your Item more discoverable.
  • As a Lyrasis Hosting Services client, you can ask that the metadata fields available for submissions be changed; this may be for an additional fee. Contact digitalservices@lyrasis.org if you are interested in pursuing this option.
  • You can decide to delay making an Item discoverable, such as through an embargo or only making it available to administrators. If you select an access condition type that is NOT openaccess or administrator, you will need to provide date(s) from/until an Item can be made available, depending on the type you select. 
    • If you uncheck the "Discoverable" checkbox, remember that your Item will only be available via the direct link.
    • Administrators will be able to see everything, including Items with embargoes.
  • You must confirm the Deposit license in order to proceed with depositing.
    • NOTE: An electronically-signed copy of the deposit license is stored within the deposited item.  (The copy is "signed" with the name of the user who agreed to the license & the date).
  • After clicking the +Deposit, you will be taken to your "MyDSpace" page, where you will see your deposited Item at the top of your "My Submissions list." 
    • Depending on what workflows, if any, have been enabled for the Collection in which you're depositing, you might see your Item labeled "Workflow." This means the Item has been deposited but is not yet publicly available and will need to go through one or more approval workflows.
      • You might also see your Item labeled "Validation," meaning that it is in the middle of an approval workflow.
    • If you have submitted to a Collection that has no approval workflows in place, your Item will be immediately submitted and you will see a label of "Archived."

Editing Items

• How-To: Editing an Item
  
  • See also the DSpace instructions for editing Items
  • There are two ways to navigate to an Item to be edited:
    • Use the sidebar administration menu to click Edit → Item → search for the Item (this option will immediately bring you into Edit Mode)
    • Search or browse for the Item and click the Edit button
    • Note: if you don't have full administrator privileges, you will see Items when searching, but if you try to edit something for which you don't have permission, you will get an error message
  • "Item Status" tab
    
    • Basic information about the Item in question, with buttons linking to other screens where you can perform actions:
      • "Authorizations" - Edits the permissions on this Item. (Not recommended to tweak from this screen unless you know what you are doing; you can click on the "Authorizations" button to discover what kind of access policies exist for the Item and for its bundle, e.g. if a bundle has an embargo on it)
      • "Mapped collections" - This will show if the Item has been mapped to another Collection in your repository and allow you to either map or remove mappings. More information about mapping Items is available in the DSpace wiki
      • "Withdraw this item" - Immediately withdraws the Item.  Withdrawing essentially hides the item and temporarily removes it from the DSpace archive. However, the item still exists, and can be restored by "reinstating" it
      • "Make it non-discoverable..." - This will stop an Item from being browsable or searchable; it will only be accessible via direct link
      • "Move this Item to a different Collection" - This takes you to a search screen where you can look for the other Collection to which you wish to move the item. There is a checkbox to "Inherit policies" if you wish the Item to inherit the destination Collection's default policies
      • "Permanently Delete" - Immediately deletes the Item. As noted, this is a permanent action and cannot be undone. The item is fully removed from the system.
  • "Bitstreams" tab
    
    • Allows you to add/remove Bitstreams (files) to/from the Item
    • You can also reorder Bitstreams, if multiple exist.  This lets you determine which bitstream is listed first on the Item page.
    • A note about Bundles: In DSpace, bitstreams (files) are kept in "Bundles" (essentially just groups of files).  There are three main Bundles which DSpace handles automatically:
      • ORIGINAL : These are files which were uploaded when the Item was created/deposited.  These are also the files that are available for download/viewing within DSpace.
      • LICENSE: This is a "hidden" bundle which stores an electronically signed copy of the deposit license (which was signed when the Item was deposited).  It is only viewable to Administrators.
      • THUMBNAIL : If one (or more) of the files in the "ORIGINAL" bundle were images (BMP, GIF, JPEG, PNG), then DSpace will automatically generate a Thumbnail version for display. The auto-generated thumbnail is stored in this Bundle. Note that thumbnails are generated via a service that runs overnight, so thumbnails will not appear until the following day (i.e. allow for up to a 24-hour time period to elapse before thumbnails may be generated and available).
      • TEXT : If one (or more) of the files in the "ORIGINAL" bundle were common textual formats (HTML, Word, PowerPoint, PDF, Plain Text), then DSpace will automatically generate a plain text version of the document (for its search within document feature). The auto-generated plain text file is stored in this Bundle.
  • "Metadata" tab
    
    • Allows you to directly edit each field of Qualified Dublin Core metadata associated with this Item.
    • BE CAREFUL. It is assumed you know what you are doing. Metadata changes here are not validated in any way. So, anything you save will be accepted as-is.
    • You'll also notice here that there are several hidden metadata fields that are automatically generated/updated by DSpace (such as "dc.description.provenance" and "dc.date.accessioned")
  • "Curate" tab
    
    • Similar to Communities & Collections, you can also run basic "curation" / reporting scripts on individual Items. Again, be careful; if you have a script you would like to run, feel free to reach out to dspacedirect@lyrasis.org for help.
  • "Relationships" - this tab does not currently function in DSpaceDirect
  • "Version History"
    • If there are different versions of the Item available, metadata will appear here. More information about item versioning is available at the DSpace wiki
  • "Access Control"
    • Allows you to update access policies for the Item's metadata and/or bitstreams
  • "Collection Mapper" takes you to the same screen that "Mapped collections" under the "Status" tab takes you to.

Managing Permissions (EPeople & Groups)

• Under the "Administrative" menu, there are tools to add individual EPeople & Groups (which can then be used in Community or Collection "Roles").
• How-To: Add a New EPerson (logged in as an Administrator)
  • See also the DSpace wiki for information
  • NOTE: Lyrasis does not recommend allowing self-registration, as this will greatly increase the likelihood of your repository being overrun by spam accounts. If you wish to allow self-registration, we will enable reCAPTCHA for your repository. We strongly suggest only allowing accounts from specific, known domains (e.g. the email domain(s) of your institution)
  • Click on the administrative sidebar menu "Access control" -> "People"
    • On the search/browse screen for all EPeople, click the +Add EPerson button
      • Name (First & Last)
      • Email (This will be the user's email address and also their username)
      • Check the "Can log in" box. You can leave the "Requires certificate" box unchecked
      • After clicking Create, the Administrator can inform the individual their account has been created and use the "Forgot password" functionality to set their password OR
  • Administrator: Find the newly created user and click the "Edit" button next to their email
    
    • Press the "Reset Password" button.  An email will now be sent to the user's email address, which lets them setup a password in DSpace. 
  • NOTE: If you are using SAML, LDAP, or Shibboleth with DSpace, new user accounts will be automatically created the first time a user logs into DSpace via SSO.  So, once they login, a DSpace E-Person will be automatically created that is associated with their LDAP/Shibboleth account.
  • Users must be added to Groups in order to do anything in the system
  • Users can discover what Groups they belong to by navigating to the User profile menu/logout at the righthand top of the screen and clicking on "Profile."
    • Scroll to the bottom of the screen to see which Groups you belong to
    • Users can also update profile information from this screen (including adding a contact telephone and preferred language) and change their password
• How-To: Add a New Group (logged in as an Administrator)
  
  • INFO: Groups can be used to manage permissions across several individuals. You can choose to create as many (or as few) groups as you wish to help you manage DSpace permissions. You may only need to create Groups associated with specific Communities and Collections for workflows and access permissions, or you may need to have Groups who span several different Communities
    
    • Synchronizing Groups with LDAP: If you are using LDAP, you can ask Lyrasis to setup a mapping between LDAP Groups (i.e. LDAP Organization Units or "OU") and internal DSpace Groups.  This provides an automated way to "sync" group membership between an external system (LDAP) and DSpace's internal Groups. DSpace does NOT do this mapping automatically. It needs to be configured (by Lyrasis) for specific Groups. This option is not currently available for all SSO configurations.
  • Click on the administrative sidebar menu "Access control" -> "Groups"
    • On the search/browse screen for all Groups, click the +Add group button
      • Group name: Each group needs to have a name. Names can include spaces, so name it something that describes the group. E.g. "Mathematics Department" or "Staff" or similar
      • You can choose to add a Description of the group or not
      • Click save
      • You can now add members to the group. Groups can contain individual EPeople and/or other Groups
        • The search options on this page include metadata keywords
        • You will need to click the + button or the Trash icon to add/remove EPeople or Groups
  • HINT: You will likely notice in the Group listing groups named "COLLECTION_" or "COMMUNITY_".  These groups are internal groups that DSpace creates for different Collection or Community Roles.  They are essentially "special" groups which are directly associated with a particular role in a particular Collection or Community.  (You can edit these "special" groups from this same area of the user interface).
• Once you have created user accounts (E-People) and Groups, you can use those to assign permissions within specific DSpace Communities or Collections (see the "Assign Roles" tab when editing a Community/Collection).
  • In addition, by adding EPeople or Groups to the DSpace "Administrator" group you can give users Site-wide Administrator permissions (add/edit/delete anything in the system).
• You can use the same administrative sidebar Access Control menu to find and edit EPeople and Groups. 
  • NOTE: Searching Groups from this page does NOT search metadata/linked hierarchical information; you must know the Name and/or find the UUID for the Group to find a group to edit. Names generated for workflow/access purposes from a Community or Collection are auto-generated and cannot be edited for a more human-readable version. It may be easier to edit permissions for individual Communities and Collections by navigating to the Community or Collection and editing an associated group from the "Assign Roles" or "Authorizations" tabs.

Usage Statistics

• DSpaceDirect supports two primary types of usage statistics:
  
  • Google Analytics (if enabled) - DSpace can use Google Analytics to track page views/accesses with the system. This is similar to using Google Analytics to tracking any other website. The use of Google Analytics is recommended. Google Analytics more thoroughly weeds out spider and bot activity, resulting in more accurate statistics.
    • If you have not yet asked Lyrasis Hosting to enable Google Analytics on your DSpaceDirect repository but would like to do so, please reach out at dspacedirect@lyrasis.org
    • See also the DSpace wiki for more information about Google Analytics in DSpace
  • DSpace Internal Statistics - DSpace also tracks its own basic Usage, Workflow & Search statistics.
• DSpace Statistics available in the user interface are available site-wide, or on any specific Community, Collection or Item page.  Statistics are context-specific, meaning that based on where you are in the system, you will receive a slightly different statistical report.
  • The statistics provided change depending on this context. For example, statistics for the whole repository will display the top results for Total visits to individual items. At a Community or Collection level, statistics may include top city and country views, total visits per month, as well as total visits to that Community or Collection. Item statistics will provide number of views for files.
• If you would not like these statistics to display publicly, contact dspacedirect@lyrasis.org and let us know.
• Tip: View Total Number of Items in a Repository
  • The total number of items in the repository is most easily found by navigating to Browse by Title, as title is a required field.
• Unavailable currently: View the Number of Items Added in a Year
  • Unfortunately, the built-in DSpace statistics and Google Analytics do not list this data. The easiest way to determine the number of items added in a given time frame is to export the repository metadata to CSV, and look at the dc.date.accessioned in that export. The dc.date.accessioned field is not included by default in metadata exports from DSpaceDirect repositories; please contact dspacedirect@lyrasis.org if you would like to be able to export this field.
    

Bulk/Batch Metadata Editing

• DSpace's "Batch Metadata Editing" tool allows you to export sets of DSpace Item Metadata (all Items or just those in specific Communities/Collections) into a CSV file.  The metadata values/fields in the CSV file can then be edited using Microsoft Excel (or OpenOffice Calc or LibreOffice Calc).  Once editing is complete, you can re-import the modified CSV to apply the metadata changes into DSpace.
• Also see the official DSpace Documentation at Batch Metadata Editing 
• How-To: Batch Metadata Editing basics
  
  • Batch Metadata Editing can be performed at a Community or Collection level
  • Browse to a specific Community or Collection and select Export → Metadata from the administrative sidebar menu (you can also search from the homepage, but again, this pop-up menu is context-specific if you have already navigated to the Community or Collection you wish to work with)
  • Click "Export Metadata."  This will take you to the Processes screen and generate a CSV file that contains all the metadata for every Item within that Community or Collection hierarchy. You'll see a .csv file to download under "Output Files" when the process has completed. A log will also be available to download, which will be a copy of the Process Output available directly from the Process screen in the web interface.

• • Perform your edits. Once finished, re-upload the changes to DSpace by navigating to the administrative sidebar menu and selecting Import → Metadata. The "Validate Only" checkbox will likely be automatically checked; you can choose to uncheck it if you are confident about your changes and just want to directly upload your revised metadata. From this screen you can either drag your csv into upload or you can browse to find your file. DSpaceDirect will again take you to the Process screen and provide you a log of changes (or expected changes, if you kept the "Validate Only" box checked). The log will only be available from the "Process Output" button if you are directly updating Items, rather than only validating your metadata changes.

Bulk/Batch Content Uploads

• DSpace allows you to batch upload content + metadata in a specific Zip package format that DSpace calls the Simple Archive Format.
• How-to: Create an upload package
  • Details about the Simple Archive Format (SAF) are provided in the DSpace documentation at Importing and Exporting Items via Simple Archive Format
  • A SAFBuilder tool is also available that can transform spreadsheets (Excel or CSV) into valid Simple Archive Format (SAF) packages

  • SAFBuilder is a commandline tool, and as such, it requires a few prerequisites to run. These are all listed in the SAFBuilder instructions

    1) Install Java JDK (version 7 or 8). Here's the Java 8 JDK (download a Windows version and install)
    2) Maven should also be installed. This is guide for installing on Windows that may be helpful
    3) Git is optional. You can use it to download SAFBuilder (or just download the Zip of it, as shown below)

    After the above are installed, just download SAFBuilder to any directory, this "installs" it.

  • Another option with a graphical user interface is the SAFCreator tool. The documentation with both of these tools point to other tools that may also be helpful in creating your SAF packages.
• How-to: Upload the SAF package to DSpace
  • Keep in mind that large packages (over several GB in size) may prove difficult to upload via the web. They may timeout during upload or processing. Therefore, with DSpaceDirect, you may wish to consider creating several separate upload packages (and upload them individually) if you have a larger set of content to upload
  • More information about importing via the user interface is available in the DSpace wiki

DSpace Permissions Overview

DSpace has several permission types that are defined in the system:

• ADD: This permission is available only on Collections or Communities. It gives someone the ability to submit/add Items within a Collection, or create/add Collections under a Community.
• DELETE: This permission gives someone the ability to permanently remove/delete an object. Usually only Administrators should be given this permission.
• READ: This permission gives someone the ability to view an object.  For example, READ access on an Item lets someone view the Item's metadata.  READ access on a file (bitstream) lets someone view/download that file. DSpace's default for Items is to allow anonymous (non-signed in) users to read and download.
• WRITE: This permission gives someone the ability to edit/change an object.  For example, WRITE on a Collection lets someone edit/change that Collection's name or description. 
  • Keep in mind, this is different from ADD permission.  Someone who has ADD permission on a Collection but does not have WRITE permission would only be allowed to submit Items to the Collection. They would not be allowed to edit the Collection name or description.

Individual Item Permission Changes

• DSpace allows you to modify the permissions on any Item at any time.  This may be useful if an item needs to be access restricted at a later date, or was accidentally deposited as restricted but needs to be made openly available.
  • NOTE: You can also perform batch/bulk permissions changes (for all Items in a single Collection). More information on that can be found below in the section "Bulk/Batch Permissions Changes (Advanced)"
• How-to: Change Permissions on a single Item
  • See also the DSpace wiki
  • Login to your site as an Administrator
  • Locate the Item whose permissions you wish to change
  • Click "Edit this Item" from the small pencil icon in the upper right corner of the screen
  • On the "Status" tab, click "Authorizations."  This will bring you to a "Policies" page which details the current permissions on this Item.
  • Overview of the "Policies" page:
    • You'll see a listing of all current policies/permissions on the Item, along with all its associated files (called "bitstreams")
      • To modify a policy, click one of the options in the Edit column
        • You can either edit the policy itself, or you can edit the Group to which the policy applies, such as adding sub-Groups or EPeople
      • To add a new policy, click one of the "Add" buttons
      • To remove an existing policy, check the checkbox next to the policy, and click the "Delete Selected" button. 
    • Types of Policies:
      • Item Policies ("Policies for Item ___") - These policies define the permissions on the Item's metadata. In other words, they define who can locate the Item via the DSpace browse & search tools. If the "Item Policies" are limited to a specific Group, then ONLY users who belong to that Group will be able to search/browse to locate that Item.
        • Please note: restricting access to an Item's metadata also means that search engines like Google or Google Scholar will NOT be able to index the Item. That means the Item will NEVER appear in Google or Google Scholar search results.  If you want an Item to appear in Google search results, but do not want everyone to be able to download its file(s), then you should leave the Item policies as unrestricted, while restricting access to individual files (Bitstreams).
      • Bundle Policies ("Policies for Bundle ___") - These policies define permissions across a "Bundle" (loose grouping) of Files.  Bundles in DSpace are mostly "hidden" from users, but they include "ORIGINAL" (the originally uploaded files), "LICENSE" (a copy of any deposit licenses), "TEXT" (optionally, the extracted plain text from originally uploaded files).  Generally speaking, the Bundle permissions here should really just be identical to the permissions you wish to set on the various Files (Bitstreams).
      • Bitstream Policies ("Policies for Bitstream __") - These policies define permissions on individual Files (called Bitstreams).  The "READ" permission lets users view/download the specific files in question. You may have to click on "Show bitstream policies for bundle ____" in order to see these policies.
    • Action types:
      • "READ" permissions gives a single group the ability to view or download the Item
      • "WRITE" permissions gives a single group the ability to edit or modify the Item
    • Start and End Dates:
      • Optionally, individual policies can have a start or end date.  This allows you to set temporary (or expiring) permissions on an Item (e.g. for embargoes).
      • Start Date: Policies will not take affect until the start date has passed
      • End Date: After this date, the specific policy will no longer be in effect. 
      • If there is no Start or End date, the policy is in effect at all times
    • Some Sample Policies:
      • An Item Policy that provides "READ" access for "Anonymous" group.  This policy will allow anyone in the world to access the metadata for this specific Item.  It means that anyone will be able to search/browse for this Item in DSpace (and search engines like Google or Google Scholar will be able to index this Item, so anyone will also be able to find it within Google)
      • An Item Policy that provides "READ" access for only the "On Campus Users" group.  This policy will only allow users who belong to the "On Campus Users" group to browse or search for this Item within DSpace.  This means that all other users will NOT be able to locate this Item within DSpace.  It also means that search engines like Google or Google Scholar will also NOT be able to locate the item (as they will not have access to the Item's metadata).
      • A Bitstream Policy that provides "READ" access for "Anonymous" group. This policy will allow anyone in the world to view or download that particular file (bitstream).  (Please note however that users will be UNABLE to search/browse for the link to the file unless the Item Policy also provides READ access for the Anonymous group.)
      • A Bitstream Policy that provides "READ" access for only the "On Campus Users" group. This policy will only allow users who belong to the "On Campus Users" group to view or download that particular file (bitstream).  (Please note however that users will be UNABLE to search/browse for the link to the file unless the Item Policy also provides READ access for either the "On Campus Users" group OR the "Anonymous" group.)
      • POLICY NOTES: 
        • Administrators can ALWAYS access/edit all Items in the system, no matter what policies are set on the Item or its individual Bitstreams.
        • Policies are always "additive". This means that if you have two Policies, then both permissions are in effect. In other words, a more restrictive policy is always overridden by a less restrictive one (e.g. "READ for Anonymous group" will mean that anyone in the world can view/download the Item, even if there is also a secondary policy stating "READ for 'On Campus Users' group")
    • Some Sample Use Cases:
      • You want an Item to be searchable/browseable publicly and its file(s) to be viewable/downloadable to anyone in the world
        • Set ALL policies to "READ" access for "Anonymous" group
      • You want an Item to be searchable/browseable publicly, but its file(s) should ONLY be viewable/downloadable by members of the "On Campus Users" group
        • Set the Item Policy to be "READ" access for "Anonymous" group
        • Set all Bundle/Bitstream Policies to be "READ" access ONLY for the "On Campus Users" group
      • You want an Item to ONLY be searchable/browseable/downloadable by members of the "On Campus Users" group  (WARNING: In this scenario, the Item will also NEVER appear in Google or Google Scholar as that particular Item is essentially "invisible" to all users except for those in the "On Campus Users" group)
        • Set ALL policies to "READ" access for ONLY the "On Campus Users" group

Bulk/Batch Permissions Changes (Advanced)

• See also the DSpace wiki for information
• DSpace provides an option that allows an Administrative user to perform bulk permissions changes on multiple Items at once.
  • For more information on permissions / policy settings in general, please also refer to the section "Individual Item Permissions Changes" above.
• How-To: Batch Permissions Changes basics
  

  • • Login to your site as an Administrator

    • Under the "Administrative" sidebar menu, click on Access Control → Bulk Access Management

    • You will be taken to a search page where you can perform additional keyword searching and/or filtering to find only those Items for which you wish to change permissions. Each Item has a checkbox next to it; use this to select those Items you wish to update.
    • At the bottom of the screen are the same options to edit metadata and bitstream policies as are available from the "Access Control" tab when editing a Community, Collection, or Item
    • This screen allows you to change the access controls for multiple Items across Communities and Collections, or make changes to a singular Community, Collection, or Item (you may need to revise your searches and filters to get the right items you want to change)

Checking Item Links

BasicLinkChecker

DSpace provides a Basic Link Checker as part of the system Curation Tasks. This can be used for small collections as follows:

• Login as a DSpace Administrator and find the Community, Collection, or Item you wish to check; copy the handle.
• Under the Administrative menu, select Curation Tasks
• Enter the Handle of the Community, Collection, or Item to check
• Select "Check Links in Metadata" in the Task menu and choose Perform.

As noted above, this will work fine for individual items or small collections. Larger collections will likely take too long to run and will result in an error.

Checking with Exported Metadata

Links can be checked by exporting the site metadata and using an external process to verify links. An example of an external process using Google Sheets follows

• First, export the metadata to be checked
  • Login as a DSpace Administrator
  • Select the Community or Collection to be checked
  • In the Context menu select "Export Metadata" and save the resulting CSV file
• Links can be checked using Google Sheets and a simple script
  • Open Google Drive and drag the CSV file into an appropriate folder (this uploads the file)
  • Right-click on the file and select "Open with > Google Sheets"
  • Find the metadata column with links to be checked (often this is dc.identifier.uri[]). You may choose to hide other columns to simplify the view.
  • Select Extensions → AppsScript

  • Replace the default script with this code: 

    function getStatusCodes(urlset){
      if('' == urlset) {
        return '';
      }
      
      var urls = urlset.split("||");  
      var responseCodes = [];
       
      for (var i=0; i<urls.length; i++){
        var responseCode = getStatusCode(urls[i]);
        responseCodes.push(responseCode);
      }
    
      return responseCodes.join();
    }
    
    function getStatusCode(url) {
      var options = {
        'muteHttpExceptions': true,
      };
      
      var response = UrlFetchApp.fetch(url.trim(), options);
      return response.getResponseCode();
    }

    • This code includes two functions. The getStatusCodes function expects an array (list) of URLs to check. The getStatusCode function expects only a single URL. Which of these you use depend on whether the metadata column you need to check has one URL or multiple URLs in each row. If in doubt, use getStatusCodes, as it will work for one or more URLs.

  • Save the script with File → Save
    • You may be asked by Google to provide permissions to access your spreadsheet at this point. You will need to grant these permissions.

  • Back on your Google Sheets file, select an empty column that will be used for script results. On the first row with data (usually row 2) add this to the cell, replacing "Y2" with the cell ID where the URL to be checked can be found, then hitting enter. (This is also where you can choose to use the getStatusCode function rather than getStatusCodes.)

    =getStatusCodes(Y2)

  • The result posted in the cell should provide an HTTP response code. The success code is 200. A code of 404 means the page cannot be found. Other response codes are listed on this RFC website. If something else goes wrong with the request you may see an error listed here.
  • Assuming this works properly for the first row, you can apply the function to all rows by either:
    • Selecting the cell where you placed the function, selecting the small box in the bottom right corner of the cell and dragging it down to all other cells
    • Or, selecting the cell where you placed the function, copying it (Edit → Copy), then selecting all rows in the column and pasting (Edit → Paste). This method works better if the number of rows is large.
  • Once you have a response code (or multiple response codes if there are multiple URLs) in each row you will be able to review the results looking for non-200 codes that may need further investigation.