Cura: Extruder application menu always acts on currently active extruder

[fieldOfView]

Description:
The application menus for an extruder will always change the setting of the "currently active" extruder, no matter which extruder menu you use. If you have the Extruder 1 tab selected in the settings sidebar, and then use the application menu to change the material, print core or profile of Extruder 2, Cura will actually make that change in Extruder 1. This is not correct.

CURA Release:
2.3 - master

Bug Type:
New Bug

Platform:
any

Graphics Card:
any

Operating Sytem:
any

Machine:
Jedi, any multi-extruder

Community Issue:
https://github.com/Ultimaker/Cura/issues/1641

Preconditions:
n/a

Reproduce steps:

• Add a new UM3 printer to Cura, do not connect it
• Note that both extruders have PLA for material and that Extruder 1 is the selected extruder tab in the sidebar.
• From the Settings application menu, choose Extruder 2 -> Material -> ABS

Expected result:
The material of Extruder 2 (2nd tab) changes

Actual result:
The material of Extruder 1 (1st tab) changes instead

Report types:
1) Coding error

Screenshot:
n/a

Model:
n/a

Logs:
n/a

"It's an old template, but it checks out."

[Ghostkeeper]

This is my current template by the way:

*Description:* 
*Source:* 
*Version:* 
*Operating System:* 
*Machine:* 
*Reproducibility:* 
*Reproduce steps:*
# 

*Actual result:*
* 

*Expected result:*
* 

*Keywords:*

[Ghostkeeper]

Reproduces on 2.5.

[fieldOfView]

All those n/a fields made me think of the good old times with Jorg.

[Ghostkeeper]

This issue was closed by our product manager because it has been inactive for 3 months.

[fieldOfView]

It is still a bug though.

Closing feature requests due to inactivity is one thing. Closing reproducible bugs is quite another.

[Ghostkeeper]

I typically leave the issue open here on Github, but I do communicate the Project Manager's decision here.

The argument for closing bugs is that they sometimes expire (i.e. are no longer bugs) because of changes in the code, and that if nobody comments on the issue then it must not be that important.

The first argument doesn't really hold for closing features though. Feature requests don't really expire.

The second argument doesn't really hold if the decision to close them is based on the internal Jira ticket rather than the Github issue, which is the case for us. We've had cases where the Github issue was very busy but we don't copy all of the updates and comments to Jira and the Jira ticket was closed anyway.

There's also the third argument that keeping the list of issues short makes it easier to order them to their relative importance. The solution to that would be to have a separate category of issues in Jira of "probably never"-like issues. But in the end they are deleted from that category as well so that's not used very consistently either.