This issue is causing hindrance in automation testing due the reason that multiple teams working with an agent now have no idea who actually has the node/agent offlined and whom to contact.

Jenkins: 2.440.3
OS: Linux - 3.10.0-514.el7.x86_64
Java: 17.0.10 - Eclipse Adoptium (OpenJDK 64-Bit Server VM)

I disagree that the email address should be used instead of the username. Email address is not a unique identifier in Jenkins. The user ID describes the user that performed the action.

Even though email/username doesn't seem unique identifier, one could quickly identify who exactly made the agent offline and contact them if required.
With user ID, this is impossible to do without maintaining some sort of look up table and searching for name corresponding to the user ID.
The user ID may be unique, it is affecting the user experience.
One alternative way could be displaying both the username and the unique ID?

This issue was also filed as https://github.com/jenkinsci/azure-ad-plugin/issues/575. If Jenkins is using the Microsoft Entra ID security realm, then Jenkins user IDs are Microsoft Entra object IDs, and Jenkins displays something like this:

Nov 10, 2024, 2:51:36 PM
Disconnected by c86d8884-f8f9-443d-b94b-fcdf3b2b066f : adding more RAM and disk

From this, it is not obvious how to contact the user. If the message displayed the user name and/or email address, then that would be easier. Alternatively, the message could link to the "/user/c86d8884-f8f9-443d-b94b-fcdf3b2b066f/" page, which shows the user name and email address.

I'm not sure how read access to those per-user pages is managed, though. AuthorizationStrategy.getAcl(User) (javadoc, source) just calls getRootAcl() by default, and neither AzureAdMatrixAuthorizationStrategy nor GlobalMatrixAuthorizationStrategy overrides that, so I guess the per-user pages will be readable by anyone who has Overall/Read access to Jenkins.

I think this should (1) show the display name of the user, from User.getDisplayName(); and (2) link to the per-user page that shows the rest of the information, including the unique user ID.

For the hyperlink, there is a complication. OfflineCause.UserCause currently extends OfflineCause.SimpleOfflineCause, which extends OfflineCause. The OfflineCause.SimpleOfflineCause class is documented as:

{@link OfflineCause} that renders a static text, but without any further UI.

Would it be OK to add a jelly template for OfflineCause.UserCause while it extends OfflineCause.SimpleOfflineCause, or should one instead break the API and make OfflineCause.UserCause extend OfflineCause directly, like OfflineCause.ChannelTermination and OfflineCause.LaunchFailed do?

OfflineCause was recently changed in https://github.com/jenkinsci/jenkins/pull/9883 but those changes don't look like they'd affect how this should be implemented.