"Number of static analysis issues" column should not be added by default

[fredg02]

The column should not be added to a new view by default, but rather if the user deliberately wants to add it.

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [ ] Link to relevant issues in GitHub or Jira
• [ ] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

---

I've manually tested that the fix works as expected. Creating an automated test for this is not worth the effort IMHO.

Let me know if I need to create a corresponding GitHub or JIRA issue first.

[uhafner]

I am not sure if I am missing something but how can you configure the columns of the default view?

[fredg02]

I am not sure if I am missing something but how can you configure the columns of the default view?

If you are referring to the "All" view, please see https://wiki.jenkins.io/display/JENKINS/Editing+or+Replacing+the+All+View

[KalleOlaviNiemitalo]

Why would you want to hide the column by default; would that make the view render faster (by how much) or make the view fit better in a narrow window?

I am mainly using Multibranch Pipeline projects in folders. To keep the "# Issues" column visible after this change, it seems I'd have to define new views to replace the "Branches", "Pull requests", and "Tags" tabs in each Multibranch Pipeline project individually. That wouldn't be good.

I hope this change won't be merged as is. If shownByDefault were instead configurable globally, per project, or per user, then that would be OK.

[uhafner]

If Jenkins would provide a simple way to change the columns of the default view, this PR would not harm. However, in the current situation it will be too much effort to get the column back for all other users who like the column. So I see it problematic to merge this PR as well.

BTW: Unfortunately the core team (@daniel-beck, @oleg-nenashev) rejected an issue to change the configuration of the All view in JENKINS-22340. So I see no way to solve this usability problem in a simple way. I experimented with a student on how to configure table columns more easily in the metrics-aggregation-plugin, but this requires to replace the ancient HTML table of the Jenkins views with something modern like DataTables.

[daniel-beck]

rejected an issue to change the configuration

That would just make the All view a list view like any other. Which might make sense, but is a separate issue. It is not a bug however.

Note that any custom list views would retain whatever columns they already have; this change would only affect All views (which use whatever is enabled by default), new views (what columns are added by default), and possibly the list views in generated folders, although I'm unsure about those.

[oleg-nenashev]

Unfortunately the core team (@daniel-beck, @oleg-nenashev) rejected an issue to change the configuration of the All view in JENKINS-22340.

It was seven years ago.. Apart from feeling old now, I do not have a strong opinion about AllView as it is designed now. I would rather rework the default view approach so that the basic view becomes editable. It is better for user experience. After that, it makes sense to implement another fallback view (or maybe even a "recovery mode") for Jenkins.

[uhafner]

Maybe it would be a good GSoC project idea for the next year: provide a user friendly view concept 😄

[oleg-nenashev]

It is rather a UX design. Happy to support this idea, e.g. as a self-hosted program

[fredg02]

@KalleOlaviNiemitalo

Why would you want to hide the column by default; would that make the view render faster (by how much) or make the view fit better in a narrow window?

I don't care about performance or layout in this case, but I'm not aware of any other plugin (so far) that adds new columns by default to a new view. IMHO this should always be an opt-in, not opt-out to avoid a "my new view has 25 additional columns that I don't need"-situation. ;)

I am mainly using Multibranch Pipeline projects in folders. To keep the "# Issues" column visible after this change, it seems I'd have to define new views to replace the "Branches", "Pull requests", and "Tags" tabs in each Multibranch Pipeline project individually. That wouldn't be good.

I understand your use-case. I'd recommend that the warnings-plugin should have an option in the general config to opt-in to the column for Multibranch Pipeline and similar views.

@uhafner

If Jenkins would provide a simple way to change the columns of the default view, this PR would not harm. However, in the current situation it will be too much effort to get the column back for all other users who like the column. So I see it problematic to merge this PR as well.

The underlying problem is definitely the columns UX that desperately needs an overhaul. Still, the warnings-ng plugin does not set a good example (IMHO) with adding it's column by default. It is the user-friendly shortcut solution for users that want to see the column by default in every view, but it's the user-annoying solution for all other users that don't want/expect that.

I hope I'll find some time to contribute to a new columns UX in the not so distant future. In the meantime, feel free to close this PR.

[uhafner]

IMHO this should always be an opt-in, not opt-out to avoid a "my new view has 25 additional columns that I don't need"-situation. ;)

Nobody complained so far. So I'm not sure if this actually is a problem.

I understand your use-case. I'd recommend that the warnings-plugin should have an option in the general config to opt-in to the column for Multibranch Pipeline and similar views.

What about adding it here in this PR? Shouldn't be too hard to add an additional checkbox to the existing WarningsPluginConfiguration and read the value in the column? (Or does the column not know whether it is part of the All view or any other configurable view?)

I hope I'll find some time to contribute to a new columns UX in the not so distant future.

That would be wonderful!!! Please join the UX SIG (Gitter channel or Zoom meeting) before you actually start so we can discuss what options are available).

[fredg02]

Nobody complained so far. So I'm not sure if this actually is a problem.

Let's agree on "nobody bothered to report it". ;)

What about adding it here in this PR? Shouldn't be too hard to add an additional checkbox to the existing WarningsPluginConfiguration and read the value in the column? (Or does the column not know whether it is part of the All view or any other configurable view?)

I will take a look.

That would be wonderful!!! Please join the UX SIG (Gitter channel or Zoom meeting) before you actually start so we can discuss what options are available).

I will need to do some exploring first.