Closes #36: Add changelog_enabled toggle to CustomObjectType

[bctiemann]

Closes: #36

Summary

Adds a changelog_enabled boolean field (default True) to CustomObjectType. When disabled, changes to objects of that type are silently skipped by NetBox's change-logging signal — no ObjectChange rows are written, and the Changelog tab is hidden from the custom object detail page.

How it works

The implementation is confined to two points:

1. Model field — CustomObjectType.changelog_enabled (migration 0015, default True).

2. Generated model override — get_model() injects a to_objectchange() method that returns None when the flag is off. NetBox's handle_changed_object signal guards on objectchange and objectchange.has_changes before saving, so None is the documented way to suppress a change record — no signal disconnection, no monkey-patching of the signal itself.

Surface area

• Form: new Options fieldset with the changelog_enabled toggle
• Serializer: field included in CustomObjectTypeSerializer
• Table: field available as an optional column
• COT detail template: status shown with a checkmark
• CO detail template: Changelog tab is hidden when changelog_enabled=False; direct URL access to the changelog view returns 404

Notes

• Branching compatibility: if changelog_enabled=False, objects of that type also cannot participate in branching (branching requires change capture). This is consistent with the issue's statement that "this user would be fine with these changes not being branchable."
• The per-COT toggle was chosen over a global flag because the use case is inherently per-type (some types warrant an audit trail, others don't).

🤖 Generated with Claude Code

[bctiemann]

@claude /review and limit response to areas of potential concern.

[github-actions]

Claude finished @bctiemann's task in 2m 56s —— View job

---

Review: Areas of Potential Concern

• Read changed files
• Analyze for concerns

---

1. Migration is missing help_text and verbose_name

models.py defines:

changelog_enabled = models.BooleanField(
    verbose_name=_('changelog enabled'),
    default=True,
    help_text=_("If disabled, changes to objects…"),
)

But 0015_customobjecttype_changelog_enabled.py has:

field=models.BooleanField(default=True),

Django's Field.deconstruct() includes help_text when non-empty, and verbose_name when it differs from the auto-generated name. Because of lazy-translation proxies, Django may not recognize _('changelog enabled') as equal to the auto-generated 'changelog enabled'. Running makemigrations after merging this will produce a spurious AlterField migration. Recommend regenerating the migration from the final model state before merging. Fix this →

---

2. Branching side-effect is undocumented in the UI

The PR description notes that changelog_enabled=False also silently disables branching for objects of that type (branching depends on change capture). But this does not appear anywhere in the product:

• The form field's help_text doesn't mention it
• The COT detail template only shows a checkmark, no warning
• There's no form validation warning when this is checked off

An operator disabling changelog for noise-reduction won't know branching is also disabled until they actually try to use it. Consider adding this side-effect to the help_text string, e.g.: "When disabled, objects of this type cannot participate in branching."

---

3. No test for mid-lifecycle toggle

All three tests create a COT with changelog_enabled fixed at creation time. The realistic user journey — creating a COT with changelog_enabled=True, writing some objects (so the model is cached), then toggling to False and confirming that subsequent saves don't write ObjectChange rows — is not covered.

The cache_timestamp mechanism should handle this correctly (saving the COT bumps cache_timestamp, which forces get_model() to regenerate on the next call), but this is the primary operational path and is currently untested. Fix this →

---

4. changelog_enabled absent from CustomObjectTypeFilterSet

filtersets.py:259 only exposes id, name, and group_name for COT filtering. Operators can't query the API (or use the list-view filter form) to find all types where changelog is disabled. Given that this is an operational flag, being able to enumerate types with it off seems useful. This is a minor gap, not a blocker.

---

Minor / Not Concerns

• The lambda _self, _action: None override is correct. The underscore-prefixed parameters avoid shadowing the outer self (the COT instance); the previous commit note about "fix lambda shadow" confirms this was already caught.
• Cache invalidation on toggle is handled correctly: CustomObjectType has cache_timestamp = auto_now, so any save() that changes changelog_enabled will cause the next get_model() call to regenerate the model with the new setting.
• Raising Http404 (rather than 403) on direct URL access to a disabled changelog URL is a reasonable choice — it avoids leaking whether objects exist. The behavior is called out in the PR description.

[bctiemann]

Addressed items 2, 3, and 4. The migration is fine as-is (makemigrations produces an identical file).

[arthanson]

This is really ugly for branching, I think we might need to say this can only be set on creation and never modified (not sure if that breaks the intent) but if you toggle it mid-way and have items already in a branch I can see all sorts of potential bad side-effects.

Also please add a whole set of tests with branching for this - especially with custom objects having fields linking to and being linked from COT that have object-change disabled and run through the sync/merge/revet lifecycle - they can be added as extra test cases to the co-branching tests. Also make sure polymorphic fields are included as well as those are special case. so object, multi-object and those as polymorphic being in a regular CO linking to a non-object-change CO and the same ones in a non-object-change CO linking to a regular CO.

[bctiemann]

The "Changelog enabled" setting now cannot be changed after creation. guarded in the form and serializer.

Also a set of unit tests have been added as recommended. However, note that these tests do not run in CI, so they will not proactively defend against regressions. I've opened #583 to add that pipeline to the CI matrix; it should run in parallel with the existing ones and not take any additional time.

[arthanson]

1. create a COT with changelog enabled = False
2. create a CO of that type
3. delete that CO
4. crash

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/core/handlers/exception.py", line 55, in inner
    response = get_response(request)
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/core/handlers/base.py", line 198, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/views/generic/base.py", line 106, in view
    return self.dispatch(request, *args, **kwargs)
           ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/netbox/netbox/views/generic/base.py", line 26, in dispatch
    return super().dispatch(request, *args, **kwargs)
           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/netbox/utilities/views.py", line 152, in dispatch
    return super().dispatch(request, *args, **kwargs)
           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/netbox/utilities/views.py", line 51, in dispatch
    return super().dispatch(request, *args, **kwargs)
           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/views/generic/base.py", line 145, in dispatch
    return handler(request, *args, **kwargs)
  File "/Users/ahanson/dev/work/netbox/netbox/netbox/views/generic/object_views.py", line 482, in post
    obj.delete()
    ~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox-custom-objects/netbox_custom_objects/models.py", line 917, in delete
    return super().delete(*args, **kwargs)
           ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/Users/ahanson/dev/work/netbox/netbox/netbox/models/deletion.py", line 85, in delete
    return collector.delete()
           ~~~~~~~~~~~~~~~~^^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/db/models/deletion.py", line 462, in delete
    signals.pre_delete.send(
    ~~~~~~~~~~~~~~~~~~~~~~~^
        sender=model,
        ^^^^^^^^^^^^^
    ...<2 lines>...
        origin=self.origin,
        ^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/Users/ahanson/dev/work/netbox/venv/lib/python3.14/site-packages/django/dispatch/dispatcher.py", line 209, in send
    response = receiver(signal=self, sender=sender, **named)
  File "/Users/ahanson/dev/work/netbox/netbox/core/signals.py", line 201, in handle_deleted_object
    objectchange.user = request.user
    ^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'user' and no __dict__ for setting new attributes

[bctiemann]

Should be OK now. The fix is in the pre_delete handler, so both UI and API paths should be fixed/exercised by tests.

[arthanson]

still having issues:

1. be in main
2. create a COT cot1 (turn off ObjectChange), add field text f1
3. create a CO of that type 'aaa'
4. create a branch b1 and activate it
5. create another CO of the cot1 type 'bbb'
6. go to the list of cot1
7. switch to main

what you will see is just one item in the list 'aaa'

since ObjectChange is off all items should be created in main branch so you should see two items in the list (both 'aaa' and 'bbb') in main and branch b1.

[bctiemann]

Fixed. Thanks for doing the local testing on this, my custom-objects+branching setup is a bit messed up and I can't be sure I'm covering the right territory.