Spec

This page describes the specification for the B2SHARE service, describing what the service should provide. Differences to the actual behavior are considered bugs. The specification is also intended to be used as basis of a manual test plan.

1. Web UI

1. Home page

• must contain a search control
• must contain a new deposit control
• must provide options to register/log in (or information on the current user)

2. Register new user page

3. User login page

4. User account page

• must provide a logout option
• must provide a list of all the deposits owned by the current user
• must list the roles of the current user (e.g. domain administrator)

5. New Deposit page

• must provide means of uploading files, selecting domain, and inserting metadata
• access restriction control options:
  • 1. open access: anyone must be able to read the metadata and files
  • 2. embargo until YYYY-MM-DD:HH:MM datetime: hidden record (metadata and files) until the specified datetime; owner and domain administrators must be able to edit the record
  • 3. private deposit: public access to reading metadata; file names and content are private; owner and domain administrators must be able to edit the record
  • the access options must be properly documented

6. View Record page

Depending on the access rights of the record and the identity of the current user, only parts of the following information could be displayed

• must describe all the metadata provided by the user, including the domain
• must show all the files, for each file: its name, size, PID and checksum
• must additionally provide the PID and checksum of the entire record
• must additionally display the owner of the record
• must provide options to export the record into various file formats
  • most important: Dublin Core, (Marc XML - used by B2FIND?)
• must provide a link to editing the record, if the current user has the appropriate rights
• must provide a link to Report Abuse
• when the current user does not have access rights to view the list of files, the page must provide a way to request access to the data from the owner of the record

7. Edit Record page

• must only allow users with the appropriate rights, otherwise displaying an error message
• must allow for editing of any piece of metadata the user inserted at deposit time
• must allow for changing the file names and deleting files

8. Report Abuse page

9. Request Data Access page

10. Search page

• must provide a search bar control and a paginated list of hits for the current query
• a search hit must provide basic information on the record and a one-click-away list of its filenames
• each search hit must link to the View Record page

11. Various documentation pages

---

2. REST API

The REST API must provide the following basic functions:

• paginated list of records, optionally filtered by: domain
• creation of new records, with all the options provided by the web UI
• updating of existing records (depending on the record state and access rights)

The REST API is properly documented here.

The REST API should not allow retrieval or update of information that the UI does not allow. All the access rights must apply.