- Jun 29, 2014
-
-
Kohsuke Kawaguchi authored
-
- Jun 23, 2014
-
-
Kohsuke Kawaguchi authored
-
Kohsuke Kawaguchi authored
-
- Jun 18, 2014
-
-
tfennelly authored
-
Oliver Gondža authored
-
- Jun 17, 2014
-
-
Jesse Glick authored
[FIXED JENKINS-14264] For logs >200Kb, just show two <t:task>s without nesting, for proper interoperability with the context menu.
-
- Jun 16, 2014
-
-
Jesse Glick authored
[FIXED JENKINS-23191] f:radio is not databinding-aware and does not correctly handle multiple configuration sections unless you make it.
-
Oliver Gondža authored
-
Oliver Gondža authored
-
Kohsuke Kawaguchi authored
-
Kohsuke Kawaguchi authored
-
- Jun 13, 2014
-
-
tfennelly authored
-
Jesse Glick authored
-
- Jun 12, 2014
-
-
Jesse Glick authored
-
Kohsuke Kawaguchi authored
Integrated the fix made in winp 1.20.
-
Daniel Beck authored
-
Oleg Nenashev authored
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
-
- Jun 11, 2014
-
-
Daniel Beck authored
-
- Jun 10, 2014
-
-
Daniel Beck authored
-
Jesse Glick authored
[FIXED JENKINS-20327] When saving a list view, submit POST data with size proportional to the # of jobs selected for inclusion, not the number of options. This can be done easily by setting json="true"; otherwise the default is to pass =false for each unselected job. Ironically, even with this fix we are sending 2× what is needed, since currently ListView.submit does not even check the json parameter for job names: it only pays attention to top-level request parameters that the browser defines for selected checkboxes. Ideally we could ask buildFormTree to ignore a given form element entirely, so as to avoid the wasted data.
-
Kohsuke Kawaguchi authored
-
Jesse Glick authored
The basic fix is to use ${rootURL} plus full model object URLs rather than relying on ${jobBaseUrl}. This is made trickier by the fact that the model object URLs are computed inside ProgressiveRendering.compute, and therefore will not be correct when nondefault views are in the crumb trail unless the original request information is present. So modifying ProgressiveRendering to preserve a copy of the original request for use during computation. (This could probably be used to simplify parts of AsynchPeople as well.) Also improving AbstractItem.getUrl to properly construct a URL including views even when the current page is not inside the item; it should suffice for some ancestor of the current item (or a view thereof) to be in the ancestor list of this page.
-
Kohsuke Kawaguchi authored
-
- Jun 09, 2014
-
-
Jesse Glick authored
-
Kohsuke Kawaguchi authored
-
Jesse Glick authored
-
- Jun 08, 2014
-
-
Kohsuke Kawaguchi authored
Documented this feature and integrated a newer version of Stapler. I took the opportunity to reorder the content in the section, so that the tree parameter becomes the main subject. At this point, the depth parameter should be only used in a limited circumstance, so it should be treated as such.
-
- Jun 03, 2014
-
-
Oleg Nenashev authored
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
-
Kohsuke Kawaguchi authored
-
Jesse Glick authored
-
- Jun 02, 2014
-
-
Kohsuke Kawaguchi authored
-
- Jun 01, 2014
-
-
Oleg Nenashev authored
-
Oleg Nenashev authored
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
-
Oliver Gondža authored
-
Oliver Gondža authored
-
Oliver Gondža authored
-
Oliver Gondža authored
-
Oleg Nenashev authored
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
-
Daniel Beck authored
-
Oleg Nenashev authored
Signed-off-by: Oleg Nenashev <o.v.nenashev@gmail.com>
-