How do I edit a comment on a closed issue?

[Scott Harman]

Hi all - 

Bit of a weird one that came up today - our helpdesk was using a script in an old comment on a closed issue from about 2 years ago.  I've since discovered that the script is now wrong, but I've tried to edit the old comment, but I can't.

I can edit the issue itself, but I can't actually edit the incorrect comment and the script that it contains,

Currently running JIRA 5.2

[Jose M.]

If an issue is closed, as far as I know it is not possible to edit a comment.

[Scott Harman]

Yeah - you're right... I will just delete the comment containing the incorrect SQL script and add a new comment in it's place.

[Scott Harman]

Hmmm - ok, I can edit any comment on any closed issue, except when the commenter has been been removed as an active user. The guy who wrote the original SQL has left, and his account has been disabled. This appears to be one of the only cases where I can't edit comments.

[Scott Harman]

... Also, where the issue security scheme has been applied, but that doesn't make a lot of sense. I can't edit comments on just a handful of issues. I can't even delete the incorrect comments. Just seeing if that issue has anything wrong with it - but bloody odd.

[Jose M.]

Please note, that there is no history for an edited comment, so it is not recommended to allow to edit an issue after it's closure.

[Nic Brough -Adaptavist-]

That actually makes some sense - there was a bug in Jira that allowed people to be deleted (not disabled, but fully deleted) even when they'd made comments. When that happens, it actually blocks further updates to the comments they had made. Is that a possibility? (Newer versions of Jira block deletion of users with comments, preventing this issue)

[Jose M.]

My point is, that we allow to add comments even to closed issues, but not to edit comments on closed issues. Acc. to the permssion scheme the owner or the admin can edit or even delete comment before its closure, but not afterwards. We do not allow to edit closed issues, by exception of some fields through a transition, but only for a few members.

[Nic Brough -Adaptavist-]

Check the workflow status for the property that prevents issues being commented on (I can't remember the name of the property, but it is pretty clear)

However, you mention that the comment contains a "script" - what is that script, what does it do, and what is it written in?  There's a good chance that the script is the problem.

[Scott Harman]

Hi Nic - It's actually someone's SQL script inline 

We already have the jira.issue.editable flag set to true on those ones, as I can change everything else except for editing the comment

I've just added a new comment with a 'safe' script to prevent any more fsckups like the one I've just had

I'd rather fix what's there, but I guess I'll have to reopen it to do that.

[Jose M.]

The comment permission is handled separate from the edit permission. I do not see, why the edit property could influence the behaviour.

[Nic Brough -Adaptavist-]

You're confusing properties and permissions. Start with permissions - a user can be granted the project permission to add/edit/edit-own/delete/delete-own comments. That's a general rule that applies across the whole project and is the starting point. Properties are separate. They live on assorted Jira artefacts - the important one here is Status. You can add several properties to a status to control various things. If you look at the fixed, hard-coded default Jira workflow in your system, have a look at the "closed" status. You will find a property on there that says "you can not edit an issue in this status". That overrides your general access to edit the issue. Doesn't matter if the permissions say "user can edit issue", this property blocks it, but only when the issue is in that status. There is another, similar property for "comments" - you can block commenting on issues based on the status as well, and that, again, overrides the general permissions.

[Norman Abramovitz]

There is also a jira.permission.* workflow properties that might be interfering as well.  In particular

jira.permission.comment properties or you might need to add that admins can edit

jira.permission.edit.group=<admin-group>

Look at these articles.and in some cases do the reverse to turn things on.

http://www.j-tricks.com/tutorials/permissions-based-on-workflow-status  (most useful)

https://confluence.atlassian.com/display/JIRA/How+to+deactivate+comments+for+closed+issues

http://modem7.wordpress.com/2013/01/15/editing-closed-issues-without-reopening-in-jira/#comment-418

https://confluence.atlassian.com/display/JIRA/Workflow+Properties  (correct documentation for your JIRA version, but I am pretty sure the properties you need to deal with has been around for awhile(ie 5.x time for sure).

Different JIRA versions have different default property values, so it is better to be explicit when setting property values.

I cannot say which properties to add or change without knowing what you have already.

[Ollie Guan]

Check your workflow status properties

[Joe Pitt]

Look in the permission scheme. There is permission to edit own or all comments.

[Scott Harman]

Yeah, I can quite happily comment on the closed issue, and edit all other fields, likewise I can edit all comments on non-closed issues. Jose is correct... looks like it can't be done.

[Nic Brough -Adaptavist-]

It's not right - I can edit comments on closed issues, if I've got the settings correct (workflow properties, plus, as Joseph says, the right general project permissions)

[Jose M.]

We use a workflow step to edit issues after it's closure, because this is than restricted to selected users. In this context it is not possible to edit a comment. The property to prevent to edit a closed issue is very important, we don't want to skip it.