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

'NoneType' object has no attribute '_base_manager' #5301

New Issue
Closed
opened 2025-12-29 19:26:24 +01:00 by adam · 9 comments
adam commented 2025-12-29 19:26:24 +01:00
Owner
Copy Link

Originally created by @hocker96 on GitHub (Sep 2, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.1

Python version

3.8

Steps to Reproduce

Upgrade from 2.11.0 with git, after this

Expected Behavior

Server Error
There was a problem with your request. Please contact an administrator.

The complete exception is provided below:

<class 'AttributeError'>

'NoneType' object has no attribute '_base_manager'

Python version: 3.8.10
NetBox version: 3.0.1
If further assistance is required, please post to the NetBox discussion forum on GitHub.

Observed Behavior

What can I do?

Originally created by @hocker96 on GitHub (Sep 2, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.1 ### Python version 3.8 ### Steps to Reproduce Upgrade from 2.11.0 with git, after this ### Expected Behavior Server Error There was a problem with your request. Please contact an administrator. The complete exception is provided below: ``` <class 'AttributeError'> 'NoneType' object has no attribute '_base_manager' Python version: 3.8.10 NetBox version: 3.0.1 If further assistance is required, please post to the NetBox discussion forum on GitHub. ``` ### Observed Behavior What can I do?
adam added the type: bugstatus: accepted labels 2025-12-29 19:26:24 +01:00
adam closed this issue 2025-12-29 19:26:24 +01:00
adam commented 2025-12-29 19:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

Upgrade from 2.11.0 with git, after this

This alone is not sufficient to reproduce the error. Under #7082 is was suggested that the error may be related to the existence of secrets prior to upgrade. (Note that v3.0 drops support for secrets entirely.) Can you confirm this on your installation?

Also, can you please provide the complete stack trace?

@jeremystretch commented on GitHub (Sep 2, 2021): > Upgrade from 2.11.0 with git, after this This alone is not sufficient to reproduce the error. Under #7082 is was [suggested](https://github.com/netbox-community/netbox/issues/7082#issuecomment-911176019) that the error may be related to the existence of secrets prior to upgrade. (Note that v3.0 drops support for secrets entirely.) Can you confirm this on your installation? Also, can you please provide the complete stack trace?
adam commented 2025-12-29 19:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

I was able to reproduce this by starting with a v2.11.12 install, creating a user key and secret, and then upgrading to v3.0.1. AFAICT it only affects installations which have an active changelog entry relating to a secret.

@jeremystretch commented on GitHub (Sep 2, 2021): I was able to reproduce this by starting with a v2.11.12 install, creating a user key and secret, and then upgrading to v3.0.1. AFAICT it only affects installations which have an active changelog entry relating to a secret.
adam commented 2025-12-29 19:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

While we work on a fix for this, it's possible to work around this bug by deleting all changelog data relating to objects from the old secrets app in NetBox.

This will delete all changelog data for all secrets, secret roles, user keys, and session keys. If this data is important to you, either wait for the fix in v3.0.2, or make a copy of your database before applying the script below so that the data can be retrieved at a later date.

To delete all secrets changelog data, open the NetBox shell (manage.py nbshell) and run the following script:

content_type_ids = ContentType.objects.filter(app_label='secrets').values_list('id', flat=True)
ObjectChange.objects.filter(changed_object_type__in=content_type_ids).delete()

You should see it return a total count of the changelog records which have been deleted, like this:

(123, {'extras.ObjectChange': 123})

At this point, NetBox should behave normally. It is not necessary to restart any services after deleting the data.

@jeremystretch commented on GitHub (Sep 2, 2021): While we work on a fix for this, it's possible to work around this bug by deleting all changelog data relating to objects from the old secrets app in NetBox. **This will delete all changelog data for all secrets, secret roles, user keys, and session keys.** If this data is important to you, either wait for the fix in v3.0.2, or make a copy of your database before applying the script below so that the data can be retrieved at a later date. To delete all secrets changelog data, open the [NetBox shell](https://netbox.readthedocs.io/en/stable/administration/netbox-shell/) (`manage.py nbshell`) and run the following script: ```python content_type_ids = ContentType.objects.filter(app_label='secrets').values_list('id', flat=True) ObjectChange.objects.filter(changed_object_type__in=content_type_ids).delete() ``` You should see it return a total count of the changelog records which have been deleted, like this: ``` (123, {'extras.ObjectChange': 123}) ``` At this point, NetBox should behave normally. It is not necessary to restart any services after deleting the data.
adam commented 2025-12-29 19:26:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

The root issue here is that latent changelog records referencing e.g. a Secret instance from v2.11 or earlier raise an exception when trying to resolve the related object into a Python instance.

While it may be possible to catch and suppress these exceptions, doing so would likely be hacky and error-prone. A more robust approach would be to introduce a database migration to simply delete the offending changelog records. While this would result in deletion of changelog data, the impact of this doing so be negligible given that these objects no longer "exist" in NetBox anyway.

Any arguments for or against?

@jeremystretch commented on GitHub (Sep 2, 2021): The root issue here is that latent changelog records referencing e.g. a Secret instance from v2.11 or earlier raise an exception when trying to resolve the related object into a Python instance. While it may be possible to catch and suppress these exceptions, doing so would likely be hacky and error-prone. A more robust approach would be to introduce a database migration to simply delete the offending changelog records. While this would result in deletion of changelog data, the impact of this doing so be negligible given that these objects no longer "exist" in NetBox anyway. Any arguments for or against?
adam commented 2025-12-29 19:26:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 2, 2021):

So we had a quick discussion about this, couple of important things:

  1. If someone else wants to hook into change logging in the future then if the plugin is removed or deleted this will pop up again
  2. There are a few ways to handle this (getters around the object, checking for NoneTypes in the templates, etc), some of them aren't bulletproof
  3. You only see this if you have used secrets in the past (probably recently) that has generated a change log

Just wanted to capture that here.

@DanSheps commented on GitHub (Sep 2, 2021): So we had a quick discussion about this, couple of important things: 1. If someone else wants to hook into change logging in the future then if the plugin is removed or deleted this will pop up again 2. There are a few ways to handle this (getters around the object, checking for NoneTypes in the templates, etc), some of them aren't bulletproof 3. You only see this if you have used secrets in the past (probably recently) that has generated a change log Just wanted to capture that here.
adam commented 2025-12-29 19:26:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 2, 2021):

I've submitted a draft PR to introduce a database migration that will automatically delete all changelog records pertaining to a model from the old secrets app, which will avoid the AttributeError exception.

The downside of this approach is that we lose all secrets changelog data, although this is likely of little impact to most users. The upside is that it fixes #7149 without manipulating the ObjectChange model itself, which would require far more testing.

@jeremystretch commented on GitHub (Sep 2, 2021): I've submitted a draft PR to introduce a database migration that will automatically delete all changelog records pertaining to a model from the old `secrets` app, which will avoid the AttributeError exception. The downside of this approach is that we lose all secrets changelog data, although this is likely of little impact to most users. The upside is that it fixes #7149 without manipulating the ObjectChange model itself, which would require far more testing.
adam commented 2025-12-29 19:26:26 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Sep 3, 2021):

This actually more generic, and not only related to the Secrets app.
Whenever you have an addon that logged something, and then the addon gets removed, the error occurs.

I think a exception catcher makes more sense to keep the log history of addons that are removed.

@PieterL75 commented on GitHub (Sep 3, 2021): This actually more generic, and not only related to the Secrets app. Whenever you have an addon that logged something, and then the addon gets removed, the error occurs. I think a exception catcher makes more sense to keep the log history of addons that are removed.
adam commented 2025-12-29 19:26:26 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 3, 2021):

Perhaps a more reasonable measure would be a management command that simply checks for their existence and reports back that "You may need to run x command to remove these stale change log entries if you do not intend to install the plugin/app that will use these" and an additional switch which processes the removal instead of a migration for the removal. This could even be run at every upgrade and throw a warning.

Couple this with some code upgrades and it might be more sustainable.

@DanSheps commented on GitHub (Sep 3, 2021): Perhaps a more reasonable measure would be a management command that simply checks for their existence and reports back that "You may need to run x command to remove these stale change log entries if you do not intend to install the plugin/app that will use these" and an additional switch which processes the removal instead of a migration for the removal. This could even be run at every upgrade and throw a warning. Couple this with some code upgrades and it might be more sustainable.
adam commented 2025-12-29 19:26:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 3, 2021):

I think a exception catcher makes more sense to keep the log history of addons that are removed.

The simple fact that an exception is raised indicates that the condition is not supported by the Django framework. If we try to hack up a solution around that, I fear we may be inviting other problems. Best to keep things clean and advise plugin authors to do the same.

@jeremystretch commented on GitHub (Sep 3, 2021): > I think a exception catcher makes more sense to keep the log history of addons that are removed. The simple fact that an exception is raised indicates that the condition is not supported by the Django framework. If we try to hack up a solution around that, I fear we may be inviting other problems. Best to keep things clean and advise plugin authors to do the same.
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 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#5301
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?