Content
View differences
Updated by Pavel Balashou about 3 years ago
## 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.
## Proposed Solution
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, , the system needs to provide a way to ensure correct permission for the project folder inside the storage:
1. Add permissions for new memberships
2. Remove permissions when memberships are removed
If the storage provider is capable enough, a fully managed solution can be considered. In that case OpenProject can take care of adjusting permissions automatically.
#### New file sharing permissions per project
In order to allow seamless integration of a _project folder_ with a project, additional project permissions might need to be added:
* Read files
* Write files
* Create files
* Delete files
* Share files
#### 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 can be triggered anew manually.
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.
## Proposed Solution
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,
1. Add permissions for new memberships
2. Remove permissions when memberships are removed
If the storage provider is capable enough, a fully managed solution can be considered. In that case OpenProject can take care of adjusting permissions automatically.
#### New file sharing permissions per project
In order to allow seamless integration of a _project folder_ with a project, additional project permissions might need to be added:
* Read files
* Write files
* Create files
* Delete files
* Share files
#### 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 can be triggered anew manually.