MUST Adjust entry point for authors based on their position in the workflow

[rija]

User story

As an author I want to be land in a appropriate for my workflow So that I don't waste looking for the appropriate stage

Acceptance criteria

Given I am submitting dataset files using File Upload Wizard And the dataset upload status is "UserUploadingData" When I go to my user profile And I click on "upload Files" then I'm presented with the file uploader screen

Given I am submitting dataset files using File Upload Wizard And the dataset upload status is "DataPreparation" When I go to my user profile And I click on "upload Files" then I'm presented with the metadata editor screen

[luistoptal]

@rija I think to complete this task some backend work is involved. To enable the user to replace previously uploaded files and keep the same attributes and description, a frontend button (maybe using uppy) should open a "file upload" window, then a request to the backend should be sent to replace the old file and get the attributes to the old file and write them in the new file in the same or another request

I'm not sure if there is a request that replaces a file in this way. I suppose that since there must be an endpoint that deletes files and another endpoint that creates them, it would be possible to leverage those two endpoints to first get the attributes of a file, then delete it, and then create a new file and give it the same attributes. However I feel like a "replace" endpoint might make more sense.

Incidentally, I'm not sure how the uppy frontend is sending a file to the backend for storage. Is it through the Uppy Tus plugin? I've seen there is a TusdController

[rija]

Hi @luistoptal

yes we use a TUS server to receive the files sent by Uppy.

if in the metadata stage user click a "replace" button, that should open the Uppy screen stage pre-filled with some metadata so that a file a user would drop on the screen will have those metadata associated with it. I don't know if Uppy can do that exactly, I have the feeling it would have that flexibility but I need go through the documentation again.

but that's only part of this ticket work. The other part is to have the metadata screen shown to the returning user if they already have uploaded files, instead of always showing the Uppy uploader first.

Both parts seems to have some backend implications, let me think about it more.

[luistoptal]

Hi @rija

have the metadata screen shown to the returning user if they already have uploaded files

I think this can be easily achieved by passing the uploaded files to the filesUpload component, i.e. in file protected/controllers/authorisedDataset/FilesUploadAction.php:

  $this->getController()->render("filesUpload", array(
   "identifier" => $id, 
   "tusd_path" => Yii::$app->params['dataset_filedrop']['tusd_path'],
   "uploadsCount" => count($uploadedFiles),
    "uploads" => $uploadedFiles, // add this
  ));

And then pass the uploads to the vue component as a prop

As for the replacement function, as it needs to:

• Get the attributes and description of the old file
• Delete the old file
• Upload the new file
• Assign the old description and attributes to the new file

It seems a bit more tricky and wanted to check with you before delving into the backend code

[rija]

Hi @luistoptal,

The FUW workflow is driven by the state machine that's represented by the possible values and transitions of the upload_status property of a Dataset object.

One of the state is DataPending (current name only, It will be renamed to DataPreparation, but it doesn't change the essence of what I'm getting at)

We get into that particular state after the user has already uploaded some files (UserUploadingData), added some metadata and made them available to the curators (DataAvailableForReview), but the curators notice more work need to be done by the authors (DataPending).

I suggest that when the status is UserUploadingData the author is shown the file uploader, and when the status is DataPending (or soon DataPreparation), the author is shown the metadata editor.

• [ ] The implementation of the logic of showing file upload or metadata editor based on upload status is backend work only.

The only related frontend work would be to:

• [ ] Adjust the bread crumbs in file uploader and metadata editor so that it doesn't matter which one is shown first

Regarding the activity of replacing and deleting files, this can only be triggered in the metadata editor, because the file uploader is a dumb fire-and-forget file uploader and is not meant to manage the files on the target destination.

The description of this ticket seems to suggest that each row of the metadata editor should have 2 additional buttons (or their font-awesome/ElementUI) equivalent: replace, and delete

A delete button will send a message to the beanstalkd message queue to be asynchronously picked up by a worker php class that will delete the file in the backend.

• [ ] Placing the delete button and making sure it AJAX calls a specific backend url is the only frontend work

• [ ] The backend work is very similar to that done for fuw/app/backend/models/MoveJob.php in addition to a Yii action to receive the button's AJAX call

The replace button would be more complicated because it assumes connecting a dump file uploader and the storage and have a frontend-backend-frontend communication flow: Somehow after successful deletion (which can take some times if it's the big file and is done asynchronously) the file metadata need to be passed on to Uppy component on the file upload screen and the author to be switched on to the file uploader screen.

I suggest we don't implement it for now. If a file needs to be replaced, authors can delete it first, and then switch to the file uploader to upload the file again.

We could make the replace button to only make AJAX to deletion action and then switch the user to the file uploader screen but if they start to upload immediately when the previous file has not been fully removed yet we may end up with corrupted file, we really don't want that.

@only1chunts, let us know if the above would go in the right direction for you and the authors for implementing this ticket

[only1chunts]

What happens if a user just uploads a file with the same name as one that is already present (i think thats how most people would expect to update an existing file) . Most systems would just popup a box saying "do you want to replace the existing file of that name?" and you click yes.

[rija]

What happens if a user just uploads a file with the same name as one that is already present (i think thats how most people would expect to update an existing file) . Most systems would just popup a box saying "do you want to replace the existing file of that name?" and you click yes.

@only1chunts, at the moment if you upload a file with the same name, the existing one will be overwritten. However the metadata editor will show duplicated entries, and FUW backend will store duplicate entries too. So current state doesn't handle the situation at all (the fact that the file was overwritten is due to implementation details rather than deliberate design)

Having the interaction you describe would require working on both server and frontend to enable the bidirectional communication:

• Add a file server's hook to stop upload and signal files conflicts in its response to the client (backend work)
• Change the file uploader to listen to non successful response from server and retry (or not) for just the problematic file(s) based on user input like a confirmation dialog (frontend work)

[only1chunts]

I'm not getting a feeling for whether thats something that can be done quickly and easily or not? Please suggest the easiest option that you could implement quickly that will enable a user to replace files somehow in the FUW, and describe how that would look/work for a user.

[rija]

MUST. 22:50min. When the author re-visits the file upload tool to make updates to the files they need to be shown the current list of files first NOT the empty box where they can add files! Most updates will involve the authors having to replace existing files, so showing the file list and having a "replace file" button would be most useful as it can keep the same description and attributes.

This ticket is now just about show the appropriate screen, so we've added user story and acceptance criteria, and removed the frontend label.

For the replace file from metadata editor, we've got the new ticket #1704 which has frontend label. For the delete files from metadata editor, we've got the new ticket #1705