Project

General

Profile

Actions

Feature #1554

closed

Private comments in tickets

Added by Philippe Lafoucrière over 15 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Category:
Issues
Target version:
Start date:
2008-06-30
Due date:
% Done:

100%

Estimated time:
Resolution:
Fixed

Description

Hi,

private issues would be great, but I'd like to propose a feature taken from Request Tracker (a great tool btw).
In RT3, it's possible for admins of a queue (~= project in redmine) to add comments to a tickets. Comments are different from answers in the way they can be viewed only by admin members.

Therefore, I can use those "hidden" comments to add info on tickets, and sometimes drive my team to the right path. For example, sometimes I just want to make sure they understood correctly, and will only add this very little line at bottom of file to fix the issue.

Having such feature in redmine would be a real advantage for my company.

Thanks,
Philippe


Files

private_messages.patch (9.67 KB) private_messages.patch Used sources from /branches/1.2-stable/ r6484 Dmitry Polovka, 2011-08-20 12:43
20110820092133_add_private_to_journals.rb (204 Bytes) 20110820092133_add_private_to_journals.rb migration which you need to run Dmitry Polovka, 2011-08-20 12:43
private_messages-2011-12-14.patch (11 KB) private_messages-2011-12-14.patch Shaun Gilroy, 2011-12-14 20:25
private_messages-2011-12-14-v1.3.patch (10.4 KB) private_messages-2011-12-14-v1.3.patch Shaun Gilroy, 2011-12-14 23:15
patch_output.txt (1.85 KB) patch_output.txt Pablo Bastari, 2012-01-05 15:10
0001-add-private-messages.patch (12 KB) 0001-add-private-messages.patch Gabriel Pettier, 2012-07-25 18:06
restrict_view_private_messages_in_RSS_and_PDF_formats.patch (2.1 KB) restrict_view_private_messages_in_RSS_and_PDF_formats.patch Andrew Kirillov, 2012-08-30 06:51
revised_view_private_messages_in_RSS_and_PDF_formats.patch (51 KB) revised_view_private_messages_in_RSS_and_PDF_formats.patch Apply after first patch Andrew Kirillov, 2012-12-03 09:07

Related issues

Related to Redmine - Feature #337: Private issuesClosedJean-Philippe Lang

Actions
Related to Redmine - Feature #7412: Add an issue visibility level to each roleClosed2011-01-22

Actions
Related to Redmine - Feature #11829: View Roadmap privilegeNew

Actions
Related to Redmine - Defect #12286: Emails of private notes are sent to watcher users regardless of viewing permissionsClosedJean-Philippe Lang

Actions
Related to Redmine - Feature #1193: Staff-only notes with Role-base access controlNew2008-05-06

Actions
Has duplicate Redmine - Feature #3037: Ability to filter updates in issue historyClosed2009-03-24

Actions
Has duplicate Redmine - Feature #10788: More private posibilitiesClosed

Actions
Actions #1

Updated by Philippe Lafoucrière over 15 years ago

Funny, I can't find the option to add a relation to a ticket when the issue is created, it is a bug ??

This ticket can be related to #337

Actions #2

Updated by Chris Cage about 15 years ago

I'd like to second the desire for this feature. We've been using Bugzilla as our issue tracker some time now. Bugzilla has the ability for private issues and private comments and I can say we use the private comments feature much more (although the private issue feature is helpful as well). Similar to what Philippe mentioned, we use the private comments to create clarification or ask questions internally that we would rather not share with our clients.

This actually has been the main issue causing us to hesitate in migrating to Redmine, although we will still probably jump in soon.

Actions #3

Updated by Simon Stearn about 15 years ago

+1

Actions #4

Updated by Jens Goldhammer almost 15 years ago

+1. This would be very useful.

Actions #5

Updated by Shaun Gilroy almost 15 years ago

We also could really use this functionality. This actually more important than 'private issues'...

Seems to me that this could be handled pretty easily as a plugin... Does anybody know of one that does this?

Actions #6

Updated by Jens Goldhammer almost 15 years ago

JIRA uses a checkbox for marking a comment as private. I think, this would be a first quick hack.

Actions #7

Updated by Szabolcs Klement almost 15 years ago

I make the following changes in app/models/journal.rb:
def notes
orignote=read_attribute(:notes).to_s
if (User.current.allowed_to?(:privnote, project)||self.user.to_s==User.current.to_s)||(aa[0..0]!='/')
orignot
else
"private note!"
end
end

when the first char is '/' then the note value is "private note"
the :privnote is a new permission in lib/redmine.rb:
map.permission :felelos_valasztas, :issues => :felelos_valasztas
But this solution is bad for the mail notification.

Actions #8

Updated by chris madler over 14 years ago

+1
I also think this feature is absolutely necessary for companies that want to keep some notes on issues only visible to staff members and other notes (also) visible to clients.

I suppose it would consist of having a field "visibility" with values (private, public) on each note that is added to an issue. Then in roles, a permission to view certain visibility values (private, public, or both?). Related to #1193.

Actions #9

Updated by Philippe Lafoucrière over 14 years ago

chris madler wrote:

I suppose it would consist of having a field "visibility" with values (private, public) on each note that is added to an issue. Then in roles, a permission to view certain visibility values (private, public, or both?). Related to #1193.

This might be more easy to use than having Comment / Reply models ?
On the other hand, since redmine has automatic notification, it sounds silly to change (=hide) a ticket update after a mail is sent, so the couple Comment(hidden) / Reply(visible) should be considered too.

Thanks !

Actions #10

Updated by Aron Rotteveel about 14 years ago

+1 definately.

This feature would be an awesome addition. Currently we use Redmine for larger projects. Both our developers as customers have access to the issue list and we have entire conversations regarding bugs/features in our applications. It would be great to have private comments that would be visible for only certain users or usergroups. That way we would be able to include internal task assignments in the comments without our customers being notified all the time.

Actions #11

Updated by Mike Heininger about 14 years ago

+1

Actions #12

Updated by Jani Partanen about 14 years ago

Philippe Lafoucrière wrote:

This might be more easy to use than having Comment / Reply models ?
On the other hand, since redmine has automatic notification, it sounds silly to change (=hide) a ticket update after a mail is sent, so the couple Comment(hidden) / Reply(visible) should be considered too.

How about new setting "private issues"

When selected, then all comments in private in default, until you click "Answer author" checkbox

Hows that sounds?

Actions #13

Updated by Alex Popov about 14 years ago

+1

Actions #14

Updated by Ronald Theile almost 14 years ago

Any news on this feature?
We use now a "internal" and a external project to hide comments and development steps to the customer. But they have to be on same status, so it's more work.

regards Ron

Actions #15

Updated by Oleg Volkov almost 14 years ago

Feature #337 is updated for current trunk version.

Actions #16

Updated by Philippe Lafoucrière almost 14 years ago

Great, thanks. Anyway, I want to make sure we're talking about the same thing. This issue is about private COMMENTS in tickets. It's somehow related to #337, but they are really not the same feature request.
Thanks
Philippe

Actions #17

Updated by Oleg Volkov almost 14 years ago

First you have to push in a trunk feature 337, then make private comments. Please test the feature 337.

Actions #18

Updated by Oleg Volkov almost 14 years ago

Philippe Lafoucrière wrote:

Great, thanks. Anyway, I want to make sure we're talking about the same thing. This issue is about private COMMENTS in tickets. It's somehow related to #337, but they are really not the same feature request.

In the trunk version for private comments, it will create a subtask with a private issue.

Actions #19

Updated by Oleg Volkov almost 14 years ago

I updated the # 337. Please test it.

Private notes are needed for NOT private issue?
Who should view private notes?

Actions #20

Updated by Philippe Lafoucrière almost 14 years ago

Oleg Volkov wrote:

I updated the # 337. Please test it.

Thanks Oleg, I'll test it.

Private notes are needed for NOT private issue?

Yes, privates notes and private issues are 2 different things. A ticket can be "public" (not private) and have private notes.

Who should view private notes?

This should be part of the roles configuration, but I'd say manager + developer. Generally, the reporter is the customer, they should not see private comments.

An example of private comment :

1- John_the_customer opens an issue : "I can't login on the demo site"
2- Bill_the_dev_leader adds a private comment : "Check that this jerk has created an account on demo, and if the last database has been imported"
3- Bob_the_dev adds a reply : "John, we'll check if you an account on demo, and if everything is in place and let you know asap".

John should not see step 2 :)

Actions #21

Updated by Oleg Volkov almost 14 years ago

Privileges "Hidden notes" for the possibility of adding / editing / viewing of hidden notes will be enough?

Actions #22

Updated by Philippe Lafoucrière almost 14 years ago

Exactly!
Thanks

Actions #23

Updated by Kioma Aldecoa almost 14 years ago

Would be great to have this feature, we'd also benefit greatly by being able to control which comments can be seen by customers. We also considered an internal/external project but this would be slow and cumbersome.

Actions #24

Updated by Wytze Keuning almost 14 years ago

Would be very useful indeed. That way a person working on an issue can update the issue with information not visible for "plain" viewers. A discrete comment so to speak.

Actions #25

Updated by Ivo Leite almost 14 years ago

+1

Actions #26

Updated by Pradeep Achan almost 14 years ago

+1

Actions #27

Updated by Roland Discein almost 14 years ago

+1

Actions #28

Updated by Grant Show over 13 years ago

+1

Actions #29

Updated by Eric Peterson over 13 years ago

+1

Actions #30

Updated by Matt Meng over 13 years ago

+1

My organization is getting flustered with Redmine because there are no private comments. This would be a very good addition for us.

Actions #31

Updated by Karolina - over 13 years ago

Thank you for private issue, now we are waiting for private comments.

Actions #32

Updated by Darth Jesus over 13 years ago

Is anyone investigating this? This feature would greatly enhance our support environment.

Actions #33

Updated by Dan Scharon over 13 years ago

Oleg Volkov wrote:

Privileges "Hidden notes" for the possibility of adding / editing / viewing of hidden notes will be enough?

Yes, this would be absolutely sufficient, thus this one is not dependent on #337

Actions #34

Updated by Heiko Robert over 13 years ago

+1

Actions #35

Updated by Ant Radford about 13 years ago

+1

Actions #36

Updated by Marcel Hochuli about 13 years ago

+1

Actions #37

Updated by Cord Bellersen about 13 years ago

+1

Mantis has that feature as well and we are using it a lot. Our customers uses our issue management system and in almost every ticket we need to discuss something, that the customer is not supposed to see.

Actions #38

Updated by Karolina - about 13 years ago

Can't wait for this feature!

Actions #39

Updated by Yuke Priyantoko almost 13 years ago

+1

Actions #40

Updated by David Gillard almost 13 years ago

+1 Is anyone on the Redmine team looking at putting this onto the roadmap? Thanks

Actions #41

Updated by Etienne Massip almost 13 years ago

  • Target version set to Candidate for next major release
Actions #42

Updated by Brian Kjelin Olsen almost 13 years ago

+1 Thanks Etienne, I can't wait either :)

Actions #43

Updated by Bartek W almost 13 years ago

+ me too

Actions #44

Updated by Terence Mill almost 13 years ago

+1

Actions #45

Updated by Christian Köwing over 12 years ago

+1

Actions #46

Updated by Royce Williams over 12 years ago

+1

Actions #47

Updated by Dmitry Polovka over 12 years ago

As Eugene Kharkov mentioned before http://www.redmine.org/boards/1/topics/4325?r=25789#message-25789 Ruby and Rails not our strong side, so it would be nice if somebody of experienced Ruby developers cleaned up our code. We made patch from /branches/1.2-stable/ r6484 source code and added one permission "View private messages" which allow you view and also add private messages.

Actions #48

Updated by pasquale [:dedalus] over 12 years ago

+1: necessary feature

Actions #49

Updated by Pawel Orzechowski over 12 years ago

+1:

Actions #50

Updated by Jacob Weber over 12 years ago

+1

Actions #51

Updated by Jérôme BATAILLE over 12 years ago

+1

Actions #52

Updated by Sergey Kolodyazhnyy over 12 years ago

+1
Please, implement this feature. My client shouldn't see programmer talks

Actions #53

Updated by Anonymous over 12 years ago

Dmitry Polovka wrote:

As Eugene Kharkov mentioned before http://www.redmine.org/boards/1/topics/4325?r=25789#message-25789 Ruby and Rails not our strong side, so it would be nice if somebody of experienced Ruby developers cleaned up our code. We made patch from /branches/1.2-stable/ r6484 source code and added one permission "View private messages" which allow you view and also add private messages.

What I have to do with 20110820092133_add_private_to_journals.rb ?
I successfull patched the source, but I don't know how to change the database. Even with an "alter table journals add column private tinyint(1) default 0;" I cannot create a new notice.

NoMethodError in Issues#show
Showing app/views/issues/show.rhtml where line #94 raised:
undefined method `private' for #<Journal:0x4f8ec5c>

Actions #54

Updated by Chaim Peck over 12 years ago

+1 Agreed - it would be very useful to be able to tag a comment as "private" or a drop-down that says "Make this comment viewable to: [All, Managers, Developers, Reporters]

Actions #55

Updated by Razi Baluchi over 12 years ago

I've applied the patch to a 1.2.1 installation, and everything appears to work as expected with the exception of the activity log. This still shows all comments, private and non-private. Is there a step I might have missed?

Actions #56

Updated by Razi Baluchi over 12 years ago

Resolved the activity log issue by adding:

        # The private notes should be removed from events
    events.delete_if { |e| e.is_a?(Journal) && e.private }

to app/controllers/activities_controller.rb

Actions #57

Updated by Ernesto Baschny over 12 years ago

+1 on that feature...

Is anyone using the patch from Dmitry Polovka plus the additional change by Razi successfully? Is it safe to apply and try it out? Thanks!

Actions #58

Updated by Shaun Gilroy over 12 years ago

Razi Baluchi wrote:

Resolved the activity log issue by adding:

[...]

to app/controllers/activities_controller.rb

This method of hiding the activity is going to hide the private notes regardless of whether you have permission to see them or not. I'll fix it and post a patch if I manage to fix it.

Shouldn't logic like this be going into the model, not the controller?

Actions #59

Updated by Shaun Gilroy over 12 years ago

Alright--

This patch is compatible with 1.2-stable, but they've changed a few filenames in 1.3, so I couldn't get it to work with 1.3 without taking more time than I had on my hands today.

I've repaired a few things from the previous patch:
  1. Emails from private messages include a '[PRIVATE]' value i the subject to warn the user
  2. Incoming emails that update issues with '[PRIVATE]' in their subject will be added to the system as private notes (so you don't accidentally respond to a private note with a public response)
  3. I updated Razi Baluchi's change above to Activity Lists to only hide private notes from users who do not have permission to view private notes.

I made no changes to the migration, so I'm not uploading a new migration file.

Actions #60

Updated by Shaun Gilroy over 12 years ago

It bothered me to ditch on the 1.3 patch so quickly, so I went back and generated a 1.3 patch. Again, no new migration file was required. This should get anyone who's deployed 1.3.x up and running.

Actions #61

Updated by Alter Way about 12 years ago

  • Assignee set to Anonymous

I am a newby on ruby: How do you run 20110820092133_add_private_to_journals.rb migration script ?
thx

Actions #62

Updated by Alter Way about 12 years ago

Forget my question i found how to do it

Alter Way wrote:

I am a newby on ruby: How do you run 20110820092133_add_private_to_journals.rb migration script ?
thx

Actions #63

Updated by Anonymous about 12 years ago

Alter Way wrote:

I am a newby on ruby: How do you run 20110820092133_add_private_to_journals.rb migration script ?
thx

Please don't randomly assign tickets to people.

Actions #64

Updated by Anonymous about 12 years ago

  • Assignee deleted (Anonymous)
Actions #65

Updated by Pablo Bastari about 12 years ago

Nice feature you patched, but i am having problems to merge it with 1.3 stable i installed a few days ago. When i run the patch -p0 < private_messages-2011-12-14-v1.3.patch on the root dir of redmine and i get a lot of errors and rejected merges. Any idea why?
I am atacching the output of the patch.

Thanks.

Actions #66

Updated by Shaun Gilroy about 12 years ago

My initial thought is that you might not be running it from your redmine install directory. I occasionally get error like that when I try to apply a patch from ~/

This also might be caused if you've made modifications to redmine yourself or run a previous patch first. You really only need to run the last patch posted.

Actions #67

Updated by Deoren Moor almost 12 years ago

+1

I am really looking forward to this feature. I've been missing this since I last used Bugzilla years ago.

Actions #68

Updated by Anonymous almost 12 years ago

+1 I really need this feature. Hope it will be included in the next release. But first i try the patch right now.
Patch doesn´t work. I get the same errors as Pablo Bastari http://www.redmine.org/issues/1554#note-65.
I am in the redmine root and didn´t modify it.

Actions #69

Updated by marcin t almost 12 years ago

+1

Actions #70

Updated by Leif Lodahl almost 12 years ago

+1

Actions #71

Updated by José Campos almost 12 years ago

+1

Actions #72

Updated by Joerg Oswald almost 12 years ago

+1 ASAP

We're using the 1.3.x patch. Can anybody please provide an update for 1.4.x?
Since this issue is +4 years old, who can push this issue from "Candidate for next major release" really to next major release?

Actions #73

Updated by Ingo Linde over 11 years ago

+1
Would be a huge step forward for our use case.

Actions #74

Updated by Gabriel Pettier over 11 years ago

Applied manually (since it didn't apply cleanly) patch for 1.3 on my git version on 1.4 tag. did git format-patch HEAD^

patch attached, can be used with git apply 0001-add-private-messages.patch

Actions #75

Updated by Ryan Cross over 11 years ago

  • Assignee set to Etienne Massip

patch looks good. Can this go into the next version?

Actions #76

Updated by Etienne Massip over 11 years ago

  • Assignee deleted (Etienne Massip)
Actions #77

Updated by Ulf Johansson over 11 years ago

+1
This feature could make us replace Jira (one thing that we would like to see in redmine in order to make a transition)!

Actions #78

Updated by Thomas Pihl over 11 years ago

+1

Actions #79

Updated by Vicky Dibble over 11 years ago

How would I get the messages to be private by default? I.e. where the tickbox is shown, have it selected by default?

Actions #80

Updated by Jean-Philippe Lang over 11 years ago

  • Target version changed from Candidate for next major release to 2.2.0
Actions #81

Updated by Vicky Dibble over 11 years ago

Vicky Dibble wrote:

How would I get the messages to be private by default? I.e. where the tickbox is shown, have it selected by default?

I worked this out, if you edit
/opt/bitnami/apps/redmine/app/views/issues/_edit.html

And change

<% if view_private >
<
= check_box_tag :private_message, true, false >
<
= label_tag :private_message, 'Private message', :style => 'font-weight:bold;' >
<
end %>

to be

<% if view_private >
<
= check_box_tag :private_message, true, false, :checked => true >
<
= label_tag :private_message, 'Private message', :style => 'font-weight:bold;' >
<
end %>

Then where the 'Private' check box for messages appears, it sets it as ticked.
I have set up and tested this in 1.4 with the patches above. Great work all told guys, and a massive plus for Redmine. Thanks!

Actions #82

Updated by Terence Mill over 11 years ago

This shall be configurable in global settings.
Also private issues default shall be configurable in global settings.

Actions #84

Updated by Martin S. over 11 years ago

-1 for using just a flag for "private" vs. "non-private" as that is very limited...
+1 for a feature to be able to set the "visibility/viewing-restriction" of a comment to all users/a role/a group or even selected users.

Actions #85

Updated by Jean-Philippe Lang over 11 years ago

Martin S. wrote:

+1 for a feature to be able to set the "visibility/viewing-restriction" of a comment to all users/a role/a group or even selected users.

This is overkill IMO. I'm not saying that it would be useless but still, this feature will be implemented as a simple flag in 2.2 and visibility configured on each role.

Actions #86

Updated by Michael Stucki over 11 years ago

Jean-Philippe Lang wrote:

Martin S. wrote:

+1 for a feature to be able to set the "visibility/viewing-restriction" of a comment to all users/a role/a group or even selected users.

This is overkill IMO. I'm not saying that it would be useless but still, this feature will be implemented as a simple flag in 2.2 and visibility configured on each role.

I agree. Let's make the basic functionality a standard feature, and provide the rest (which only a few will need) through a plugin...

Actions #87

Updated by Deoren Moor over 11 years ago

Jean-Philippe Lang wrote:

this feature will be implemented as a simple flag in 2.2 and visibility configured on each role.

When you say a flag, are you referring to a flag on the ticket or on each individual comment? My apologies if you've already answered this.

Actions #88

Updated by Jean-Philippe Lang over 11 years ago

Deoren Moor wrote:

When you say a flag, are you referring to a flag on the ticket or on each individual comment? My apologies if you've already answered this.

On each comment.

Actions #89

Updated by Daniel Felix over 11 years ago

This one would be very helpful! We're thinking about a implementation of redmine in our current workflow and have many tasks where private comments would solve our problems!

Actions #90

Updated by Deoren Moor over 11 years ago

Jean-Philippe Lang wrote:

Deoren Moor wrote:

When you say a flag, are you referring to a flag on the ticket or on each individual comment? My apologies if you've already answered this.

On each comment.

That's awesome. I'm really excited about this feature.

Actions #91

Updated by Etienne Massip over 11 years ago

Just a note about comment numerotation and #2715:

As some comment will be private, there will be gaps in numerotation for users that aren't allowed to see private comments (there must be gaps because of #2715).

So maybe we can take advantage of this new issue to make this numerotation more consistent?
As it is for now, you can pseudo-delete a comment by specifying an empty text so the comment will not be visible by anyone and numerotation will be different starting from this comment, thus broking #2715.

Last thing, maybe that the same visibility setting could be used for comments and issue?

Actions #92

Updated by Brian Lacy over 11 years ago

I'm thrilled to hear that 2.2 will include Private Comments! Our team intends to use Redmine as a way to help keep our clients updated, but sometimes as developers we deal with information that will only confuse (or even unduly alarm) the non-techie types. I do have a quick request, though:

Can we make "Private" the default value for the flag?

I'd just hate for one of our developers to forget to tick the "Private" box on a client issue and end up complicating an otherwise trivial support issue. Thanks!

Actions #93

Updated by Jean-Philippe Lang over 11 years ago

Brian Lacy wrote:

Can we make "Private" the default value for the flag?

This can't be the default behaviour. But we could make it configurable, maybe globally or on a per user or role basis?

Actions #94

Updated by Jean-Philippe Lang over 11 years ago

  • Status changed from New to Closed
  • Assignee set to Jean-Philippe Lang
  • Resolution set to Fixed

Feature added in r10547.

Actions #95

Updated by Abdul Halim Mat Ali over 11 years ago

Jean-Philippe Lang, is the revision change stable?
I will love to test the private comment feature.

Actions #96

Updated by Jean-Philippe Lang over 11 years ago

Current trunk is pretty stable. It would nice if you could give it a try before 2.2 release.

Actions #97

Updated by Jean-Philippe Lang over 11 years ago

  • % Done changed from 50 to 100
Actions #98

Updated by Jean-Baptiste Barth over 11 years ago

Just tested it, it looks great! I didn't know there was some work going on here, so last week I released a very basic plugin that achieves the same idea (redmine_comments), but it looks a bit pathetic now ;) People who need this feature in Redmine 2.1.x can try my plugin though, I'll try to handle the transition to the core feature as soon as 2.2.0 is out. Thanks for this feature!

Actions #99

Updated by Etienne Massip over 11 years ago

Jean-Philippe Lang wrote:

Brian Lacy wrote:

Can we make "Private" the default value for the flag?

This can't be the default behaviour. But we could make it configurable, maybe globally or on a per user or role basis?

Per role would be great and very useful, same for default issue level.

Tested also, nice job indeed. Only remark, the french label associated with the 'Private note' checkbox in the upadte issue form is in plural form.

Actions #101

Updated by Dirk Schmidt over 10 years ago

Etienne Massip wrote:

Jean-Philippe Lang wrote:

Brian Lacy wrote:

Can we make "Private" the default value for the flag?

This can't be the default behaviour. But we could make it configurable, maybe globally or on a per user or role basis?

Per role would be great and very useful, same for default issue level.

Tested also, nice job indeed. Only remark, the french label associated with the 'Private note' checkbox in the upadte issue form is in plural form.

+1

Actions #102

Updated by redmine nemo about 10 years ago

I've created a plugin to enforce private notes for a role by default.
See https://github.com/githubnemo/Redmine-Private-Note-Enforcment

Actions #103

Updated by Etienne Massip over 9 years ago

  • Has duplicate Feature #1193: Staff-only notes with Role-base access control added
Actions #105

Updated by Go MAEDA almost 5 years ago

  • Has duplicate deleted (Feature #1193: Staff-only notes with Role-base access control)
Actions #106

Updated by Go MAEDA almost 5 years ago

  • Related to Feature #1193: Staff-only notes with Role-base access control added
Actions

Also available in: Atom PDF