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

[Radu Dumitriu · Accepted solution]

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.

[Radu Dumitriu]

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

[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

[Roberto Torres]

I need admin permission for this we need an individual option this feature is extremely useless and annoying

[Nic Brough -Adaptavist-]

I think this entire conversation established that this feature is useful and highly appreciated by most Jira users.  A decade ago.

[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.

[gugglegum]

I'm not agree. The problem is that the same user action may have different effects. For example, middle button in Linux -- is the analog of Ctrl-V and this cannot be disabled. Also, middle button on link in browser -- is opening link in new TAB. You add middle button to start editing text. This makes an interference effect. Two standard (system) behaviours intersects with your application behaviour of middle click -- and this makes a collision. Collision -- it's not user careless. At least NOT ONLY user careless. This application behavour creates conditions increases the likelihood of errors, leading to a breach of privacy.

Look at this screenshot: http://joxi.ru/tMIpUxjKTJASNo-DNVo

[Nic Brough -Adaptavist-]

Well, frankly, no. That's not the behaviour I see on my Linux box. It's different on my Mac and it's different on the rare occasions I have to downgrade to Windows. And, on all OSs, your middle button is completely customisable.

And, sorry, it absolutely IS a user fault. If information is sensitive, you shouldn't have it ready to paste. Or you should be careful where you're pasting it. Again, my point is that your user could paste it into anything and breach security. The software is utterly irrelevant, it's the fact they're not being careful ebough.

Is there some part of "Do NOT paste sensitive information in a random app " that is confusing things here?

[MattS]

When I make a mistake and paste my bank number into an online app, I'm annoyed at myself for doing it and at the app for allowing me to do it. I agree that some people want this feature disabled to stop them making mistakes. I don't agree that this is technically a "security issue". No hacker can make me accidentally paste my bank account into an online app, this isn't a phish scam

[gugglegum]

Security issue is not only possibility of hacker attack. It's any possibility of violated privacy. If user clicked to edit, pasted private info into textarea and clicked Submit -- there is completely user fault. This can't be done accidentially. But if user middle click twice in big text area and then click once anywhere outside this area -- this easily can be done accidentially. Even my cat can do that! Should application have a small protection from this? I think yes.

I completely don't agree that I should always be aware of copying sensitive data into clipboard. In normal situation I have no chance to compromise my clipboard accidentially. And this is normal when complex passwords are not typing directly but copy-pasting via clipboard.

It's easiest to blame the user carelessness. Difficult to create a user interface that helps to avoid user errors and does not cause them to appear. Your interface provokes users to make errors that might lead to a breach of privacy. May be it's not security issue in traditional understanding but it's somewhere close.

[MattS]

A usability bug with far-reaching consequences for sure.

[Nic Brough -Adaptavist-]

The usability could be improved. (And, click-to-edit configuration could and should be improved)

It still doesn't make it a security issue. The security issue is your user pasting things into the wrong place.

>Your interface provokes users to make errors that might lead to a breach of privacy. May be it's not security issue in traditional understanding but it's somewhere close

No, the user interface makes mistakes slightly easier. It doesn't "provoke" the user into doing something insecure in the slightest. It simply cannot do anything about the fact that your user is doing something careless and insecure. It's nothing to do with traditional understanding - that understanding has always been "you shouldn't paste sensitive data into the wrong application".

[gugglegum]

Yes, you shouldn't paste sensitive data into the wrong place but I point that this place may became wrong very unexpectedly for typical user.

[Nic Brough -Adaptavist-]

Good, so you accept it's not a security issue in the software, it's a security issue in the users. Thank you.

[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

[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 < editableElms.length; i++) 
        {    
            //For each editable element
            var clickToEditElm = evaluate("//" + editableElms[i] + "[contains(@class, 'editable-field inactive')]");
            for (var j=0; j < 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-

[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.

[Daniel Bower]

Based on this thread and the issue that's been open, there's several people who noticed and don't appreciate that there is not a system setting to control the functionality. End user may like the feature, but it impacts administrator and managers that are watching metrics. The 162 votes on the issue probably translate into a pretty large user base, I have licensing for several thousand users alone.

[Nic Brough -Adaptavist-]

If you're having that many problems with it, turn it off, and hope Atlassian add it on a field-by-field basis (unlikely, given the vast amount of customers who either praise it or haven't noticed)

[Daniel Bower]

How would I turn it off? There's no system setting to do so. And doing it field by field is overkill, by project would make a lot of sense.

[Nic Brough -Adaptavist-]

Admin -> General configuration - there's an option near the bottom for "inline edit" I suspect you'll find Project level even more unlikely - that would lead to horribly inconsistent UI for users (why can I edit in project A and not B? Field by field is a better solution according to the UI people I've spoken to - "Oh, I can't quick edit Description or summary, but I can do dates" - apparently that seems smoother) Having said that you can disable it, reconsider if you have JIRA Agile. The flag only applies to core JIRA fields (i.e. issue view). JIRA Agile has similar functionality (in a more limited fashion, so it may not affect you too much). Just have a quick play with Agile before you turn it off to check it's not going to prompt your users to complain.

[Daniel Bower]

I'm running v6.0.8 currently. I don't see the option to disable inline edit in General Configuration. We're planning to upgrade to in the near future, would the newer version have the option? We do run JIRA Agile, so I would test that in our sandbox environment before making the change in Prod.

[Nic Brough -Adaptavist-]

Not sure when the ability to disable it was added - I want to say 6.0, but as you don't have it, that has to be wrong, so I'm going to bet on 6.1 first, and if not there, then definitely 6.2 because that's the one I looked in (I couldn't remember if it was on the main "general config" screen or the advanced settings)

[Daniel Bower]

Ability to disable inline edit has been removed from 6.0+: https://confluence.atlassian.com/display/JIRA/JIRA+6.0+RC+1+Upgrade+Notes#JIRA6.0RC1UpgradeNotes-Disablinginlineeditnolongerallowed The recommended work around is to remove Edit permissions and create a loop-back transition called "Edit" for every status which isn't an acceptable workaround. Looks like we'll just have to live with it unless Atlassian decides to fix this defect that allows Edits on a View screen.

[Nic Brough -Adaptavist-]

Well, it's back in later versions.

[Nic Brough -Adaptavist-]

And it's not a "defect", it's an "improvement"

[Daniel Bower]

I know you keep calling it that, but the documentation for 6.3 shows that the functionality now requires a user to mouse-over a field and then click a pencil icon to edit. So they fixed the bug that allows editing on a what should be a read-onlly screen by requiring it to be a more deliberate action. This is exactly what I want as an administrator, and what our management team wants, so I'll plan to push to upgrade sooner since the newer versions no longer have the click-to-edit that's been causing us problems.

[Nic Brough -Adaptavist-]

Yes, that is an improvement on the original interface. It's still NEVER been a defect, you're misusing the word to mean "something I don't like, but the overwhelming majority of users want". The bit I was talking about as in "it's back" is the flag to disable it globally.

[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) > -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 > 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.

[David_Turner]

Result:

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

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

[aware74]

This is absolutely awesome. Thank you for this.

Is there a way to enhance this so that it only applies if you're a member of a particular group?

Yep, totally understand that this should usually be done with a Permissions Scheme. But we have 15 users who shouldn't edit, and 2,000 total users, so we would have to maintain two groups, one for all users, and one for all users minus the 15, to be able to allow anyone to view, but to prevent just those 15 from editing.

Thanks,

Mike

[Mike_Rosoft]

It's pretty convenient to be able to edit the page inline. But it's extremely inconvenient to automatically go to edit mode by clicking the field, and as a result 1) not to be able to copy text from the page, and 2) possibly inadvertently edit it without intending to. Several users have requested the possibility to edit *only* by clicking on the edit icon and not by clicking on the field itself (which Atlassian has summarily ignored).

So is there a Greasemonkey script to:

* Remove automatic edit mode on clicking the field; and

* Keep edit icon, and keep edit mode on clicking on the icon?

[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.

[jocelyn fournier]

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.

[Ian Lewis]

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.

[Matthias Malstädt]

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 < editableElms.length; i++) 
    {    
        //For each editable element
        var clickToEditElm = evaluate("//" + editableElms[i] + "[contains(@class, 'editable-field inactive')]");
        for (var j=0; j < 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);

[Matthias Malstädt]

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

[kestrelau]

Solid catch, wd.

[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.

[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 .

[Nic Brough -Adaptavist-]

I suspect that the entire area reacts to the click because that's what users expect when editing. I do think the testers will have run into the trying-to-select problem, but I don't think people copy and paste out of Jira anywhere near as often as you think (everywhere I've worked, people just say "read Jira-123" instead of copying bits out). I'm mildly curious to know why you've clicked on it 10 times today, when I've spent days with our test system without triggering it accidentally at all.

p.s I like the idea of being able to disable it as a user preference, and at three levels - off, icon-only, icon and text. I'd vote for that, even though my preference would be the current behaviour, it would be really nice to be able to lower the functionality for people using it differently to me.

[Jimi Jimi]

Radu: I will most definately register an enhancement request regarding this. I just wanted to clearify how it works now (since I have no admin access, and anyone who does is on vacation for a few more weeks).

Nic: I don't copy text from Jira that often either. The main reason that I have accidently triggered the feature is that I simply click on text alot, to select or deselect text. I often do this when I read some text, to make the text easier to follow, for example when there is a to-do-list, and I want to read each line, check if it is done, and then continue on the next line. Without being able to easily select and deselect parts of the text, reading text will be much more work for me. It is just the way I do things, and I want to continue that way. But this "Click anywhere on the text to edit" feature stops me from doing so.

[Jimi Jimi]

I just registered this feature request:

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

Feel free to up vote this issue, if you think that people should be able to configure this in more detail, even if you personally don't have such a need.

[Radu Dumitriu]

I just voetd for it.

[Nic Brough -Adaptavist-]

Mmm, I take highlighting blocks of text for readability as a sign that I need to adjust my colours or monitor settings. But I completely understand the "using it as a bookmark" trick.

I've voted too - I really do think it's worth being able to configure for personal preferences.

[Mark Symons]

I cast my vote.

OK.. maybe I should ask this question separately, but has anyone tested Inline Editing with the Behaviour Plugin? I recall Jamie Echlin saying that he was worried that things might break... but I think that was said when the new feature was first made known to people and before anyone had had a chance to have a good play.

[Dmitry Savvateev]

Editing description is quite a rare operation for me - I mostly write comments for the issues I work on. Therefore I really dislike the "feature".

[Renjith Pillai]

Then disable it.

[Dmitry Savvateev]

I can't change it globally, and GreaseMonkey-based solution seems too complicated.

[Steve Kuo]

This is an absolutely annoying feature. Everytime I click on a text area it enters edit mode. Worse, if I accidentally press a key then the enitre text is repalced (since it defaults to select all) and lost.

It's annoying Ajaxy features like this that many people on my company just want to use Bugzilla.

I tried clicking on the gear in Jira and there no option to disable this.

[Nic Brough -Adaptavist-]

@SteveK - funny - this is a function that's actually persuaded a block of my users to reconsider their long-term preference for Bugzilla and finally embrace Jira with the rest of their colleagues.

As mentioned several times already, you can simply disable it in the global options.

[Dmitry Savvateev]

It's a controversial feature that should not be enable by default. At least until there is an easy way to turn it off on per user basis.

[Daniel Bower]

Voted. Would love to be able to disable at the project level. Since we occasionally have users click on the screen and use the mouse wheel, in an attempt to scroll the page but end up changing a field value unintentionally. I don't understand the difficulty of clicking Edit to edit an issue.

[Martin Middelmann]

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

Export > Printable 

Boom!

[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

[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!)

[C_ Faysal]

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