starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Colour code dot on notification bell #11892

New Issue
Open
opened 2025-12-29 21:51:16 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:51:16 +01:00
Owner
Copy Link

Originally created by @cs-1 on GitHub (Dec 4, 2025).

NetBox version

v4.4.7

Feature type

Change to existing functionality

Proposed functionality

It would be helpful to colour code the dot for new notifications next to the notification bell in the upper right corner:

  • green dot: all notifications are success messages,
  • red dot: at least one notification is a failure message.

Use case

In everyday use it's important to tell success notifications from failure notifications. Right now, all new notifications are indicated by a red dot to the upper right of the notification bell. Red in general indicates some sort of problem. However, the dot is also red if there're just success messages present. Colour coding the dot would help to quickly assess whether failure notifications are present or not. Especially if there're many background jobs with regular notifications, success messages don't necessarily force you to check the notifications.

Database changes

Likely not necessary.

External dependencies

N/A.

Originally created by @cs-1 on GitHub (Dec 4, 2025). ### NetBox version v4.4.7 ### Feature type Change to existing functionality ### Proposed functionality It would be helpful to colour code the dot for new notifications next to the notification bell in the upper right corner: - green dot: all notifications are success messages, - red dot: at least one notification is a failure message. ### Use case In everyday use it's important to tell success notifications from failure notifications. Right now, all new notifications are indicated by a red dot to the upper right of the notification bell. Red in general indicates some sort of problem. However, the dot is also red if there're just success messages present. Colour coding the dot would help to quickly assess whether failure notifications are present or not. Especially if there're many background jobs with regular notifications, success messages don't necessarily force you to check the notifications. ### Database changes Likely not necessary. ### External dependencies N/A.
adam added the type: featurestatus: under reviewnetbox labels 2025-12-29 21:51:16 +01:00
adam commented 2025-12-29 21:51:17 +01:00
Author
Owner
Copy Link

@rconkor commented on GitHub (Dec 4, 2025):

Typically the logic I see would be:

green = all unread notifications are green
yellow = SOME unread notifications are not green, (but some are green)
red = ALL unread notifications are not green, (none are green)

@rconkor commented on GitHub (Dec 4, 2025): Typically the logic I see would be: green = all unread notifications are green yellow = SOME unread notifications are not green, (but some are green) red = ALL unread notifications are not green, (none are green)
adam commented 2025-12-29 21:51:17 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 4, 2025):

While I can appreciate the use case, I suspect it will deliver little value in practice. I can't even think of any other applications that do something similar with a notification bell. There's also an accessibility consideration here: A tiny colored dot is not very significant, particularly to the color-deficient.

@jeremystretch commented on GitHub (Dec 4, 2025): While I can appreciate the use case, I suspect it will deliver little value in practice. I can't even think of any other applications that do something similar with a notification bell. There's also an accessibility consideration here: A tiny colored dot is not very significant, particularly to the color-deficient.
adam commented 2025-12-29 21:51:17 +01:00
Author
Owner
Copy Link

@cs-1 commented on GitHub (Dec 5, 2025):

@jeremystretch We have a very similar colour coding in monitoring system notifications e.g. in LibreNMS where there's a very similar system of colour coding alerts. LibreNMS's alert system has at least three different severities which are colour coded green, orange and red. In our organisation we find it very helpful to be able to deduce from the colour of the notification symbol in the dashboard whether any "orange" or even "red" alerts are present. I understand your argument regarding colour deficient users but that holds true for almost any monitoring system's colour coding in dashboards. In our current case it wouldn't take anything away for colour deficient users since a "new notification" symbol would still be there but it would add a bit of comfort for all other users.

@rconkor I'd colour code the following way:

  • green: all notifications are green,
  • orange: at least one notification is orange but none is red,
  • red: at least one is red.

This seems to be the way most other software (e.g. LibreNMS) handles it.

@cs-1 commented on GitHub (Dec 5, 2025): @jeremystretch We have a very similar colour coding in monitoring system notifications e.g. in LibreNMS where there's a very similar system of colour coding alerts. LibreNMS's alert system has at least three different severities which are colour coded green, orange and red. In our organisation we find it very helpful to be able to deduce from the colour of the notification symbol in the dashboard whether any "orange" or even "red" alerts are present. I understand your argument regarding colour deficient users but that holds true for almost any monitoring system's colour coding in dashboards. In our current case it wouldn't take anything away for colour deficient users since a "new notification" symbol would still be there but it would add a bit of comfort for all other users. @rconkor I'd colour code the following way: - green: all notifications are green, - orange: at least one notification is orange but none is red, - red: at least one is red. This seems to be the way most other software (e.g. LibreNMS) handles it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox status: under review type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11892
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?