Content
View differences
Updated by Dominic Bräunlein over 2 years ago
## Problem
When organizations 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 project folder so that everybody has permissions to either read, create, write, delete or share all files in that folder. Having the permissions managed by OpenProject automatically will boost the 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 create for each project a shared folder within a dedicated _Document Library_ in a dedicated _SharePoint Site_.
The OpenProject project menu will have a menu item per connected _SharePoint Document Library_. Clicking that menu item the user leaves OpenProject and will directly open the shared project folder in the web interface of _SharePoint_.
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
#### Reuse of existing file sharing permissions per project
The existing permission per role and project will be respected:
* Read files
* Write files
* Create files
* Delete files
* Share files
Note: SharePoint has only following permission
* Read files
* Write files
#### Fixing/re-syncing sharing permissions per project
OpenProject and _SharePoint_ are two independent systems. Network communication between the two can fail for a multitude of reasons. Therefore it is crucial that failed request for setting permissions will be regularly retried.
**Note to developers: All features should be behind a feature flag.**
When organizations 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 project folder so that everybody has permissions to either read, create, write, delete or share all files in that folder. Having the permissions managed by OpenProject automatically will boost the 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 create for each project a shared folder within a dedicated _Document Library_ in a dedicated _SharePoint Site_.
The OpenProject project menu will have a menu item per connected _SharePoint Document Library_. Clicking that menu item the user leaves OpenProject and will directly open the shared project folder in the web interface of _SharePoint_.
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
#### Reuse of existing file sharing permissions per project
The existing permission per role and project will be respected:
* Read files
* Write files
* Create files
* Delete files
* Share files
Note: SharePoint has only following permission
* Read files
* Write files
#### Fixing/re-syncing sharing permissions per project
OpenProject and _SharePoint_ are two independent systems. Network communication between the two can fail for a multitude of reasons. Therefore it is crucial that failed request for setting permissions will be regularly retried.
**Note to developers: All features should be behind a feature flag.**