Please add the EDIT button to the new view! I always use the Edit button because I can update multiple fields at once and then it is cataloged as ONE item under the History log, making it much cleaner and easier to read.

The thing that is strange to me is that Context fields seem to behave as if they are Hide when empty fields.

If I have an empty field in both View and Edit screens, but positioned in Context fields on the Layout, it will be shown even when empty.

If the same field is only on View screen it will not be shown when empty.

But if the field is positioned in the Description fields on the Layout, it will always be shown, even if not present on the Edit screen.

Seems like a bug, honestly, because one would imagine only the Hide when empty fields should be hidden when empty.

In terms of the issue as originally described in this request, could the watchers of this issue let me know if they still face these problems? I could not reproduce the following:

Given that fields that do not have a value do not show up, this means that it will not be possible to set values that are otherwise not available to change on transitions, nor is it possible to set those fields without performing a transition.

Here is how two empty fields appear on the New Issue View when I view the issue (i.e. not on a transition screen). Their placement on the screen has been determined by how I configured its layout:

Because comments create pressure...

I can reinforce the arguments mentioned before.

It's so much worse, we can't comprehend why there are edit screens in existence. This is not logical and now forcing millions of people to the new issue view. You don't see us suffer. But you should. I am not exaggerating, we just arrived in our cloud instance after leaving our beloved on-prem environment. There are needs you know about. Can't stress this enough. We don't want work-arounds to be our "solution" because they aren't.

I pick up some key words from the comments before.

• (very, VERY poor UX decision...)
• Workflows will more and more hard to maintain
• PLEASE don't remove OLD VIEW until EDIT VIEW is available. That is our only work around.
• The workaround is not extensible for a customer of our size (>1,100 projects, close to 1MM issues) and does not fit into our strategy for template reuse.

You are making the experience worse. That's the wrong direction. I kindly ask you to overthink your UX strategy, or enlighten us with your visions, which aren't yet to come.

My apologies for my emotional, but honest opinion to this topic.

This shouldn't be an open Issue for years...

The new paradigm also prevents users from easily copy and pasting just about anything on the page (very, VERY poor UX decision...). We really miss the old edit issue screen, it was simple and it also served as a visual queue that you are editing an issue. Now others and I, on multiple occasions, have accidentally went into "edit mode" without realizing and modified the description and/or other fields, instead of being able to select and copy what the user wanted from the ticket. 

Maybe go back to the table and rethink this one, its not fully baked yet... 

Global Transitions are one possible solution, but honestly it can be the maintainable solution.
It is solution already used to restrict Edit operation depending on Status and/or User Role. If we have to replace the default Edit screen too by Global Transition, Workflows will more and more hard to maintain.

Yuan Jiang  I haven't seen any movement on this since last year and I'm tracking it's progress because this is really important to our use of this tool. Does anyone know if the Edit (button) View will be added back soon? I should add preventing the email deluge online forced upon us at conversion by not having the edit view is the reason we need this back. We have to go to OLD VIEW to EDIT more than one field to reduce emails. PLEASE don't remove OLD VIEW until EDIT VIEW is available. That is our only work around. Thanks for any update you can share!  

yes please!

Interesting approach.  Still untenable.  If the cloud instance merely had 1 issue type to 1 screen scheme, then multiple EDIT buttons could be added with a condition to only show for issuetype = <specific value>.  In our cloud, when issuetype = Story, we have 11 Story screen schemes.  The Old issue view allowed admins to associate a specific Edit screen.  The workaround is not extensible for a customer of our size (>1,100 projects, close to 1MM issues) and does not fit into our strategy for template reuse.

Paula,

I would like to suggest solution to your problem.

You can create as many global transitions as there are different issue types using same workflow. Jira does not limit number of global transitions in a workflow.  Global transition has same attributes as any other transition in Jira (including Validators, Conditions, Post functions). You can connect specific screens to specific global transition and then use Condition for Issue type Value.  This will make the right Global Transition show up on correct issue, while it will also hide all others.  You would have to name these global transitions with unique name (EDIT 1, EDIT 2, etc)

We are using Global transitions with many other conditions (Status, User Group, etc)

The global edit can be used as a workaround provided your environment is set up as 1 workflow to 1 issue type.  As soon as you have a workflow assigned to multiple issue types or use with multiple screen schemes, this workaround falls apart. The global transition can be associated with only 1 screen.  I cannot implement this workaround unless I bloat the number of workflows and exponentially increase my maintenance effort.

Yep, brilliant!

I tested this and it works quite well, thank you greatly for the suggested workaround, Lev.

I am not sure everyone is aware, but there is a simple way to create edit screen functionality in New Issue view.  You will have to be Jira Admin and have access to Edit Workflows.  Just use Global Transition (My term for this function) with Dedicated Edit Screen and control access to this screen through transition condition.  We just added this global transition to all workflows that needed EDIT screen and connected our original Edit screen to it.

Unfortunately I can not add screen shot of of our workflow here.

So Here are step by step instructions.

Creating of global transition is al little tricky (there is a known bug here). 

1.  In Workflow editor Add Transition Using Button (Add transition). DO NOT create transition by starting on existing status.  You will get "Add Transition" Dialog.

2.  From Status select "Any Status"

3.  To Status Select "Itself"

4.  Name this Transition "EDIT"

5.  Select your original Edit Screen under screen field.  Close Dialog.  You should see New Global Transition.

6.  Publish this Workflow (There is bug here.  Publish before next step).

7.  Edit workflow again.

8.  Select new Global transition and create Condition for group access (optional)

9.  Add Post functions and/or validators (optional)

10.  Publish again.

It is actually very simple.

You will get EDIT button to the right of issue status in New Issue vIew (or Edit will be in dropdown under Action Button, if you have additional global transitions or transitions back to the current status (loop transition)

You are welcome.  Comment back if you are experiencing any problem with this method.  We have been using it for few month now.  Works great and no complains.

If you consider that there are Teams in Organizations that handle all internal change/maintenance requests (as well as all external Client change/maintenance requests) then the Team must be Watchers on all of these issues. This already barrages such teams with notifications. Now these notifications are multiplied in magnitudes when such Team members have to update single field Start Dates/End Dates/Priorities/etc.

There needs to be a way for Users to update multiple issue fields and submit those changes as a "batch" update for the issue (aka, the "Edit" screen"), without triggering an Issue Updated event for every single field update. And forcing a User to modify multiple fields for a single issue using "Bulk Edit" to avoid spamming Watchers or Notified Parties is not acceptable for Teams that deal with hundreds of issues a day with a variety of contexts requiring individual consideration when scheduling out dates. As in they cannot bulk update 30 tickets at once when they need to review each request and schedule based on various dependencies from various projects.

Just a review: in the "old" days it was possible to hide all the fields that didn't have data in them. I think that the thought behind this was to minimize the clutter. If you have an organization that has a lot, and I mean a lot, of custom fields, then you could organize it in such a way that it was in neat tabs. You can still use tabs. But because the screen is now divided in to 2 columns the tabs are really small now. 

The problem is that it is not possible to adjust this. It would be a great idea to be able to alter the view like in a Confluence page! Can you imagine how wonderful that would be?!

Just echoing what others have said. The convenience of each edited field saving instantly does not outweigh the inconvenience of every watcher, assignee or reporter being pinged for each single change made in an issue vs. being able to press Edit and make multiple changes, Save once and all others receive a single email. It is making too much noise and preventing recipients from distinguishing between critical updates and this noise. This should be treated with greater urgency as it is creating inefficiency. We are currently trying to determine an alternative means of communicating as creating watchers is not creating problems. 

"e" hotkey doesn't work for us

+1 - Not having an edit view means that all our project views must be updated to be able to edit fields post creation since all our custom fields were defaulted to "hide when empty'.

+1 to this.  Current workaround has been to use the "Bulk Change" with a single item so we can set multiple values at once and not spam all of the watchers.  Inline edits don't feel transactional and make it more difficult for auditing purposes.

Until this problem can be fixed, in case it can help, I've noticed that adding the following suffix to the Jira issue's URL allows opening it in the OLD view right away:

?oldIssueView=true

Same problem for me as well.  I wish I could link to my ticket but I can't Edit this issue.

https://mitel.atlassian.net/servicedesk/customer/portal/4/DEVOPS-7428?created=true

Can't you change your issue layout in your project to have the fields you need always displayed to not be in the "Hide when Empty" section?

My understanding is this: If a field is in the View screen, then it is available in the Issue Layout screen to place in various sections of the issue...Description Fields (always shown), Context Fields (always shown), Context Fields (hide when empty), and Hidden Fields (always hidden). If the field is also in the Edit screen of the issue, then the displayed field will also be able to be edited inline.

Of course this doesn't allow you to effectively use a field if it's in the Edit Screen and not in the View Screen, but I'm don't understand the value of a field that works like that anyway.

This is sad.  I've held out using the old issue view specifically because I prefer using my custom-made edit issue screen instead of relying on inline edit.  I'm disappointed that I may be forced to migrate away from my custom-made edit issue screen because Atlassian hasn't implemented this feature in the new issue view, almost 2 years after launching it in beta.

The issue has been labeled as "post-transition-longterm"... seems that there is no interest in fixing that in the near future...

Hello, I totally agree with this issue. At the end of March 2021, new screen is expected to be enabled for everybody. But we need the EDIT button. How can we add it?

Well, more notifications you send, the faster you will exceed your free e-mails limit and you will have to pay extra to increase that limit.

In addition to the reasons above. Inline editing triggers messages to watchers, assignee and reporter for each update. If you need to update several fields, this may spam them with multiple unnecessary messages. A one time update with the edit screen was the best option in this case. Atlassian is removing too many good features in JIRA.

I agree with the description, for the stated reason AND for the following reason:

Without an EDIT button, we can't lock certain fields (making some fields VIEW ONLY and others editable).  This is CRITICAL.  If EVERY field can be inline edited, then you've taken a way a HUGE piece of functionality that we relied upon in the Jira Server product. 

We need the ability to control if a field is editable or not on the displayed screen.

Mark

Editing hidden fields should be handled by the comma dialog (""); but that feature also does not work in the new issue view.

Is there any estimate on when we can expect this functionality?  The new issue screen is essentially useless to my organization without the ability to either have and "edit" button to be able to edit all fields or to have blank custom fields visible on the issue view screen.  Until this is resolved we cannot switch to the new issue view.