Ability to set visibility when writing comments in linked issues (part of JSD projects)
When writing a "new comment" on linked issues that happen to be of Service Desk type project we need a way to select the type ("visibility") of comment. This is actually handled by a comment entity ("CommentProperty") property (propertyKey="sd.public.comment".) Now the default behavior is to add the comment as "public" one, even if the executing user is a collaborator.
<EntityProperty id="10439" entityName="CommentProperty" entityId="10274" propertyKey="sd.public.comment" created="2015-09-21 07:16:26.794" updated="2015-09-21 07:16:26.794" value="{"internal":"true"}"/>
<EntityProperty id="10440" entityName="sd.comment.property" entityId="10274" propertyKey="sd.public.comment" created="2015-09-21 07:16:26.826" updated="2015-09-21 07:16:26.826" value="{"internal":true}"/>
Cheers, AP
Comments (24)
-
repo owner -
reporter Thanks for letting us know Fidel.
Cheers,AP
-
repo owner Hi Aggelos,
I have made available version 2.2_beta_20 which supports setting visibility for JSD comments.
You have two different ways to do it:
-
Once created a comment (e.g., using "New comment" virtual field), you can use virtual field "Last comment's visibility restriction" for setting visibility restriction. You should write on this field value "internal" or "public" (without double quotes) for setting JSD (Jira Service Desk) comment's visibility.
-
A more direct way to do it is simply by adding string ": {visibility=internal}" or ": {visibility=public}" at the end of your comment's body when creating a comment with "New comment" or when editing a comment with "Last comment".
This is an example of the second option:
And here is the resulting comment:
You can also use the name of a group or the name of a project role as value of optional parameter visibility (i.e., ": {visibility=jira-developers}" or ": {visibility=Managers}"), and the visibility will be set for entered group or project role.
-
-
reporter Kudos Fidel,
works great! Tried the first method, as I think it's the only one that can be used for posting a comment on linked issues, right? The second would work on workflow post-functions acting on the issue at hand.
Cheers, AP
-
repo owner You can use the second method with any issue (linked issues, subtasks or JQL selected issues).
Simply compose the text for the comment body and include the visibility parameter at the end of the text. Store this text in an "Ephemeral string" field, and then use post-functions "Write field on linked issues or subtasks" or "Write field on issues returned by JQL query" for writing it into virtual field "New comment" or "Last comment".
-
reporter Oh cool, we can use %{Transition's comment} when composing the ephemeral string and add the visibility attribute {visibility=internal}
Thanks Fidel.
-
repo owner - changed status to resolved
Resolved in just released version 2.2.
-
reporter Great work Fidel, thanks!
-
repo owner Post-function "Add comment" now also supports JSD comments visibility modes.
-
Account Deactivated Hi Fidel,
what should I do if I want to copy the comment from the actual issue from Field "Transition's comment - [Text]" to the linked issue into the field "New comment - [Text]? How can I add the visibility to the role "Users"?
Cheers Stefan
-
repo owner Hi @the_bit
You can do it using Write field on linked issues or subtasks post-function with the following configuration:
-
Account Deactivated Wow, Fidel!
It works and you safed my weekend. Great and such a quick answer.
Thanks a lot Stefan
-
repo owner You are welcome ;-). Have nice weekend.
-
reporter Fidel the unsung JIRA hero. Saved a lot of weekends for us too :)
-
repo owner Thanks Aggelos. Proud of users like you. :-)
-
@fcarmario any way to use this in the conditional execution of a post function? if a comment is internal, send an email to someone? or verify the comment is not internal? that type of thing. Thank you.
-
repo owner Assuming that your condition is on comment entered in the transition, you can use boolean expressions like these:
1) A comment has been entered in transition, and the visibility is Internal.
%{00127} != null AND %{00130} = "Internal"
2) A comment has been entered in transition, and the visibility is not Internal.
%{00127} != null AND %{00130} != "Internal"
3) A comment has been entered in transition, and the visibility is public.
%{00127} != null AND %{00130} = ""
Note that %{00127} is field code for Transition's comment, and %{00130} is field code for Last comment's visibility restriction.
-
@fcarmario Thank you! That's exactly what I was looking for. This add-on is amazing
-
reporter Brian, if we keep praising Fidel's work he's going to raise the add-on price very soon :) Jokes aside the add-on rocks.
-
repo owner Thanks guys :-)
-
Account Deactivated Hi Fidel, if you look above, you were able to help me with the problem of the visibility of a Transition comment. Your solution does completely what I need and it works great:
Unfortunately and more by luck I found out, that this post function will always write a comment to the linked issue. If there was a comment in the transition the text of this comment will be written in a new comment in the linked issue = Correct! But if there is no transition comment, a new but empty comment will be written which makes no sense and will confuse the users = Incorrect.
Is there a chance only to write a comment to the linked issue if there is a transition comment?
Cheers Stefan
-
repo owner Hi @the_bit,
You should use the following boolean expression at parameter Conditional execution:
%{00127} != null
where
%{00127}
is field code for Transition's comment. -
Account Deactivated Thank you for your quick help! It works fine!
Cheers Stefan
-
repo owner You are welcome
- Log in to comment
Hi Aggelos,
Next version of the plugin (2.2) will implement this improvement. It will be released in a month approximately.
Regards,
Fidel