We need to use quick transformation filters that behave as if they are connected with an "OR" instead of an "AND" clause. I realize doing that would be problematic, but there would be a simple workaround if it were possible to merely invert the effect of selecting the filter buttons. Specifically, when the button is deselected (the default state) the filter would be applied, and when selected the filter would be deactivated.

This could be implemented by providing a single checkbox in the edit screen for a quick filter that inverts the effect of the filter. So instead of not showing non-matching items, selecting the button would now show non-matching items. This may sound confusing at first, but only the creators of the filter buttons need to understand the logic. Most users would just see a button that says "include x" or something to that extent and know that selecting it shows "x" which was filtered out by default.

When such a filter is created, it would be written according to its default (button deselected) behavior so that it filters out the items that selecting the button are intended to show. However, it should be named according to its deactivated (button selected) behavior so that users know its effect is to include rather than hide certain items.

As an example, let's say that I have a number of possible statuses for each issue, and I want buttons for each status that when selected show all issues having that status. As it stands, the only options are (1) have the buttons filter out every other status besides the desired one or (2) design the buttons to hide all issues with a given status. The obvious problem with (1) is that selecting more than one button returns nothing. The problem with (2) is that it is cumbersome to select every single status that one wishes to hide, just to show one or two of them.

If it were possible to simply invert the effect of the "hide" buttons in method (2), then by default (when deselected) these filters would all be active, showing none of those statuses. The buttons would obviously be renamed as "show x" rather than "hide" so users know to select the desired subset of statuses, instead of the undesired subset.

It is a widely adopted practice to not share specific dates in long term planning and it would therefore be helpful if I could hide the dates/timeline in the gantt view.

The only option today is to zoom out but that is not practical as the feature-bars will become to small and the timeline is still visible but in years.

I want to be able to show how feature A is scheduled before Feature B and that it is dependent upon Feature C being completed without having to show when the features will be worked upon.

Simply hiding, or making the dates blank, will do just that.

It is a widely adopted practice to not share specific dates in long term planning and it would therefore be helpful if I could hide the dates/timeline in the gantt view.

The only option today is to zoom out but that is not practical as the feature-bars will become to small and the timeline is still visible but in years.

I want to be able to show how feature A is scheduled before Feature B and that it is dependent upon Feature C being completed without having to show when the features will be worked upon.

Simply hiding, or making the dates blank, will do just that.

In our company we use very closely JIRA and Confluence. Structure allows us to properly organize issues based on our demands and workflows and it works perfectly for people who are assigning tasks or implementing them. But we use Confluence for executive summary of progress on specific builds where would be very helpful if we can display progress bar of a specific issue (counted from all issues below of selected issue in the hierarchy). This way we would be able to create great overviews like e.g. "Bug fixing of Feature1", "Implementing Feature2", ... with progress bars behind without a need of displaying complicated window with all issues in the hierarchy.

Having possibility to select display mode as in Roadmap for JIRA (displaying open, in-progress and resolved issues with different color) would be absolutely awesome :)

First set of columns each represent a structure level.
Following structure, top row includes field names for data entry (e.g. Story Points, Type=Epic, Story...

(not sure if this will come through or not, but something like this:

|Level1 |Level2|Level3 |Level4 ... |Type |Story Points|
|Jurassic Park| | | ... |Epic |
|Jurassic Park|T-Rex| | ... |New Feature|
|Jurassic Park|T-Rex|Goat Release| ... |Story |
|Jurassic Park|T-Rex|Goat Release| As a goat I can be raised up so the T-Rex can eat me|Story| 8 |
|Jurassic Park|T-Rex|Goat Release| As a goat I can NOT escape so that I will live|Story| 2 |

Note structure relates stories to stories.