Clarifications on the space image handling
- Dominant language
- Go
- Stars
- 2.1k
- Forks
- 274
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 106
Description
There seems to be 2 different operations involved: uploading the image and then patch the space to use the uploaded image.
At the moment, only patching the space requires "space admin" privileges.
Checking the server code, it seems that uploading the image is an optional step, and you can technically use any available image, including "public" images already uploaded in the space.
If we assume that the image upload is optional:
* The current permissions seem OK. Anyone with edit permissions on the space could upload files there, but only space admins could setup an image as space image.
* Web's approach of uploading an image and then assign it as space image it's web's decision. Possible issues caused by this decision are up to web to handle.
* It's also web's decision to upload the file inside the hidden ".space" folder.
Following this idea, the expected workflow to set a space image would be:
1. Check the current space image.
2. If the current space image path isn't ".space/image.png" (default image), AND it's inside the special ".space" folder, note the file in order to delete it later (if everything goes right). We don't want to delete the default image, and we don't want to delete files that might be public.
3. Upload the image file. This is uploaded into the special hidden ".space" folder.
4. Patch the space to use the uploaded image as space image.
5. Delete the old space image if needed.
As said, uploading the image (step 3) is optional because clients can set up another existing image as space image. However, from an UX perspective, it might be the easiest option because otherwise the clients would need to show a remote file selector otherwise.
Since this is a client's workflow, there are several issues that the clients (not just web) will need to take care:
* Different permissions for uploading the files and assigning the space image (https://github.com/owncloud/ocis/issues/11794). If patching the space fails, clients should remove the uploaded file.
* Overwriting the previous space image. Need to be careful with the previous point.
* Removing old / unused space images (https://github.com/owncloud/ocis/issues/11821)
In order to show the space image, clients should use contained file id. Right now, web is using the filename and is assuming that the file is inside the ".space" folder, so instead of accessing via file id, it's accessing by path. This works for now because web is the only easy way to setup the space image, but as said above, the file might be in other places.
Contributor guide
Research direction
Review the server code paths for space-image upload and space patch, then compare them with the client workflow described here and linked issues #11794 and #11821. Confirm how contained file IDs, .space paths, permissions, and cleanup are expected to work; done means the project records a decided, testable workflow for clients.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, authorization, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100