Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-69339] Add support for badge icons in Management links #6995

Merged
merged 15 commits into from
Jan 2, 2023

Conversation

mawinter69
Copy link
Contributor

@mawinter69 mawinter69 commented Aug 15, 2022

Allow to define a badge icon and a tooltip for all management links.

Adjust PluginsLink to the new method
Add implementations for OldDataMonitor and NodesLink

See JENKINS-69339.

Proposed changelog entries

  • Add support for badge icons in Management links

Proposed upgrade guidelines

N/A

Submitter checklist

  • (If applicable) Jira issue is well described
  • Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
    • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
  • Appropriate autotests or explanation to why this change has no tests
  • New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, 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 directives (see documentation on jenkins.io).
  • For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

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

  • There are at least 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 does not block the change
  • Changelog entries in the PR 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, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (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).

Allow to define a badge icon and a tooltip for all management links
fix compile errors
@daniel-beck daniel-beck self-requested a review August 15, 2022 13:55
@NotMyFault NotMyFault added web-ui The PR includes WebUI changes which may need special expertise rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted needs-security-review Awaiting review by a security team member labels Aug 15, 2022
@NotMyFault NotMyFault requested a review from a team August 15, 2022 19:27
@daniel-beck
Copy link
Member

The weird thing about the existing badge is that it only exists for a feature that does not have a corresponding admin monitor (plugin updates). My guess is that it's probably deliberately so, because there are always plugin updates, especially since JEP-229, so having an admin monitor that's always on would be spammy and quickly ignored by many admins.

Other features like Old Data Monitor do have an admin monitor when they have useful content. Usually because this is something that needs attention (in that case, loss of configuration data, loss of functionality, etc.).

If this is added, we need to provide guidelines to explain when you would have the admin monitor, when you would have the badge, and when you would have both.

An interesting case is In-Process Script Approval (script-security plugin): It currently has a badge-like feature (the label changes). This feature should be migrated to badges if this is merged (would make a nice downstream PR for this change), and I wonder whether an admin monitor would make sense there as well. Could probably go either way.

Copy link
Member

@daniel-beck daniel-beck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like this PR. It cleans up the existing tooltip for plugin updates and adds useful additional tooltips (although I'm not entirely sure the node one is useful as-is, given agents on a schedule etc.).

An open question remains about the guidelines for plugin developers on how to use this feature. We should have documentation when to (not) use this ready at the same time we publish this API addition. If we keep the String type, the docs should also explain it's for short labels only (probably mostly numeric; e.g., 4 of 12 might be OK, 21 available updates is not). This should be added to Javadoc and/or https://plugins.jenkins.io/design-library/

Otherwise (and assuming a quick re-test confirms the non-HTML tooltip behavior) this looks good 👍

<div tooltip="${m.getUpdateCount() == 1 ? '%updateAvailable(m.getUpdateCount())' : '%updatesAvailable(m.getUpdateCount())'}" class="jenkins-section__item__icon__badge">
${m.getUpdateCount()}
<j:if test="${m.badge != null}">
<div tooltip="${m.badgeTooltip}" class="jenkins-section__item__icon__badge">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now (once re-merged with master) a non-HTML tooltip. That seems fine.

@daniel-beck daniel-beck added security-approved @jenkinsci/core-security-review reviewed this PR for security issues and removed needs-security-review Awaiting review by a security team member labels Dec 15, 2022
@daniel-beck
Copy link
Member

assuming a quick re-test confirms the non-HTML tooltip behavior

Confirmed, non-HTML tooltip and content when merged with master.

@mawinter69
Copy link
Contributor Author

I'm wondering if there are other places where such badges might be useful. If so it might make sense to create a Badge class that contains the data, tooltip and maybe a severity so the badge can have different colors. Even when not used somewhere else it might help to avoid running some calculations twice (once for the badge and once for the tooltip.
For severity, e.g. when there are plugin updates that fix security issues display it in red, otherwise in orange.

@mawinter69
Copy link
Contributor Author

(although I'm not entirely sure the node one is useful as-is, given agents on a schedule etc.).

The agents on a schedule wouldn't be a problem, but the ondemand would show up whenever they have nothing to do and thus disconnect. Maybe restrict the check to agents that use the always online strategy which is the default and most people use I guess.

@daniel-beck
Copy link
Member

avoid running some calculations twice (once for the badge and once for the tooltip

For expensive calculations, could be handled by individual ManagementLink in a cache. I don't think there are that many cases where computation would be expensive?

Feel free to sketch this out, might be reasonable for future extension (e.g. severity/color), but IMO all that's missing here is related documentation.

Maybe restrict the check to agents that use the always online strategy which is the default and most people use I guess.

Right, something along those lines. Might be simpler to remove this from the PR for now and look into it as followup. Migrating Manage Plugins to this is already pretty nice cleanup, and Manage Old Data is a reasonable new use.

Badge class takes message, tooltip and severity

Do not create badge for NodesLink. It will not work with the
agent-maintenance plugin as this configures as well a retention strategy
that can't be queried here. To get the reliably working Demand and
SimpleScheduled would need some reworking at least.

The plugin link badge now changes color when there is an update that
fixes a security vulnerability.
@mawinter69
Copy link
Contributor Author

I removed the badge for the nodes now, there is no way of reliably determining this information, e.g. when the agent-maintenance enabled for an agent, which is proxying the retentionstrategy
Added a Badge class to wrap all the information
Plugin update badge is now red when updates fix security vulnerabilities and orange otherwise. Tooltip shows the actual numbers for total updates and updates with security fixes. One could think of extending the badge/tooltip also for plugins that have incompatible changes

* @return badge or {@code null} if no badge should be shown.
* @since TODO
*/
public @CheckForNull Badge getBadge() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One drawback of the new Badge type is that it requires a new core dependency. Previously, the String based API could be implemented even by plugins with an old core dependency.

I don't think this change must be reverted, but considering simple page navigation shouldn't be expensive anyway, the argument for one call instead of two isn't that strong (expensive computation should be done elsewhere and cached values shown, kind of like available updates).

core/src/main/java/jenkins/management/PluginsLink.java Outdated Show resolved Hide resolved
core/src/main/java/jenkins/management/Badge.java Outdated Show resolved Hide resolved
war/src/main/less/modules/section.less Show resolved Hide resolved
add info about incompatible changes
@timja timja requested a review from a team December 29, 2022 20:15
Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM just one wording question in the Javadoc but no blockers, tested locally.

@timja timja requested review from daniel-beck and a team December 30, 2022 20:49
timja added a commit to timja/jenkins that referenced this pull request Dec 30, 2022
timja added a commit to timja/jenkins that referenced this pull request Dec 31, 2022
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
@timja
Copy link
Member

timja commented Dec 31, 2022

/label ready-for-merge


This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

@comment-ops-bot comment-ops-bot bot added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Dec 31, 2022
@timja timja merged commit 622e4c6 into jenkinsci:master Jan 2, 2023
@NotMyFault NotMyFault changed the title [JENKINS-69339] badge icon for Management links [JENKINS-69339] Add support for badge icons in Management links Jan 2, 2023
timja added a commit to janfaracik/jenkins that referenced this pull request Jan 2, 2023
@daniel-beck
Copy link
Member

timja dismissed daniel-beck’s stale review Dec 31, 2022
addressed

In multiple comments I kept requesting developer documentation. Could you point me to it?

#6995 (comment):

If this is added, we need to provide guidelines to explain when you would have the admin monitor, when you would have the badge, and when you would have both.

#6995 (review):

An open question remains about the guidelines for plugin developers on how to use this feature. We should have documentation when to (not) use this ready at the same time we publish this API addition. If we keep the String type, the docs should also explain it's for short labels only (probably mostly numeric; e.g., 4 of 12 might be OK, 21 available updates is not). This should be added to Javadoc and/or https://plugins.jenkins.io/design-library/

#6995 (review):

FWIW I look forward to reading in docs about the interaction between admin monitors and badges here :)

@timja
Copy link
Member

timja commented Jan 2, 2023

In multiple comments I kept requesting developer documentation. Could you point me to it?

/**
* Definition of a badge that can be returned by a {@link ManagementLink} implementation.
* The badge is shown as a small overlay over the corresponding icon on the {@code Manage Jenkins} page,
* it can display additional information in a tooltip and change it's color depending on the severity.
*
* <p>
* A badge mainly serves as a fast feedback for the corresponding management page.
* It could be used to just display some short status information or hint that some action can be taken.
* For example the badge on {@code Manage Plugins} shows information about the number of available updates
* and in its tooltip additionally how many updates contain incompatible changes or fix
* security vulnerabilities. It also changes its color when there are security fixes available.
*
* <p>
* A badge might display the same information as an {@link AdministrativeMonitor}. While an {@link AdministrativeMonitor}
* can be disabled, a badge will always be shown. E.g. the badge of {@link OldDataMonitor.ManagementLinkImpl} always shows the number of old data entries.
*
* @since TODO
*/

/**
* A {@link Badge} shown as overlay over the icon on "Manage Jenkins".
*
* @return badge or {@code null} if no badge should be shown.
* @since TODO
*/

If we keep the String type, the docs should also explain it's for short labels only (probably mostly numeric; e.g., 4 of 12 might be OK, 21

/**
* Create a new Badge
*
* @param text The text to be shown in the badge.
* Keep it short, ideally just a number. More than 6 or 7 characters do not look good. Avoid spaces as they will lead to line breaks.
* as this might lead to line breaks.
* @param tooltip The tooltip to show for the badge.
* Do not include html tags.
* @param severity The severity of the badge (danger, warning, info)
*/

@daniel-beck
Copy link
Member

Thanks, missed it (or forgot in the mean time) 👍

NotMyFault added a commit that referenced this pull request Apr 16, 2023
* Init

* Update core/src/main/resources/lib/layout/task.jelly

Co-authored-by: Alexander Brandes <brandes.alexander@web.de>

* Remove duplicated class

* Update core/src/main/resources/lib/layout/task.jelly

Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>

* Add support for badges in menus + manage jenkins page

* Update index.jelly

* Update ModelObjectWithContextMenu.java

* Merge with #6995

* Add tooltip in task links

* Add tooltip support to badges

* Lint

* Escape badge tooltip/text in menus

* Use xmlEscape for escaping attributes

* Support nulls

* Update breadcrumbs.js

* Update breadcrumbs.js

---------

Co-authored-by: Alexander Brandes <brandes.alexander@web.de>
Co-authored-by: Daniel Beck <1831569+daniel-beck@users.noreply.github.com>
Co-authored-by: Tim Jacomb <21194782+timja@users.noreply.github.com>
Co-authored-by: Tim Jacomb <timjacomb1@gmail.com>
Co-authored-by: Alexander Brandes <mc.cache@web.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted security-approved @jenkinsci/core-security-review reviewed this PR for security issues web-ui The PR includes WebUI changes which may need special expertise
Projects
None yet
5 participants