How can I disable delete permission once an issue changes state?

[Deleted user]

Recently I had a user request the ability to delete their own issues in case they accidentally created one improperly.  I was able to grant that permission by adding "reporter" to the Delete Issues permission. 

However, I only want them to have this ability while the issue is "new".  Once it has gone to "In Progress", I want to restrict that to "Project Administrator."  I thought I could do this with workflow transition properties such as  jira.permission.delete.reporter = false

This "article" is not well written and completely void of good examples: https://confluence.atlassian.com/adminjiraserver073/workflow-properties-861253674.html

Basically, upon transition from the "New" state, I would like to permanently disable reporter delete permissions.

[Joe Pitt]

Do not delete issues. When you delete it is GONE. Hardly a week goes by without someone wanting to restore an issue. Deleting issues will come back and bite you when it is the most inconvenient. I suggest closing with a resolution value of Deleted anything you want to delete. I implement a special transition only the project lead can execute and it requires filling in a reason field from a select list (such as entered in error, OBE, Duplicate, Other) and explanation text.

Missing issue numbers will eventually cause a question about what it was and why was it deleted even if it was done properly. Missing data always brings in the question of people hiding something that may have looked bad.

The only viable way to restore an issue is to create a new instance of JIRA and restore a backup that has the issues. Then export them to a csv file and import them to your production instance. You will lose the history.

[Deleted user]

Hi Joseph, thanks for the input, i did see your message elsewhere while browsing for this.  Though in general that is a good practice, I was hoping to make sense of the transition/issue properties so that I can use it for other non-delete purposes further down the line.  I am frustrated that properties are not clearly explained and there isn't a comprehensive list of them, seems that documentation on them is also an after thought as if they are not fully supported. 

I do wish there were a comprehensive listing, preferably through a picker of valid options, and that the assignment of values were restricted to valid values. Seems I can add any properties that begins with jira.permission.*, whether JIRA uses it or not.  Also seems that I can set this property, jira.permission.delete.group.1, to a negative value.  Why is this allowed if it is intended to represent a group?

[Vasiliy Zverev]

Dear Jorge, hi!

I usually create a transition from first state to last one which allowed only for creator. 

In postfunction I add one to set resolution to "Will not be done" or something like this.

And it works well.

Best regards, 

Vasiliy.

[Deleted user]

Thanks for the suggestion, I have not used post functions though our users have the ability to pick a resolution reason, including Won't Do.  This was more to accommodate restricting certain actions once an issue passes a certain point.  Initally, I'd like to restrict deleting an issue once progress has begun on it, but if can get properties working, it opens up a whole other world of possibilities to restricting further changes in certain states (eg, QA can close an issue, but only once it has reached a certain state).  

[Vasiliy Zverev]

As for me delete issues is a bad idea, because it is impossible to restore deleted ones. 

It is much safe to close it with descriptive resolution.

We can be sure that during a year we will face when good issue was deleted.

Also it is bad user expirience to get used delete issues.

[Alexey Matveev]

Hello,

Have a look at this article. You will find an answer there:

https://www.j-tricks.com/tutorials/permissions-based-on-workflow-status

[Deleted user]

Thanks, Alexey, I did read that before, however that article is 7 years old, and not sure how well the suggestions in it work and it isn't very clear.  Here is what I did:

1. I created a test project with my own custom permissions scheme where only reporter can delete issue.  Neither Administrators (Project Role), nor jira-administors (global group) has this ability

2. On workflow transition away from "New" state, the "Issue Estimated" transition, I set two properties (again, what is valid here, project Role or global group; seems no validity checking is done):

jira.permission.delete.group.1 Administrators  
jira.permission.delete.group.2 jira-administrators

4. I have verified via Admin Permissions Helper, that the only stated reason for being allowed to delete an issue is that I am the reporter.3. I created a few test issues, and moved them through the transition.  It seems that either the transitions are not setting the properties permanently, or the properties don't have any impact.

In fact, adding a property jira.permission.<any garbage> is accepted and added, which leads me to believe that you can put anything in there and it either won't have an effect or perhaps I have to set a very specific property which is impossible to determine.

The most frustration I have is that I haven't found a concrete source showing actual properties available in the system by default.  There should be a specific list for JIRA 7.12.3 that says these are the properties and this is how JIRA uses them.  Instead it seems I can set almost any property.  It is also unclear whether setting a property on a transition allows it to persist as part of the issue until changed later (which would make sense to me that it does).

As previously stated, the link at the top of the actualy JIRA article is useless, looks more like static variables that some JIRA functions use, no explanation and no comprehensive list.  EVEN WORSE, the scant examples that are shown link to blog entries that are either outdate or unavailable.  I would think that Atlassian would have concrete examples; seems the properties are not actually fully supported.

[Alexey Matveev]

You should put these properties to a status, not to a transition.