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 extract from all _work package journal entries_ the notes into Messages (migration). Finally create a association relationship between messages table and the work package journal entry allowing to isolate the message specific attributes to the message itself, without requiring messages to always be present on the journal entry. Almost like a 1:1 relationship, but more like 1:0..1

* 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)


#### 3\. Use a separate Comments table independent of journals

Create a new Comments table where new comments are stored (allowing us to make them restricted). DONT MIGRATE historical journal notes yet to support existing uses of `notes` for Begin of the insertionintegrationsEnd of the insertion Begin of the deletion integartionsEnd of the deletion like github/gitlab. Adapt existing services and APIs to aggregate data from both Comments and Journals wherever it makes sense.

* Good ✅: Simplify messages out of the scope of journals

* Good ✅: Enable future development around the concept of comments

* Good ✅: Reduces the burden on the journals table

* Neutral 💬: Increases complexity of Activities slightly Begin of the insertion

* Bad ❌: Postpones the harmonization of notes leading to increased complexity throughout the application as parts will continue to use `notes` while other parts will work on `comments` End of the insertion


## 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 - e.g. [https://community.openproject.org/activity](https://community.openproject.org/activity)


There might be others unaccounted for here...

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

* Work packages

* Wiki pages

* Begin of the insertionchangesets

* [https://github.com/opf/openproject/blob/dev/app/models/changeset.rb#L238](https://github.com/opf/openproject/blob/dev/app/models/changeset.rb#L238)

* [https://github.com/opf/openproject/blob/dev/app/models/changeset.rb#L280](https://github.com/opf/openproject/blob/dev/app/models/changeset.rb#L280)


End of the insertion Begin of the deletion ~~changesets~~ (changesets don't use journals)


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