This document compiles the decision making for the technical approach for implementing the comments with restricted visibility feature

### Current state

Comments are implemented as part of journals (`notes` field under the `journals` table). There are rules as to how journals get aggregated which affect comments to some extent. Also, because of comments being part of journals, whenever anything needs to render a list of messages, it needs to query and handle datasets which might include non comment entries in journals.

Additionally there are "message specific implementations" like emoji reactions which are currently implemented associated to journals.

### Challenges for implementing comments with restricted visibility

Specific to restricting visibility of comments there is one larger challenge. The naive implementation would be adding the ability to "restrict visibility" to a journal entry. But, because journals have a _aggregation time window,_ we could compile several changes into the same restricted journal and unintentionally hide events that a user might be allowed to see.

Implementing a solution that makes restricted comments "non aggregatable" increases the burden of the journals table. The impact is not obvious to estimate, but it for sure increases the complexity of the journals table.

### Options to solve

#### 1\. Keep everything in Journals table

The solution consists of adding a new field to the `journals` table to mark journals as restricted and changing the behaviour of the journal aggregation to make sure that "restricted" entries are never aggregations

* Good ✅ : Less time to implement

* Bad ❌: Adds information to the journals table that is not applicable to all journal entries

* Bad ❌: Increases the burden of the journals table


#### 2\. Use a separate table for Messages linked to Journals

Create a new Messages table. Then Begin of the insertionextractEnd of the insertion Begin of the deletion exctactEnd of the deletion from all _work package journal entries_ the notes into Messages (migration). Finally create a 1:1 relationship between messages table and the journal entry allowing to isolate the message specific attributes to the message itself.

_// TO BE DONE: example of how the data model would look like_

_// Plot twist, there are many ways to data model this. Including ways where the messages are not even connected to journals._

* Good ✅: Isolate the data onto it's own table

* Good ✅: Enables future development around the concept of messages, in a less tied manner to journals

* Neutral 💬: Doesn't affect the burden on the journals table

* Neutral 💬: Does not take into account existing implementation like emoji reactions

* Bad ❌: Takes longer time to implement (not sure yet how much, though)


## Additional Notes

Currently there are a few places that care about rendering comments in the context of a timeline/journal:

* Activity tab

* Project activity - e.g. [https://community.openproject.org/projects/communicator-stream/activity](https://community.openproject.org/projects/communicator-stream/activity)

* Global activity - Begin of the insertione.g.End of the insertion Begin of the deletion e.v.End of the deletion [https://community.openproject.org/activity](https://community.openproject.org/activity)


There might be others Begin of the insertionunaccountedEnd of the insertion Begin of the deletion unnacountedEnd of the deletion for here...

And there are a few `acts_as_journable` models that use `notes`:

* Work packages

* Wiki pages

* Change sets


There might be others as well, but we do not need (probably) to refactor all of them with messages.