Skip to content

Conversation

@stephenc
Copy link
Member

@stephenc stephenc commented Jul 4, 2016

JENKINS-36315

@reviewbybees

return type.cast(user);
}
} else if ("job".equals(firstSegment) || "item".equals(firstSegment) || "view"
.equals(firstSegment)) {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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 ;-)

Copy link
Member

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.

@ghost
Copy link

ghost commented Jul 4, 2016

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);
Copy link
Member

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
Copy link
Member

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 + '&';
Copy link
Member

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 {
Copy link
Member

@rsandell rsandell Jul 4, 2016

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.

Copy link
Member Author

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

Copy link
Member

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 ;)

Copy link
Member Author

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;
Copy link
Member

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 {
Copy link
Member

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.

@rsandell
Copy link
Member

rsandell commented Jul 4, 2016

🐝

@oleg-nenashev
Copy link
Member

oleg-nenashev commented Jul 4, 2016

I keep was-bug (fixed) for checkForDuplicates() domain handling and className escaping, but the most of the issues have been addressed

@oleg-nenashev
Copy link
Member

"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

@stephenc
Copy link
Member Author

stephenc commented Jul 4, 2016

@oleg-nenashev are you removing your bug then?

@oleg-nenashev
Copy link
Member

Removed bug, need to perform another iteration before adding a bee

@rsandell
Copy link
Member

rsandell commented Jul 5, 2016

🐝

</j:forEach>
</f:dropdownList>
<j:local>
<j:set var="it" value="${it.store}"/>
Copy link
Member

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.

Copy link
Contributor

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.

Copy link
Member Author

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

Copy link
Member

@slide slide Feb 4, 2019

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

Copy link
Member Author

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?

@jglick
Copy link
Member

jglick commented Jul 7, 2016

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 Stapler.tryInvoke, which would seem to require an implementation in Stapler core itself.

The rest of the PR I do not really understand. Something about mismatched its. Do not see anything obviously wrong, other than the usual nightmare of making form validation work in exotic circumstances.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants