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

webhook timestamp format #8853

New Issue
Closed
opened 2025-12-29 20:42:06 +01:00 by adam · 2 comments
adam commented 2025-12-29 20:42:06 +01:00
Owner
Copy Link

Originally created by @mmolbech on GitHub (Nov 18, 2023).

Originally assigned to: @arthanson on GitHub.

NetBox version

v3.6.5

Python version

3.11

Steps to Reproduce

This is my first bug report :) for netbox so bear with me

I was generating a webhook feature on virtual machines - and i discovery/got annoyed on the inconstancy with the timestamp, for each event.

{"event": "updated", "timestamp": "2023-11-17 22:03:54.864187+00:00", "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual-
....

So i was looking at the code to find the place where it does the timestamping and found it in netbox/netbox/webhooks.py, and
i change line 119 in webhooks.py

from timestamp=str(timezone.now()),
to timestamp=str(timezone.now().isoformat()),

and get iso8601 format

{"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/",
.....

The other timestamps in the event is in iso8601 format

Regards
Michael

Expected Behavior

I would expect a ISO8601 format

{"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/",
.....

Observed Behavior

I saw this

{"event": "updated", "timestamp": "2023-11-17 22:03:54.864187+00:00", "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual-
....

Originally created by @mmolbech on GitHub (Nov 18, 2023). Originally assigned to: @arthanson on GitHub. ### NetBox version v3.6.5 ### Python version 3.11 ### Steps to Reproduce This is my first bug report :) for netbox so bear with me I was generating a webhook feature on virtual machines - and i discovery/got annoyed on the inconstancy with the timestamp, for each event. {"event": "updated", "timestamp": "**2023-11-17 22:03:54.864187+00:00"**, "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual- .... So i was looking at the code to find the place where it does the timestamping and found it in netbox/netbox/webhooks.py, and i change line 119 in webhooks.py from timestamp=str(timezone.now()), to timestamp=str(timezone.now().isoformat()), and get iso8601 format {"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/", ..... The other timestamps in the event is in iso8601 format Regards Michael ### Expected Behavior I would expect a ISO8601 format {"event": "deleted", "timestamp": "2023-11-18T20:16:40.955375+00:00", "model": "virtualmachine", "username": "*****", "request_id": "e4fbac3e-810b-4aff-aae6-cf35c68d49a4", "data": {"id": 51, "url": "/api/virtualization/virtual-machines/51/", ..... ### Observed Behavior I saw this {"event": "updated", "timestamp": "**2023-11-17 22:03:54.864187+00:00"**, "model": "virtualmachine", "username": "*******", "request_id": "f27dc260-7190-4494-b1a3-34754e86fe1a", "data": {"id": 60, "url": "/api/virtualization/virtual- ....
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 20:42:06 +01:00
adam closed this issue 2025-12-29 20:42:06 +01:00
adam commented 2025-12-29 20:42:07 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Nov 19, 2023):

I'm unable to understand what the inconsistency is here?

@abhi1693 commented on GitHub (Nov 19, 2023): I'm unable to understand what the inconsistency is here?
adam commented 2025-12-29 20:42:07 +01:00
Author
Owner
Copy Link

@mmolbech commented on GitHub (Nov 19, 2023):

I have not added everything (sorry) from the output - but everywhere else you are doing iso8601 format - but also know this will break things - as people probably has made a work around
The problem is a non iso8601 format used default

"timestamp": "2023-11-21 21:00:12.324363+00:00"

and all other places the iso format is used

{
"event": "updated",
"model": "virtualmachine",
"timestamp": "2023-11-21 21:00:12.324363+00:00",
"request_id": "a9d14c77-0279-4175-a83a-b40396a8e043",
"data": {
"id": 70,
"url": "/api/virtualization/virtual-machines/70/",
"display": "Testvm",
"name": "Testvm",
"status": {
"value": "active",
"label": "Active"
},
"site": {
"id": 2,
"url": "/api/dcim/sites/2/",
},
"cluster": {
"id": 2,
"url": "/api/virtualization/clusters/2/",
"display": "TestNet",
"name": "TestNet"
},
"device": null,
"role": null,
"tenant": null,
"platform": {
"id": 4,
"url": "/api/dcim/platforms/4/",
"display": "CentOS 8 (64-bit)",
"name": "CentOS 8 (64-bit)",
"slug": "centos-8-64-bit"
},
"primary_ip": {
"id": 29,
"url": "/api/ipam/ip-addresses/29/",
"display": "100.110.65.8/22",
"family": 4,
"address": "100.110.65.8/22"
},
"primary_ip4": {
"id": 29,
"url": "/api/ipam/ip-addresses/29/",
"display": "100.110.65.8/22",
"family": 4,
"address": "100.110.65.8/22"
},
"primary_ip6": null,
"vcpus": 2.0,
"memory": 4096,
"disk": 40,
"description": "",
"comments": "",
"config_template": null,
"local_context_data": null,
"tags": [
{
"id": 7,
"url": "/api/extras/tags/7/",
"display": "NetBox-synced",
"name": "NetBox-synced",
"slug": "netbox-synced",
"color": "9e9e9e"
},
{
"id": 8,
"url": "/api/extras/tags/8/",
"color": "9e9e9e"
}
],
"custom_fields": {},
"created": "2023-11-18T22:56:06.615351+01:00",
"last_updated": "2023-11-18T23:58:29.195615+01:00",
"interface_count": 1
},
"snapshots": {
"prechange": null,
"postchange": {
"created": "2023-11-18T21:56:06.615Z",
"last_updated": "2023-11-18T22:58:29.195Z",
"description": "",
"comments": "",
"local_context_data": null,
"config_template": null,
"site": 2,
"cluster": 2,
"device": null,
"tenant": null,
"platform": 4,
"name": "Testvm",
"status": "active",
"role": null,
"primary_ip4": 29,
"primary_ip6": null,
"vcpus": "2.00",
"memory": 4096,
"disk": 40,
"interface_count": 1,
"custom_fields": {},
"tags": [
"NetBox-synced",
]
}
}
}

@mmolbech commented on GitHub (Nov 19, 2023): I have not added everything (sorry) from the output - but everywhere else you are doing iso8601 format - but also know this will break things - as people probably has made a work around The problem is a non iso8601 format used default "timestamp": "2023-11-21 21:00:12.324363+00:00" and all other places the iso format is used { "event": "updated", "model": "virtualmachine", "timestamp": "2023-11-21 21:00:12.324363+00:00", "request_id": "a9d14c77-0279-4175-a83a-b40396a8e043", "data": { "id": 70, "url": "/api/virtualization/virtual-machines/70/", "display": "Testvm", "name": "Testvm", "status": { "value": "active", "label": "Active" }, "site": { "id": 2, "url": "/api/dcim/sites/2/", }, "cluster": { "id": 2, "url": "/api/virtualization/clusters/2/", "display": "TestNet", "name": "TestNet" }, "device": null, "role": null, "tenant": null, "platform": { "id": 4, "url": "/api/dcim/platforms/4/", "display": "CentOS 8 (64-bit)", "name": "CentOS 8 (64-bit)", "slug": "centos-8-64-bit" }, "primary_ip": { "id": 29, "url": "/api/ipam/ip-addresses/29/", "display": "100.110.65.8/22", "family": 4, "address": "100.110.65.8/22" }, "primary_ip4": { "id": 29, "url": "/api/ipam/ip-addresses/29/", "display": "100.110.65.8/22", "family": 4, "address": "100.110.65.8/22" }, "primary_ip6": null, "vcpus": 2.0, "memory": 4096, "disk": 40, "description": "", "comments": "", "config_template": null, "local_context_data": null, "tags": [ { "id": 7, "url": "/api/extras/tags/7/", "display": "NetBox-synced", "name": "NetBox-synced", "slug": "netbox-synced", "color": "9e9e9e" }, { "id": 8, "url": "/api/extras/tags/8/", "color": "9e9e9e" } ], "custom_fields": {}, "created": "2023-11-18T22:56:06.615351+01:00", "last_updated": "2023-11-18T23:58:29.195615+01:00", "interface_count": 1 }, "snapshots": { "prechange": null, "postchange": { "created": "2023-11-18T21:56:06.615Z", "last_updated": "2023-11-18T22:58:29.195Z", "description": "", "comments": "", "local_context_data": null, "config_template": null, "site": 2, "cluster": 2, "device": null, "tenant": null, "platform": 4, "name": "Testvm", "status": "active", "role": null, "primary_ip4": 29, "primary_ip6": null, "vcpus": "2.00", "memory": 4096, "disk": 40, "interface_count": 1, "custom_fields": {}, "tags": [ "NetBox-synced", ] } } }
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 severity: low status: accepted type: bug
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#8853
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?