Content
View differences
Updated by Dominic Bräunlein over 2 years ago
### Problem and background
Currently, file links get deleted when the target file got moved to the trash bin or deleted permanently.
This behaviour can have a negative impact for the user in case the file got deleted accidentally.
The file links would need to be recreated in all linked work packages after restoring the deleted file from the trash bin.
The current behaviour is event more problematic in SharePoint/OneDrive where we don't differentiate between deleted files and files a user lost permissions to. If a user looses permission to a file and opens the Files tab the file links will be deleted.
This epic covers the different use cases and storages to have a more robust and harmonised user experience.
### Current workflow in detail
1. A file in a storage is linked to a work package
2. The file in the storage gets deleted
3. User opens the **Files** tab in OpenProject
4. File links that are saved in OpenProject are loaded
5. The currently saved file information gets updated (e.g. to update last modified date)
6. To accomplish the update a request to the file storage in the user context is made
7. Through this request we also get the information when a file got deleted
8. When a file got deleted the file link in OpenProject gets deleted too
### Reasons a file link looses it's target
* The permission on a file changed and a OpenProject user lost access to the file
* The file in the file storage got deleted (accidentally or on purpose)
* The file got moved to the trash bin (accidentally or on purpose)
###
### Solutions
#### User lost permissions to a file (High priority)
##### Nextcloud
For Nextcloud storages we disable the file link and show information that the user has no permission
<img class="op-uc-image op-uc-image_inline" style="width:232px;" src="/api/v3/attachments/84730/content">
This is the wanted behaviour and no further changes are needed
##### OneDrive/SharePoint
Currently for OneDrive/SharePoint storages the file links would be deleted when a user accesses the file tabs and has no access to the file.
With the new changes we want the same behaviour as we have currently in Nextcloud. We disable the file link and show information that the user has no permission.
_Technical notes: To replicate the desired behaviour we will need two requests to the storage. One request within the user context to identify what files the user has access to and one with admin access, to see what files exist._
_The difference of both requests would be the files that we disable the corresponding file links and show information that the user has no permission._
#### File got deleted permanently
Currently the file link gets deleted when the file is deleted.
With the new changes the file link should be disabled and the user should be informed that the file link can't be found. Additionally, we let the user decide what should be done with the file link:
**Delete:** The user should be able to remove a file link. This is needed when the file got deleted on purpose and the file link is not needed anymore.
**Relink:** The user should be able to relink a file. This is needed when the user deleted the file accidentally, and permanently, and re-uploaded the file.
Workflow: By clicking the relink button a file picker opens. The user chooses a file and the link is restored.
Here is the current [Figma design for this workflow.](https://www.figma.com/file/gtLQfPe09X7XugAH8L7dTy/File-Storages-Integration?type=design&node-id=5837-92079&mode=design&t=NJTTus1impKCGOtE-0) The design is still **work in progress** and not finalised.
_Note: This workflow needs a single file picker_
**Delete all:** When there are many orphaned file links in it might be helpful have a button that deletes all orphaned file links for a work package. Alternatively the user can select multiple file links and can delete the selected links at once.
#### File got moved to trash bin
Currently the file link gets deleted when the file is deleted.
With the new changes the file link should be disabled and the user should be informed that the file link can't be accessed because the file is in the trash bin. Additionally, we let the user decide what should be done with the file link:
**Delete:** The user should be able to remove a file link. This is needed when the file got moved to the trash bin on purpose and the file link is not needed anymore.
**Restore file:** The UI should provide a link to the corresponding trash bin so the user can restore the file directly in the storage if wanted.
_Note: There was the idea of restoring the file directly from OpenProject but the restoring functionality needs access to an additional API that is expensive to implement and complicated for the admins to set up. <mention class="mention" data-id="51708" data-type="work_package" data-text="#51708">#51708</mention>_
_Technical note: In SharePoint/Nextcloud it is not possible to get file information when the file is in the trash bin. The response is the same as if the file would not exist. But it is possible to get all content of the trash bin via Beta API._
**Note to developers: All features should be behind a feature flag.**
**Proposed scope**
**Step 1 (High priority)**
* Stop auto-deletion of file links.
* When a file got deleted for a file link,
* add an info message that this file can't be found (because deleted or no permission)
* add a remove file link button (on hover)
* other distinct visual feature to recognise its file was deleted without hover.
**Step 2**
* Add a "remove all orphaned file links" action on top of list.
* Show missing permission info for Sharepoint files like on Nextcloud (needs 51713)
* What about OneDrive files, can we see if permission is missing too?
Currently, file links get deleted when the target file got moved to the trash bin or deleted permanently.
This behaviour can have a negative impact for the user in case the file got deleted accidentally.
The file links would need to be recreated in all linked work packages after restoring the deleted file from the trash bin.
The current behaviour is event more problematic in SharePoint/OneDrive where we don't differentiate between deleted files and files a user lost permissions to. If a user looses permission to a file and opens the Files tab the file links will be deleted.
This epic covers the different use cases and storages to have a more robust and harmonised user experience.
### Current workflow in detail
1. A file in a storage is linked to a work package
2. The file in the storage gets deleted
3. User opens the **Files** tab in OpenProject
4. File links that are saved in OpenProject are loaded
5. The currently saved file information gets updated (e.g. to update last modified date)
6. To accomplish the update a request to the file storage in the user context is made
7. Through this request we also get the information when a file got deleted
8. When a file got deleted the file link in OpenProject gets deleted too
### Reasons a file link looses it's target
* The permission on a file changed and a OpenProject user lost access to the file
* The file in the file storage got deleted (accidentally or on purpose)
* The file got moved to the trash bin (accidentally or on purpose)
###
### Solutions
#### User lost permissions to a file (High priority)
##### Nextcloud
For Nextcloud storages we disable the file link and show information that the user has no permission
<img class="op-uc-image op-uc-image_inline" style="width:232px;" src="/api/v3/attachments/84730/content">
This is the wanted behaviour and no further changes are needed
##### OneDrive/SharePoint
Currently for OneDrive/SharePoint storages the file links would be deleted when a user accesses the file tabs and has no access to the file.
With the new changes we want the same behaviour as we have currently in Nextcloud. We disable the file link and show information that the user has no permission.
_Technical notes: To replicate the desired behaviour we will need two requests to the storage. One request within the user context to identify what files the user has access to and one with admin access, to see what files exist._
_The difference of both requests would be the files that we disable the corresponding file links and show information that the user has no permission._
#### File got deleted permanently
Currently the file link gets deleted when the file is deleted.
With the new changes the file link should be disabled and the user should be informed that the file link can't be found. Additionally, we let the user decide what should be done with the file link:
**Delete:** The user should be able to remove a file link. This is needed when the file got deleted on purpose and the file link is not needed anymore.
**Relink:** The user should be able to relink a file. This is needed when the user deleted the file accidentally, and permanently, and re-uploaded the file.
Workflow: By clicking the relink button a file picker opens. The user chooses a file and the link is restored.
Here is the current [Figma design for this workflow.](https://www.figma.com/file/gtLQfPe09X7XugAH8L7dTy/File-Storages-Integration?type=design&node-id=5837-92079&mode=design&t=NJTTus1impKCGOtE-0) The design is still **work in progress** and not finalised.
_Note: This workflow needs a single file picker_
**Delete all:** When there are many orphaned file links in it might be helpful have a button that deletes all orphaned file links for a work package. Alternatively the user can select multiple file links and can delete the selected links at once.
#### File got moved to trash bin
Currently the file link gets deleted when the file is deleted.
With the new changes the file link should be disabled and the user should be informed that the file link can't be accessed because the file is in the trash bin. Additionally, we let the user decide what should be done with the file link:
**Delete:** The user should be able to remove a file link. This is needed when the file got moved to the trash bin on purpose and the file link is not needed anymore.
**Restore file:** The UI should provide a link to the corresponding trash bin so the user can restore the file directly in the storage if wanted.
_Note: There was the idea of restoring the file directly from OpenProject but the restoring functionality needs access to an additional API that is expensive to implement and complicated for the admins to set up. <mention class="mention" data-id="51708" data-type="work_package" data-text="#51708">#51708</mention>_
_Technical note: In SharePoint/Nextcloud it is not possible to get file information when the file is in the trash bin. The response is the same as if the file would not exist. But it is possible to get all content of the trash bin via Beta API._
**Note to developers: All features should be behind a feature flag.**
**Proposed scope**
**Step 1 (High priority)**
* Stop auto-deletion of file links.
* When a file got deleted for a file link,
* add an info message that this file can't be found (because deleted or no permission)
* add a remove file link button (on hover)
* other distinct visual feature to recognise its file was deleted without hover.
**Step 2**
* Add a "remove all orphaned file links" action on top of list.
* Show missing permission info for Sharepoint files like on Nextcloud (needs 51713)
* What about OneDrive files, can we see if permission is missing too?