We have a JIRA project called simply Accounts. It's used for people to request new accounts. We use JEMH, so most requests are coming in via email and the requestor has no JIRA access. However, sometimes existing JIRA users create account requests.
Currently it's set up so all jira-users are in the "users" role and users can create tickets and see all tickets.
We would like it to work differently. Specifically
Is this possible?
Thanks in Advance.
You should check out this plugin: Jira Watcher Field
It adds a new field type that you can use in permisison schemes, Issue Security Schemes etc. It will make it possible to grant various access to watchers on specific tickets.
Make sure everyone can create tickets and that your new watcher field has browse permission, maybe even edit permission if you want them to be able to edit the tickets they are watching.
I am using this plugin for a number of JIRA projects and it works great!
This sounds good. It's not working yet for me so I'm setting this up incorrectly. I installed the plugin. I created the custom field per the documentation. In the relevant permission scheme, I removed "users" from "browse projects". Added user field "Watcher Field" to "browse projects". Tried adding a watcher to an issue and got the error "The user does not have permission to view this issue."
So then I created a new security scheme. (my first so this may be the problem).
Set a security level called "watchers". In that gave roles administrators and developers and custom field "Watcher Field" permissions.
Got the same error when I tried to add a watcher.
Then I left the security scheme in place and gave users browse projects permissions again and still the same error.
The way I'm reading this plugin is it does all the work of putting watchers into the custom field.
Any idea what I'm doing wrong? Thanks in advance.
So my advice is to start over (I mean - just revert the changes in the permission and issue security scheme) and perform the steps in the following sequence:
I hope I'm not missing something , but the general idea is to test the result on each step , so eventually you can see which exact step you did wrong an then try to figure out this specific problem.
After step 4 and before step 5 do I not need to assign the new issue security scheme to the project in question? I did this, but results aren't correct. My test user, that was a watcher on at least one issue in the project, could not see any issues in the project and could not be added as a watcher (same error as before).
As far as step 5 goes, I'm not actually sure how to do that. https://confluence.atlassian.com/display/JIRA/Configuring+Issue-level+Security does not cover setting the issue security for a single issue. I'm new to using issue security levels, as I'm sure you can tell. This will be cool when I get it to work.
I appreciate your patience with me.
For step 4 I what I ment was to assign the Issue Security scheme to the project, but it's a good idea to test that before setting issue security all users can see everything, so you're sure that before assigning the issue security scheme to the project everything is fine.
As to the set issue security level - only users with "Set Issue Security Level" permission from the project's permission scheme can set issue security and also this filed should be added to the screens (To check why the field is not there use the "Where is My Field" admin tool
Before assigning the Issue Security Scheme make sure that all users can see all issues (All users should have the appropriate permissions in the project's permission scheme - Browse Projects)
Got it! It's working. Based on the plugin docs I thought the watchers field would write to the CF, not the other way around. However, that's the only part that doesn't seem to be working. I add users to the CF and they can see only those tickets so that's good. But their names are not being added to the watchers field of those tickets.
It's sort of seems like the plugin isn't actually doing anything. ??
Feels like I configured per Julian's recommendation. What is the plugin doing for me?
Great to hear that you got it to work!
The JIRA built-in watcher field actually populates your CF but in this specific use-case granting issue access it is not possible due to a catch-22 situation. The built-in watcher does not allow you to add a user that won't see the ticket.
The fact that the user will get access when added is irrelevant to the built-in watcher. It is here the plugin works well since you can override this check with the plugin configuration.
When you say that the field is not synched between the CF and Watcher I don't understand. In my setup that works fine. I add the user to the CF and when the ticket is saved it shows in the built-in watcher field.
Can you describe a little bit more what is happening when you add a watcher.
Have you added your CF Watcher field to the Issue Security Scheme? I guess if this is not the case the JIRA built-in watcher will reject it.
You could try this out by creating a temp account that you grant access using this mechanism and then use the permission helper (great tool) to se if your temp user can see the ticket. The permission helper will reveal any problems with your schemes
Let me know how that works out!
Yes, the CF Watcher FIeld has been added to the Security Scheme. And yes I have a dummy account that I use for various testing.
I can't find the permission helper. It's a plugin I assume? I'm not getting anything by that name to pop up with I search for addons.
(thanks for sticking with me on this one!)
Hi, no problem, I don't give up until we have solved this issue :-)
The permission helper is a bundled add-on (since 5.2, I think). You need to be JIRA admin to reach it. See https://confluence.atlassian.com/display/JIRA/JIRA+Admin+Helper#JIRAAdminHelper-PermissionHelperfor details. From what you have described so far I cannot see why you don't see this great tool. Maybe it has been disabled for some reason.
Check in the manage add-ons (system add-ons) for the Atlassian JIRA - Admin Helper Plugin and make sure all its modules are enabled.
Found permission helper. Wow. The things I learn. :)
It's not clear to me how big an issue it is that the watchers field is not populated. The only thing that may not work well are email notifications. I've done this all on my staging JIRA that does not have email enabled. I'll have to move it to production to check that.
I'll plan on that in the next day or two and get back to you.
It is a mystery why the JIRA watcher field is not updated properly. Hope it will be solved in your production environment.
Right next to the Permission Helper you'll find the Notification Helper which is also an awesome tool for trouble-shooting. You should check it out as well!
Good luck with your implementation in production!
you can setup a specific permission scheme for this project. In particular tyou need to setup "Browse issue" permission just to watcher/reporter and project administrator (if you want that administrators can see all the issue within the project).
Create Issue permission should be set as well in order to allow jira-users to create ticket.
Hope this helps.
You can use JIRA Issue Security Level for restriciting user to see the tickets. Since the security level can be bound to the custom field, you could create a "User Picker" custom field and set the security level to refer to the users in that custom field. This will make only the users inside the custom field that are able to see the ticket.
For more details, you could check this documentation:
This is bad, very bad. The moment you add "Browse Permission" to the user custom field value for the "Watchers" field - regardless of whether it has anything assigned to it, suddenly any user in the system can go to the "View All Projects" screen and list all and any project set up in JIRA. That means if you have a client who logs in they can view all of the company's internal projects and know what the company is working on. We therefore can't use the JIRA Watcher Field plugin.
We're using JIRA 6.2.1.
This is exactly our scenario. We need to enable project visibility to users only if they have the correct permission, but when we add the user custom field value "Watchers" to the "Browse Permission", any user in the system gains the "View All Projects". This is very confusing for our users, even if it doesn't brake the correct project mapping for the "Create" functionality.
Now on JIRA 6.4.12, tested also on a JIRA 7.0.5 instance.
Does anyone know if this issue still exists? Giving a restricted user 'View all projects' rights seems counter initiative to the whole point of the exercise. Our objective is to restrict a user to viewing a single project on tickets that only exist when the user has been added to the watcher field. I assume this is a bug? Can anyone confirm if this is still the situation?
We are using JIRA v7.3.3
I don't believe this is an issue. But JIRA is complex and you have to watch out for it.
We are currently working on only allowing Reporters and Watchers to see the issues they are allowed to see. I'm using this Watchers plugin and I'm getting it to work. Granted Consultants have to use the Edit button to edit the Watchers CF to get it to work. If they use the standard built-in Watchers field they will get an error stating that user to not allowed to be added. (That whole Catch22 that is mentioned above I believe)
My test user, who is locked down, only sees issues where they are a reporter or a watcher of. And I'm bouncing around multiple projects and they see nothing. So, long story, it is possible.
We are not done building this out, but you can do it and I believe I don't have any issues.
we are on 7.7.2
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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