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

Increase visibility of journal entries for an object #11427

New Issue
Closed
opened 2025-12-29 21:45:06 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:45:06 +01:00
Owner
Copy Link

Originally created by @pobk on GitHub (Jul 29, 2025).

NetBox version

v4.3.4

Feature type

Change to existing functionality

Proposed functionality

Journal Entries are currently something of an underdog feature for NetBox. Used properly, journal entries could add a significant benefit to documentation and communication of important free-form information in NetBox.

However, they are not presently a useful tool for the following reason: visibility. There is presently no visibility of any journal entries for an object in NetBox beyond a tab with a count badge at the top of the page. There is no way to make "Danger" and "Warning" journal entries immediately visible to anyone viewing an object.

My proposal would be to add a visible count to the header for the object if journal entries exist.

[ Danger: 4 ] [ Warning: 2 ] [ Success: 42 ] [ Info: 2 ]

Alternatively, add a row to the "Management" panel (e.g. on Devices)?

Use case

During a deployment for a new rack/infrastructure project, it might be prudent to document a list of journal entries for each of the snags related to work items, tagged agaisnt the object and with a 'deployment-snag' project.

Or, during a maintenance window, it may be prudent for enegineering to create a journal entry on an object while the maintenance is underway so that the NOC are made aware of an in-progress maintenance and which infrastructure might be affected. A NOC engineer might open the object in NetBox to investigate a separate issue and not realise that maintenance might be underway.

Database changes

None anticpated. This is a cosmetic change.

External dependencies

None

Originally created by @pobk on GitHub (Jul 29, 2025). ### NetBox version v4.3.4 ### Feature type Change to existing functionality ### Proposed functionality Journal Entries are currently something of an underdog feature for NetBox. Used properly, journal entries could add a significant benefit to documentation and communication of important free-form information in NetBox. However, they are not presently a useful tool for the following reason: visibility. There is presently no visibility of any journal entries for an object in NetBox beyond a tab with a count badge at the top of the page. There is no way to make "Danger" and "Warning" journal entries immediately visible to anyone viewing an object. My proposal would be to add a visible count to the header for the object if journal entries exist. [ Danger: 4 ] [ Warning: 2 ] [ Success: 42 ] [ Info: 2 ] Alternatively, add a row to the "Management" panel (e.g. on Devices)? ### Use case During a deployment for a new rack/infrastructure project, it might be prudent to document a list of journal entries for each of the snags related to work items, tagged agaisnt the object and with a 'deployment-snag' project. Or, during a maintenance window, it may be prudent for enegineering to create a journal entry on an object while the maintenance is underway so that the NOC are made aware of an in-progress maintenance and which infrastructure might be affected. A NOC engineer might open the object in NetBox to investigate a separate issue and not realise that maintenance might be underway. ### Database changes None anticpated. This is a cosmetic change. ### External dependencies None
adam added the type: feature label 2025-12-29 21:45:06 +01:00
adam closed this issue 2025-12-29 21:45:06 +01:00
adam commented 2025-12-29 21:45:06 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Jul 29, 2025):

@pobk , could you mock up what you're thinking of (even if it's a screenshot edited in Paint)? I'm having a hard time understanding exactly what you're proposing where.

@jnovinger commented on GitHub (Jul 29, 2025): @pobk , could you mock up what you're thinking of (even if it's a screenshot edited in Paint)? I'm having a hard time understanding exactly what you're proposing where.
adam commented 2025-12-29 21:45:07 +01:00
Author
Owner
Copy Link

@pobk commented on GitHub (Jul 31, 2025):

Sure,

I'm thinking something like this in the subtitle block:

Image

or perhaps the management panel:

Image

Of course, I'm not sure how this fits in with design or UI standards... I am not a UI person... so please forgive my absolute abominable formatting/structuring here. The latter management panel would allow for a possible future feature request which would highlight unread journal entries? It's an idea for another day though.

@pobk commented on GitHub (Jul 31, 2025): Sure, I'm thinking something like this in the subtitle block: <img width="338" height="106" alt="Image" src="https://github.com/user-attachments/assets/835b9aa3-9e4e-4e9b-a8a1-853e97e73bc1" /> or perhaps the management panel: <img width="793" height="155" alt="Image" src="https://github.com/user-attachments/assets/e94eb584-61eb-4899-9c14-d23c1a54b8a4" /> Of course, I'm not sure how this fits in with design or UI standards... I am not a UI person... so please forgive my absolute abominable formatting/structuring here. The latter management panel would allow for a possible future feature request which would highlight unread journal entries? It's an idea for another day though.
adam commented 2025-12-29 21:45:07 +01:00
Author
Owner
Copy Link

@jnovinger commented on GitHub (Aug 4, 2025):

I am not a UI person

Same. Thanks for the visual, we'll talk about this sometime this week.

@jnovinger commented on GitHub (Aug 4, 2025): > I am not a UI person Same. Thanks for the visual, we'll talk about this sometime this week.
adam commented 2025-12-29 21:45:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2025):

Journaling is intended to capture the long-running history of objects, not to highlight momentary concerns. Entries are meant to be retained permanently; it wouldn't make sense to permanently highlight an entry that was made months or years ago and no longer applies.

I think what you want instead is some mechanism to temporarily flag issues relating to objects. I'm not sure what that would be (maybe some combination of status and tags?) but journaling seems like a poor fit.

Alternatively, add a row to the "Management" panel (e.g. on Devices)?

This would not be suitable as this panel is present only for a few object types.

@jeremystretch commented on GitHub (Aug 7, 2025): Journaling is intended to capture the long-running history of objects, not to highlight momentary concerns. Entries are meant to be retained permanently; it wouldn't make sense to permanently highlight an entry that was made months or years ago and no longer applies. I think what you want instead is some mechanism to _temporarily_ flag issues relating to objects. I'm not sure what that would be (maybe some combination of status and tags?) but journaling seems like a poor fit. > Alternatively, add a row to the "Management" panel (e.g. on Devices)? This would not be suitable as this panel is present only for a few object types.
adam commented 2025-12-29 21:45:07 +01:00
Author
Owner
Copy Link

@pobk commented on GitHub (Aug 8, 2025):

Journaling is intended to capture the long-running history of objects, not to highlight momentary concerns. Entries are meant to be retained permanently; it wouldn't make sense to permanently highlight an entry that was made months or years ago and no longer applies.

This reads as "this is not how I want you to use it". Good show.

I think what you want instead is some mechanism to temporarily flag issues relating to objects. I'm not sure what that would be (maybe some combination of status and tags?) but journaling seems like a poor fit.

The journal seems very much the place where you should put it. Resolved issues get removed or re-classified.

If they're not meant to be deleted, why do you retain the delete button? Bug?

@pobk commented on GitHub (Aug 8, 2025): > Journaling is intended to capture the long-running history of objects, not to highlight momentary concerns. Entries are meant to be retained permanently; it wouldn't make sense to permanently highlight an entry that was made months or years ago and no longer applies. This reads as "this is not how I want you to use it". Good show. > I think what you want instead is some mechanism to _temporarily_ flag issues relating to objects. I'm not sure what that would be (maybe some combination of status and tags?) but journaling seems like a poor fit. The journal seems very much the place where you should put it. Resolved issues get removed or re-classified. If they're not meant to be deleted, why do you retain the delete button? Bug?
adam commented 2025-12-29 21:45:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 8, 2025):

This reads as "this is not how I want you to use it". Good show.

From the docs:

All primary and organizational models in NetBox support journaling. A journal is a collection of human-generated notes and comments about an object maintained for historical context. It supplements NetBox's change log to provide additional information about why changes have been made or to convey events which occur outside NetBox. Unlike the change log, in which records typically expire after a configurable period of time, journal entries persist for the life of their associated object.

You are trying to use a feature for a purpose for which it was not intended.

If they're not meant to be deleted, why do you retain the delete button? Bug?

Sometimes people make errors, and need to correct those errors.

@jeremystretch commented on GitHub (Aug 8, 2025): > This reads as "this is not how I want you to use it". Good show. From [the docs](https://netboxlabs.com/docs/netbox/features/journaling/): > All primary and organizational models in NetBox support journaling. A journal is a collection of human-generated notes and comments about an object maintained for historical context. It supplements NetBox's change log to provide additional information about why changes have been made or to convey events which occur outside NetBox. Unlike the change log, in which records typically expire after a configurable period of time, journal entries persist for the life of their associated object. You are trying to use a feature for a purpose for which it was not intended. > If they're not meant to be deleted, why do you retain the delete button? Bug? Sometimes people make errors, and need to correct those errors.
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 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#11427
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?