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

Journal Entries reference field #5996

New Issue
Closed
opened 2025-12-29 19:35:30 +01:00 by adam · 5 comments
adam commented 2025-12-29 19:35:30 +01:00
Owner
Copy Link

Originally created by @snowie-swe on GitHub (Jan 24, 2022).

NetBox version

v3.1.6

Feature type

Change to existing functionality

Proposed functionality

Would like to see Journal entries extended to include a "reference" field.

Use case

If there is an issue on a VM / Devices that involves a hardware replacement / software hotfix or similar.
It would be very nice to be able to search for a case number / ticket from the vendor "reference"

Same can be used for reference to internal tickets / issues

Database changes

dont know

External dependencies

dont know

Originally created by @snowie-swe on GitHub (Jan 24, 2022). ### NetBox version v3.1.6 ### Feature type Change to existing functionality ### Proposed functionality Would like to see Journal entries extended to include a "reference" field. ### Use case If there is an issue on a VM / Devices that involves a hardware replacement / software hotfix or similar. It would be very nice to be able to search for a case number / ticket from the vendor "reference" Same can be used for reference to internal tickets / issues ### Database changes dont know ### External dependencies dont know
adam added the type: feature label 2025-12-29 19:35:30 +01:00
adam closed this issue 2025-12-29 19:35:30 +01:00
adam commented 2025-12-29 19:35:31 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 26, 2022):

It would be very nice to be able to search for a case number / ticket from the vendor "reference"

Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it.

@jeremystretch commented on GitHub (Jan 26, 2022): > It would be very nice to be able to search for a case number / ticket from the vendor "reference" Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it.
adam commented 2025-12-29 19:35:31 +01:00
Author
Owner
Copy Link

@snowie-swe commented on GitHub (Jan 26, 2022):

It would be very nice to be able to search for a case number / ticket from the vendor "reference"

Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it.

In general i believe that extending custom field to more/all modules is a good middle ground.
It allows organizations to add smaller things without requiring additional development from the community.

@snowie-swe commented on GitHub (Jan 26, 2022): > > It would be very nice to be able to search for a case number / ticket from the vendor "reference" > > Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it. In general i believe that extending custom field to more/all modules is a good middle ground. It allows organizations to add smaller things without requiring additional development from the community.
adam commented 2025-12-29 19:35:31 +01:00
Author
Owner
Copy Link

@mmfreitas commented on GitHub (Jan 28, 2022):

Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it.

A custom field, custom link and tags could be useful in the JournalEntry model.

I don't think this is what you meant but if journaling were to be built into the core, I would propose having the ability to journal on "create"/"update"/"delete" of anything, and the possibility to journal from the changelog of said event. Keeping this history even if changelog is deleted

@mmfreitas commented on GitHub (Jan 28, 2022): > Is this something we should build into core, or would it be more appropriate as a custom field on the JournalEntry model? I'm just considering validation possibilities, but maybe I'm over-thinking it. A custom field, custom link and tags could be useful in the JournalEntry model. I don't think this is what you meant but if journaling were to be built into the core, I would propose having the ability to journal on "create"/"update"/"delete" of anything, and the possibility to journal from the changelog of said event. Keeping this history even if changelog is deleted
adam commented 2025-12-29 19:35:31 +01:00
Author
Owner
Copy Link

@martinum4 commented on GitHub (Mar 16, 2022):

Had a similar issue right now, kinda wished we had custom links and fields for journals too.
This has a huge potential addon value for end users, e.g. one could easily build links to external issue trackers or third parties.

Proposal for Issue Opener: Change Title to "Extend Data model of Custom Links and Fields to include journal entries"

@martinum4 commented on GitHub (Mar 16, 2022): Had a similar issue right now, kinda wished we had custom links and fields for journals too. This has a huge potential addon value for end users, e.g. one could easily build links to external issue trackers or third parties. Proposal for Issue Opener: Change Title to "Extend Data model of Custom Links and Fields to include journal entries"
adam commented 2025-12-29 19:35:32 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 31, 2022):

A custom field, custom link and tags could be useful in the JournalEntry model.

Agreed. I've opened #9006 to propose this and plan to implement these changes in v3.2.

I'm going to close out this issue as I believe the original use case is best served via the creation of a custom field for the JournalEntry model.

@jeremystretch commented on GitHub (Mar 31, 2022): > A custom field, custom link and tags could be useful in the JournalEntry model. Agreed. I've opened #9006 to propose this and plan to implement these changes in v3.2. I'm going to close out this issue as I believe the original use case is best served via the creation of a custom field for the JournalEntry model.
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#5996
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?