nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Disable "Click to edit" in JIRA?

Jimi Jimi

Hi,

I just noticed a new, extremely annoying feature in JIRA. When I have an issue open in the browser, and I click on the content of a field, it automatically goes into edit mode for that field. Apparently this feature is called "Click to edit".

The problem I have with this feature is that I very often click on parts of the text without any intention of editing it. It could be because I want to select the text, or I have some text selected and now I want to de-select it (so I just click anywhere in the text). Or it can be that I simply click somewhere because I just wanted to (I do that quite often, you might call it a tic), or maybe I click just by accident. In neigher of these cases I want to have the edit mode activated.

Quite honestly I can't really understand what the JIRA-developers was thinking when they implemented this feature. Do people really want this? If I want to edit a field I can click on the smaller "Click to edit" icon in the top right corner. What I dislike is that the *entire* text area functions like a "Click to edit" area. Surely other people also find this annoying, right?

Is there a way to disable this function? Preferably by user preferences, because maybe some people in a project like it, and some (like me) really dislikes it.

Regards

/Jimi

Accepted answers

Radu Dumitriu

I do not know OnDemand, but for Jira 5.1 it can be disabled from Administartion- > General Configuration.

It's a new feature introduced by Jira 5.1, I'm not able to tell if this is annoying or not (I guess such decisions are taken with some impact considerations ...).

All comments

Radu Dumitriu

I do not know OnDemand, but for Jira 5.1 it can be disabled from Administartion- > General Configuration.

It's a new feature introduced by Jira 5.1, I'm not able to tell if this is annoying or not (I guess such decisions are taken with some impact considerations ...).

Jimi Jimi

ok, a global configuration. So not is it not possible to configure individually, it is global for all projects? Strange...

Do you happen to know if this disables the "Click to edit" feature completely? Or does it only disable the "entire text area is click-to-edit" while the smaller "Click to edit" icon at the top right is still available? Because it is only the text area click that I want to disable.

The reason I ask this is because I have no access to the Administration part of JIRA.

Nic Brough -Adaptavist-

People absolutely want it - while looking at an issue and thinking "that needs updating", it's immensely useful to be able to click it and change it without having to go through a whole chain of clicks just to change one field.

I can completely understand it would be useless to people who don't work like that, but I suspect the majority of people do work that way. We're in the middle of looking at 5.1, got about 20 "lead" users playing with test and they all love it. The techies in the team upgrading it vary between "nice, but I might not use it much" and "can we bypass all the testing and put it in NOW"

As Radu says, if your teams fall into the "don't like it" group, you can simply turn it off. But it is global.

Radu Dumitriu

1. No. 2. Completely. 3. You should ask your admin.

Jimi Jimi

But why does the *entire* text area have to react to the click? Why is it not enough to go into edit mode by clicking the "Click to edit" icon in the upper right corner of that field? I can maybe understand it for smaller text fields, but for the description field, which usually is several paragraphs long?

All these test persons testing this feature, do they never click on the text for selection etc, and getting into edit mode unwantedly?

Jimi Jimi

The problem I have with the global configuration is that I might not be able to convince the other users that this should be disabled, because they want an easy way to edit a field (and so do I). But since one can't select the perfect middle way (being that the "Click to edit" icon remains, but the "Click anywere on the text to edit" is disabled), I will still suggest that we disable the "Click to edit" function completely.

It's just so sad that JIRA only offers two extreme configuration options, and also not a per user configuration option. If my fellow Jira users at my company still wants the "Click anywere on the text to edit" feature, then I think I will go crazy by all the accidental opening of edit mode (I have done it maybe 10-15 times already today, on one single jira issue).

Radu Dumitriu

If it's a democratic environment, then you'll have to obey the majority. If not, try to persuade your decision factor.

Either way, maybe it's time for you - instead of whining - to open up an enhancement request on Jira here: https://jira.atlassian.com/browse/JRA .

kestrelau

I, too, was a bit put off by this feature. GreaseMonkey to the rescue. Assembly of these components into a working script, left as en exercise to the reader. Only finished this about 5 mins ago, so may require some testing to ensure I caught every case. Confirmed working in FF and Chrome.

EDIT: Updated the script to be tighter and handle a couple of missed cases.

-snip-

//Set to fire just after page load so as to catch the correct elements
    //Using setInterval instead of setTimeout because we need to re run this constantly for when Jira's AJAX calls reenable the feature
    var removeCTE = setInterval(function() {
        //For each editable element type
        var editableElms=["h1", "div", "span"];
        for (var i=0; i &lt; editableElms.length; i++) 
        {    
            //For each editable element
            var clickToEditElm = evaluate("//" + editableElms[i] + "[contains(@class, 'editable-field inactive')]");
            for (var j=0; j &lt; clickToEditElm.snapshotLength; j++)
            {
                //Modify the CSS to remove the feature
                var thisClickToEditElm = clickToEditElm.snapshotItem(j);
                thisClickToEditElm.className = thisClickToEditElm.className.replace("inactive","inactive-disabledbygreasemonkey");                
            }            
        }
    },500);

-snip-

function evaluate(evalString)
{
    return document.evaluate(evalString, document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
}

-snip-

Matthias Malstä

The following line of code is kind of dangerous

thisClickToEditElm.className = thisClickToEditElm.className.replace("inactive","inactive-disabledbygreasemonkey");

Better use:

thisClickToEditElm.className = thisClickToEditElm.className.replace("inactive","disabledbygreasemonkey");

The "dangerous"-version replaces "inactive" by "inactive-disabledbygreasemonkey".

This results in an endless replacement operation because the string "inactive-disabledbygreasemonkey" contains the string "inactive".

C.Faysal {CFcon}

i also was kinda stressed by reporters filing an issue...during state "In Progress" they decided to edit some essential info of the issue so the whole thing got a completely different meaning.

i solved this by only letting reporters (or non-developers) edit ther own issues (including inline editing) as long as it is in state "Open"

once it was transitioned to "In Progress" it is not editable anymore..

this was done by setting a workflow property i.e.

Property Key = jira.permission.edit.projectrole

Value = 10001 (10001 is projectrole Developer)

if you need to disable editing in a specific state at all use jira.permission.edit=false

kestrelau

@ Mr P:

Indeed - this bug's been fixed, and we've added a few lines that also get rid of the tooltip that remains, ever enticing the user to "Click to Edit".

(As before, left as an exercise to the reader!)

Matthias Malstä

This is "my" current version (actually "coded" by a friend of mine) of your script:

Features:

- Disabled Click-To-Edit-Feature

- Removed Tooltip "Click to Edit"

- Removed Pencil-Icon

function evaluate(evalString)
{
    return document.evaluate(evalString, document, null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
}

//Set to fire just after page load so as to catch the correct elements
//Using setInterval instead of setTimeout because we need to re run this constantly for when Jira's AJAX calls reenable the feature
var removeCTE = setInterval(function() {
    //For each editable element type
    var editableElms=["h1", "div", "span"];
    for (var i=0; i &lt; editableElms.length; i++) 
    {    
        //For each editable element
        var clickToEditElm = evaluate("//" + editableElms[i] + "[contains(@class, 'editable-field inactive')]");
        for (var j=0; j &lt; clickToEditElm.snapshotLength; j++)
        {
            //Modify the CSS to remove the feature
            var thisClickToEditElm = clickToEditElm.snapshotItem(j);
            thisClickToEditElm.className = thisClickToEditElm.className.replace("editable-field inactive","editable-field");  
            thisClickToEditElm.title = "";
        }            
    }
},500);

Mark Symons

It looks like JIRA v5.2.5 will include a fix for part of this problem:

Don't auto-highlight entire field upon inline edit

Ian Lewis2

This is a very annoying feature. I don't want developers going in and randomly editing descriptions and comments it completely breaks the flow of accountability.

jocelyn fournie

A really annoying behaviour also is if someone else edited the field before you edit it, the changes will be lost. At least, the edit in place feature should refresh the text description before entering in edit mode.

RambanamP

Another way is,if the fields removed from edit screen then that feature can disable.

if field need to edit then crete transition(something like "Update Data") and add fields to it.

Sripad Dattajirao

The edit should be enable only after clicking the pencil icon and not clicking in/on the field. Also once the user realizes they have accidentally clicked an unwanted field their reaction is to click outside the field which automatically saves the changes which is too bad. So the default behaviour should be clicking outisde the field should cancel the cahnges.

RambanamP

issue has submitted for this behaviour, vote up here

https://jira.atlassian.com/browse/JRA-29091

Leos Junek

Hello Radu!

I'm administrator of JIRA 6.1.5 and want to disable inline editing Completely. However, I could not find any field/item in menu Administration > General Configuration. Would you be so kind and tell me, if inline editing can be disabled completely in JIRA 6.1.5 too? And if so, what's the name of the configuration item, please?

Leos

gugglegum

THIS IS SECURITY ISSUE!

It's very annoying when I clicking the links in JIRA task description and html text switches to textarea editor. I didn't found how this may be disabled. I don't need editing by single click -- it's not convenient for me. Typically I have several URL links splitted by lines. I middle-clicking on them to open in new tabs. But sometimes mouse pointer points to small interval between lines and therefore description switches to textarea. At the same time as I use Linux, the middle click in editable area forces to Paste from clipboard (analog of Ctrl-V). And then clicking outside of textarea -- saves this insertion. This way I accidentally inserted random clipboard data and saved this in public task. This data stores in change history, so this can't be completely removed. And also all watchers of task receive this change notification on e-mail... It has security issue because my clipboard may contain password, private links or some private information that should not be shared.

THIS IS SECURITY ISSUE!

Nic Brough -Adaptavist-

The security issue here is the user not being careful, not the sotware.

gugglegum

Software does non-standard user interface behaviour and this comes to user mistakes. This is not user careful problem — user is careful but software acts not as user expected. User has some computer experience. In this experience text not become editable on click (and middle-click) and editable areas not going to submit on clicking outside of this area. I'm not understand why you persist. There are so many people who says this feature is bad. Isn't it good idea at least to give users choice in settings? This is not free service, people paid for this. Why don't you hear them? Why users should use Greasemonkey userscripts to disable this feature?

Nic Brough -Adaptavist-

I wasn't saying anything about how good or bad this feature is (I think we've clearly established that the majority of users like it, but when we run into people who don't, they really really do not like it and really do need to be able to turn it off). I was responding to your suggestion that it is a security issue.

I am simply pointing out that your perceived security issue is with your user not Jira.

The fact is, your user has pasted senstitive information into a text field in a system that they should not have pasted it into. It could have been email, a document, a web page, a print out left on a train, it's utterly irrelevant.

Is NOT the fault of the software, that is the user not being careful enough.

David_Turner

I've noted that Jira 6 now includes the ability to provide distinction of separate screens for 'Edit/View/Create' operations, see: https://confluence.atlassian.com/display/JIRAKB/How+to+Disable+Inline+Editing+in+JIRA+6.x. This is one option, and the Behaviours plugin might also work for some but doesn't always seem to trap AJAX refreshes (e.g. through QuickReload plugin) in my testing. So this JavaScript-based option is great for those that want a more flexible custom solution. Thanks for all the contributions above!

This is my derivative solution I've tried which uses JQuery selectors instead of XPATH; it might not perform quite as well, but this library is easier to use and understand. Very briefly tested in JIRA 6.2 in Firefox and IE8/9 to block inline-editing of all editable fields.

You could modify this script to target only selected fields by changing the selector accordingly (e.g. '#customfield_10004-val.editable-field.inactive'), or selected pages or projects by checking that condition (e.g. if (AJS.$('#project-name-val').text() == 'My Project') { removeCTE(); }).

This script works by removing the 'inactive' style className from editable fields so the JIRA scripts are tricked into thinking the inline edit mode on the fields is already active, and it also removes the tooltip and edit 'pencil' icon, but you still get the hover-border around the field elements which is kind of neat. Of course if a user is particularly quick or sneaky, they could bypass this JavaScript restriction, so it is not a security measure, only a convenience.

You could add this code in a 'script' block in your Announcement Banner or JavaScript file included on the page, see: https://confluence.atlassian.com/display/JIRA/Fields+Allowing+Custom+HTML+or+JavaScript.

// Disable 'click to edit' function.
// Using setInterval to re run this constantly for when Jira's AJAX calls reenable the feature.
var removeCTE = setInterval(function() {
    //For each editable element type
    var editableElms = AJS.$('h1.editable-field.inactive, div.editable-field.inactive, span.editable-field.inactive')
    if (editableElms.length) {
      editableElms.removeClass('inactive');
      editableElms.removeAttr('title');
      editableElms.find('span.overlay-icon').hide();
    }
},500);

David_Turner

Or if you like, this is my more advanced version with project and custom field filters & console logging for debug.

//Disable inline 'click to edit' function
//Using setInterval instead of setTimeout because we need to re run this constantly for when Jira's AJAX calls reenable the feature.
var removeCTE = function() {
    // Enable static variables on 'me' as a function object
    var me = removeCTE;
    
    // Configuration
    if (!me.options) {
      me.options = {
        'targets':
          {'My Project One':['h1','div','span'],
          'My Project Two':['#summary-val','#description-val','#customfield_10004-val']
          },
        'cssFilter':'.editable-field.inactive'
      }
    }
    
    // Create timer instance
    if (!me.timer) {
      me.timer = setInterval(me,500);
    }
    
    // Page init check
    if (!me.init) {
      me.projName = AJS.$('#project-name-val').text();
      if (me.projName) {
        var projKeyArr = AJS.$.map(me.options.targets, function( v, pk ) { return pk });
        if (AJS.$.inArray(me.projName, projKeyArr) &gt; -1) {
          me.init = true;
          me.targetSelectArr = AJS.$.map(me.options.targets[me.projName], function( el ) { return el + me.options.cssFilter });
          console.log('Checking in-line edit removal for project:',me.projName,', Target selectors:',me.targetSelectArr);
        } else {
          // Not applicable to this project, Cancel timer.
          clearInterval(me.timer);
          me.timer = null;
          console.log('No in-line edit removal applies for project:',me.projName);
        }
      }
    }
    
    if (me.init) {
        // Modify each editable element type
        var elms = AJS.$(me.targetSelectArr.join(', '));
        if (elms.length &gt; 0) {
          console.log('Removing in-line edit from fields.',elms);
          elms.removeClass('inactive');
          elms.removeAttr('title');
          elms.find('span.overlay-icon').hide();
        }
    }
};
removeCTE();

kestrelau

Solid effort, much neater. In the time since my original post, I have also become a JQuery convert.

Incidentally, I've unsubscribed from this thread so many times but still get the email notifications. Le tres annoying.

kestrelau

Solid catch, wd.

David_Turner

Result:

&gt; Checking in-line edit removal for project: My Project Two, Target selectors: ["#summary-val.editable-field.inactive"
, "#description-val.editable-field.inactive"
, "#customfield_10004-val.editable-field.inactive"]

&gt; Removing in-line edit from fields.
[h1#summary-val.editable-field, div#customfield_10004-val.value, div#customfield_10005-val.value, div#description-val.field-ignore-highlight]

Daniel Bower

As an Enterprise administrator, and can't stress enough how much I want to see this feature implemented. All too often we have users (that have legitimate access to edit a field) accidentally edit a field because they click on the screen and use the mouse wheel to scroll the page, but end up changing a select list that they happened to click on. When a user is on a VIEW screen my expectation is that they cannot make EDITs. This should absolutely be a configurable option. Removing the field from the VIEW screen is not viable, because we want to VIEW the value, but we do not want to EDIT the value unless we are on an EDIT screen. What other software allows EDITs on a VIEW screen? I shouldn't have to make a hack with Javascript for this, there's a legitimate business need to make the VIEW screen READ-ONLY.

Nic Brough -Adaptavist-

A LOT of software allows edit on view screens - most users like the ability to update things without having to jump through hoops. But it is a valid thing to want to configure, there are going to be times when you want to stop a field being edited so you can enforce an update or process. Have you voted on the issue in Atlassian's tracker? They generally take no account of Answers when looking at improvements and changes, but they do look at the tracker and the votes accumulated.

Daniel Bower

I have to disagree. Especially with enterprise applications. When other software allows edits from a view screen there's some form of edit button (Ellipsis dots for example). I have voted and commented on that issue. We have a user base of several thousand individuals, many of which are non-technical and having options to control how information is entered/modified is extremely important for metrics and general data cleanliness.

Nic Brough -Adaptavist-

A lot of the stuff I work with does it in much the same way. Since it was introduced, I've not heard anything but praise or "didn't notice" from a user base of hundreds of thousands.

Martin Middelmann

I find this feature extremely annoying and disruptive. However I have found a work around:

Export > Printable

Boom!

smile

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-cloud

jira-administration

configuration