Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-17011

More convenient job selection control

    Details

    • Similar Issues:

      Description

      For fields assignable to Item, the preferred UI control type is unclear. There are two choices in the field:

      1. text field, with completion
      2. 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.

        Attachments

          Issue Links

            Activity

            Hide
            jglick Jesse Glick added a comment - - edited

            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.

            Show
            jglick Jesse Glick added a comment - - edited 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.
            Hide
            danielbeck Daniel Beck added a comment -

            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.

            Show
            danielbeck Daniel Beck added a comment - 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.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            danielbeck Daniel Beck added a comment -

            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.

            Show
            danielbeck Daniel Beck added a comment - 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.
            Hide
            jglick Jesse Glick added a comment - - edited

            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.

            Show
            jglick Jesse Glick added a comment - - edited 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.
            Hide
            danielbeck Daniel Beck added a comment -

            , 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.

            Show
            danielbeck Daniel Beck added a comment - , 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick Jesse Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated: