I have the following project roles:
Administrators, Assignable Users, Read-Only, Issue Closers, and Users.
My permission scheme is set up to allow Administrators, Read-only, and Users the browse project permission - and Issue Closers and Reporter the close issue permission.
Why is it that a person with the project role Users that is not the Reporter is able to Close the ticket?
PLease check
1. if the permission scheme you are browsing is enabled to your project
2. Close issue permission does not include any group and the member closing the issue may be included in that group
3. Close issue transition on your workflow does not have any funny post-function attached to it.
Rahul
1. I have verified that the permission scheme is in place and indicates that only the Reporter and someone with the project role Issue Closers has the Close Issues permission.
2. The Close Issue permission does not include any groups.
3. The transition only contains the 5 standard post functions:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Look at the conditions on the workflow - I suspect you'll find that the "close" transition is missing a condition like "must have close permission"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't have "must have close permission" set up in the transition - but I do have "must be in specific group". The system is allowing anyone with browse access the ability to close all issues - even though they are not part of the specific group that is a condition in the transition.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Could you post the exact conditions, and then the group and role membership of a user who is able to perform the transition (when they shouldn't be able to)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Transition Reopened => Closed:
Only users in group JIRA_SBS_REPORTERS_PR can execute this transition.
— OR
Only users in group JIRA_SBS_MANAGERS_PR can execute this transition.
|
Browse Project permissions go to the following:
Close Issue permissions go to the following:
I myself am a member of the JIRA_ALL_PROJECT_PR role, which was created so that people with a need to see all projects across the company could see them...but not transition them. Browse Project is the only permission that the role has been granted. However, I am able to transition the workflow to closed.
My group memberships are as follows:
We have also verified that users who are not part of JIRA_ADMIN_PR and JIRA_SYS_ADMIN_PR can make the transitions. JIRA_USER_PR is the role that we have designated via LDAP that all users must have in order to log into JIRA.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The transition you have mentioned is re-opened -> Closed. Can you check if there are aother statuses such as In progress etc etc which can transition to close directly. If yes, check the same things on those transitions.
Check if the workflow is correctly applied to the issue type on your workflow scheme and that the same workflow scheme is associated with your project.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have verified that the correct workflow is being used. This particular project uses a workflow which has unique statuses. Also - this is just one example of a workflow where we are able to transition to closed unexpectedly. It truly only seems to be tied to the Closed status - all others appear to transition as expected with the user group restrictions mentioned above.
It seems that in all workflows (whether they have conditions or not), anyone with Browse Project permissions is able to Close the issue. Almost all of our workflows have access to the Closed transition from multiple steps. I was able to verify this behavior by removing the JIRA_ALL_PROJECT_PR role from the Browse Project permission in the permission scheme. When that was done - then I was not able to see Closed as an option in the issue. When the role was given back the permission, then I was able to Close the issue again.
In my opinion...if the user only has Browse Project permissions, then they should be able to see the issue, but nothing else. No workflow transitions and no editing. We did not even give them the Add Comments permission. Once JIRA has verified that the user has Browse Project permissions, then it should look to see what Issue Permissions the user has to determine what that user can do within the issue.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your conditions are spot on, and your analysis of the group memberships is perfect.
That really does make me think that the issue you are looking at is actually using a different workflow from the one you are looking at.
If you're on Jira 5+ could you check that with "browse workflow"? Near the status in the issue view.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Your opinion is exactly the behaviour that is designed, intended and expected here.
If the issue is using the workflow you have shown to us, then there is no question that something is broken - "browse" rights should not be granting "close", or anything else. Even for administrators (which is a good permissions model, unlike the extremely stupid "admins can do everything" a lot of software implements).
I have to admit that I'm a bit stuck here. Your condition is clear - "group A or B can do this". You are using the workflow that implements that condition on the transition that is appearing. Yet a user who is not in group A or B can still perform the transition.
There is still one thing you've said that I'd like to follow up - you removed the jira-all-project-pr from "browse" and were no longer able to see closed as an option. That's fine. But that should have removed your ability to see the issue completely. Could you re-do that test with a user who is not in any browse groups and make sure they can't see the issue at all? (Note - I suspect this is a red-herring, but it might tell us more)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I removed JIRA_ALL_PROJECT_PR from the permission scheme, tried to do a search on a project that I have no project roles assigned, and returned no values in my search. I mis-stated that earlier.
The other thing that we have tried is putting the condition into the actual transition that the user must have Close Issue permission. This will correct our problem. However, it just doesn't seem right that we would have to add that condition to every workflow that we have for closing issues. I swear (but cannot prove) that these transitions were working as expected in October. I have not been able to pinpoint exactly when the behavior started.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
> I removed JIRA_ALL_PROJECT_PR
That's a good test, it shows the browse permissions are working correctly.
>The other thing that we have tried is putting the condition into the actual transition that the user must have Close Issue permission.
Mmm, you really shouldn't have to do that. Your confitions are correct for what you want to do. Having a dubious workaround of "must have close permission" really doesn't sound right to me. I'd be very tempted to raise this with Atlassian, simply because your configuration sounds absolutely right for what you need and yet is not working. I really cannot see anything wrong, and yet it clearly doesn't do what it is supposed to!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.