• Refactor DepositController.uploadDraftFiles method to delegate the all the action to the DepositFileUploader.
  The method should look like

uploadDraftFiles = async (record, files, { store }) => {
    const recordSerializer = store.config.recordSerializer;
    const payload = recordSerializer.serialize(record);
    if (!this.draftAlreadyCreated(payload)) {
      this.createDraft(payload, { store });
    }
    for (const file of files) {
      this.fileUploader.upload(file, { store });
    }
  };

then the corresponding DepositFileUploader methods should be created

• initializeUpload

initializeUpload = async (files, {store}) => {
  store.dispatch({
      type: 'FILE_UPLOAD_INITIATE',
      payload: { fileName: file.name, size: file.size },
    });
   const resp = await this.apiClient.initializeUpload(files)
   // TODO: update state with response
}

• startUpload

startUpload = async (file, {store}) => {
  store.dispatch({
      type: 'FILE_UPLOAD_EXECUTE',
      payload: { fileName: file.name },
    });
   const resp = await this.apiClient.startUpload(file)
   // TODO: update state with response
}

• completeUpload

completeUpload = async (file, {store}) => {
  store.dispatch({
      type: 'FILE_UPLOAD_COMPLETE',
      payload: { fileName: file.name },
    });
   const resp = await this.apiClient.completeUpload(file)
   // TODO: update state with response
}

• upload

upload = async (file, {store}) => {
  this.initializeUpload(file)
  this.startUpload(file)
  this.completeUpload(file)
}

• Configure upload endpoint from the backend e.g response will return a link with the upload url
• Make request to invenio to initialize an upload e.g POST /api/records/12345-aaaaa/draft/files

Request Payload

POST /api/records/12345-aaaaa/draft/files HTTP/1.1
[
  {
    # Required
    "key": "article.pdf",

    # Optional
    "checksum": "md5:abcdef...",
    "size": 2048,  # 2kB
    "metadata": {
      "description": "Published article PDF.",
    },
  }
]

Response payload

HTTP/1.1 201 OK

{
  "entries": [
    {
      "id": "...",
      "created": "2020-11-15T19:04:22",
      "updated": "2020-11-15T19:04:22",
      "key": "article.pdf",

      "checksum": "md5:abcdef...",
      "size": 2048,
      "metadata": {
        "description": "Published article PDF.",
      },

      "links": {
        # To be used for the actual file "transmission"
        "upload": {
          "href": "/api/records/12345-aaaaa/draft/files/article.pdf/upload",
          "method": "PUT"
        }
        "self": "/api/records/12345-aaaaa/draft/files/article.pdf",
      }
    },
  ],
}

• Make a request to start the file uploading e.g PUT /records/:id/draft/files/:key/upload
  Request payload

PUT /api/records/12345-aaaaa/draft/files/article.pdf/upload HTTP/1.1
<...article.pdf raw bytes..>

Response payload

HTTP/1.1 201 OK

# Might slightly change to return a Files-REST response
{
  "mimetype": "application/zip",
  "checksum": "md5:2942bfabb3d05332b66eb128e0842cff",
  "size": 13264,
}

• Make a request to finalize the file uploading e.g POST /records/:id/draft/files/:key/commit

Request payload

POST /api/records/12345-aaaaa/draft/files/article.pdf HTTP/1.1

Response payload

HTTP/1.1 200 OK

{
  "id": "...",
  "created": "2020-11-15T19:04:22",
  "updated": "2020-11-15T19:04:22",
  "key": "article.pdf",

  "checksum": "md5:abcdef...",
  "size": 2048,
  "metadata": {
    "description": "Published article PDF.",
  },

  "links": {
    "self": "/api/records/12345-aaaaa/draft/files/article.pdf",
  }
}

Implement a upload flow when an exteral storage is used e.g S3 (M/L)

• On upload the client should make an initial request to Invenio.
• Retrieve the external url to upload and initialize the upload process.
• On completion, the client should make another request to Invenio for setting the upload as complete.

We are going to have to implement the deposit page form fields. Starting from this mockup

but simplifying things as much as we can for this first pass. Goal is to just get a sense for integration and get minimum viable form field in each case.

• title
• Creators + Contributors
• Resource type
• Subjects #7
• Description #8
• Language #9
• Publication Date #10
• License #11
• Dates #12
• Version #13
  (- [ ] Publisher #14 (not in the backend so can ignore for now))
• Related Work #15
• References #15
• Awards #16
• Funding #16
• DOI #17
• Location #20
• TODO: add any other missing

• The user should be able to select from the uploaded files the one that wants to be the default previewable in the record's landing page
• Make request to the backend to persist the select file for default Preview

• Configure file deletion endpoint from the backend
• Request file deletion

(extracted from #22 - this deals solely with the UI/looks)

Package version (if known): 0.12.X

Describe the bug

• AccordionField's warning sign is missing left padding. It should be inside the blue rectangle, not on the edge.
• Error texts should be in red

Make sure all potential errors during the upload process are being handled and appropriate cleanup is done.

See #4

Data Model Question: (implications extend beyond just frontend and into backend)

Can this field be repeatable? If the record contains multiple publishers. This came up from librarians on our side: we have 105 deposits with multiple publishers (only 1.4% of our collection).

• From Carlos: While publishing a record using the deposits UI, there are not specific error messages from required information. For example if the license type is missing and the resource type, the error message is the following one: The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.
  however in the uwsgi.logs you can see marshmallow.exceptions.ValidationError: {'access_right': ['Missing data for required field.'], 'resource_type': ['Missing data for required field.']}

Package version (if known): 0.7.8

It would be nice to have a bigger description text area field by default. By default, there is only 1 line worth of space.

Screenshots (if applicable)

When an entry is added to an ArrayField. The UI goes from (for example):

to:

I see 2 possibilities:

1. Accommodate for the size of the "x" button beforehand so that clicking "Add entry" only reveals it
2. Keep the display as it is now and when "Add entry" is clicked only shrink enough to accommodate the "x" button.

This is related to making sure each of our Field component is implemented similarly so that styling and spacing affects them similarly.

We should feed the UI components as much as we can with the same objects/fields (i.e schema) that we receive from the API response. This will make easier the understanding of the data format that the components are expecting and might decomplexify the debugging of issues in the future.

Package version (if known): 0.7.8

Describe the bug

The "Related Work" field (internally related identifiers) says "add related identifier" and then on the record landing page also says "Related Identifiers", but the field label is "Related work". The wording should be consistent everywhere.

Screenshots (if applicable)

Upload page

Record page

Creators and Contributors that are people can have an affiliation. This task is about adding (back) the frontend component for it.

Package version (if known): 0.7.8

Describe the bug

• Fix additional description typo (https://github.com/inveniosoftware/react-invenio-deposit/blob/master/src/lib/components/AdditionalDescriptionsField.js#L34)
• Make the [x] button look like other ArrayField close button
• Make clicking anywhere on the [x] button delete the entry (this applies to all other ArrayField close buttons too). Right now the onClick callback is assigned to the x icon.

Screenshots (if applicable)

Sub of #4 for creators + contributors field

This is the component side of the issue about revisiting the FundingField inveniosoftware/invenio-rdm-records#264 .

It also depends on the more general task of creating an API backend backed field: #82

When you submit a new draft without a titles entry then the error you get back from the request response has the shape:

"errors" : [
  {
    "parents": [], 
    "field": "titles", 
    "message": "Missing data for required field."
  },
  ...
]

Currently the TitlesField component is displaying only errors in the format titles.{index}.title thus the above errors are not handled correctly.

See #4

Data Model Question:

Can this field be repeatable? If the record contains multiple languages the https://en.wikipedia.org/wiki/ISO_639-3 code mul can be used but it doesn't specify which languages. This came up from librarians on our side.

EDIT
Yes, multiple languages are supported.

We are getting warnings in the frontend, about using null as an initial value for some form elements. This is because we do want null in the formik initialValues as a way to differentiate fields that change when we submit to the backend (formik touches all fields when it validates so we can't use touched) and if we did use "" we would have no way of differentiating with a user inputting an empty string (or more realistically deleting some text ... unless there is a way to compare initialValue with values...)

The functionality works though, but fixing the warnings is probably a good idea.

See #4 (grouped functionality so together)

• Test serialize method
• Test deserialize method
• Test removeEmptyValues method

• UI should enable/disable the file uploading based on configuration

See #4

PRs:

• license vocabulary (inveniosoftware/invenio-rdm-records#279)
• create LicenseField in react-invenio-deposit (#90)
• add LicenseField to invenio-app-rdm's RDMDepositForm (pending)

• When a record is marked as "Metadata only", the UI should disable the upload area or show a label instead. See #91 for decided view.

Check the final mockups in #91 and implement the different views.

Note: needed backend might not be there but we can implement all the views even as placeholders!

Style file uploader views

• Style uploader when no file metadata exist
• Style uploader when the record is marked as metadata only
• Style uploader when file metadata exist on a draft record
• Style uploader when a file upload is in progress on a draft record
• Style uploader file list view on a published record

See #4

See #4

The file uploader holds a redux state with the current uploaded/ongoing files. This state should remain intact and the files representation from/to the backend should be handled centrally e.g de/serializer props.

See #4

See #4

The top-level form fields have the same font characteristics as the sub fields. This makes it especially hard to differentiate between top-level required fields and sub-level required fields (i.e. fields that are required only if filled).

We should make top-level fields visually different somehow.

Not in the mockup, but in the backend. Have something similar to DescriptionsField for internal notes.

Here there is an await: https://github.com/inveniosoftware/react-invenio-deposit/pull/60/files#diff-b5b3deb83dcaa18c58f0a85d23df3e40R51 but there is also in the create function that it calls (

List of mockups

• File uploader - no metadata initial view
• File uploader - metadata only record
• File uploader - metadata initial view (Draft record)
• File uploader - upload in progress (Draft record)
• File uploader - list of files (Published record)

See #4

Awards, keywords and licenses (those are the ones that came to mind) fields all need a way to plug into a backend API to populate options. There should be a common field to achieve this that is then customized/enhanced for each case.

• implement api backed field
• use it for subjects
• use it for licenses
• use it for awards

See #4

See #4 . This one will need to be revisited when we settle on how access is all structured. But it is blocking the record page from rendering and having all components for needed fields covered, so it should be done in a quick simplistic manner first.

A simplistic component is tackled in this issue:

• Open/Public
• Closed/Private
• Embargoed
• Restricted

with no mechanical impact other than badge visibility.

This may be connected to #1 .

React gives a warning about some form elements being uncontrolled and then controlled. Again everything works, but this warning is probably alerting us of an edge case that would be hard to identify otherwise. We should see what can be done to remove this warning.

• User should be able to order e.g by dragging the table rows and define the order that files will persist in the backend

If I recall correctly, @lnielsen wanted to collapse the 2 dropdowns into one. This will make that field take less space and allow us to reuse it elsewhere in the form nicely (see Related Work field).

Describe the solution you'd like

A single dropdown with resource type choices in the form of

<General> / <Subtype>

See #4 . Similar to each other.

• Call the cancel endpoint (most probably the same as the deletion one) DELETE /records/:id/draft/files/:key

From a previous discussion:

If the missing value for a Boolean field (or other) on the backend is True, then when it is set to False on the frontend, the serialization would strip it and the backend not seeing it would set the field back to True... This is actually true for all fields...

It is not enough that we are using PUT in the end.

We need to decide how we deal with empty values on the frontend. Ideally we would do a diff of initialValues and final form.values and use a PATCH... but meanwhile we have to find a compromise that works.

We should test large file uploads e.g 20gb+

See #4 . They are similar to each other and in the same section so might as well do both at the same time. Splitting them.