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
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.
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.
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.
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
Look at these articles.and in some cases do the reverse to turn things on.
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.
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)
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs