Update Issue status directly in Advanced Roadmaps!

[#1]

Hello power planners!

We’re excited to announce that you can update the issue status directly in Advanced Roadmaps. No more opening the full issue details screen to change the status. Shazam!

In order for the new status to be updated in your boards and backlog, you’ll need to use the Review changes button.

Thanks again for all your continued feedback and suggestions. Keep them coming!

Irene.

[Curt Holley]

Oh, this is a very welcome feature. 👌

[Drew Zhu]

Hi everyone

Drew here, an engineer from the Atlassian team. We're pleased to announce the full rollout of the support update issue status in ARJ for all non-bundled release customers. For those on the Bundled release track, anticipate this change in December. Thanks for your patience

Regards

Drew

[Simon Carroll]

Irene - hopefully this feature will not be default for new plans.

The movement of statuses on the scrum board is for the scrum team and part of their empowerment as they progress to the sprint goals.

Project Managers in my opinion should not need this feature but remind the team to keep the statuses up to date - I can see issues on the horizon if a project manager changes a status (especially when using the scenarios that roadmaps provide) that could mean that appropriate quality assurance measures may be impacted.

Can you please confirm

Cheers

Simon

[Dave Mathijs]

Hi @Irene Thanks for sharing this update. Some questions:

• What happens if a transition has a transition screen? Will a pop-dialog window appear to enter comments and/or other required/optional fields?
• Does the in-line status change take into account workflow conditions and validators?

[Casey Gould]

Will the plan respect all existing project-based permissions for who can/cannot edit certain issues or fields? Thanks.

[Chris]

Hi @Casey Gould all existing permissions should be respected with this change.

Note permission checks are applied when the user commits changes from the Advanced Roadmaps "scenario" sandbox to Jira (via the Review Changes screen).

[Chris]

@Dave Mathijs good questions!

The short answer is that this feature is intended to support all existing workflow transition features. 

For the most part these are applied at "commit" time, when you save the sandbox changes to Jira via the Review Changes screen. At that point the transition is executed. If you have a screen configured with your transition, this will be shown. Similarly, conditions will be applied and validators will be executed. 

[Chris]

Hi @Simon Carroll 

The feature will be available on all plans. 

On your concern - Jira does provide features that may alleviate this?

For example the issue change history and change notifications provide visibility as to who is changing your issues and when. It is even possible to implement workflow conditions to restrict who is allowed to perform a transition.

[Simon Carroll]

Chris

Understand that Jira has history tracking - but in the scenario I presented - if we rely on that it is reactive and in essence for quality or if a legislative  breach has happened is akin to closing the gate once the horse has bolted.

Asking organisations to then create automations to solve this by restricting access to changing statuses means adding effort to create these restrictions for a benefit for a percentage of organisations that will take advantage of this change.

My point is that an option to switch this on in a plan(s) setting may have benefited all organisations whether they are for or against this change.

Cheers Simon

[Simon Carroll]

Chris 

2 points in your response to Dav Mathijs is I have a couple of concerns...

You mentioned it is intended to support all exiating workflow transition features so this is akin to an acceptance criteria saying the the out put should do something instead of must do something. Assuming transition features mean features on the transition within the workflow but does that include global automations that is in place.

The second is that we now have the potential of a project manager applying a change that is overruled by a system restriction that in the background stops the change - does this present an error message to the project manager or does it leave the project manager thinking the change has been applied to the story?

I understand the attractiveness of this for some project managers - this feels like a change to benefit traditional project management approaches - I am concerned more as a Jira Administrator and how I manage this change as I can see substantial problems that this introduces.