How do I disable click to edit description?

[Wp]

This has been very problematic for our team. We put in about 2 weeks to a month planning big feature tickets, we use all the cool authoring tools like expand/collapse and warning messages. However once the ticket is ready to be worked, it not usable. For example, a dev goes to copy a color value out of the ticket so they don't have to retype it which increases the chance of error, but they end up in edit mode, all the expand controls expand in edit mode and they have to scroll the big document to find the spot to copy paste, thus defeating the purpose of that authoring tool entirely. One partial solution would be to make the expand collapsible in edit mode. Jira and confluence operation should fairly identical, we copy from confluence to create tickets when verbiage is ready. Confluence has the explocit edit button because the programmers understood our reading and authoring are so different, usually 2 completely different users in different roles. Another issue pops up when we are planning the subtasks for a story... we started using expand collapse because to set all the fields and content for the subtasks became tedious, everytime you backout of a subtasks and return to the parent, your taken all the way back to the top of this huge story and are forced to scroll 1 to 6 pages to enter the next subtasks. Thus, this "feature" presents a serious usability problem for both "planning" and "completing" work. Scope does change so we don't want to lock editing... but bottom line, edit and use/read mode are two different things and we find ourselves in the wrong mode by accident too often, edits occur when they shouldn't and use mode is, well, unusable.

I cant submit a feature request for some reason or vote for similar, and most of the equivalent threads failed to state the problems this causes, so I thought I'd try this.

[Eric Law]

I too rely heavily on double and triple clicks to select-by-word and line and find myself in edit more for jira fields (typically the description field) all the time.  I'd rather use the pencil, but I get that for many a simple click-to-edit feature just makes more sense.

There appear to be extensions to disable this in chrome at least.

I've yet to examine it closer though, as there is no reference to github code, so fetching the source for inspection delays my use.

The ones I've found are:

no click to edit jira:

https://chrome.google.com/webstore/detail/no-click-to-edit-jira/hgfanlbmojbgkkpkglecefjggnmbmlef

no inline edit:

https://chrome.google.com/webstore/detail/no-inline-edit/nihabdbcgkpmbdcpghkdfpkpbegjgllh

[Eric Law]

The first extension (No Click to Edit Jira) I reference above gets an error when attempting to install.

The second one (No Inline Edit) installs fine, which then allows me to inspect the code.  Code inspection reveals a reference to source code in github:

https://github.com/xduseko/no-inline-edit

I tried it out with Jira Cloud, but alas, it still allows single click on description to edit.

It seems to be trying to disable a plugin called `com.atlassian.jira.jira-issue-nav-components:inline-edit-feature` but there is no reference in the page payloads in the Jira Cloud instance I'm using.

I also notice there is no pencil to edit the description field, so even if I could disable click-to-accidentally-edit, there is no easy way to bypass it.  A chrome extension could, however, provide such a feature or at least allow easy enable/disable.

Alas, I'll have to live with accidental-click-to-edit for the time being.

[Wp]

Yeah, do to these sorts of issues with Atlassian software, I dropped it's use from my various companies and forced everyone to use a shared drive with more general process oriented traditional project management methods. It's insanely better when done right... I dont have to buy an extra plugin if I want formatted numbered headings... excel filter sort controls are superior to Atlassian filters... half the widgets on their dashboard are broken by default and the others are unfixable when you start customizing...its a Frankenstein, resulting from over designing and under engineering as is typical in the software realm... this is just one of many consequences and after bringing this to their attention here, having some of my messages deleted without notification and seeing a complete lack of empathy from Atlassian and understanding of fundamental industrial design, I've come to the conclusion they just don't deserve my business... a paid plugin if you want numbered headings, give me a break.

[Click-to-Edit-is-Stupid-UX]

As someone who is fed up with it, here is a Userscript that disables click-to-edit

https://gist.github.com/fanuch/1511dd5423e0c68bb9d66f63b3a9c875

It's clearly not going away and Atlassian are not producing an option to disable it.

[Eric Law]

Yay! ... and THANK YOU for that JS snippet. It concisely does the trick!

I had tried to see what handlers get called by clicks to enter edit mode, but never thought to stop event propagation to some eventual mystery handler.

Now I can avoid accidentally editing the description when focusing the window or when using double-click to highlight-by-word so I can copy stuff out of it.

I don't see an alternate way to edit those fields, but that isn't a big blocker for me as those fields are still available during Jira issue status transitions.

[Click-to-Edit-is-Stupid-UX]

@Eric LawI was thinking of adding in an *edit* button ;)
Something which Atlassian could easily implement but refuse.

For the moment if you are using a userscripting agent on the browser, I just toggle it off, refresh page, and back to click-to-edit.

Annoying, but I edit a description once every six months. Double click and drag? I do that practically every single day copying code, or IP addresses, or to source a description.

It's almost like Jira used to be for software development ... not sure who it's for now.

[Eric Law]

I spent too much time figuring this out this INCOMPLETE solution.

In our cloud configuration, there are a few larger click-to-edit fields and many many smaller ones.  The patterns used in querySelectorAll() varies for these but a relatively common starting point appears to be an ancestor DIV element with attribute 'data-component-selector' with values containing variations of 'jira.issue-view*' and 'jira-issue-view*'

Several of these *already have a button* of size 0x0!

I ended up with the following javascript snippet that works on just my larger fields to reveal those buttons and removes click-to-edit via your stopPropagation approach.

I open chrome devtools and simply paste into the console.

After clicking edit, however, the input widgets re-write the DOM and the buttons disappear and click-to-edit returns.  It likely needs a MutationObserver someplace to notice the re-write and re-apply the changes (without infinitely looping of course).

document.querySelectorAll(
  'div[data-component-selector^="jira.issue-view.common.inline-edit.compact-wrapper-control"] > div > form > div > div > button'
).forEach(
  elem => { elem.setAttribute("style","width:32px;height:32px;border:solid 1px;appearance:button"); elem.setHTML("edit") }
);
document.querySelectorAll(
  'div[data-component-selector^="jira.issue-view.common.inline-edit.compact-wrapper-control"] > div > form > div > div > div > div'
).forEach(
  elem => elem.addEventListener('click', ev => ev.stopPropagation() )
);

[Wp]

Impressive. So it's already freaking configured with edit buttons, simple settings flag implement.

[Click-to-Edit-is-Stupid-UX]

I'm back with a more COMPLETE solution.

Updated the same gist

https://gist.github.com/fanuch/1511dd5423e0c68bb9d66f63b3a9c875


First state

Note the lock in the top left and the console message on press within description

Second state

Note the pencil icon and on double click, the description now has the text format tools


"Cancelling" the text edit (or pressing ESC key) allows you to press the pencil to lock editing again

[Adam Alma]

Signed in just to upvote this. Great solution, a shame that Atlassian doesn't do this themselves but not surprising.

[Roeland Nas]

How would I 'install' or use this? This seems like a great solution.

[Adam Alma]

Here are the steps I followed to configure this in Chrome:

1. Install the Tampermonkey Chrome extension from the Chrome Web Store

2. Click "Create a new script . . . " from the Tampermonkey extension menu

3. Copy the script from the github gist linked to above at the top of this thread

4. Paste that script into the body of your new Tampermonkey script

5. Click File / Save in Tampermonkey and that should be it

[Zalary Young]

@Click-to-Edit-is-Stupid-UX  thank you so much for the script, it is exactly what I needed/wanted.  <3

[Kristjan Kiolein]

They are building the tools for managers, who decide what tools the company uses.
Managers create/edit tasks more often than developers and it is probably the preferred way of doing things for them even if it makes absolutely no sense for everyone else.

Also, how hard is it to understand the use case of "reading the ticket"....
Seems you need a team of people just for that.

[Dave Mathijs]

Hi @Wp ,

Reading your use case, it seems overly complicated to me. Without any screenshots, I don't really understand what you're trying to achieve with a planning/feature issue.

Basically, there are 2 options:

1. Add the Description field to the Edit Issue Screen and it will be editable, both via the pencil and the Edit button.
2. Remove the Description field from the Edit Issue Screen, leave it on the Create and View Issue Screen. Once your issue has been created, you cannot modify the Description any more.

"Serious usability problem" and "very problematic" sounds to me a Jira issue isn't used what it's meant for.

[Wp]

Just to be clear, my use case is:

• A Developer trying to read and or copy from a ticket without accidentally entering edit mode potentially causing compounding issues.
• A Product Owner planning inherently heirarchical tickets of many types efficiently as they navigated between related tickets. 

If that's an overly complicated use case, then it has convinced me hands down without a question that Jira is no good for agile, project management, waterfall, IT support, Product planning, programming task management, and everything else I've seen it used for.

Why does Atlassian think accidental edit mode enabling of a ticket is okay, but not acceptable in confluence? Has this company actually thought through this, or are they just iterating randomly and differently for the two products based on oke managers preference?

You have to understand how disconcerting and depressing it is, to be a front end engineer designing great interfaces that allow doctors, physicists, etc to do their job super fast and efficiently, but we end up stuck in Jira to do our work and it's actually slower and less safe than managering things with a less specialise tool, like MS Word and Spreadsheets.

I can manage projects under any workflow and using any tool you give me... jira, trelo, Primavera,  ms projects, and an infinite sea of others... however, I can't always do it efficiently because of pretty but poorly designed interfaces... the sad part, and this happens in our products as well, is that ball is often dropped early and this is a good example. Edit mode is sacred in interface design, entering it accidentally is a serious usability problem, period. Could you imagine using a GUI to start a pump, you press a drop-down and suddenly your editing the GUI... you really don't see how dangerous this could be? Granted, we arent using jira to control hardware, but its all information in the end and right now Jira is putting prettiness and cleverness over data integrity and usability. 

So, after this clarification, and a few paragraphs attempting to justify removing or at least allowing us to disable this... what exactly is the official justification for this mode of operation, and what is the justification for not allowing admins to disable it?

Thanks.

[Wp]

Just to be clear. I plan 2 features a week while working spring tickets in parallel, tool different things but required. Bottom line, every single day, I accidentally enter edit mode in jira no less than 30 times a day.

I cant click a hyperlink or drop-down without fear of edit mode... and god help me if I double click a word to copy it... and job help people who don't understand what's happening as well as I do. The problem is compounded in jira because all other software we use throughout our lives, including framing confluence, has learnt this lesson long ago.

In otherwords, the document is unusable in the traditional sense of the word "document" we all know. The ticket description can be used in 2 modes at present, edit mode and read but don't touch mode, making hyperlinks and drop-down and cool active content pointless.

Locking a description field after creation is not a valid solution as it ignores the issue of change.

Does it make clearer sense? You make it sounds like the edit and view issue screens are different, if they were I might not have this problem, perhaps some pop-up is misconfigured. We click the kazan board and see a pop-up, other routes lead to a page view I think... but it starts in view mode, 9/10 reads only want view mode, 9/10 readers are entering edit mode just by touching text.

[Wp]

This has been a pain in my butt for like a decade I hope you understand my frustration, everytime I use this software depending on the client.

There are plenty of solutions to make all happy:

- floating button to edit instead of click to edit, always shown.

- absolute position button form controls so edit is always shown.

- triple click to edit, that will solve the issue for me 99/100 times... I'm okay accidentally entering edit mode once every 3 days instead of 30 times a day.

[Nic Brough -Adaptavist-]

The best "solution" for all of my users is the current behaviour - when you need to edit a field, you click on it, it takes focus and you can amend the data in it.

All of the examples you give seem vastly overcomplicated and unnecessary to me.  You have given great descriptions of the behaviours you are seeing, and yes, it does work that way, but I don't understand why your people are doing everything in such a torturous way.  Have you really built systems and processes that are that hard to use?  Why?

[Wp]

Jira is setup in a pretty default fashion, I can't imagine how that is considered overcomplicated.

Our product department makes an epic, it's usually 6 pages, a classic 6 page document from the agile world. It includes everything from a sales statement to user stories to technical and regulatory requirements ect. 

Our architects then break the epic down to workable stories that are more technical in nature and account for release cadence.

The Our backend, front-end, e2e and infra engineers break down the stories into subtasks.

Once the ticket is ready to work, the text is static 99% of the time from then on out.

Is this really overcomplicated? How can it be simplified? These are things we have to do. We chose to use jira to help us do it, and this feature slows us down. We use the jira provide expand controls to shrink the 6 page document down to one, so that as we are planning substories to the epic, we don't have to scroll 6 pages on every back click, however we enter edit mode and 6 pages are shown again when we just click the document.

I am usually planning 20 features at a time at various stages of completion and doing sprint work, I need a fast trustworthy interface. The fields aren't a big deal, but the description is basically its own form and is the source of the problem.

The only justification I can see for keeping it as is is that you want to click to edit fast... thats fine, use a floating button, triple click to edit description, or equivalent... if you give the expand controls a memory, it maybe a lot less jarring for the user when they do accidentally enter edit mode. Another option is to set the max height and scroll for the description field, that way scrolling a 6 page ticket to get back to the subtasks would NEVER be a problem... now, I have to scroll the same 6 pages everytime I press the backbutton... its crazy, it gives me a headache everyday and there are so many simple fixes Atlassian can do.

[Nic Brough -Adaptavist-]

I wasn't asking about the setup of your Jira, I was asking why you've set up your systems in such a complicated way that makes you want to make it harder to track issues in your issue tracker.

[Wp]

Sorry, I guess I don't understand the question. Which systems are you referring to that are overly complicated? We don't have any significant issue tracking tickets, the issue is preparing the tickets and working with the discrete but groupped tickets, edit and view.

We have recently simplified a bit. We moved out epic, story and subtask planning work to confluence because we can author the hierarchical content there much faster than Jira, mostly due to the issue I mentioned but also just because the interface seems faster and more mature (team edit mode, better history, clearer working doc vs published doc controls, wider margins, etc).

The descriptions are what's most important on a ticket, the most unique field on a ticket.

If there is a simpler way to manage the development of a new large feature intended to span many sprints across all these departments and personel, I am totally all ears. But in the end, when I am in developer mode and not planning mode, I and everyone else would still like to be able to interface with the document in a normal fashion, so I can click a hyperlink (to a design layout for example) or select some text (such as for form control labels written by product department) without the fear and annoyance of entering edit mode by mistake. At the moment, devs usually enter edit mode to copy text or they just retype it which is error prone indeed.

[Wp]

Only the description field is the problem... because it isn't really a field as much as it is a formatted document if you get my intent.

[Wp]

I'm just really tired of accidentally going into edit mode man, nothing complicated about it really.

[Nic Brough -Adaptavist-]

The systems that are over-complicated are the ones that are causing you to think you need to click on fields when you don't.  Why have you got processes that demand your users copy and paste snippets?  Even when it's a good thing to do, why are they not just copying and pasting, instead of trying to edit?

Why are you thinking you can't click on hyperlinks for fear of going into edit mode?  This is working fine for me, and all my users.

I'd be tired of going into edit mode too, if it happened when I didn't need it.  But it doesn't for me.

[Wp]

Why can't we single click a comment in a jira ticket or a confluence article to enter edit mode? Because those programmers understood the sanctity of the single click even when it comes to long text fields.

None of this makes sense? Is there anyway to escalate this case? I want to make sure I'm understood even if they chose to do nothing.

[Wp]

"Why are you thinking you can't click on hyperlinks for fear of going into edit mode?"

Because for the description field, that is very long formatted text, all mouse events usually used to interact with the document... They start with at least one mouse down and a mouse up, almost all mouse events... whether single, double triple click, drag drop to select, drop-down click, hyperlink click, etc, they all start with a click... but I can't reach all the document defaults because the the single click means edit here. Triple click to select a line, double click to select a word, click off selected text to deselect the text, all can result in accidental edit mode and another scrolling action of 6 pages to get to the cancel mode.

[Nic Brough -Adaptavist-]

Well, you could try raising a request to get it turned off, but as it is the intended direction of field-handling in Jira, I don't think it's going to get very far.

I'm a bit stuck on what the problem is too - if I want to highlight text in the description, I click and hold.  If I want to follow a link, I click on the link. 

I understand that you're struggling, but I'm not entirely sure how or why, so I'm a bit stuck.  I'm afraid everyone I've worked with regards click-to-edit as an improvement on having to open a new screen or triple-click or, or, or...

[Wp]

It is an improvement for fields, excluding long text... which is why comment fields and confluence article fields still do not use it. What would happen if I click to edit someone else's comment? Click to edit doesn't work everywhere, seems many at Atlassian understand this but not the guy that edited the description controls, which tend to be team text like the confluence.

"if I want to highlight text in the description". Me too, but there are two scenarios where it can result in entering edit mode... (1) say you selected too much text, you click off to deselect and start over, your in edit mode (2) drag and drop is a slightly error prone operation, sometimes folks will drop and repickup something so fast that it's almost unnoticeable... all system I've ever used in my life understand this, and they are fault tollerant to it.

Again... click to edit and submit individually instead of always edit and save on fields is fine, i understand why folks like it, but the description is not a typical field, it needs to be thought of like a document... the the comments or and article but unique, because it isn't user specific.

I dont understand how your not following me man, ill try to upload a video in the near future... the click to edit is interfering with standard usability of the document.

[Nic Brough -Adaptavist-]

>click to edit and submit individually instead of always edit and save on fields is fine, i understand why folks like it

Thank you, at last!

Again, I really don't see any of the problems you are describing here.  You're giving me essays and walls of text that no-one else is reporting, so I'm just lost. 

[Wp]

To clarify, in an engineer interfacing with 200 applications a day... I'm only complaining here on one company product on one field, that I cannot select text without fear of a unneeded 6 page scroll.

[Wp]

1 field, not all fields, 1 field... "description".

[Nic Brough -Adaptavist-]

Which then begs the question of why you've got six pages of text in an issue-tracker when it should be in a documentation system, or why that should work differently to every other field in the system.

I can select text without fear o a 6 page scroll in Jira long-text fields without problems, I generally choose not to, because it's not the right place to be writing essays.

[Wp]

My response disappears... assume someone is deleting them... you win.

[Vitaly Belevtsev]

Dear Nic Brough,

You keep saying that you don't understand why people struggle with this (indisputably horrible) feature of single-click-to-edit. Please excuse me for pointing out that - even if you do not understand the problem, there are multiple people that struggle with it. It's a fact. Wouldn't you want to help all those people even if you don't feel their pain?

You can look at this as a form of disability: you personally don't need ramps and extra-wide stalls and braille labels - but it's nice to install them anyway.

Now, to the whys. It's rock simple, really.

1) I have two windows side by side; I want to switch focus to the Jira window. I click on that window and accidentally hit the description field. It goes into the edit mode - thank you very much;

2) I want to click a link in the issue description and miss, hitting plain text - it goes into the edit mode;

3) I am editing another field in the issue, and I want to end editing it. To do that, I need to click outside the edited field. I click on what appears to be blank space, but it is in fact the description field. It goes into the edit mode;

4) I am reading through the description, and I accidentally click the text (a habit from text editors, where you click to put the cursor to the desired point). It goes into the edit mode.

How many examples do you need to accept that I need an option to turn this single-click option off?

To make it worse, when I edit any other field on the Jira page, I can end editing by clicking outside the field. This action does not work for the description field (why?). The Cancel button is also not visible, because some genius put it _inside_ the scrollable edit area - I need to scroll through the whole description to find and click the Cancel button.

You say that "everybody you've worked with" like this functionality. I am happy for them. Now, could you please recognize that some other people do not like it and give us an option to switch to some "button-to-edit" mode?

In fact, the best thing to do would be to lock _the whole_ issue. Put it into read-only mode by default, where it's a passive, safe read-only html page. Then you can click an "unlock" button to make it fully editable.

Thank you for your time and understanding.

[Eric Law]

ignore post - unable to delete?

[Wp]

Yeah, 5 years ago Atlassian support was decent, now it's not worth a dime. The amount of money they must be making... never developing anything new... seems a lot of the internet is devolving back into AOL, Atlassian is just a symptom. When you corner the market and become the standard only because you were first, then just sit on it holding up the progress of humanity or plain old devolving it, well I might not call you evil but I'm sure thinkin it... and gaurantee not giving a dime.

[Hamza Azghoul]

Hi Nic, 

Here you have another person that thinks that the one button editable Description is not as usefull as you think. If in your case that is a good feature, then i am happy for you, but there are a lot of people that don't find it as good, and i am one of them. 

I don't need to give you more explanations on if it's good or not, if i don't like it then i don't, and as a Tier A Company and you as a community leader, you should try to understand the people that pays for your services better, and try to give them a solution or a workaround to the issue they are facing. 

The only valid explanation i should give you is that in my companies case it's illegal to change or modify the actual description. 

We need a solution to this !!!!! can you do it, or should we start looking elsewhere.

[Roeland Nas]

+1

and +50 from my company.

I just want to be able to select a piece of text from an issue or double click a value that I need without entering edit mode. Time consuming, since when in edit mode the text is on a different place again (loads the tools above, so the part i need is gone).

Come on, just let me easily copy a part of the description!

[david.tran]

Double clicks can, at times, cause it to go into edit mode.

Click-to-edit has its place, like areas where there's a dropdown list. For paragraphs of text, where you're commonly clicking around, highlighting, un-highlighting, I don't think it's very helpful and providing responses that equate to, "You're wrong because you don't highlight text the way I do" seems out of touch with the user base.

Also, the implementation of this is inconsistent throughout JIRA. You need only scroll down to the Comments of any JIRA case to see there is an "Edit" link to edit your comment.