Transitioning all Jira Cloud users to the new issue view

[Greg D]

@Rob Horan  you can do that in both New and Old issue view by having it only on the Create screen and View screen (but not the Edit screen) in the screen scheme (there are 3 screens that you can apply to a single issue type).  New View still lets you maintain a View and Edit Screen (it just no longer has a modal for the Edit screen... so if something is just on the View screen and it doesn't have a value, it actually does not show at all.  If it does have a value, it is view-only and you cannot click it.  The only thing that you cannot do in New Issue View is have a field that can only be edited, but is not on the View screen (since there is no modal)... so that is where the transition screen comes into play.

[Rob Horan]

Sorry, youre right, I was getting my use cases mixed up!  I was having a conversation with someone about this and how it all worked. 

The case I described was the problem with having an 'edit screen' when there is no edit screen any more. 

Kind of odd terminology - why have a 'screen' when there is no screen?

[Liz Medsker]

Not here to complain about the new issue view. I'm having totally different issues. I can't find any easy way to actually move my account to the new issue view. Everything I see says to do it in my "Profile" settings, but going there takes me to my Atlassian Account settings, NONE of them have anything about the new issue view.

Anyone else stuck like this?

[Greg D]

@Liz Medsker I think they keep changing the name of that section.  Unless something else is going on with your instance (or you are on server/data center), when you click on your picture, it is the "Personal settings" that you need to go into (which is just for that particular Jira instance).  Alternatively you can go to https://<your-site-name>.atlassian.net/secure/ViewPersonalSettings.jspa to get there directly.  It is towards the bottom and called "Jira labs".

[Liz Medsker]

@Greg DAh, yes!! That worked perfectly once I went directly to the URL. I guess we'll see how I feel about this new view. Thanks so much!

[JAMES PEYTON]

@Matthew Canham I'm concerned the default text renderer is not supported in new issue view. Hyperlinks embedded in multi-line text fields are no longer clickable when shown as Context fields. Embedded hyperlinks render correctly only if added as Description fields in the issue layout, and that is a blocker where we have multiple tabs for an issue. Will this be fixed?

[Austin Chambers]

Two years ago, when I first encountered the new issue view, I was deeply dismayed. Like some of the others here, I had to instruct or manually opt out of this new view for every user. It was a tremendous pain, but it was necessary because information & workflow affordances got hidden in the new view. 

As an engineer, I understand the reason behind forcing this new view down our throats. Atlassian only wants to maintain and support one way of issue presentation. However, this should not be done until some of the most basic capabilities are at parity. So I hope that work continues in this direction. Reviewing updates to the new issue view in the past two years gives me some hope, as I note some progress... 

I've managed to get the new view close to usable with two exceptions: 

1. The "Configure" link shouldn't be shown when the user doesn't have permission to configure issue fields for the project. In most other examples (e.g., the “Add Apps” dropdown), JIRA adopts a convention of not showing an action link/item when it's not possible to perform an action. It is inconsistent to show it here in a disabled state with a tooltip to "ask your administrator." Moreover, it's confusing to the end user. Why show something and introduce more clutter to the page if that thing can't be used by the end user? If I can't keep JIRA simple, then non-engineers won't use it. If non-engineers don't use it, the value of the system goes vastly down. Help me keep it simple by removing this superfluous disabled item. 
2. The “Open” dropdown is a step backward for those that have really simple workflows (which, in general, is a good idea). Previously, the issue status (Open, In Progress, Closed) was always apparent because it was labeled in a field (i.e., "Status: In Progress") and the action was always apparent because it was visible in a button (i.e., "Resolve" or "Reopen"). Now it is a button that says "Open" with a dropdown. The change results in (a) confusion about issue status, since it’s no longer explicit, (b) confusion on how to take the next step, since it’s no longer visible (you have to know to click the dropdown first). Both of these could be handled with training, but it’s not ideal. Moreover, even after training, you’re now subjecting the user to two clicks instead of one to bring up the next workflow step. My suggestion here is to allow Issue Status to be a field again (even if you decide to hide it by default), and allow workflow steps to be buttons (maybe explicitly via a setting, or to simply show a button when there is only one or two actions you can take. I get that it looks "neater" in this new way, but it impairs usability and how intuitive the interface is, which is very important to me as I prepare to roll this out to a new audience. 

Please continue to make good forward progress on this view so that we don't lose too much by moving to it. 

Also, from an administration perspective, I don't want any banners to appear about switching back to the old view. Before my rollout, I want to set everyone to the new view without an option to switch back. These are new users, so I want them to have one view and be done with it. If you entice them to switch back to the old view, then I've got more work down the road when it's forced in 2021. 

[Mark Thompson]

Basically I need grouping to be functional before I can really even look at this new tool.  I personally want a migration tool that allows me to take a tab and make it a group.  Manually creating groups for 30+ projects = NOT FUN.  

Some projects use different flows/field schemes that may not have all the same fields.  Right now it looks like if I have a field that is not available for all types it looks like I can't add it to the side pane.  

The fields that are displayed in the side pane make no sense based on how my fields were configured in the old view.  We need to be able to have fields show whether they have a value or not.  We don't set the values on ticket creation.  They get set later and are interacted with quite a bit.

Oh and create subtask in my implementation - not good.  That has to be removable and not a choice for my users.  The buttons you have fixed at the top are not what we would use.  Only the attachment is useful

You took away the type.  I'm an admin and can't see how to change an issue from a bug to an enhancement.  How are my users going to know how to do it.  This is something that happens often in teams that have non-engineering people.  Things have to be obvious or I get asked "How To" questions.  I hate "How To" questions because it means the tool is poorly designed.

This looks roughly the same as the last time I looked at it.  Didn't work for me then and doesn't work for me now.   How are these issues going to be resolved so we can have a seamless migration with all our old functional behavior?   

Really don't want to hear migrations are painful.  I've worked for numerous companies that had seamless upgrades.  You can do behavior changes without causing pain to your customers.

[Radek Antoniuk]

On top of all other comments, please disable the warning about "moving to new issue view".
There is a "deadline" set on 31st of March but as discussed in this thread, there are still bugs, some functionality is not even implemented yet and marked as "Coming Soon".

So the effect is that this warning is actually not actionable and the "remediation" options  are unusable as they are "coming soon".

[Ricardo Gomes]

@Matthew Canham ,

There needs to be clear documentation about what the differences between "old view" and "new view" are in terms of functionality. I don't care about how I view the ticket - of course, improvements are always welcome - but we all know this isn't just about a "new view". We're talking about a re-architecture that will cause loss of functionality to all Jira users.

Again, now the question is - 

Where is the documentation that shows me A to A and B to B so that as a Jira administrator, I am able to make the correlation and have a clear picture of what functionality I'll be loosing so that I can take the appropriate next steps - whether that is adjusting my configuration OR leave Atlassian for something else.

Right now, it's all up in the air and it's a mess! and I don't even know in depth how these changes will be affecting our usage. There are significant changes to the experience, bugs, loss of functionality and configuration will not be as flexible it seems.

I'm sorry but it's not my job to read hundreds of issues and try to figure that out myself.

Atlassian MUST provide clear documentation that shows the feature set comparative between old and new views, explicitly showing what are the changes being made, what are the losses in functionality (what we can do now in the old view that won't be able to on the new view), clear roadmap items for the missing items, and the status of each one.

Again, I feel like Atlassian is just making us swallow this and it's up to us to go out there and figure out what to do with it. That's just the wrong posture.

Thanks.

[Jeanne Howe]

@Ricardo Gomes 

@Matthew Canham 

Ricardo is absolutely correct. This whole thing has been a cluster from the start (has it been 2 years, or almost?). With the exception of getting Tabs back, Atlassian has largely ignored every issue/concern that the community has voiced. Things are no better on the Confluence side of the house and the changes being implemented there.

Atlassian is touting their Cloud offering as the Flagship of their product line. I certainly hope all that marketing is bring in new customers, because you'll be losing an awful lot of existing customers come March 2021.

If this is such a flagship, and the new UI changes such an improvement, why is it that Atlassian's support portal, Jira projects, and Confluence documentation are all in DC and not on Cloud?

Atlassian has always stated that you must "eat your own dog food". I say, eat this.

[Svante Jacobsen]

I have written to you (Atlassian) about this (Log work) dialog for too long, probably 3-4 times over a 14-16 month period. Please make it functional!

1. The Time spent field should be focused and ready to receive input right when first opened! The first couple of months I did not think the Log work form worked at all, then at random I noticed you can use the mouse to click the center part of the Time spent field (I was clicking inside the field but perhaps too close to the edges and also trying to focus by using TAB key which did not work either). 

2. Pressing enter should submit the form! Even when a value has been entered in the Time spent field the form will not submit. Pressing Enter does nothing. One can get passed this by reaching for the mouse, aim and click on the highlighted (default Submit) Save button but that's too much work when used 20 times a day.

3. Date started should be a single text field with the current date/time pre filled (for me in ISO format) like in the Old issue view. Now I'm unable to copy-paste dates and times (like I can in the Old issue view). It is MUCH less effort to edit dates and times in a text field than using a forced date/time picker.

4. Too many tabs to reach description field! I don't know the correct design here but now tab stops on all text formatting tools before focusing on the actual field.

5. Show all logged work just as hours, everywhere! How many hours are 2d 2h? We have a 40h cap, has that been reached? How long is a day? How many hours would 1w 4d 1h be? That's too much cognitive work.

Log work should be as easy as <dot> L <Enter> 30 <Enter> (to log 30 minutes on an issue).

EDIT on dec. 6 2020:

Trying this out yesterday I found that with a few quirks it can be somewhat functional (I think some work to improve must have been made to this recently):

/1/ Even though it doesn't look like the Time spent field has focus one can now start writing when dialog is first opened. To show it as focused would be even better.

/2/ Pressing Enter works if you type "30m" (not just "30" - minutes used to be and should be the default). In fact this must be new - not allowing "30" as "30m" - one is now unable to submit - even by mouse click. Please change back to allow also "30"!

/3/4/5/ Did not test the rest but I suppose they still apply.

[Peter Fjelsten]

@Matthew Canham, I am really sorry to read about you not intending not to make sure that the huge plugin Tempo works properly before the new issue view forced down our throats ("JRACLOUD-70942 and JRACLOUD-72556 are two improvements that we plan on bringing back to the new issue view shortly after we transition to the new issue view.").

May I suggest you move the date for the switchover further out into the future (judging by the number of comments here, no-one will complain) so you can make sure all issues are actually fixed - and so I do not need to spend a lot of time supporting our users because they cannot find this critical functionality (we're a web consultancy company).

We normally bill our customers around €180/hour - which Atlassian PO Number address should I send the bill to?

[Christophe Noualhat]

We have been using the new view since we started with Jira cloud earlier this year and we have nothing to report that is not working with Tempo... its available in the right most column and in the center column.

[Peter Fjelsten]

@Christophe Noualhat , yes, I know it's there but it's hidden and needs to be clicked to see time spent, etc.

[Christophe Noualhat]

@Peter Fjelsten in the right hand column yes, not for the middle panel... it may be a change of behavior but I would not say 'it doesn't work' ... it may not be suited for your use (or others) and may need getting used to, may even be fixed later on... but it still works and does not prevent from doing our day to day job... it's literally one click away...

[Peter Fjelsten]

@Christophe Noualhat - we need remaining estimates visible all the time so devs are shown how much time is left in their estimates - and they don't "one click". So yes, it is a huge problem for us. 

[Rhana Silva Novais]

Bom dia! Eu comecei a usar o Jira a um mês e ainda estou conhecendo essa ferramenta. O que me preocupa com a mudança é que eu só consigo usar estimativa de tempo nos projetos clássicos. Gostaria de saber se terei essa possibilidade também nos projetos de última geração. 

[Dennis T]

I have started lobbying within my company to switch to Redmine Cloud*. It was bad enough earlier with simple issues not fixed for 5+ years. This rushed rollout to new view was the final straw. I’ve sent in feedback dozens of times but I don’t see a single bug ticket raised for the issues I mentioned.

* https://www.redmineup.com/pages/cloud/project-management

[Christophe Noualhat]

@Peter Fjelsten we do too. You can add the remaining estimate and the original estimate to your screen scheme and have them appear alongside the tempo sub menu

[Peter Fjelsten]

@Christophe Noualhat - but since we cannot save this across projects (JRACLOUD-71630) (we have 100's of these), we cannot use this.

[Greg D]

Hey @Peter Fjelsten, I feel your pain, but I think @Christophe Noualhat and all of us just want to be clear with Atlassian that the things we are asking them to fix are actually fully broken in New Issue View.  Your problem at least has a work-around (it is just that you don't want to go into all of the issue layouts... which is definitely a pain and you shouldn't need to do that... but I would take that 100 times out of 100 over the problems that I need Atlassian to fix since I can move a million times faster than them).

Atlassian moves at a snail's pace with critical bugs that they are claiming to be features and I think that a lot of the Product Managers assume we are complaining about things like you are mentioning here... we don't want to be dubbed the "boy who cried wolf", because the Product leaders in any company love to have an excuse to latch onto for why they are not addressing bugs and why they are instead incorrectly allocating work for new, shiny, superficial features to their Engineers.  If they lump our needs in with something that they can legitimately claim as a feature (and not a bug fix), we could be in even more trouble.

[Peter Fjelsten]

@Greg D I agree with your assessment that any bug in Jira is a feature according to Atlassian.

However, I will not accept your position that your problem is bigger than mine. Of course it's bigger for you, as is mine to me. And manually updating 825 projects is not a workaround in my book.

[Christopher Mohr]

Hi @Matthew Canham ,

I read that Atlassian aims to provide the same features in new issue view as they exist in the old issue view. Customer noticed that single comments cannot be collapsed anymore which makes it harder too navigate through issues with a large comment history. This is not addressed by JRACLOUD-74680 which handles the overall collapsing of comments, but rather by JRACLOUD-75719 for single comment collapsing.

Hope this finds a way to the roadmap before April 2021.

Regards,

Christopher

[Jack Hunter [HeroCoders]]

New Issue View does not show custom field ID anywhere. We need it sometimes from our customers (non-admin users) for support purposes. 

It was pretty easy to find the field ID in old issue view: https://herocoders.atlassian.net/wiki/spaces/IC/pages/892928051/Find+custom+field+ID