Uppy logo upload vue widget

[luistoptal]

Pull request for issue: #376

NOTE: A follow up for this PR implements use of the /tmp folder to store temporary images #2092

This is a pull request for the following functionalities:

• adds uppy uploader to add project logos, with a max height restriction of 60px and max size of 1MB (although it is very unlikely an image of 60px height could reach 1MB size)

How to test?

Local testing:

SETUP

• Run anew the up.sh script as it needs to run docker containers for the vue widget
• Modify the autogenerated file protected/config/yii2/web.php to use the local file system (this file is reset every time the up.sh script is run)

...
        'cloudStore' => [
                   'class' => 'creocoder\flysystem\LocalFilesystem',
                   'path' => '@webroot/files',
                ],
...

• in protected/models/Project.php, modify the following:

  public static function getStorageBasePath()
  {
      return Yii::getAlias('@web') . '/files'; <-- uncomment this line to use the local file system
      // return 'https://' . self::BUCKET; <-- comment this line
  }

NOTE: the above steps need to be done to mock the S3 bucket by the local filesystem. Should be done when running the app locally. I am open to suggestions to improve this flow

NOTE: unless the user is actively developing the vue widget, the build bundle should be used. In file protected/views/adminProject/_form.php I added a $isDev flag that toggles this behavior. If a dev wants to work locally on the vue app, they shoud set it to true. I am open to suggestions to improve this flow.

CREATE

• Navigate to http://gigadb.gigasciencejournal.com/adminProject/create
• you should see the uppy dashboard

• use the uppy dashboard to upload a file:
  • once you add a file to the dashboard, if the file height is larger than 60px, it should automatically open the file editor, giving you the option to crop the image
• crop the file if needed, and click on the "upload" button
  • if you try to upload a file which is too large, you should see an error message popup and the image should not upload
• the image should be successfully uploaded, and you should see a files/dev/images/projects/temp/ folder, with a nested uuid folder which contains the image. You should also see the image showing up in the UI

• fill the new project details and click "create"
• you should be redirected to the view page, looking similar to this
  
• the files/dev/images/projects/temp/ folder should be now empty, and there should be a new folder under files/dev/images/projects/, looking like a uuid, with the logo within. This uuid is deterministically derived from the newly created project id
• in http://gigadb.gigasciencejournal.com/adminProject/admin you should see the new project listed

EDIT

• if you try to edit the project:
  • you should see the image previoulsy uploaded
  • you can upload a new image and see how the thumbnail will change

NOTE: as it is expected the logos are quite small, the image is displayed as is, rather than a thumbnail

NOTE: if you try to save the edits, you will see an error informing that duplicate name or url are not valid, which makes it impossible to just edit an image (without changing name and url). This is an issue that existed in the preexisting implementation, to reduce the scope of this issue, I suggest to create a new one for this (or fix in a separate PR, for the same issue). For testing purposes changing both fields works

• after saving, the files/dev/images/projects should contain, within the same uuid folder, the new file

DELETE

• Navigate to http://gigadb.gigasciencejournal.com/adminProject/admin
• click on the "delete" icon for the new project
• the deleted project should disappear
• the previous uuid folder should have been deleted

How have functionalities been implemented?

• a new Vue 3 project was created in the vite folder
• the Vue app uses vite as bundler
• the app is containerized, relevant config in ops/deployment/docker-compose.yml, services vite-project-image-location-prod and uses a setup similar to the one for the fuw service (js service in the docker compose)
• the Vue app is mounted in protected/views/adminProject/_form.php, in the element with id vue-client_project-image-logo
  • while the vue widget is being mounted, a loading spinner is displayed instead
  • in local dev, the vue app is served in http://localhost:5173 and the main.ts is loaded directly along with vite client
  • in production, the app is bundled as js scripts and loaded as is ((cd vite && npm run build) will create the bundles in js/vite-logo-upload)

More instructions about the build flow and testing scripts in vite/README.md

Upload flow

1. user adds a file to the uppy dashboard
2. user crops the image as needed to fit dimension requirements
3. user clicks on "upload" button
4. API request to actionUploadTempLogo method, that saves the file to a temp folder
5. front receives temp image url and displays the image
6. user fills remaining project data and clicks save
7. API request to actionCreate method: A) first, project is created to get a project id, B) then, logo image is stored in a deterministic path (defined by project id), C) finally, project is updated with image url. Additionally, temp url is deleted

If user replaces the logo image for a project, the old image is deleted

NOTE: if user starts the process of uploading a logo to the point where a temp image is created, and they exit the process (reload page, abandon page, etc), the uploaded image will be left dangling in the temp folder. Generally speaking, an image will exist in the temp folder for a brief time, between uploading image with uppy dashboard and clicking on "save" --> this flow is changed in follow up PR #2092

Any issues with implementation?

• I am unable to test with the S3 bucket as I don't have access to it, S3 should be tested by someone who has access to make sure it works, before going to production

Any changes to automated tests?

Added e2e tests for the logo upload flow in playwright/tests/admin-project-logo-upload.spec.js

testing instructions added to vite/README.md

[luistoptal]

#376 has some interesting comments that should serve to improve this PR

I will apply them

[luistoptal]

@rija as for this comment: #376 (comment)

I think it's better if I implement that in a separate PR, because that is a set of changes I'm not entire sure how it should work, and I want to have it reviewed separately rather than mix with the many changes this PR already has