Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to disable Edit operation button AND live editing for users


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
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 ?

Thank you

12 answers

  1. To disable Edit button, just remove the Edit permission for all and add specific workflows with Conditions for administrators alone to do the transition (do not use any Javascripts)
  2. Live Edit, I guess you mean Inline Editing, can be disabled completly in General Configuration.

for your second point, disabling the option in General Configuration is global, but we'd like to keep it available for jira-administrators, that's why we edited the jsp file to hide it depending on the group of the current user.

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 was talking about the edit operation

You mean 'Inline Editing' or the 'Edit' operation itself?

You are right Faysal, got carried away too fast :)

so i was... too many times :)

if you only want users inside jira-administrators to be able to edit issues why don't put it in a permission scheme?

1 vote

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 - this is a long discussion about inline editing that has a lot of information I'm not going to repeat here.

yes, I know about this solution but it doesn't fit my need :-/

I would say, don't do this. Just manipulate the Edit permissions.

you can also restrict editing to roles/groups using workflow properties in certain steps.

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">
<div class="command-bar">
<div class="ops-cont">
<div class="ops-menus">
<ww:if test="/remoteUser/inGroup('jira-administrators') == true">
<ul id="opsbar-edit" class="first ops">
<li class="last">
<a id="editIssue" title="<ww:text 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"> )

0 votes

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 :

Edit Issues

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?"

Yes, thank you, I guess this could fit my first need in the best way.

What is the velocity file for the issue view screen ?

Can you start a new discussion for the last query, this post has grown up big and it is better to start a new thread?

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you