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

DCIM: Add general purpose "Schedule" custom data type #7618

New Issue
Closed
opened 2025-12-29 20:26:06 +01:00 by adam · 1 comment
adam commented 2025-12-29 20:26:06 +01:00
Owner
Copy Link

Originally created by @stavr666 on GitHub (Feb 8, 2023).

NetBox version

v3.4.3

Feature type

New functionality

Proposed functionality

Add schedule data, that like contacts, tags or CCs, can be attached to any data types.

Fields, like I see it:

  • (required) Name
  • (required) Regularity (daily, weekly, monthly, yearly, once)
  • (required) regularity-depended calendar info
  • (required) Start datetime
  • (optional) End datetime
  • (optional) Event length
  • ? Color - looks like, if rendered as calendar or list, it can be shown with correspondent outline
  • Ability to assign contact information to Schedule (for external systems to know with who to contact about changes, or send message about event start/end)

Use case

Every infrastructure require some regularity, so, I see it natural

Our use cases to be stored:

  1. Planned maintenance windows for HW and VMs
  2. Planned service contract renewal
  3. Planned software EoL
  4. Unplanned maintenance (disasters, on-site visits)

Right now, 4th scenario can (and in most cases, better do this way) be achieved, using journal records. But it can't be used for other 3 types.

Scenarios 2 and 3 achieved by custom field with date. It requires to fill this field for every Platform and VM, that have this field. It also requires to mass-update field, when something changed (contract renewed, software updated).

Scenarios 1 right now achievable by combination of tag and CC. Create tag for every possible:

  • maintenance occurrence date types (day of weeks, day of months etc.)
  • maintenance occurrence start times
  • maintenance lengths
    Create CC for every tag with json data about event. Merge multiple CC for devices and VMs by assigning tags.
    It works and accessible by API calls (by reading whole config_context attribute) but have no visual grace of specialized visualization tools:
    image

We like to see data like this as separate tab with calendar with marked dates or times. UI-options like "Show Journal entries" (for 4th case) and "Show as list" (list it instead or render dates/times) greatly welcomed, while optional.

API calls must return list of events for calendar processing (Grafana calendar panel, Grafana "next maintenance" text label for VMs and servers, "Today maintenance" list for e-mails/chat announcement). So it must assume some defaults, but have some receivable options to correctly change format of returning data (to work in possible use cases without over-processing, if api-consumer does not support scripting or data transformations).

Database changes

No response

External dependencies

No response

Originally created by @stavr666 on GitHub (Feb 8, 2023). ### NetBox version v3.4.3 ### Feature type New functionality ### Proposed functionality Add schedule data, that like contacts, tags or CCs, can be attached to any data types. Fields, like I see it: - (required) Name - (required) Regularity (daily, weekly, monthly, yearly, once) - (required) regularity-depended calendar info - (required) Start datetime - (optional) End datetime - (optional) Event length - ? Color - looks like, if rendered as calendar or list, it can be shown with correspondent outline + Ability to assign contact information to Schedule (for external systems to know with who to contact about changes, or send message about event start/end) ### Use case Every infrastructure require some regularity, so, I see it natural Our use cases to be stored: 1. Planned maintenance windows for HW and VMs 2. Planned service contract renewal 3. Planned software EoL 4. Unplanned maintenance (disasters, on-site visits) Right now, 4th scenario can (and in most cases, better do this way) be achieved, using journal records. But it can't be used for other 3 types. Scenarios 2 and 3 achieved by custom field with date. It requires to fill this field for every Platform and VM, that have this field. It also requires to mass-update field, when something changed (contract renewed, software updated). Scenarios 1 right now achievable by combination of tag and CC. Create tag for every possible: - maintenance occurrence date types (day of weeks, day of months etc.) - maintenance occurrence start times - maintenance lengths Create CC for every tag with json data about event. Merge multiple CC for devices and VMs by assigning tags. It works and accessible by API calls (by reading whole config_context attribute) but have no visual grace of specialized visualization tools: ![image](https://user-images.githubusercontent.com/84839985/217523924-f50fd384-6e0f-45ca-943b-f74d5c39d246.png) We like to see data like this as separate tab with calendar with marked dates or times. UI-options like "Show Journal entries" (for 4th case) and "Show as list" (list it instead or render dates/times) greatly welcomed, while optional. API calls must return list of events for calendar processing (Grafana calendar panel, Grafana "next maintenance" text label for VMs and servers, "Today maintenance" list for e-mails/chat announcement). So it must assume some defaults, but have some receivable options to correctly change format of returning data (to work in possible use cases without over-processing, if api-consumer does not support scripting or data transformations). ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featureplugin candidate labels 2025-12-29 20:26:06 +01:00
adam closed this issue 2025-12-29 20:26:06 +01:00
adam commented 2025-12-29 20:26:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 16, 2023):

This FR lacks sufficient detail to be actionable, and also describes substantial functionality that's likely out of scope for the core product. However, it may make an excellent plugin candidate. I encourage you to experiment with a custom plugin to see what you can come up with.

@jeremystretch commented on GitHub (Mar 16, 2023): This FR lacks sufficient detail to be actionable, and also describes substantial functionality that's likely out of scope for the core product. However, it may make an excellent plugin candidate. I encourage you to experiment with a [custom plugin](https://docs.netbox.dev/en/stable/development/getting-started/) to see what you can come up with.
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 plugin candidate 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#7618
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?