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.