How do i find out what resolve / reopen are defined as in my project?

[Hannah Bauhof]

I'm trying to update our permission scheme to only allow certain users (admins) to move tickets to 'archive'. And I think to do that I will update the "Resolve Issues" to only admins access. However, I don't know what "Ability to resolve and reopen issues" actually means with the way we have our project set up. 

How do I figure out what my project considers 'resolving an issue' and 'reopening an issue' ? 

I've been having trouble today trying to figure out the differences between the below functions. 

Issue Attribute - Resolutions 

Issue Attribute - Status: category (to do, in progress, done)

[Petter Gonçalves · Accepted solution]

Hello @Hannah Bauhof

Thank you for reaching out.

Per your description, I understand you would like to know what actions exactly would fall under the "Resolve issues" permissions.

As you can see in the documentation below, the Resolve issues permission explicit allows people to set or clear the value on the Resolution field and see the Fix version field for issues, not mattering which status category the issue is:

Permissions for classic projects 

Of course, the resolution field should only be filled/unfilled when it "goes to" or "comes from" a closed status, so the permission will obviously be applied to the status category too, although this is not required.

Let us know if you have any questions.

[Hannah Bauhof]

Thanks for the follow-up I think i'm understanding this now. 

I just added a post function, to resolved issues, to our transition/status Archive & Rejected. 

So does this mean that if a user, who doesn't have the permission to resolve issues, tries to change the status from 'in progress' to 'archive', will they get an error? 

[Petter Gonçalves]

Hello @Hannah Bauhof

You are welcome!

Workflow post functions are always executed by the user which triggered the transition, so yes: If the user does not have the resolve issue permission, he might face an error when trying to transition the issue to any status where the resolution needs to be set (By post function or not).

Let us know if you face a different behavior than that.

[Hannah Bauhof]

Great!! I have the post function in a draft workflow that i can't seem to save right now but I'll figure this out and if I encounter any issues or have more questions i'll let you know. Thanks! 

[Petter Gonçalves]

You are welcome @Hannah Bauhof

Have a nice week ahead!

[Hannah Bauhof]

@Petter Gonçalves 

I'm still having troubles with this issue. 

• I have my permission scheme to not allow Devs to resolve issues. But admins and site admins can.
• Resolve issues: done, archive, rejected
• I created Post functions to resolve/mark as 'done' when issues are transition to: done, archive, rejected

When i tested with some developers, they were still able to archive tickets and reject them. When i checked the tickets they were able to archive, they had a resolution of 'done'. Do i need to have transition screens for this to work?

[Hannah Bauhof]

Figured out what the issue was, i needed to add a validator to the transition in addition to the post function. You'd think if i created a permission for something i wouldn't need to create a trigger to check for that permission? That seems like a flaw unless I'm not understanding why this would need to be another layer of protection?