Got to Love/Hate Security! ...but love Active Choices!

[Ioannis Moutsatsos]

So after a long period of banishment the Active Choices plugin is back on the Jenkins update site!

I think everyone should be excited about this Active Choices v 2.0-(patched) release!

With optional dependency on the Scriptler plugin, and blessings from the security gods the plugin now is again ready for widespread use.

We should say that we are still testing a patch for some issues  we discovered soon after releasing v2.0, but if all goes well Bruno says we should be back on track in the next few days.

Nonetheless, the security framework in which Active Choices now runs (Jenkins release 2.46.3 or greater is required) will require some adjustments and changes to older projects.

I have discovered that HTML in Active Choices (and other parameter) descriptions is no longer supported (see Markup Formatting in Securing Jenkins)

This was a feature I used quite a lot in combination with some of the dynamic features of Active Choices. Here is an example:

In this example, only after the selection of images from a list the <RETRIEVE> button becomes visible and includes the number of selected images.

This was originally implemented as the simple HTML in the description of the Active Choices parameter.

The HTML  <div> element provides an element id that I use to render the dynamic button. 

With the new secure configuration thsi fucntionality is now lost. Instead I get:

Workaround

Just in case you run into a similar issue, ou can move this HTML into a separate Active Choice Reactive Reference which will render it correctly!

Active Choice Reactive References work in the secure jenkins realm to in fact do things that are not normally allowed by Jenkins (such as injecting HTML and Javascript into the build form page).

So you can create a new 'anonymous' Active Choice reactive reference parameter and use it in place of the HTML in the Parameter Description

Green is the correctly rendered Active Choice while red is the non-rendered HTML