• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      On creating a new job while being in a view, the job will be added to this view. This doesn't neccesarily make sense, especially when using regular expressions to filter the jobs.

      There should be a flag "don't add job to view on creation" in the view or a similar mechanism to prevent this.

          [JENKINS-19142] Don't add jobs to a view

          Daniel Beck added a comment -

          Yoichi: I doubt it's always as clear cut as the instance I mentioned. A global preference applies to your entire Jenkins (and on another instance, I have jobs for ~15 projects and teams with different needs), and is hidden from the users it affects (no preference in the affected views themselves, or a rule to learn to figure out the behavior).

          IMO, if this request is implemented using a new preference, that preference should be on the ListView level.

          Daniel Beck added a comment - Yoichi: I doubt it's always as clear cut as the instance I mentioned. A global preference applies to your entire Jenkins (and on another instance, I have jobs for ~15 projects and teams with different needs), and is hidden from the users it affects (no preference in the affected views themselves, or a rule to learn to figure out the behavior). IMO, if this request is implemented using a new preference, that preference should be on the ListView level.

          How about the following?

          • In newJob page of ListView, a checkbox to control whether to add new job to the view.
          • In config page of ListView, a checkbox to control default status of checkbox in newJob page.

          Implemented in:
          https://github.com/yoichi/jenkins/compare/JENKINS-19142-3

          Yoichi Nakayama added a comment - How about the following? In newJob page of ListView, a checkbox to control whether to add new job to the view. In config page of ListView, a checkbox to control default status of checkbox in newJob page. Implemented in: https://github.com/yoichi/jenkins/compare/JENKINS-19142-3

          Daniel Beck added a comment -

          From only reading the code, this looks like a reasonable compromise. I added a few comments on the commits.


          Just an idea, would an additional option 'Allow item creators to choose' be useful? I.e. to change between 'setting the default option' and 'enforcing one behavior' (maybe even in an Advanced… section of the list view configuration to make them less intimidating).

          This would allow the following:

          • Include new item into the view, and do not offer to change this behavior (today's behavior)
          • By default, include new item into the view, but offer to change this behavior
          • By default, don't include new item into the view, but offer to change this behavior
          • Don't include new item into the view, and do not offer to change this behavior

          If the user responsible for the view knows better than some item creator who happens to have access to the view, this would allow them to prevent adding entries to the list.

          Daniel Beck added a comment - From only reading the code, this looks like a reasonable compromise. I added a few comments on the commits. Just an idea, would an additional option 'Allow item creators to choose' be useful? I.e. to change between 'setting the default option' and 'enforcing one behavior' (maybe even in an Advanced… section of the list view configuration to make them less intimidating). This would allow the following: Include new item into the view, and do not offer to change this behavior (today's behavior) By default, include new item into the view, but offer to change this behavior By default, don't include new item into the view, but offer to change this behavior Don't include new item into the view, and do not offer to change this behavior If the user responsible for the view knows better than some item creator who happens to have access to the view, this would allow them to prevent adding entries to the list.

          Oleg Nenashev added a comment -

          There's a simple workaround.

          1) Install View Job Filters Plugin. https://wiki.jenkins-ci.org/display/JENKINS/View+Job+Filters
          2) Add the "Exclude all" as a first filter
          3) Insert all filters you need after the first one

          Oleg Nenashev added a comment - There's a simple workaround. 1) Install View Job Filters Plugin. https://wiki.jenkins-ci.org/display/JENKINS/View+Job+Filters 2) Add the "Exclude all" as a first filter 3) Insert all filters you need after the first one

          Stephan Krull added a comment -

          Oleg Nenashev's workaround works perfect for me. This keeps me from insisting to the following detail:

          By closing JENKINS-19596 this issue is no longer treated as a bug but as an improvement. I disagree because in my understandig there should be differantiation between job and view. A view has to show objects that have been configured for that view. If there is a regex or a manually checked lists of jobs that belong to that view than no algorithm or automatic process should slip in this configuration (as is by creating a new job in that view). A newly created job should be included only in views whose configurations is appropriate. This definition makes this issue a bug.

          Stephan Krull added a comment - Oleg Nenashev's workaround works perfect for me. This keeps me from insisting to the following detail: By closing JENKINS-19596 this issue is no longer treated as a bug but as an improvement. I disagree because in my understandig there should be differantiation between job and view. A view has to show objects that have been configured for that view. If there is a regex or a manually checked lists of jobs that belong to that view than no algorithm or automatic process should slip in this configuration (as is by creating a new job in that view). A newly created job should be included only in views whose configurations is appropriate. This definition makes this issue a bug.

          Code changed in jenkins
          User: Vincent Latombe
          Path:
          core/src/main/java/hudson/model/ListView.java
          core/src/main/resources/hudson/model/ListView/newJobButtonBar.jelly
          core/src/main/resources/hudson/model/View/newJob.jelly
          core/src/main/resources/hudson/model/View/newJobButtonBar.jelly
          war/src/main/js/widgets/add/addform.less
          http://jenkins-ci.org/commit/jenkins/f4c9eb0322f44d1f6b025a509fcae5a704bde666
          Log:
          JENKINS-19142 Prompt user whether to add the job to the current view (#2529)

          • JENKINS-37857 Prompt user whether to add the job to the current view

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Vincent Latombe Path: core/src/main/java/hudson/model/ListView.java core/src/main/resources/hudson/model/ListView/newJobButtonBar.jelly core/src/main/resources/hudson/model/View/newJob.jelly core/src/main/resources/hudson/model/View/newJobButtonBar.jelly war/src/main/js/widgets/add/addform.less http://jenkins-ci.org/commit/jenkins/f4c9eb0322f44d1f6b025a509fcae5a704bde666 Log: JENKINS-19142 Prompt user whether to add the job to the current view (#2529) JENKINS-37857 Prompt user whether to add the job to the current view JENKINS-37857 Fix review items from @daniel-beck

          Fixed in 2.22

          Vincent Latombe added a comment - Fixed in 2.22

          Alex Ellis added a comment -

          Causes regression in createItem by view in Jenkins 2.0 and onwards. Please consider reverting changes or making the code which expects a form submission optional, not mandatory. See related bug notes for more details.

          Alex Ellis added a comment - Causes regression in createItem by view in Jenkins 2.0 and onwards. Please consider reverting changes or making the code which expects a form submission optional, not mandatory. See related bug notes for more details.

          Please don't reopen this issue because it caused a regression. There is already JENKINS-41128 opened to track the problem.

          Vincent Latombe added a comment - Please don't reopen this issue because it caused a regression. There is already JENKINS-41128 opened to track the problem.

          Alex Ellis added a comment - - edited

          Technically the code contributed for this fix will have to change to accommodate the breakage. So it may need to be re-opened for re-testing. Also does it make sense to request a regression test from the original fixer? Does the project have any regression tests on top of the unit tests?

          Alex Ellis added a comment - - edited Technically the code contributed for this fix will have to change to accommodate the breakage. So it may need to be re-opened for re-testing. Also does it make sense to request a regression test from the original fixer? Does the project have any regression tests on top of the unit tests?

            vlatombe Vincent Latombe
            sbreitbach Steffen Breitbach
            Votes:
            2 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: