Begin of the insertion##End of the insertion Begin of the deletion #End of the deletion Problem

When organisations structure work in projects they usually have files that belong to that project.

* Many of these files have a longer life cycle as work packages and are relevant to many work packages.
* Some files are relevant to the project but are not linked to any specific work package.

_**Example:** One task could be to sketch a draft and the next task could be to finalize the document. That would make two work packages for one document. After the document is finalized and the last work package is closed, you still want to know where the document is stored, no matter if the project simply continues or even gets archived._

The challenge of this EPIC is to allow all project members access to that shared folder so that everybody has access to either read, write or share all files in that folder. Having the sharing synced boosts productivity and acceptance in the project team. No tedious manual sharing is necessary.

## Current work around

Currently some organizations use the OpenProject module _Documents_ to share files with team members. However, that module lacks usability in many ways:

* Files uploaded to that module are not synced with a Desktop, as it lacks WebDAV etc.
* This leads to the inconvenience that uploading of files needs to be done one by one instead of complete folders.
* Referencing those files from within work packages (as "inputs" or "outputs" of a task) with normal HTML links is a tedious and error prone process. It is not efficiently supported.

Working with the _Documents_ module is OK, when you only want to share a couple of documents that you rarely update. Real work on those files is not practical.

## Begin of the insertionProposedEnd of the insertion Solution Begin of the deletion (WIP)End of the deletion

In OpenProject we allow project admins to choose or create a folder in an external file storage such as _Nextcloud_ per project. The OpenProject project menu will have a menu item called "File storage" (##46242). Clicking that menu item the user leaves OpenProject and will directly open the shared folder in the web interface of the external file storage.

Every time memberships of a OpenProject project change, Begin of the insertion, the system needs to provideEnd of the insertion a Begin of the insertionway to ensure correct permission forEnd of the insertion Begin of the deletion background job gets queued in OpenProject that doesEnd of the deletion the Begin of the insertionproject folder inside the storage:End of the insertion Begin of the deletion following per project:End of the deletion

1. Add permissions for new memberships
2. Remove permissions when memberships are removed

Begin of the insertionIf the storage provider is capable enough, a fully managed solution can be considered. In that case OpenProject can take care of adjusting permissions automatically.

End of the insertion #### New file sharing permissions per project Begin of the deletion (WIP)End of the deletion

Begin of the insertionIn order to allow seamless integration of a _project folder_ with a project, additional projectEnd of the insertion Begin of the deletion OpenProject'sEnd of the deletion permissions Begin of the insertionmight need to be added:End of the insertion Begin of the deletion per projects will get extended with:End of the deletion

* Read files
* Write files
* Create files
* Delete files
* Share files

#### Begin of the deletion Managing sharings in the file storage with a central, artificial user "_OpenProject user"_

On the file storage's side there needs to be an artificial user that can act on behalf of OpenProject. We call that user the "_OpenProject_" user. The _OpenProject_ user will be the one managing permissions on the project folders in the file storage. To allow the _OpenProject user_ to re-share folders and files those need to be shared with the _OpenProject user_ in the first place. To achieve that, every time a project admin sets up a project folder, that folder needs to get directly shared with the _OpenProject user_.

During the setup up of the integration of OpenProject with the file storage instance the admin also has to setup the _OpenProject user_ manually and safe its identifier **(Todo: What is the identifier for sharing? A user ID? How does a admin obtain it? Or e-mail?)** in the file storage's settings in OpenProject\_.\_

####End of the deletion Fixing/re-syncing sharing permissions per project

OpenProject and the file storage instance are two independent systems. Network communication between the two can fail for a multitude of reasons. Therefore it is crucial that failed request for sharing Begin of the deletion _LDAP principals_End of the deletion can be triggered anew manually. Begin of the deletion Therefore a button in the project's _File storage_ settings can trigger a new sync request per storage.

## Out of scope

* Enforcing that all files linked from a work package also have to be located in the project's shared folder.

## Implementation chunks

* Folder selector in project's file storage settings
* OAuth for _OpenProject user_ with access token refreshing etc.
* Re-sync button for memberships and permissions in project settings
* Hook into membership changes in OpenProject to trigger re-syncing of memberships of _LDAP principals_ and their permissions on the shared folder.
* **... this list still needs to be completed.**End of the deletion