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

"Advanced" section should be expanded if it is customized

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      If you have configured something using an "Advanced" section, and later you or
      someone else goes back to the configuration screen, that section will be
      collapsed - even though it contains nondefault, and possibly critical,
      configuration information.

      Assuming there is some way to distinguish default from customized settings, the
      Advanced section should be displayed as initially expanded in the latter case.

          [JENKINS-3107] "Advanced" section should be expanded if it is customized

          Jesse Glick added a comment -

          Jesse Glick added a comment - https://github.com/jenkinsci/ant-plugin/pull/5 for example.

          I don't think this is a good idea...
          If we really want this, then i think the logical consequence would be to expand and remove the advanced buttons at all.
          But i think the advanced section is perfect to not have to over fill the UI.
          I think it would be much better to give the user an option to expand all advanced sections.
          In fact i fink the advanced sections should even be colapsable.

          Dominik Bartholdi added a comment - I don't think this is a good idea... If we really want this, then i think the logical consequence would be to expand and remove the advanced buttons at all. But i think the advanced section is perfect to not have to over fill the UI. I think it would be much better to give the user an option to expand all advanced sections. In fact i fink the advanced sections should even be colapsable.

          Jesse Glick added a comment -

          The advanced sections are useful to not overload the UI with options you are never use.

          The problem is when you do use those options—or rather, someone on your team used those options without telling you and now you are trying to figure out why the build is behaving weirdly. Without this patch, there is no visual indication that anything in the advanced section has been touched. And even if you know/remember that there is something customized in a given advanced section, if you made that customization it is quite likely you are going to make changes to it in the future and want to always see it.

          Remember that the patch only expands those advanced sections with customizations. Others in the same form are left collapsed. So for example if you have a job with an Ant build step that defines some properties, that section will be shown in full, but there will still be a collapsed section at the top for display name and custom workspace.

          I would not argue against making advanced sections recollapsible, but that is an orthogonal RFE.

          Jesse Glick added a comment - The advanced sections are useful to not overload the UI with options you are never use. The problem is when you do use those options—or rather, someone on your team used those options without telling you and now you are trying to figure out why the build is behaving weirdly. Without this patch, there is no visual indication that anything in the advanced section has been touched. And even if you know/remember that there is something customized in a given advanced section, if you made that customization it is quite likely you are going to make changes to it in the future and want to always see it. Remember that the patch only expands those advanced sections with customizations. Others in the same form are left collapsed. So for example if you have a job with an Ant build step that defines some properties, that section will be shown in full, but there will still be a collapsed section at the top for display name and custom workspace. I would not argue against making advanced sections recollapsible, but that is an orthogonal RFE.

          I do understand your points, but I just don't think this is a good solution.
          Some advanced sections are quite big e.g. for maven and now, just because I change a checkbox (like disable auto archiving) the whole section gets expanded.

          Dominik Bartholdi added a comment - I do understand your points, but I just don't think this is a good solution. Some advanced sections are quite big e.g. for maven and now, just because I change a checkbox (like disable auto archiving) the whole section gets expanded.

          Alex Earl added a comment -

          Why not change the appearance of the Advanced button if there are non-default modifications to the advanced settings? I also think it would be nice to be able to collapse an advanced section back down.

          Alex Earl added a comment - Why not change the appearance of the Advanced button if there are non-default modifications to the advanced settings? I also think it would be nice to be able to collapse an advanced section back down.

          Balder VC added a comment -

          Appearance changing or just a small icon/sign that changes have been made there could be useful. Expanding by default, could get annoying if there are many advanced buttons. Usually you don't need all of the changed parts of a configuration page when adapting it to a new config.

          Balder VC added a comment - Appearance changing or just a small icon/sign that changes have been made there could be useful. Expanding by default, could get annoying if there are many advanced buttons. Usually you don't need all of the changed parts of a configuration page when adapting it to a new config.

          +1 for the indication with an icon/sign

          Dominik Bartholdi added a comment - +1 for the indication with an icon/sign

          Jesse Glick added a comment -

          To @domi’s example, I would argue that if you are disabling automatic archiving for a job then probably you are making other detailed changes to the job and might as well keep this section expanded. But this is a clearly a matter of taste.

          Changing the appearance of the Advanced button when customizations are present should be easy enough if that is the consensus UI. (Probably a bit easier than the current patch, actually, since you could make such a change retroactively after invoking the body, so there is no need for the j:mute hack.)

          Any thoughts on the actual appearance? Colorizing it in e.g. red would be easy enough, though it is not very accessible. Boldfacing the label would not show up well with all fonts. Adding an asterisk * may work but is not particularly discoverable; perhaps there is some broadly recognized Unicode character or icon that could be used to indicate that a field has edits. Glowing animation could be used but is again not accessible and could be seen as intrusive.

          The current code captures internal field names, not display labels, so the actual list of customized fields probably cannot be displayed. (Some controls provide a reliable way to get an associated display label, but others I think do not.)

          Jesse Glick added a comment - To @domi’s example, I would argue that if you are disabling automatic archiving for a job then probably you are making other detailed changes to the job and might as well keep this section expanded. But this is a clearly a matter of taste. Changing the appearance of the Advanced button when customizations are present should be easy enough if that is the consensus UI. (Probably a bit easier than the current patch, actually, since you could make such a change retroactively after invoking the body, so there is no need for the j:mute hack.) Any thoughts on the actual appearance? Colorizing it in e.g. red would be easy enough, though it is not very accessible. Boldfacing the label would not show up well with all fonts. Adding an asterisk * may work but is not particularly discoverable; perhaps there is some broadly recognized Unicode character or icon that could be used to indicate that a field has edits. Glowing animation could be used but is again not accessible and could be seen as intrusive. The current code captures internal field names, not display labels, so the actual list of customized fields probably cannot be displayed. (Some controls provide a reliable way to get an associated display label, but others I think do not.)

          Alex Earl added a comment -

          Unicode 2605 ★
          Unicode 2606 ☆

          There are also these glyphs available

          http://twitter.github.io/bootstrap/base-css.html#icons

          Alex Earl added a comment - Unicode 2605 ★ Unicode 2606 ☆ There are also these glyphs available http://twitter.github.io/bootstrap/base-css.html#icons

          Jesse Glick added a comment -

          Neither of those characters says “outstanding edits” very clearly to me, and while icon-edit from Glyphicons looks reasonable, the license terms are a bit onerous.

          I am playing with document_edit.png which looks OK so far.

          Jesse Glick added a comment - Neither of those characters says “outstanding edits” very clearly to me, and while icon-edit from Glyphicons looks reasonable, the license terms are a bit onerous. I am playing with document_edit.png which looks OK so far.

          Balder VC added a comment -

          A unicode character that is outstanding enough to be a notification icon is not easy to find. Using a png that can be customised anyway some one want is perhaps a better option yes

          ☡ 2621 caution sign (curves ahead on road) or ⚠ 26A0 warning sign

          Balder VC added a comment - A unicode character that is outstanding enough to be a notification icon is not easy to find. Using a png that can be customised anyway some one want is perhaps a better option yes ☡ 2621 caution sign (curves ahead on road) or ⚠ 26A0 warning sign

          Jesse Glick added a comment -

          Well try the current state in the branch—I think it looks decent (though I am hardly a master of UI).

          Jesse Glick added a comment - Well try the current state in the branch—I think it looks decent (though I am hardly a master of UI).

          Balder VC added a comment -

          As I'm not a UI master either for me it's fine. At least this way it's easy to see something changed. +1!

          Balder VC added a comment - As I'm not a UI master either for me it's fine. At least this way it's easy to see something changed. +1!

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/resources/lib/form/advanced.jelly
          core/src/main/resources/lib/form/expandableTextbox.jelly
          core/src/main/resources/lib/form/textarea.jelly
          core/src/main/resources/lib/form/textbox.jelly
          http://jenkins-ci.org/commit/jenkins/7ce4807087239bbe236cb34e9a8d183caffefe73
          Log:
          JENKINS-3107 Expand an Advanced section if some fields are already customized.
          Initial implementation handles only text fields, not e.g. checkboxes.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/resources/lib/form/advanced.jelly core/src/main/resources/lib/form/expandableTextbox.jelly core/src/main/resources/lib/form/textarea.jelly core/src/main/resources/lib/form/textbox.jelly http://jenkins-ci.org/commit/jenkins/7ce4807087239bbe236cb34e9a8d183caffefe73 Log: JENKINS-3107 Expand an Advanced section if some fields are already customized. Initial implementation handles only text fields, not e.g. checkboxes.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/resources/lib/form/advanced.jelly
          core/src/main/resources/lib/form/advanced.properties
          http://jenkins-ci.org/commit/jenkins/ef3d6e46b9826ab84098834261daafaa1fe3b6da
          Log:
          JENKINS-3107 Rather than preëxpanding the Advanced area, just show an icon.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/resources/lib/form/advanced.jelly core/src/main/resources/lib/form/advanced.properties http://jenkins-ci.org/commit/jenkins/ef3d6e46b9826ab84098834261daafaa1fe3b6da Log: JENKINS-3107 Rather than preëxpanding the Advanced area, just show an icon.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/resources/lib/form/advanced.jelly
          http://jenkins-ci.org/commit/jenkins/d2eb9b4f633eba2ec07fdfb38f79a0c80e321475
          Log:
          JENKINS-3107 IE 9 fix.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/resources/lib/form/advanced.jelly http://jenkins-ci.org/commit/jenkins/d2eb9b4f633eba2ec07fdfb38f79a0c80e321475 Log: JENKINS-3107 IE 9 fix.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          core/src/main/resources/lib/form/advanced.jelly
          http://jenkins-ci.org/commit/jenkins/6eb958a11135ddfc28786e2377cd2b5824af8907
          Log:
          JENKINS-3107 Icon looks better before button rather than after, for reasons of alignment with the rest of the form.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: core/src/main/resources/lib/form/advanced.jelly http://jenkins-ci.org/commit/jenkins/6eb958a11135ddfc28786e2377cd2b5824af8907 Log: JENKINS-3107 Icon looks better before button rather than after, for reasons of alignment with the rest of the form.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          core/src/main/resources/lib/form/booleanRadio.jelly
          core/src/main/resources/lib/form/combobox.jelly
          core/src/main/resources/lib/form/editableComboBox.jelly
          core/src/main/resources/lib/form/enum.jelly
          core/src/main/resources/lib/form/hetero-radio.jelly
          core/src/main/resources/lib/form/number.jelly
          core/src/main/resources/lib/form/password.jelly
          core/src/main/resources/lib/form/select.jelly
          http://jenkins-ci.org/commit/jenkins/f6d20fa8f37da61095cb5bc686dfcb5d2176be74
          Log:
          [FIXED JENKINS-3107] Annotate the Advanced section if some fields are already customized.

          Compare: https://github.com/jenkinsci/jenkins/compare/99f84bc8e086...f6d20fa8f37d

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/lib/form/booleanRadio.jelly core/src/main/resources/lib/form/combobox.jelly core/src/main/resources/lib/form/editableComboBox.jelly core/src/main/resources/lib/form/enum.jelly core/src/main/resources/lib/form/hetero-radio.jelly core/src/main/resources/lib/form/number.jelly core/src/main/resources/lib/form/password.jelly core/src/main/resources/lib/form/select.jelly http://jenkins-ci.org/commit/jenkins/f6d20fa8f37da61095cb5bc686dfcb5d2176be74 Log: [FIXED JENKINS-3107] Annotate the Advanced section if some fields are already customized. Compare: https://github.com/jenkinsci/jenkins/compare/99f84bc8e086...f6d20fa8f37d

          dogfood added a comment -

          Integrated in jenkins_main_trunk #2841
          JENKINS-3107 Expand an Advanced section if some fields are already customized. (Revision 7ce4807087239bbe236cb34e9a8d183caffefe73)
          JENKINS-3107 Rather than preëxpanding the Advanced area, just show an icon. (Revision ef3d6e46b9826ab84098834261daafaa1fe3b6da)
          JENKINS-3107 IE 9 fix. (Revision d2eb9b4f633eba2ec07fdfb38f79a0c80e321475)
          JENKINS-3107 Icon looks better before button rather than after, for reasons of alignment with the rest of the form. (Revision 6eb958a11135ddfc28786e2377cd2b5824af8907)
          [FIXED JENKINS-3107] Annotate the Advanced section if some fields are already customized. (Revision f6d20fa8f37da61095cb5bc686dfcb5d2176be74)

          Result = SUCCESS
          Jesse Glick : 7ce4807087239bbe236cb34e9a8d183caffefe73
          Files :

          • core/src/main/resources/lib/form/textbox.jelly
          • core/src/main/resources/lib/form/expandableTextbox.jelly
          • core/src/main/resources/lib/form/advanced.jelly
          • core/src/main/resources/lib/form/textarea.jelly

          Jesse Glick : ef3d6e46b9826ab84098834261daafaa1fe3b6da
          Files :

          • core/src/main/resources/lib/form/advanced.jelly
          • core/src/main/resources/lib/form/advanced.properties

          Jesse Glick : d2eb9b4f633eba2ec07fdfb38f79a0c80e321475
          Files :

          • core/src/main/resources/lib/form/advanced.jelly

          Jesse Glick : 6eb958a11135ddfc28786e2377cd2b5824af8907
          Files :

          • core/src/main/resources/lib/form/advanced.jelly

          Jesse Glick : f6d20fa8f37da61095cb5bc686dfcb5d2176be74
          Files :

          • core/src/main/resources/lib/form/select.jelly
          • core/src/main/resources/lib/form/editableComboBox.jelly
          • core/src/main/resources/lib/form/number.jelly
          • core/src/main/resources/lib/form/booleanRadio.jelly
          • changelog.html
          • core/src/main/resources/lib/form/enum.jelly
          • core/src/main/resources/lib/form/password.jelly
          • core/src/main/resources/lib/form/hetero-radio.jelly
          • core/src/main/resources/lib/form/combobox.jelly

          dogfood added a comment - Integrated in jenkins_main_trunk #2841 JENKINS-3107 Expand an Advanced section if some fields are already customized. (Revision 7ce4807087239bbe236cb34e9a8d183caffefe73) JENKINS-3107 Rather than preëxpanding the Advanced area, just show an icon. (Revision ef3d6e46b9826ab84098834261daafaa1fe3b6da) JENKINS-3107 IE 9 fix. (Revision d2eb9b4f633eba2ec07fdfb38f79a0c80e321475) JENKINS-3107 Icon looks better before button rather than after, for reasons of alignment with the rest of the form. (Revision 6eb958a11135ddfc28786e2377cd2b5824af8907) [FIXED JENKINS-3107] Annotate the Advanced section if some fields are already customized. (Revision f6d20fa8f37da61095cb5bc686dfcb5d2176be74) Result = SUCCESS Jesse Glick : 7ce4807087239bbe236cb34e9a8d183caffefe73 Files : core/src/main/resources/lib/form/textbox.jelly core/src/main/resources/lib/form/expandableTextbox.jelly core/src/main/resources/lib/form/advanced.jelly core/src/main/resources/lib/form/textarea.jelly Jesse Glick : ef3d6e46b9826ab84098834261daafaa1fe3b6da Files : core/src/main/resources/lib/form/advanced.jelly core/src/main/resources/lib/form/advanced.properties Jesse Glick : d2eb9b4f633eba2ec07fdfb38f79a0c80e321475 Files : core/src/main/resources/lib/form/advanced.jelly Jesse Glick : 6eb958a11135ddfc28786e2377cd2b5824af8907 Files : core/src/main/resources/lib/form/advanced.jelly Jesse Glick : f6d20fa8f37da61095cb5bc686dfcb5d2176be74 Files : core/src/main/resources/lib/form/select.jelly core/src/main/resources/lib/form/editableComboBox.jelly core/src/main/resources/lib/form/number.jelly core/src/main/resources/lib/form/booleanRadio.jelly changelog.html core/src/main/resources/lib/form/enum.jelly core/src/main/resources/lib/form/password.jelly core/src/main/resources/lib/form/hetero-radio.jelly core/src/main/resources/lib/form/combobox.jelly

          Jesse Glick added a comment -

          Fixing JENKINS-19391 at the expense of making the annotation no longer work for the Advanced Project Options section: there is no apparent way to distinguish a non-field-based form entry which has sensible default behavior, from something crazy like the CoberturaPublisher configuration which does not use field (even where it clearly could) and deviates from the standard Jenkins style of making each subelement use its own Describable and config.xml and be data-bound. For that fix I am erring on the side of not showing the annotation.

          Given how little control the Jenkins core has over how plugins choose to (mis)use form binding, I am wondering whether this whole effort should be reverted on the grounds that there will be too many cases where it does not work and people will be misled into thinking that a section is not customized when it really is.

          Jesse Glick added a comment - Fixing JENKINS-19391 at the expense of making the annotation no longer work for the Advanced Project Options section: there is no apparent way to distinguish a non- field -based form entry which has sensible default behavior, from something crazy like the CoberturaPublisher configuration which does not use field (even where it clearly could) and deviates from the standard Jenkins style of making each subelement use its own Describable and config.xml and be data-bound. For that fix I am erring on the side of not showing the annotation. Given how little control the Jenkins core has over how plugins choose to (mis)use form binding, I am wondering whether this whole effort should be reverted on the grounds that there will be too many cases where it does not work and people will be misled into thinking that a section is not customized when it really is.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: