-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-73404] SecretTextArea missing FormValidation support #9450
Conversation
reworked the jelly and simplified the javascript. the textarea is now always present in the DOM, so no need to remove inputs to add a textarea. Rather we just remove /hide the "hidden" attribute from the elements we want to show/hide and give the textArea the expected class and attributes for validation to occur
@@ -56,17 +56,32 @@ Example usage: | |||
<st:attribute name="placeholder"> | |||
Placeholder text for input field when displayed. | |||
</st:attribute> | |||
<st:attribute name="checkUrl"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no use=optional
here and this was copied from other jelly files. placeholder also does not have it, so I can only conclude that it is unused?
if this is used then I would suggest that it is fixed in all Jelly files at once rather than piecemeal which is not the realm of this PR.
.secret * [hidden] { | ||
display: none !important; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
despite the elements having the hidden
attributes they were continuing to show up.
I did not need !important
(they where hidden without it) not did I try and track down exactly what CSS rule was matching so that they did show up.
whilst !important
is probably bad form - anyone setting a display on something with a hidden attribute is probably a bad actor that would need to be fixed. In any case hidden here means hidden.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
all the elements are now always in the dom and the textarea is always populated for form binding.
All we do now is manipulate the hidden nature of the various things to show/hide.
return emptyPassword; | ||
} | ||
|
||
@DataBoundSetter |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setters were not needed for the test, but helped with developer testing so I left them in for the next person that has to debug something in the area
values for SecretTextArea are now always sent. Whilst this is a change in behavior the only way once set to unset is to set the value to the mpty string "" which would still produce a Secret Additionally this matches the behaviour of f:password and f:textarea Given both of the above this change in behaviour should not break any production use cases.
@@ -144,7 +144,7 @@ private static TestBuilder fromStringWithDescription(String secret, String descr | |||
|
|||
@DataBoundConstructor | |||
public TestBuilder(Secret secret) { | |||
this.secret = secret; | |||
this.secret = fixEmptySecret(secret); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test was checking using j.assertEqualDataBoundBeans
on the TestBuilder
s and the new Secret was set to the empty String.
This adapts the TestBuilder to convert an empty secret to null, as it was less intrusive and also the test would still check the description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much. I found no issues during interactive testing and I see no issues in the code changes. I plan to run a plugin bill of materials check of the build to confirm that none of the plugins from the BOM have an issue with the change.
jenkinsci/jenkins#9450 with the most recent changes to the master branch merged into it.
The check with the plugin bill of materials completed successfully. This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. /label ready-for-merge |
…sci#9450) * [JENKINS-73404] unit test * roundtrip as Secrets * [JENKINS-73404] add validation for SecretTextArea reworked the jelly and simplified the javascript. the textarea is now always present in the DOM, so no need to remove inputs to add a textarea. Rather we just remove /hide the "hidden" attribute from the elements we want to show/hide and give the textArea the expected class and attributes for validation to occur * remove unused data-prompt attribute * Adapt getHiddenSecretValue to backend changes * Adapt to Secrets being sent as "" rather than null values for SecretTextArea are now always sent. Whilst this is a change in behavior the only way once set to unset is to set the value to the mpty string "" which would still produce a Secret Additionally this matches the behaviour of f:password and f:textarea Given both of the above this change in behaviour should not break any production use cases. * Remove trailing spaces --------- Co-authored-by: Mark Waite <[email protected]> (cherry picked from commit 81b90e4)
See JENKINS-73404.
FormValidation was not working with
SecretTextArea
, this change fixes that and at the same time simplifies how the SecretTextArea is handled.There is a change in behaviour to note:
null
Secrets
will end up being an empty Secret (that is one with the empty String""
).As there is no functionality to clear a
SecretTextArea
other than to set the value in the Textarea to the empty String code should already handle this case, as such it should not break any production code.This behaviour is also the same as currently happens for
f:password
andf:textarea
Screenshots
empty (null) value with validation
populated value with validation
empty (null) value after clicking Add
populated value after clicking Replace
Testing done
FormFieldValidatorTest
Proposed changelog entries
Proposed upgrade guidelines
N/A
Submitter checklist
Desired reviewers
N/A
Before the changes are marked as
ready-for-merge
:Maintainer checklist