-
Notifications
You must be signed in to change notification settings - Fork 247
[FIXED JENKINS-36315] Make it easier to infer the context in form binding #62
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
Conversation
| return type.cast(user); | ||
| } | ||
| } else if ("job".equals(firstSegment) || "item".equals(firstSegment) || "view" | ||
| .equals(firstSegment)) { |
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.
@jglick you may be interested in this section as a better implementation of https://github.com/jenkinsci/workflow-step-api-plugin/blob/aabbdca1c3c1f1aacf346b01d95d3be467547195/src/main/java/org/jenkinsci/plugins/workflow/util/StaplerReferer.java#L61
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.
:sadpanda: I've had need in the past fo something similar in Stapler as well
https://github.com/jenkinsci/build-failure-analyzer-plugin/blob/master/src/main/java/com/sonyericsson/jenkins/plugins/bfa/model/indication/BuildLogIndication.java#L263
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.
yeah... mine is better I think ;-)
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.
Yes, I didn't write mine myself and IIRC it doesn't work well with views and folders :) But hardly none has complained, probably because it isn't a well known feature.
|
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
| if (ancestor.getObject() instanceof ModelObject) { | ||
| Set<CredentialsScope> scopes = | ||
| CredentialsProvider.lookupScopes((ModelObject) ancestor.getObject()); | ||
| Set<CredentialsScope> scopes = CredentialsProvider.lookupScopes(context); |
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.
NIT. formatting. Or maybe dead code?
| * {@inheritDoc} | ||
| */ | ||
| public FormValidation.CheckMethod getCheckMethod(String fieldName) { | ||
| // this is an ugly hack to make the @ContextInPath annotation more failsafe |
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.
Should this hack be restricted (from direct override calls)?
| if (token != null) { | ||
| String fillUrl = (String) attributes.get("autoCompleteUrl"); | ||
| if (fillUrl.indexOf('?') != -1) { | ||
| fillUrl = fillUrl + '&'; |
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.
Check for null
(just because the three known impls are safe does not mean that some plugin won't introduce an extension that needs escaping)
| // this is an ugly hack to make the @ContextInPath annotation more failsafe | ||
| super.calcFillSettings(field, attributes); | ||
| if (attributes.containsKey("fillUrl")) { | ||
| try { |
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.
Same check as above, so this code will not run.
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.
nope... the calcFillSettings method will add the attribute.
The idea is to do a no-op if the user supplied the fillUrl, but if the fillUrl was calculated then we add the $provider and $token
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.
Then 🐜 A comment mentioning that would be nice ;)
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.
you mean like // the user already provided a custom one, get out of the way
| } else { | ||
| if (match.getScope() == CredentialsScope.SYSTEM) { | ||
| // system scope is not exported to child contexts | ||
| continue; |
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.
🐛 Should it continue with other credentials in the domain then? firstOrNull skips others from what I see
| // this is an ugly hack to make the @ContextInPath annotation more failsafe | ||
| super.calcAutoCompleteSettings(field, attributes); | ||
| if (attributes.containsKey("autoCompleteUrl")) { | ||
| try { |
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.
So, seems like only a one string difference between this and the code for fillUrl above. Reducing the "hack" to a one method call would help with scrubbing it in the future.
|
🐝 |
|
I keep |
|
"Let's all share core's lack of escaping of descriptor ids" looks good to me since there is no flaws in the known OSS code |
|
@oleg-nenashev are you removing your bug then? |
|
Removed bug, need to perform another iteration before adding a bee |
|
🐝 |
| </j:forEach> | ||
| </f:dropdownList> | ||
| <j:local> | ||
| <j:set var="it" value="${it.store}"/> |
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.
Do you really need j:local here? AFAIK it would have been scoped only to this include anyway.
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.
I'm curious about this j:local -- it bleeds into the html that web browsers see. That isn't inherently bad, but in general one shouldn't bleed xml namespaced tags to html web browser.
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.
It shouldn’t, assuming the xml namespace is correctly defined
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.
I don't see a <local> tag in the Jelly documentation
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.
Ahh should be scope http://commons.apache.org/proper/commons-jelly/tags.html#core:scope Do you want to fix it?
|
The JENKINS-19413 workaround does look like a modest improvement over the existing implementations (there are at least two copies lying around that I know of); these should I think be moved into a library plugin for eventual inclusion in core (or Stapler itself). Obviously the better approach would be to directly reuse the URL-binding logic in The rest of the PR I do not really understand. Something about mismatched |
JENKINS-36315
@reviewbybees