Content
View differences
Updated by Kabiru Mwenja about 1 year ago
While implementing ##31163 we discussed
* ##61874
* ##62239
This CODE MAINTENANCE is an outcome of that discussion.
We agree that extracting `Comments` from `Journals` will improve the quality of OpenProject's data model. Reasoning:
* Comments require attributes and associations that other Journals do not require. Having them mixed in one model is a code smell.
* Restricted: true/false
* Emoji reactions
* Comments will in future eventually refer to each other
* Temporal order
* Cross referencing via "Reply"
* Comments might be needed on other objects like
* Threads
* Inline comments of rich text fields like work package description
* Attachments to comments (e.g. inline attachments in texts) shall receive their visibility scope through the visibility of the comment rather than of the "journalized" model (e.g. `WorkPackage`)
* Comments can be restricted in their visibility. This affects the visibility of the (inline) attached files.
**To watch out:**
Currently the Journals "notes" comment field has been misappropriated for "comments" of a Journal, and Journal is used for all sorts of things
* ~~Repository module - TBA by <mention class="mention" data-id="80250" data-type="user" data-text="@Kabiru Mwenja">@Kabiru Mwenja</mention> <mention class="mention" data-id="99165" data-type="user" data-text="@Bruno Pagno">@Bruno Pagno</mention> .... e.g. Git commits journals~~ \*_Repository module uses a dedicated model "Changesets" which have a comments field_
* GitLab & GitHub integration progress updates as comments commits?
Semantically, GitLab & GitHub integration are likely using Journal notes as was the original intent- as metadata for an event/journal. However, we're now at a point that this functionality can be extracted- encapsulated into it's own entity.
**Out of scope**
* Extraction of journal snapshots
* `cause`
* Perfromance optimizations, e.g. materialized view for events (Comments, Snapshots, ...)
* ##61874
* ##62239
This CODE MAINTENANCE is an outcome of that discussion.
We agree that extracting `Comments` from `Journals` will improve the quality of OpenProject's data model. Reasoning:
* Comments require attributes and associations that other Journals do not require. Having them mixed in one model is a code smell.
* Restricted: true/false
* Emoji reactions
* Comments will in future eventually refer to each other
* Temporal order
* Cross referencing via "Reply"
* Comments might be needed on other objects like
* Threads
* Inline comments of rich text fields like work package description
* Attachments to comments (e.g. inline attachments in texts) shall receive their visibility scope through the visibility of the comment rather than of the "journalized" model (e.g. `WorkPackage`)
* Comments can be restricted in their visibility. This affects the visibility of the (inline) attached files.
**To watch out:**
Currently the Journals "notes"
* ~~Repository module -
* GitLab & GitHub integration progress updates as comments
Semantically, GitLab & GitHub integration are likely using Journal notes as was the original intent- as metadata for an event/journal. However, we're now at a point that this functionality can be extracted- encapsulated into it's own entity.
**Out of scope**
* Extraction of journal snapshots
* `cause`
* Perfromance optimizations, e.g. materialized view for events (Comments, Snapshots, ...)