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.

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?

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.

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.

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

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')?

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

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.

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

> 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

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

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

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

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

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…

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.

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.

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?

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

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.

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'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

• JENKINS-37857 Fix review items from @daniel-beck

Fixed in 2.22

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.

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?