How to disable Edit operation button AND live editing for users

[William JUTEAU]

Hello,

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 ?

Thank you

[Nic Brough -Adaptavist-]

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.

[William JUTEAU]

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

[Renjith Pillai]

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.

[William JUTEAU]

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.

[Renjith Pillai]

Wait what am I talking about.

1)

For restricting Edit operation, just customize the Edit permissions in the Permission scheme. Why am I talking about transitions. Sorry :(

2)

For Inline editing, I have no idea how to restrict it only for adminisrators (if that was your question)

[William JUTEAU]

I was talking about the edit operation

[Renjith Pillai]

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

[Renjith Pillai]

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

[C_ Faysal]

so i was... too many times :)

[C_ Faysal]

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

[Renjith Pillai]

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?

[William JUTEAU]

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 ?

[C_ Faysal]

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

https://developer.atlassian.com/display/JIRADEV/Customising+interface+based+on+user%27s+role

[William JUTEAU]

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.

[C_ Faysal]

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

[Nic Brough -Adaptavist-]

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.

[William JUTEAU]

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

[William JUTEAU]

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="'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>
</li>
</ul>
</ww:if>
<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>
</li>
</ul>
</ww:elseIf>

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.

[C_ Faysal]

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

[Renjith Pillai]

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