Closed mzbroch closed 3 years ago
I'm not entirely clear on the benefit of making OnboardingTask into a ChangeLoggedModel. Don't we create a new OnboardingTask instance every time we run onboarding - so an OnboardingTask is really a "one-and-done" object that doesn't get revisited after a given onboarding session completes? Or am I misunderstanding when we would actually have a meaningful change history for an OnboardingTask?
Indeed, it is intended to behave as you described.
Our production use cases required us to add "owner" and "created/updated" fields to the OnboardingTask and this integration actually fits this requirement without duplicating NetBox's features
Per our discussion on Slack, by using ChangeLoggedModel
we also automatically get ObjectChange
records created when an OnboardingTask
is created or updated, and ObjectChange
includes a user
field identifying which user was responsible for the creation/update of the OnboardingTask
. That's really the primary driver for this PR as I understand it now - that was the context I was previously missing, thanks for the clarification.
The goal of this PR is as follows:
With NetBox's ChangeLoggedModel, we can access the onboarding task's creation/modification history including information about the user requesting change