support-core-plugin Modernize the UI and add preselect URLs

This is an attempt to enhance the Support Bundle Generation view. The improvements introduced are:

Moving the list of options from the main page to a pop-up/widget.

Users don't always need to mark or unmark any options if they just want to generate a default support bundle. Moving the list to a pop-up or widget allows us to add more elements to manage the checked options in the main view (see next improvement sections).

To open the widget we will need to click on Select options:

The new widget shows the following:

Please pay attention to the code displayed in the bottom-right corner. This is a HASH generated from the current selected (checked) options. Please refer to the "Custom options" section for more information about this new element.

You can close the widget by clicking on Close or pressing the Esc key.

Choose a general set of options

Selecting which options should be checked can be complex for standards users, so it may be a good idea to have a dropdown element with some standard options (such as configuration files, performance, etc.). For the moment, only three options were added (default, default + configuration files, and performance). As soon as the user clicks or selects one general option in this dropdown, the options will be checked in the widget (by JS).

Custom options

This could be the most interesting part of this development.

Each option will have an ID in the list of options. Anytime that a user check or uncheck any option in the widget a HASH value will be calculated in base on the current selected options. This HASH will appear in two locations: in the bottom-right corner of the widget, and in the input textbox under the Choose a general set of options.

Selecting the Custom value in the Choose a general set of options dropdown, the textbox for the custom value will appear. If you type a HASH value in this textbox and press the Enter key (or click in the Apply button), the options in the widget will be selected according to this HASH value. After that, we could optionally click on Select options and alter this set of select options.

There is an issue with plugins that extend the Component class. The elements shown in the widget (and originally on that page) are classes that extend the Component class and satisfy some requirements. Those classes can be provided by any plugin (not only the support-core-plugin). This question makes the management of this HASH so hard (since we cannot ensure that all the child components will implement the getHash method (inherited from the Component class). Therefore, the decision was made to disregard the child components that would not correctly implement the getHash method. By doing that, we can share a HASH code that we can ensure will work.

Testing done

The development was tested in three different ways:

A Junit test was created for the getHash method of the child components.
The plugin was deployed in Jenkins version 2.479.3 and passed the basic integration tests:
1. Selecting all the general options and confirming that the options were checked correctly in the widget.
2. Selecting the Custom general options and confirming that the correct options were checked with different known HASH codes.
3. Checking and unckecking different options in the widget and confirming that the generated HASH was correct.
4. Confirming the usage of events (like the Esc for the widget or the Enter for the custom textbox).
5. Generating a support bundle and confirming that the options checked in the widget were included in the file.

Submitter checklist

[X] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main 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 demonstrate the feature works or the issue is fixed

Aug 28 '25 12:08 ironcerocloudbees

Hi Pierre, thank you for taking care of that.

it looks like you chose to go with a client only implementation, which means that we won't have this feature available in the API for use by a external tool. Did you consider implementing the feature server side?

I did not consider it. The development of having a server-side should be easy. Initially, we can have an input hidden textbox in the form that the server side will ignore if the rest of the names/checkboxes are present in the data (which will mean that we are coming from the UI), and it will be treated in case the other elements are missing (so, we can use this value for APIs).

I'm worried about delegating the hash implementation to all the plugin developers offering a Component, which excludes important components from this new feature (and might be seen by end users as a bug in this plugin). Maybe we could thing of another hash implementation that would work out of the box for anybody (something based on the className of the component maybe?).

That is an excellent question. Cristian and I have been discussing this question in depth. AFAIU, including the Component offered by other plugins will make it hard to prepare and deliver (to the users) a pre-setup code/hash/config. Let me try to explain it:

The main goal of this development (apart from making the generation of support bundles easier for the users) is to have some previously discovered codes/hashes. Once a user has a problem, we (the community) can share one of those codes/hashes with the user to accurately collect the information that we need to help with the troubleshooting. If the user has a set of plugins (that we don't know yet until having the first support bundle) that include new Components, we will not be able to share a code/hash that includes those new options.

In the current approach (ignoring the new Components), we can use codes/hashes with a good number of options (all the elements from the support-core-plugin and from other well-known plugins like pipelines, etc), and ignore the options for the custom ones.

It is true that if a developer introduces a new component and uses the same hash that already exists in the support-core-plugin, the ui will fail and we will not be able to use the new feature. I will consider ways to avoid such issues.

Aug 29 '25 09:08 ironcerocloudbees

Hi @PierreBtz,

I have been reviewing the options for the "I'm worried about delegating the hash implementation to all the plugin developers offering a Component" problem. I do believe the best option to avoid this problem (other developers could break the new system making wrong implementation of the getHash method) is to have a list in the support-core-plugin. We will have the Class’s Fully Qualified Name assigned to a part of the hash for each component. So, we can manage which components will be included in the code/hash. We can include a comment in the Component class to advise the developers to make a PR in support-core-plugin to include the new components in the list.

What do you think?

Aug 30 '25 10:08 ironcerocloudbees

Also I wonder if we need the dropdown and the popup, or if we could just have buttons to select all/none of the components generally, or within one of the categories. That would be make it easy to collect all components pertaining to agents, for example. Plus a button to reset to defaults.

Sep 04 '25 19:09 jglick

@ironcerocloudbees sorry for the delay. My suggestion to get going would be to split this development in two since you are trying to tackle two issues at once:

Introduction of profiles

The current architecture is problematic, the plugin shouldn't have knowledge of downstream components.

I tend to agree with Jesse's approach of storing custom profiles as a UserProperty (or if want to keep things on the front end, a cookie maybe?).

One thing that this approach doesn't allow is custom profile sharing (I don't know if it's a requirement of yours or not?). If it is, you could maybe provide an url fragment to share with the component selection appearing as query parameters. Note that to keep things simple, this can be delivered independently on a subsequent PR.

a UX redesign (depends on 1 but can be delivered after)

No strong opinion on this I'm no UX designer (and maybe we could ask for the opinion of one...). I personally like that the main view is not polluted by a long list of components anymore.

Sep 05 '25 07:09 PierreBtz

an url fragment to share with the component selection appearing as query parameters

I like this idea. There is already a Component.id or similar that could be used. (If a full list of literal ids is too long for a query parameter, you could just use a short hash of each id to include, like ?components=468de0a,223ff0a,cc320ab or the like. Assuming there are no hash collisions, unlikely at such a small scale, this is safe because the server can look up a list of all known ids and see which ones which were selected by hash.)

Sep 05 '25 11:09 jglick

Hi @Dohbedoh,

Thank you so much for your review.

When testing this PR, I was looking for the list of components that each of those options would pre-select. Which I could not get. I thought that the "Select components" would show me the list for the option I just picked but actually it doesn't. I wish I could see what components are included.

This behavior sounds like a bug. When we choose an element in the dropdown menu (with Default, Default with configuration files, or Performance data), a JS function will check and uncheck the components in the form. After choosing the element, clicking the Select component button will display the components currently selected in the form. I thoroughly tested it in various browsers, and the JS function did not fail.

Could you please check if you have any JS errors in the browser console?

The default selection is changed. There is a method isSelectedByDefault() that should be integrated in the "Default" options to preserve it. NOTE: the review of the defaut selection is a topic in itself. There's been a growing lists of components that are selected by default and that need to be reviewed. Maybe as part of a different PR.

That is a really good idea. I will modify it to use the isSelectedByDefault() method in case of Default option.

Some UI tests will need to be updated I think.

Are you considering additional tests for the UI changes? Or did you mean revisiting the UI tests with the new UI changes in the PR?

NOTE: I am also wondering if the options list should be made extensible. If other plugin could contribute a profile for example.

Are you meaning the predefined option lists (aka Default, Default with configuration files, Performance data, Custom)? If so, I will investigate how to accomplish it, and we could include it in a different PR (once this one is merged).

For the rest of the comments/tips/etc, I will update the sub-conversations.

Kind regards,

Sep 22 '25 07:09 ironcerocloudbees