Make space image and readme upload more convinient

[AlexAndBear]

To enhance the efficiency and convenience of managing the .space folder and its associated functionalities, the following improvements are proposed:

1. Ensure the Persistence of the .space Folder: The .space folder should be inherently integral to the system and therefore should not be subject to deletion unless the entire space or drive itself is deleted. This ensures the stability and consistency of the structure. The same applies to the auto-generated markdown file in the .space folder

2. Implement Automatic Patching during Upload: Rather than requiring clients to manually patch the drive (specialFolder) after uploading a space image or readme, the server should handle this task automatically. This can be achieved by introducing parameters such as isSpaceReadme=true or isSpaceImage=true during the upload process. By incorporating this functionality into the upload procedure, unnecessary requests are eliminated, streamlining the process for clients and facilitating easier implementation by other clients.

By adopting these enhancements, we not only optimize the management of the .space folder but also improve the overall integration for other clients. These modifications are designed to be non-disruptive, ensuring compatibility with existing systems while offering significant benefits in terms of efficiency and usability.

cc @kulmann @micbar

[micbar]

@AlexAndBear @kobergj

I think you already implemented some improvements. Can this be closed?

[AlexAndBear]

@micbar none of these has been implemented. This is a follow up after the improvements @kobergj did

[butonic]

• [ ] prevent deleting .space
• [ ] prevent deleting .space/readme.md
• [ ] WebDAV request should check isSpaceReadme=true and isSpaceImage=true query headers to automatically set the file as space readme / image if the path is in the .space folder.
• [ ] if these query parameters are present on a request that tries to upload a file outside of the .space folder we should return a 400 Bad Request

check if this is better covered with the graph api?

[AlexAndBear]

I think setting isSpaceReadme=true is not necessary anymore, if we disable the ability to delete the .space/readme.md file (which is auto generated, when a space is created).

set isSpaceImage=true is still very welcome

[butonic]

hm ... I wonder if it would be easier to just hardcode the space image path to sth like folder.(png|jpg) / space.(png|jpg). Same goes for the space readme. Wouldn't it make more sense to just always display the content of a Readme.md. Not only in the space root but also in subfolders?

When listing drives in the graph api we can populate the ̀ descriptionandspecial.image` properties if those files are present.

The more I look at the .space folder the more I dislike it ...

why even allow configuring the space image as a property of the space? IMO it should be implicit.

🤔

@tbsbdr @micbar @AlexAndBear do you remember why we added the .space folder?

Wouldn't it be nicer to have a Readme.md and folder.(jpg|png) in every folder?

[AlexAndBear]

In every folder? What's the purpose of this ?

Space readme can an should be hardcoded now. For image: can do that as well but I don't know how you might do this because of the different formats.

[butonic]

So you can give subfolders their own Readme / image. Github also renders the Readme in every directory of a repo.

And on my desktop I can also assign a custom folder icon.

[AlexAndBear]

The .space folder is used to store metadata, such as images and readme files, related to the space.

We introduced this hidden .space folder to protect these files from being accidentally deleted by non-technical users who might not know how to restore or recreate them.

There are some issues with your new approach, particularly with using hardcoded image formats (.png, .bmp, .gif, .jpg, etc.):

If multiple images with the same name but different formats are present, it becomes unclear which image should be displayed. While we could default to a preferred file type, this can be difficult to communicate to users.

The user interface includes a convenient feature that allows users to right-click and set an image as the space image. With the .space folder in use, the selected image is copied to the metadata folder. If we were to use the root folder for this purpose, it could require replacing an existing file, potentially leading to unintended data loss if the previous image is overwritten.

Overall, I really like your idea, but implementing it would represent a significant shift. It would require good communication to the users and involve considerable work on the front end.

We possibly could stop the work on this ticket and do refinements with your idea, if this is something we decide we want to have @tbsbdr I really like @butonic 's approach

[2403905]

The @butonic 's approach is looking more generic 👍

[butonic]

The .space folder is used to store metadata, such as images and readme files, related to the space.

anything else? the .space folder was originally intended to allow users to sync the image and readme to edit them on their desktop machines, IIRC.

We introduced this hidden .space folder to protect these files from being accidentally deleted by non-technical users who might not know how to restore or recreate them.

They can always be restored from the trash.

However, there are some issues with the current approach, particularly with using hardcoded image formats (.png, .bmp, .gif, .jpg, etc.):

If multiple images with the same name but different formats are present, it becomes unclear which image should be displayed. While we could default to a preferred file type, this can be difficult to communicate to users.

Stick to two formats or just one ... IIRC windows would show folder.jpg as icons ... which seems to be an interesting feature, as as tons of people are complaining if ms tries to ditch it

We would have to document something anyway. The less options we give the easier it is to document and implement.

The user interface includes a convenient feature that allows users to right-click and set an image as the space image. With the .space folder in use, the selected image is copied to the metadata folder. If we were to use the root folder for this purpose, it would require replacing an existing file, potentially leading to unintended data loss if the previous image is overwritten.

Again, we have revisions. Nothing is lost.

[AlexAndBear]

The @butonic 's approach is looking more generic 👍

It is, but it requires some additional work:

1. Clear communication to users about how to set the image and readme.
2. A method for choosing which image.x to display when multiple options exist (perhaps based on the last modified date).
3. Measures to prevent data loss, such as an overwrite confirmation dialog.
4. Ensuring that the space template is copied to the root folder of the space, rather than the .space folder.
5. Removing any leftover specialFolder elements in web.
6. Adjusting code paths to enable displaying images and readme files not just for spaces but also for regular folders in web.

[AlexAndBear]

anything else? the .space folder was originally intended to allow users to sync the image and readme to edit them on their desktop machines, IIRC.

Nothing else, they could still sync it without the folder and as the feature was implemented, we couldn't store the data elsewhere than on the filesystem

Stick to two formats or just one ... IIRC windows would show folder.jpg as icons ... which seems to be an interesting feature, as as tons of people are complaining if ms tries to ditch it

Big no, we can display gif files, that feature is beloved by many

Again, we have revisions. Nothing is lost.

We have, but please try to focus as well on users, that are not that technical versatile

[tbsbdr]

@tbsbdr schedule meeting to clarify how to proceed

[butonic]

I propose to proceed in two steps:

1. To prevent users from accidentially deleting metadata, deny deletion of the .space folder and the auto-generated markdown file.
2. ADR a generic solution for any space and folder using a README.md (as known from github) and folder.jpg (as known from windows, osx does not seem to support it, linux users can install cover-thumbnailer). We can discuss other file name options in the ADR.

Regarding 1: I remember problems with the oc10 Shares folder being readonly/undeletable and the deskop client trying to sync a local deletion back to the server. @TheOneRing how would the client handle this today? I imagine the VFS could prevent deletion, but sync on linux cannot ... but ... I know nothing ;-)

[tbsbdr]

puh, I dont know what problem we are trying to solve here. could you please rephrase your issue with our bug- or user story template @AlexAndBear ? (if you think this issue still exists)

[AlexAndBear]

I am closing the issue, this should be just an easy enhancement to save some requests and solve some edge cases on top of the improvements @kobergj already did. But since the issue is getting out of our hands and leads to endless discussions: closed