Content
View differences
Updated by Hagen Mahnke 10 months ago
Requirements for Documents
* Belongs to a project/program/portfolio
* Text
* Types
* Status
* configurable by type
* Comments
* EMOJIS
* Internal
* Assignee
* Notifications
* Watchers
* Hierarchy
* Meetings
* Files
* Templates
* Relations
* To workpackages, projects/portfolios/programs, risks, ....
<br>
<br>
* Documents are created like workpackages within a project
context, they share (most of) the features that a workpackage
has - at least under the hood
* Documents have types that determine their possible fields and
values (like workpackages)
* Document Status
(eg. Draft, In-progress, approved, needs review)
* Project context-sharing: the document is by default shared with project members with certain roles in a project.
* Do not show up in workpackage views/queries
Topics/questions:
* If we're modelling documents as workpackages, how do we exclude documents from showing up in workpackage views/queries?
* Will require lot's of conditionals. Risk/Goals do not have this issue, they show up with workpackages.
* Will documents 'just work' in places where we have workpackages now, such as Notification Center?
* No, BlockNote alone will require extra logic.
* What if we copied workpackages code and create a Document model from that?
* Even if we do it, we will need to do some work to adapt the elements (comments, ....) that make a workpackage so powerful.
* What happens if someone already has a workpackage type called 'Document' and we seed a protected workpackage type called 'Document'?
#######################
**As** a \[enter role of user\]
**I want to** \[enter objective\]
**so that** \[enter desired result\]
**Acceptance criteria**
* <br>
**Technical notes**
* <br>
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* <br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._
* Belongs to a project/program/portfolio
* Text
* Types
* Status
* configurable by type
* Comments
* EMOJIS
* Internal
* Assignee
* Notifications
* Watchers
* Hierarchy
* Meetings
* Files
* Templates
* Relations
* To workpackages, projects/portfolios/programs, risks, ....
<br>
<br>
* Documents are created like workpackages within a project
context, they share (most of) the features that a workpackage
has - at least under the hood
* Documents have types that determine their possible fields and
values (like workpackages)
* Document Status
(eg. Draft, In-progress, approved, needs review)
* Project context-sharing: the document is by default shared with project members with certain roles in a project.
* Do not show up in workpackage views/queries
Topics/questions:
* If we're modelling documents as workpackages, how do we exclude documents from showing up in workpackage views/queries?
* Will documents 'just work' in places where we have workpackages now, such as Notification Center?
* What if we copied workpackages code and create a Document model from that?
* Even if we do it, we will need to do some work to adapt the elements (comments, ....) that make a workpackage so powerful.
#######################
**As** a \[enter role of user\]
**I want to** \[enter objective\]
**so that** \[enter desired result\]
**Acceptance criteria**
* <br>
**Technical notes**
* <br>
**Permissions and visibility considerations**
* _To whom is this feature visible?_
* _When is it not visible?_
**Translation considerations**
* _Key terms and phrases in the key languages_
**Out of scope**
* <br>
_Set the_ **To be informed/consulted teams** _field to include all teams necessary to be informed of the changes._