I'm currently working to upgrade our jira4.4.5 instance to version 5.1.8. Some native features needs to be updated to replicate previous behaviour which fit our needs :
1/ disabling edit operation button for users
In JIRA 4.4.5, we were able to disable this Edit button for users because it's default screen (we kept it available for administrators). The solution was found with https://support.atlassian.com/browse/JSP-132934
What is the parameter which avoid this in Jira 5.X ?
2/ Disable live editing and limit the "Configure fields" button on pop-up
This new feature in JIRA 5 has to be diabled for our users.
Actually, it can be very usefull for some customfields (that we used to display on creation screens in Jira 4) but this live edit option is too large, some fields can be updated at the creation step as we don't want them to be edited before a specific step later in the workflow.
Is it possible to limit the list of customfields that can be edited in live ? If not, how to disable completely the live editing ?
Wait what am I talking about.
For restricting Edit operation, just customize the Edit permissions in the Permission scheme. Why am I talking about transitions. Sorry :(
For Inline editing, I have no idea how to restrict it only for adminisrators (if that was your question)
I am guessing that you mean "inline editing" when you say "live edit". If not, then can you explain what you actually mean?
1. We can't see other people's JSP requests, so you'll have to explain what code you customised.
From what we can see of your set up in this question, it sounds like all you did was change the permissions in the project so that only administrators had edit permission - this has not changed in Jira 5.
2.1 You can disable inline editing in Admin -> General configuration.
2.2 I don't think the configure fields option can be turned off in the UI, I think you might need to code for that.
You might want to read through https://answers.atlassian.com/questions/49613/jira-5-1-inline-editing-how-this-will-work-for-you - this is a long discussion about inline editing that has a lot of information I'm not going to repeat here.
I had edited the page on my previous instance to hide the Edit operation button to all users except jira-administrators members.
Here is the first code lines in includes/panels/issue/viewissue-opsbar.jsp :
<%@ page import="com.atlassian.seraph.util.RedirectUtils" %>
<%@ taglib prefix="ww" uri="webwork" %>
<%@ taglib prefix="aui" uri="webwork" %>
<%@ taglib prefix="page" uri="sitemesh-page" %>
<ww:if test="/showOpsBar() == true">
<ww:if test="/remoteUser/inGroup('jira-administrators') == true">
<ul id="opsbar-edit" class="first ops">
<a id="editIssue" title="<ww:text name="'admin.issue.operations.plugin.edit.issue.name'"/>" class="issueaction-edit-issue button edit first last" href="<%=request.getContextPath()%>/secure/EditIssue!default.jspa?id=<ww:property value="/issueObject/id" />"><span class="icon butt-edit"><span><ww:text name="'common.forms.edit'"/> - <ww:property value="/issueObject/key" /></span></span><ww:text name="'common.forms.edit'"/></a>
<ww:elseIf test="/showLogin() == true">
<ul id="opsbar-login" class="first ops">
<li id="ops-login" class="last">
<a id="ops-login-lnk" class="button first last" href="<%= RedirectUtils.getLinkLoginURL(request)%>"><ww:text name="'common.concepts.login'"/></a>
The ninth line (<ww:if test="/remoteUser/inGroup('jira-administrators') == true"> replacing the initial <ww:if test="/showEdit() == true"> is no more working for jira 4.4.5.
So, to summarize :
1/ inline edition :
does it concern the issue fields edition on the view screen OR the Configure fields button when I create an issue ?
The first one would be ok if we could define which ones can be editied (by default we'll disable this feature), but the second point has to be banned
2/ Edit operation:
Could you please give us the workaround on jira5 to replicate what works i jira 445 ( <ww:if test="/remoteUser/inGroup('jira-administrators') == true"> )
I don't think your "workaround" ever actually had a lot of use, because you can do it more cleanly with permissions, and securely (you can easily construct an "edit" url that will still work for normal users even if you remove the button). In version 5, there are more routes to editing issues than in 4, so your workaround is even less use, as you'll have to expand it for all the routes, as well as disabling inline edit.
Exactly as Renjith and C.Faysal have said, you really should simply use the permissions correctly.
if you disable inline editing nobody will be able to quickly edit issues in the view-issue screen.
you will still be able to edit the issue if you klick "Edit" option
you will only see "Edit" Option if your user is inside a group/role which has permissions to "Edit Issues" inside the permission scheme that is assigned to your project.
btw: posting a link to an atlassian support case is useless. security level is set to "Reporters & Support" so nobody else (except atlassians) and you can view it
According to Atlassian KB :
Permission to edit issues (excluding the 'Due Date' field — see the Schedule Issues permission). Includes the ability to convert issues to sub-tasks and vice versa (if sub-tasks are enabled). Note that the Delete Issue permission is required in order to delete issues. The Edit Issue permission is usually given to any groups or project roles who have the Create Issue permission (perhaps the only exception to this is if you give everyone the ability to create issues — it may not be appropriate to give everyone the ability to edit too). Note that all edits are recorded in the Issue Change History for audit purposes.
I still want my user to move issue to sub-task, so it might be too restrictive to feed this permission with jira-administrators only.
so your users should be unable to edit the issue but still be able to convert it into a sub-task ?
if so the question is "how to hide the edit button from Operations Bar to specific users?"
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
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