Why is Epic Link field not save during Create Issue, unless User Group as Edit Issue Permission?
I want to limit users from Editing existing issues, unless they are the Reporter of the issue. I have the Epic Link field defined as one of the attributes of the issue that can be set at Issue Creation time. I have given Create Issue permission to the Group g1, and Edit issue permission to the Reporter. I have a set of users that are in Group g1. If g1 is NOT given "Edit Issues" permission, the Epic Link field can be filled in by the Reporter (who is a member of g1) on the Create Issue Screen, but when completing the screen, and creating the issue, the Epic Link field does not show up. Similarily the field does not show up after using the Edit Issue screen.
What can I do differently such that I do not have to give Edit Issue permission to everyone in Group, in order to be able to allow the Reporter, a memer of the Group, to set the Epic Link during Issue Create?
I've come across this while trying to solve a related problem. It seems that the Epics which show up in the "Epic Link" field when editing are any Epics the user can "see", i.e. Epics in any project where the user has the "Browse Projects" permission. I think that in order to be able to link two issues (in this case, link something to an epic) you should need the "Link Issues" permission for both issues (i.e. if they're in different projects you will need permissions in both projects). Maybe you also need the "Edit Issues" permission as you seem to have found.
So, basically the problem is that you can select an Epic on a screen which you don't have permission to link to. I have found that if I do this, the issue creation succeeds but the Epic Link field is blank. There is no error message or warning, it just doesn't link to the Epic. I think this is what is happening for you. That doesn't help with how you can grant permissions to just the reporter, but hopefully explains why you're able to pick the Epic on the create screen.
To actually fix your problem (sorry for only now getting to this ), you can grant specific permissions to the Reporter in the permission scheme your project(s) is using. If you find the permission scheme you want to change and select "Grant Permission" a small window will pop up where you can choose who to grant the permission to. If you click "Show More", reporter is one of the options. So you should be able to only grant the "Edit Issues" permission to the reporter. You may also want to do this for "Link Issues" in order for the Epics to behave themselves.
Hope that helps,
As I said, granting the "edit permission" (and/or the "link permission even if it's not required in this case) to the "reporter" doesn't do the trick : only adding group or role is working in that specific case.
Moreover as a "reporter" granted whit "edit permission" one simply cannot edit Epic Link field!
+1 : I'm facing the same problem.
If I set up the "edit permission" to a group or a role, it is then possible for people that belong to this group or role to create a ticket while setting the value for "Epic link" field. But this same behaviour is not working when the "reporter" is set with the same "edit permission". In fact I can see in the history of the ticket that the "Epic link" field is receiving its value just after the ticket creation. By the way as a "reporter" I cannot change the "Epic link" of a ticket I've created before even if I have the "edit permission"! That sounds like a bug to me...
Same problem here:
- We have an Epic A in project A with reporter A
- Any reporter has edit permisson in project A.
- During the creation of a new issue (issue B for instance), reporter B see the Epic A as selectable, and the issue is created. But finally this information is not saved.
- I've tested that if reporter B is also reporter fo the Epic A, then it works.
Conclussion, to be able to use Epics by the reporters, the permissons must allow to Edit both the Epic and the issue to be included in the Epic. I think a new permisson of "Edit Epic Link" should be included in JIRA, to manage permissons separately.
Is there any news on whether this has been fixed or if there is a work around for it?
We don't want to give those users full edit permission on the stories and the epics, but that means that although they can create a story, they can't add add it to an epic. It must be a bug and need an urgent fix/workaround.
If being allowed to link two issues *requires* you to have the edit permission for both projects, what is the point of the link issues permission? When would someone want to allow users to edit both issues independently but not link them? It may not be a bug but that is a pretty rubbish piece of functionality, with similarly rubbish documentation. Kim's use case seems far more common and useful to me: you want users to be able to link to an issue in another project without granting full edit rights in that project.
Also, don't forget that there is genuinely something to fix here. Showing users a list of Epics they can see but can't link to in the Epic Link field on a screen and then giving no warning or error when that link is not created is a bug to all but the most cynical of devs.
>It allows the user to choose the epic link value when creating the story but then doesn't save the value. No error given.
>If being allowed to link two issues *requires* you to have the edit permission
You're looking at the wrong thing. The epic link is duplicated in the link tables, but is not controlled by the link issue permission.
This is the same as some of the comments above.
A question on edit permission:
You said "changing the epic link is an edit, so you need edit permission to change it."
but if you use transition screens, a set of users that doesn't have edit permission, can edit certain fields without any permission error. The Edit permission just seems to remove the Edit button from the issue view. Is that correct? (I've just tested this again and worked fine (except for epic links) or have I misunderstood something.
It is a bug with how the Epic Link field is implemented and/or the underlying custom fields framework. The issue picker displays all the Epics the user can see (i.e. has Browse Project permission for), rather than all those they can edit (which seems to mean has Edit and Link Issues permissions). The user can therefore select an Epic they have no permission to link to or edit. If they do so, the issue is created/edited/whatever successfully but the Epic Link is empty. No warning or error is given by the UI (I'm not going to trawl the logs, I shouldn't have to, it's extremely easy to replicate).
> You're looking at the wrong thing. The epic link is duplicated in the link tables, but is not controlled by the link issue permission.
I understand that, my point is that the effect that has for Epic Links is that the Link Issues permission is pretty much redundant. It may still be fine for other types of link, but for Epics it does nothing. Not having the ability to link to an Epic unless you have the Edit permission negates a use case that is quite widespread, i.e. wanting to allow people to link to an Epic without having the ability to edit that Epic entirely. It's also clearly causing confusion for a lot of users. Add that to the above bug and you have a pretty poor UX for large scale, multi-project use of Epics.
We are all here to say the epic link permission should be moved from "Edit permission" to "Link permission" since the usage case is closer. I can give plenty examples of all implementations of SAFe, Less, or any other scalability . The same should apply for ParentLink of JIRA Portfolio.
I thought I had posted these here a while ago but maybe not. It looks like the "needing Edit permissions to link to an Epic" feature has been rejected by the JIRA Software guys:
I have registered my displeasure, you may want to as well. If enough people do we could look to get it reopened, unfortunately I think the architectural aspects highlighted by Nic in some of his comments means they will never be brave enough to deal with it, they would rather tweak the UI again! I also created a bug for the "showing Epics the user cannot edit and failing to properly warn/error" problem as well:
This one should be pretty unforgivable if you ask me, so hopefully we have a better chance of success!
Hope that helps,
This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...
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