[JENKINS-70169] Add missing breadcrumb items

[lemeurherve]

Follow-up of #6912

Initially fixing JENKINS-70169, I've included every missing breadcrumb items I've found by searching for "sidepanel.jelly" in jelly files.

Notes:

• There are some places I didn't manage to find in Jenkins interface, marked by <!-- TODO: (no) breadcrumb here? -->, any hint would be welcome. ^* (for another PR)

• I've also added <!-- no need for breadcrumb here --> as comment in views where adding a breadcrumb item wasn't necessary, let me know if it's preferable to omit them.

• This doesn't fix missing breadcrumb depending on plugin (ex: Add missing breadcrumbs to job configuration cloudbees-folder-plugin#278)

Testing done

Built and ran Jenkins locally, going on modified pages to check the change (Except the locations I didn't found, cf asterisk above)

There is no additional automatic test added for these breadcrumb items.

Proposed changelog entries

• Entry 1: Add missing breadcrumb items
• […]

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

cc @Wadeck

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[Wadeck]

There are some places I didn't manage to find in Jenkins interface, marked by , any hint would be welcome. *

I would recommend you to have them somewhere else, like second PR, so that this one can be merged without too much ping pong discussion.

I've also added as comment in views where adding a breadcrumb item wasn't necessary, let me know if it's preferable to omit them.

I think that's important to have explicit information like this, to help future ourselves who are looking for information, for reason why it was not done, etc.

(will edit comment later, currently cloning your branch and testing before/after => edit not possible due to the review comments, so it counts as an edit... )

---

BTW due to the number of "bugs" found due to the previous change, it seems interesting to consider the revert of the previous PR, to ensure the behavior is as expected at least on the pages from core, without even thinking about plugins.

[amuniz]

Thanks!

[Wadeck]

I stopped the review after the LogRecorderManager pages.

The situation does not seem as easy as initially thought and contains multiple caveats.

If we want to not revert the previous PR, we have to create multiple smaller PRs focused on one area, easier to test and move forward.

Changes addressed

[uhafner]

When I look at all those similar changes in these jelly views I think we should not increase the layout mess by adding another duplicate element to those views. Wouldn't it be a much cleaner architecture if we would encapsulate the view composition into a new jelly template?
Then we can later change only a single file if we need to adapt the side panel or breadcrumbs again.

So

<l:layout title="${%Available plugins} - ${%Plugin Manager}" permission="${app.SYSTEM_READ}">
     <st:include page="sidepanel.jelly"/>
     <l:breadcrumb title="${%Available plugins}" />

     <l:main-panel>
       <l:app-bar title="${%Plugins}" />
          ... Actual View Code ...

will be simplified to

<l:layout 
      title="${%Plugin Manager}" 
      subTitle="${%Available plugins}"
      permission="${app.SYSTEM_READ}" 
      hasSidePanel="true"/>

          ... Actual View Code ...

Thank we can silently add an app bar for every view in the main jelly file.

[lemeurherve]

I'll take a look at the suggestion from @uhafner, meanwhile I'm splitting this PR in smaller ones for a potential quicker (short term) resolution.

• Add missing breadcrumb items in resources/jenkins
• Add missing breadcrumb items in resources/hudson/slaves
• Add missing breadcrumb items in resources/hudson/PluginManager
• Add missing breadcrumb items in resources/hudson/logging
• Add missing breadcrumb items in resources/hudson/model/User
• Add missing breadcrumb items in resources/hudson/model/Run
• Add missing breadcrumb items in resources/hudson/model/View
• Add missing breadcrumb items in resources/hudson/model/Abstract*
• Add missing breadcrumb items in resources/hudson/model/Computer*
• Add missing breadcrumb items in various resources/hudson locations

[lemeurherve]

Split completed, closing this PR.

[lemeurherve]

I understand most of these PRs might not ever be merged, but could at least this one be taken in account?

#7491

It contains the fix for the Console log view, which is the subject of the JENKINS issue and the most lacking breadcrumb IMO