Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            Hide
            jacob_robertson Jacob Robertson added a comment -

            Duplicate of JENKINS-19142

            See workaround mentioned there - add a filter (i.e. regex filter) to filter out all jobs as your first filter, then add jobs back in with filters.

            Show
            jacob_robertson Jacob Robertson added a comment - Duplicate of JENKINS-19142 See workaround mentioned there - add a filter (i.e. regex filter) to filter out all jobs as your first filter, then add jobs back in with filters.
            Hide
            sbreitbach Steffen Breitbach added a comment -

            Hi Jacob,

            you marked this issue as Duplicate of itself.

            Apart from that, I don't think I get your explanation. How does the usage of filters prevent Jenkins from adding Jobs to that view?

            Show
            sbreitbach Steffen Breitbach added a comment - Hi Jacob, you marked this issue as Duplicate of itself. Apart from that, I don't think I get your explanation. How does the usage of filters prevent Jenkins from adding Jobs to that view?
            Hide
            jacob_robertson Jacob Robertson added a comment -

            Oops. Should have been Duplicate of JENKINS-14799.

            Adding filters doesn't prevent it from adding jobs to that view, but it does prevent it from displaying the jobs that are added. So you'll see a bunch of jobs in the massive list of checkboxes, but then the first filter will filter all those jobs out, and then subsequent filters will add whatever exact jobs you actually want back in. It's just a workaround, and I think JENKINS-14799 speaks to your issue.

            Show
            jacob_robertson Jacob Robertson added a comment - Oops. Should have been Duplicate of JENKINS-14799 . Adding filters doesn't prevent it from adding jobs to that view, but it does prevent it from displaying the jobs that are added. So you'll see a bunch of jobs in the massive list of checkboxes, but then the first filter will filter all those jobs out, and then subsequent filters will add whatever exact jobs you actually want back in. It's just a workaround, and I think JENKINS-14799 speaks to your issue.
            Hide
            sbreitbach Steffen Breitbach added a comment - - edited

            Sorry, I guess I picked the wrong component. I wasn't aware that there is a plug in "View Job Filters". Looks interesting though, might give it a try.

            However, the issue persists in Jenkins core, so I've reopened the issue.

            Show
            sbreitbach Steffen Breitbach added a comment - - edited Sorry, I guess I picked the wrong component. I wasn't aware that there is a plug in "View Job Filters". Looks interesting though, might give it a try. However, the issue persists in Jenkins core, so I've reopened the issue.
            Hide
            yoichi Yoichi Nakayama added a comment -

            Why don't you click "New Job" in the context menu via the breadcrumb list?

            Show
            yoichi Yoichi Nakayama added a comment - Why don't you click "New Job" in the context menu via the breadcrumb list?
            Hide
            danielbeck Daniel Beck added a comment -

            Yoichi: Won't this just add the job to the selected item group's default view (that may well be computed, like ci.jenkins-ci.org's 'All Failed')?

            Show
            danielbeck Daniel Beck added a comment - Yoichi: Won't this just add the job to the selected item group's default view (that may well be computed, like ci.jenkins-ci.org's 'All Failed')?
            Hide
            yoichi Yoichi Nakayama added a comment -

            In ListView, regular expression and manual selection can be used together.
            So I think it is difficult to determine whether to add automatically.

            Show
            yoichi Yoichi Nakayama added a comment - In ListView, regular expression and manual selection can be used together. So I think it is difficult to determine whether to add automatically.
            Hide
            danielbeck Daniel Beck added a comment -

            First order approximation could be whether there are any jobs selected for manual inclusion. If all of them are deselected, and the contents of the view entirely computed using regexp and/or filters, don't add the job to the list.

            FWIW a Greasemonkey userscript might also be able to change the 'New Job' URL from /view/Viewname/newJob to /newJob to prevent the job from being added to the view automatically.

            Show
            danielbeck Daniel Beck added a comment - First order approximation could be whether there are any jobs selected for manual inclusion. If all of them are deselected, and the contents of the view entirely computed using regexp and/or filters, don't add the job to the list. FWIW a Greasemonkey userscript might also be able to change the 'New Job' URL from /view/Viewname/newJob to /newJob to prevent the job from being added to the view automatically.
            Hide
            yoichi Yoichi Nakayama added a comment -

            > First order approximation could be whether there are any jobs selected for manual inclusion. If all of them are deselected, and the contents of the view entirely computed using regexp and/or filters, don't add the job to the list.

            When a user invoke "New Job" from a view, I think the expected behavior is that new item is included in the view.
            Now I think the point of the problem is any item will be checked in View configuration page even if it matches regexp.
            Following patch avoids such double inclusion:
            https://github.com/yoichi/jenkins/commit/01269b8dec9dc40dfac7e197a40053abb67f52a6
            How about that?

            > FWIW a Greasemonkey userscript might also be able to change the 'New Job' URL from /view/Viewname/newJob to /newJob to prevent the job from being added to the view automatically.

            Same result is achieved by clicking "New Job" in the top-level context menu via the breadcrumb list, as I mentioned above.

            Show
            yoichi Yoichi Nakayama added a comment - > First order approximation could be whether there are any jobs selected for manual inclusion. If all of them are deselected, and the contents of the view entirely computed using regexp and/or filters, don't add the job to the list. When a user invoke "New Job" from a view, I think the expected behavior is that new item is included in the view. Now I think the point of the problem is any item will be checked in View configuration page even if it matches regexp. Following patch avoids such double inclusion: https://github.com/yoichi/jenkins/commit/01269b8dec9dc40dfac7e197a40053abb67f52a6 How about that? > FWIW a Greasemonkey userscript might also be able to change the 'New Job' URL from /view/Viewname/newJob to /newJob to prevent the job from being added to the view automatically. Same result is achieved by clicking "New Job" in the top-level context menu via the breadcrumb list, as I mentioned above.
            Hide
            yoichi Yoichi Nakayama added a comment - - edited

            > Same result is achieved by clicking "New Job" in the top-level context menu via the breadcrumb list, as I mentioned above.

            I noticed it is not true if default view configuration is not AllView.
            One extra step is needed in that case: select AllView before adding a job

            Show
            yoichi Yoichi Nakayama added a comment - - edited > Same result is achieved by clicking "New Job" in the top-level context menu via the breadcrumb list, as I mentioned above. I noticed it is not true if default view configuration is not AllView. One extra step is needed in that case: select AllView before adding a job
            Hide
            sbreitbach Steffen Breitbach added a comment -

            In ListView, regular expression and manual selection can be used together.
            So I think it is difficult to determine whether to add automatically.

            That's exactly the reason why I wanted to have the "don't add job to view on creation"-Flag (on each view).

            To explain my particulat need for this:

            I administrate our Jenkins installation. Our Jenkins does have 16 main views with 4 nested views each (so 64 in total) in order to structure our roughly 1200 jobs. We have round about 100-150 Users that use Jenkins.

            The problem is that they tend to create their jobs "anywhere" and not in the particular view the are supposed to. So I don't want to have that job being displayed in the view they created it in (we manage this by regular expressions).

            Show
            sbreitbach Steffen Breitbach added a comment - In ListView, regular expression and manual selection can be used together. So I think it is difficult to determine whether to add automatically. That's exactly the reason why I wanted to have the "don't add job to view on creation"-Flag (on each view). To explain my particulat need for this: I administrate our Jenkins installation. Our Jenkins does have 16 main views with 4 nested views each (so 64 in total) in order to structure our roughly 1200 jobs. We have round about 100-150 Users that use Jenkins. The problem is that they tend to create their jobs "anywhere" and not in the particular view the are supposed to. So I don't want to have that job being displayed in the view they created it in (we manage this by regular expressions).
            Hide
            yoichi Yoichi Nakayama added a comment -

            Steffen,
            Thank you for the clarification.
            Is it sufficient to introduce a new configuration to view as follows?
            https://github.com/yoichi/jenkins/commit/d0b7ab6d86b7883271d452caaa435520339956cb

            Show
            yoichi Yoichi Nakayama added a comment - Steffen, Thank you for the clarification. Is it sufficient to introduce a new configuration to view as follows? https://github.com/yoichi/jenkins/commit/d0b7ab6d86b7883271d452caaa435520339956cb
            Hide
            sbreitbach Steffen Breitbach added a comment -

            Hi Yoichi,

            looks good from a first glance, thanks

            For my clarification: what is "root" in this context? Is it the "Default view" as configured in the Jenkins main configuration?

            Regards
            Steffen

            Show
            sbreitbach Steffen Breitbach added a comment - Hi Yoichi, looks good from a first glance, thanks For my clarification: what is "root" in this context? Is it the "Default view" as configured in the Jenkins main configuration? Regards Steffen
            Hide
            yoichi Yoichi Nakayama added a comment -

            > For my clarification: what is "root" in this context? Is it the "Default view" as configured in the Jenkins main configuration?

            No, it is not "Default View". It indicates /newJob instead of /view/Viewname/newJob.
            There might be more appropriate name...

            Show
            yoichi Yoichi Nakayama added a comment - > For my clarification: what is "root" in this context? Is it the "Default view" as configured in the Jenkins main configuration? No, it is not "Default View". It indicates /newJob instead of /view/Viewname/newJob. There might be more appropriate name...
            Hide
            danielbeck Daniel Beck added a comment -

            Maybe '(Do not) Automatically add new jobs to this view'?

            I'd actually prefer it if the jobs list (and the regexp) were made into a regular job filter that can be added, and if the view has no jobs list filter, jobs aren't added to the view automatically. But that's probably a lot of work…

            Show
            danielbeck Daniel Beck added a comment - Maybe '(Do not) Automatically add new jobs to this view'? I'd actually prefer it if the jobs list (and the regexp) were made into a regular job filter that can be added, and if the view has no jobs list filter, jobs aren't added to the view automatically. But that's probably a lot of work…
            Hide
            yoichi Yoichi Nakayama added a comment -

            Introducing new config independent from job selector was not a good idea.
            I've reworked to add option to disable job selector:
            https://github.com/yoichi/jenkins/commit/f00ecb653173b27785d3e9719a4848ad6377b178
            If job selector is disabled, new job won't be added to the view.

            Show
            yoichi Yoichi Nakayama added a comment - Introducing new config independent from job selector was not a good idea. I've reworked to add option to disable job selector: https://github.com/yoichi/jenkins/commit/f00ecb653173b27785d3e9719a4848ad6377b178 If job selector is disabled, new job won't be added to the view.
            Hide
            danielbeck Daniel Beck added a comment -

            When a user invoke "New Job" from a view, I think the expected behavior is that new item is included in the view.

            Unless it's the default view. How else are you creating jobs, if not in a view? There's no way (except by entering the URL or using weird view types) to create a job and not have it listed in any way. Since Folders plugin always uses a list view as default view, using a different view type as default won't work.

            I've reworked to add option to disable job selector:

            Not sure this is approach is better than the earlier one. I have a default view with manually selected contents. Any newly created jobs are added to that view automatically (unless users select a different view first). To disable automatically adding jobs, I need to use a workaround to get the manually selected content.

            How about the following:

            Let's assume that the problem is mostly with the default view in the current ViewGroup, because users who just want to create a new job usually select the ItemGroup<TopLevelItem> the job should be in (i.e. Jenkins homepage, or a folder), and then create it there.

            Further, note that URLs /.../ and /.../view/DefaultViewName/ both exist and show the same view (you navigate to the latter after saving a default view's configuration). Unfortunately, when clicking the 'DefaultViewName' tab, you're directed to /.../ instead of /.../view/DefaultViewName/.

            How about 1) the 'New Job' link simply links to (effectively) $currentUrl/newJob, and 2) the tab title for 'DefaultViewName' links to /.../view/DefaultViewName/? Then you won't automatically add jobs to the default view if you just selected its parent, but will be able to add jobs to it when navigating there deliberately.

            Unfortunately, this will behave weirdly when you only have one view. In that case, a redirect to /.../view/DefaultViewName/ might work: If there are other views, don't add the job anywhere, otherwise add to the default view.

            Maybe the solution is to get rid of the default view entirely and use a dashboard-like or nested-view-like view instead, whose 'Add' link doesn't have add jobs anywhere by default. Won't work for Folders plugin unfortunately, as the default view is always a list view.

            To explain my particulat need for this:

            Also adding one of my use cases: I have a Jenkins instance with ~6500 jobs which build and bundle components for a rather large software distribution. Nobody cares about these jobs as long as they're successful, and showing list views with 150-4500 jobs each (distinguished by type, and no further division is useful) wouldn't be productive. So the only views I have only show unstable, failing, or disabled jobs, using View Job Filters. When someone adds a new job, it makes no sense to add it to one of these computed views.

            Show
            danielbeck Daniel Beck added a comment - When a user invoke "New Job" from a view, I think the expected behavior is that new item is included in the view. Unless it's the default view. How else are you creating jobs, if not in a view? There's no way (except by entering the URL or using weird view types) to create a job and not have it listed in any way. Since Folders plugin always uses a list view as default view, using a different view type as default won't work. I've reworked to add option to disable job selector: Not sure this is approach is better than the earlier one. I have a default view with manually selected contents. Any newly created jobs are added to that view automatically (unless users select a different view first). To disable automatically adding jobs, I need to use a workaround to get the manually selected content. How about the following: Let's assume that the problem is mostly with the default view in the current ViewGroup , because users who just want to create a new job usually select the ItemGroup<TopLevelItem> the job should be in (i.e. Jenkins homepage, or a folder), and then create it there. Further, note that URLs /.../ and /.../view/DefaultViewName/ both exist and show the same view (you navigate to the latter after saving a default view's configuration). Unfortunately, when clicking the 'DefaultViewName' tab, you're directed to /.../ instead of /.../view/DefaultViewName/ . How about 1) the 'New Job' link simply links to (effectively) $currentUrl/newJob , and 2) the tab title for 'DefaultViewName' links to /.../view/DefaultViewName/ ? Then you won't automatically add jobs to the default view if you just selected its parent, but will be able to add jobs to it when navigating there deliberately. Unfortunately, this will behave weirdly when you only have one view. In that case, a redirect to /.../view/DefaultViewName/ might work: If there are other views, don't add the job anywhere, otherwise add to the default view. Maybe the solution is to get rid of the default view entirely and use a dashboard-like or nested-view-like view instead, whose 'Add' link doesn't have add jobs anywhere by default. Won't work for Folders plugin unfortunately, as the default view is always a list view. To explain my particulat need for this: Also adding one of my use cases: I have a Jenkins instance with ~6500 jobs which build and bundle components for a rather large software distribution. Nobody cares about these jobs as long as they're successful, and showing list views with 150-4500 jobs each (distinguished by type, and no further division is useful) wouldn't be productive. So the only views I have only show unstable, failing, or disabled jobs, using View Job Filters. When someone adds a new job, it makes no sense to add it to one of these computed views.
            Hide
            yoichi Yoichi Nakayama added a comment - - edited

            Daniel,
            I understand that there is no need to add job into View automatically, for your use case.
            How about introducing a global config to disable/enable the behavior?

            Show
            yoichi Yoichi Nakayama added a comment - - edited Daniel, I understand that there is no need to add job into View automatically, for your use case. How about introducing a global config to disable/enable the behavior?
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            yoichi 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

            Show
            yoichi 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
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            oleg_nenashev 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

            Show
            oleg_nenashev 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
            Hide
            krulls 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.

            Show
            krulls 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.
            Hide
            scm_issue_link 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
            Show
            scm_issue_link 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
            Hide
            vlatombe Vincent Latombe added a comment -

            Fixed in 2.22

            Show
            vlatombe Vincent Latombe added a comment - Fixed in 2.22
            Hide
            alexellisadp 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.

            Show
            alexellisadp 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.
            Hide
            vlatombe 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.

            Show
            vlatombe 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.
            Hide
            alexellisadp 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?

            Show
            alexellisadp 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?

              People

              • Assignee:
                vlatombe Vincent Latombe
                Reporter:
                sbreitbach Steffen Breitbach
              • Votes:
                2 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: