I installed the quisapps field security plugin for Jira 6.0.8 (after installing patches per the instructions) and entered an eval licence. I was able to create a field security scheme and associate it with a project and a group and even an individual user. When I log in with that test user I am completely unable to edit the fields I specified. It seems like I am so close to solving this problem, but mising some vital piece that ties it all together.
Hi Robert,
As I can see in your other question, you are trying to make fields editable when the user has no edit permission for that issue. JFS can not do this.
Alex
Hi Udo,
Thank you for your comment. I think the problem is a bit more fundamental, and if I am correct, it prevents me from using this plugin. Although this is not explicitly stated in the documentation, I believe users will need "Edit Issues" permissions before write rights can be used. My goal was to deny edit rights to users with the exception of one or two custom fields.
If I am wrong about this please let me know. It appears that I need to give members of a group edit rights and then deny them write access to pretty much everything except the one or two fields I want to give them write access for. In addition to being very difficult and time consuming to set up, this is not a complete solution as the plugin has no control over the built in fields, such as summary, description, or priority. We cannot allow the group in question to have access to these fields.
As a result I have had to design a workaround which is OK for now but is imperfect when viewing transitions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Robert,
sure, user will need to have edit issue permission in order to change any fields in an issue.
Yes, you would need to give write access to all fields but those two (and I know it is very time consuming to set it up). Regarding the standard fields I'm not quite sure which can be restricted by this plugin (some of them can be used , but I don't remember which can't be used).
Good luck with your workaround,
Udo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Udo. The necessity for edit issue permissions was not stated in the documentation. Unfortunately this means we cannot use this plugin.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Robert,
maybe it is the order of permissions in your field security scheme. You have a field with different permission (read, write, deny all) for different groups.
group1 read
group2 deny all
group3 write
So if an user is member of group 1 and group 3 he only can read that field. The permission are evaluated from top to bottom. If a permission is found (in our case read) it stops to evaluate the next permissions.
If you change the order
group1 write
group2 deny all
group3 read
now the user can write that field, since the first match is write permission
hope that helps,
Udo
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.