[#31163] Add private comment activity and permission

[jbk83]

https://community.openproject.org/projects/openproject/work_packages/31163/activity

Use case

When OpenProject is used with end clients, it is necessary to hide certain confidential messages from these clients. For example, messages about the cost of a task or about internal problems.

This feature allows one to write “private notes” and define which roles are allowed to write and see them.

Description Configuration

In the “Roles and permissions” tab, a new setting allow to define which roles are allowed to write and see privates notes.

Front office In the front office, private notes are displayed only for allowed roles with gray backgrounds.

[ulferts]

Hi @jbk83 , thanks for your contribution. I did not yet look into the change in detail. The first thing I noticed is that there are no tests included in the PR which would be a requirement for merging it.

[simon-rohart]

Hello @ulferts,

I work at Picomto and we funded this development. We are happy to be able to share it with the community.

You will find attached some screenshots of how this feature works. We use it daily and do not encounter any bugs.

Settings :

Activities panel:

Batch edition:

API:

Sincerely,

[simon-rohart]

Hello @ulferts Are you interested in this feature?

[wielinde]

@psatyal What is your take on the word "private" in this context? I am asking as I also would love to have personal/private notes at some point that are only visible to me alone and are NEVER visible to anyone else. So, how would one best differentiate by naming the three different concepts?

• normal messages shared with everyone having the rights to see the work package (either by being project member or by having someone sharing the individual work package with me providing certain rights)
• private messages shared with a selected subset of people having the a certain right in the project (as proposed here in this PR). Would "confidential" be a better term?
• personal message that nobody else will ever be able to read, not even the admin (maybe "personal note" could be a term for that as it is not a message/comment)

[psatyal]

Hi @wielinde,

Thanks for drawing my attention to this. My thoughts are similar to yours; the word "private" in the context of OpenProject is ambiguous. A view is "private" (only visible to you) or public (visible to anyone who can access that project); for notes such as these, I think it would have to be abundantly clear to the user what the scope of "private" is for her to be able to use it confidently.

At the moment, we don't have an easy way to handle this a micro-level. We have groups for example, but no easy preview of who is in the group, and we're unable to limit visiblity to certain groups.

Thank you for contributing to extending OpenProject, @simon-rohart. As for if we're interested in this feature, from purely a Product/UX point of view, the idea is indeed interesting (in a helpdesk context for example, to add notes for internal team members that external entities/clients cannot see). However, this would have to be evaluated in a larger context of helpdesk features (of which visibility settings will be a very important party). So I'm unable to say if we're interested in tacking this feature at this time.

[simon-rohart]

Thanks for your answer @psatyal.

Indeed, we use OpenProject with our customers as a kind of helpdesk. That's why we have developed this feature and a second one to manage the visibility of fields (standard and custom) by role. @jbk83 will share it with you soon.

For us, these two features form a coherent whole for this helpdesk use with frequent customers.

[wielinde]

@simon-rohart Yes, confidential/internal comments and confidential/internal fields together make a help desk. Those features would be very cool to have. We will review your PR anyways. The product roadmap is a different topic.

[wielinde]

@simon-rohart I had a quick look through this very relevant PR. Telling from test coverage side it is clear, that it changes a lot of pieces but does not back those changes up with specs. Only API specs were added, which of course does some sort of integration test. However, if we merged that code, we would have a lot of logic/code not covered by specs and our code base would become less maintainable as we don't know what we break when refactoring pieces.

That does not mean that the code is bad. We simply cannot merge it like that. More energy needs to go into this PR before it can get merged.

The product roadmap is a different discussion.

[simon-rohart]

Hey @wielinde ,

No worries, I understand that you need time to analyse it. If you need help, don't hesitate to ask me.

[gaumondp]

I just want to add that this feature (or lack of it, really) is probably the only deal-breaker in our fit-gap analysis. I understand it's not on the roadmap (yet?) but wanted to remind OP team how critical it is.

Gitlab, Youtrack, Monday.com(with add-on) and Easy Redmine are some that I know got those.

Thanks.