The Problem still exists with using issue security. The security level is only editable when creating an issue, or while a workflow transistion when an edit screen is linked to the transistion. You can remove the security level when some is set before, but you can't add the security level later on if the reporter forgot to set the security level initially!

That is because the "field" (it is actually a button on top right in the new issue view) is not displayed by Jira when security level is not set, and you can't find it in the "Issue layout" of the new issue view, because it is neither any type of "field" nor a "custom field", that means also not in the "hidden fields" section.

If you try to find the field, then Jira says that this field exists in the field configuration and it is present on this issue - but it is not present in the new issue view!!!

The problem is also described by some other person [in this community question|https://community.atlassian.com/t5/Jira-questions/Access-an-issue-in-edit-screen-edit-link/qaq-p/1827234.]

There is no workaround for setting the issue security level afterwards. You can only move the issue to a status, where you have assinged a screen to a specific transition. If you don't have one, then you have to change your workflow.

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.