-
Improvement
-
Resolution: Unresolved
-
Minor
For fields assignable to Item, the preferred UI control type is unclear. There are two choices in the field:
- text field, with completion
- drop down of all possibilities
#1 adds little overhead to the server even on large installations, and supports relative paths, but is forbidding for many users. #2 is easy to use, at least for smaller installations, but cannot render relative paths. We might like a hybrid.
https://wiki.jenkins-ci.org/display/JENKINS/Chosen+plugin is a possibility but might be too much for some browsers and it is not clear that it supports editable combos anyway.
Better might be an adaptive control which loads the item list asynch, then if the current value exists, show it; otherwise, or if an Edit button is clicked, switch to a text field view with completion. There can be a cutoff on the number of items displayed in the pulldown, e.g. 1000, before switching to the text field automatically.
- is related to
-
-
- Open
-
[JENKINS-17011] More convenient job selection control
I've relied on the current behavior in Copy Artifact plugin (using the simple/short name of a project in the same folder) a lot when creating (release) branch folders for a product: Just copy the previous release's folder and increment a few (Folders Plus) variables, and done.
While this could be considered a bug (not pointing to the original folder's job, e.g. ../previous_release/Project) it works quite well.
While this could be considered a bug
If a folder is copied which includes both an absolute-path-referring job and its referent, the reasonable expectation is that an onLocationChanged implementation ought to ensure that the reference points to the copied referent, not the original. Most likely some kind of helper utility in core is required to make this kind of logic practical.
absolute-path-referring job and its referent
To clarify, the reference to /release_folder/Up from /release_folder/Down is Up. So the current behavior of retaining Up rather than becoming e.g. ../release_folder/Up when creating a copy /new_release of /release_folder works quite well.
Right, I am just saying that if the original referent were instead /release_folder/Up then you would expect to copied reference to become /new_release/Up. CJP-1522 (visible only to CloudBees employees) is an example of this.
, I am just saying that if the original referent were instead /release_folder/Up then you would expect to copied reference to become /new_release/Up.
Actually, no, I would not. Absolute references are absolute.
What happens when you copy a folder with a bunch of symlinks in them? Absolute ones point to the original item, relative ones possibly point to a copied item.
Should also consider whether identifying items by relative path was a good idea to begin with. It is not always easy or even possible to evaluate a relative path when the value is needed. During form validation you can usually use hacks like @AncestorInPath to guess at the context, though not always; and there is no equivalent magic thread-local variable (that I know of) available during deserialization (Converter.unmarshal).
And what was the purpose? Depending on the UI control chosen, it is not necessarily more convenient for users. It is not necessary in order to order to maintain relationships between jobs in folders created from template, since you could simply ensure that the target folder path is a variable available during template expansion. It could be used to ensure that sets of related jobs behave the same way when moved or copied to another folder, but renaming jobs—and moving only dependent jobs to other folders—anyway requires that Jenkins use ItemListener.onLocationChanged to update item name references, whether they are relative or absolute.