Add last updated user attribute to models #4324

Closed
opened 2025-12-29 18:34:45 +01:00 by adam · 5 comments
Owner

Originally created by @imransobir on GitHub (Dec 3, 2020).

Environment

  • Python version: 3.6.12
  • NetBox version: 2.9.8

Proposed Functionality

Add last updated user attribute to site, device and other models.

Use Case

We use NetBox as a data source for a larger system which needs to show last updated user for each model. I understand that this could be achieved by searching through the change log, but the change log can get cleaned up.

Database Changes

Add last_updated_by field to models.

External Dependencies

None

Originally created by @imransobir on GitHub (Dec 3, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/g/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.6.12 * NetBox version: 2.9.8 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality Add last updated user attribute to site, device and other models. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case We use NetBox as a data source for a larger system which needs to show last updated user for each model. I understand that this could be achieved by searching through the change log, but the change log can get cleaned up. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes Add last_updated_by field to models. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies None
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:34:45 +01:00
adam closed this issue 2025-12-29 18:34:45 +01:00
Author
Owner

@jeremystretch commented on GitHub (Dec 4, 2020):

Implementing this might be more difficult than it seems at first. Assigning a user to the object requires a request context, which is present only with normal UI/API requests. Modifications to an object don't include a user context by default (although it is possible to provide one). Change logging avoids this problem by creating a new record only when the change logging middleware is active, but updating a field on the instance itself is tricky.

Imagine a scenario where user A has modified an object. The object is saved with last_updated recording the current time and last_updated_by pointing to user A. Now suppose user B modifies and saves the object directly through the NetBox shell. The last_updated field will be updated to reflect the most recent change automatically, but the last_updated_by field will still point to user A (unless user B had enabled the change logging middleware or set the field manually). This makes it appear as though user A was the last person to modify the object.

I can think of one partial safeguard: If we check whether last_updated_by has been set on the instance when save() is called, and nullify the field if not, that should avoid reflecting a misattributed change. Though I'm not sure what potential caveats I might be overlooking.

@jeremystretch commented on GitHub (Dec 4, 2020): Implementing this might be more difficult than it seems at first. Assigning a user to the object requires a request context, which is present only with normal UI/API requests. Modifications to an object don't include a user context by default (although it is possible to provide one). Change logging avoids this problem by creating a new record only when the change logging middleware is active, but updating a field on the instance itself is tricky. Imagine a scenario where user A has modified an object. The object is saved with `last_updated` recording the current time and `last_updated_by` pointing to user A. Now suppose user B modifies and saves the object directly through the NetBox shell. The `last_updated` field will be updated to reflect the most recent change automatically, but the `last_updated_by` field will still point to user A (unless user B had enabled the change logging middleware or set the field manually). This makes it appear as though user A was the last person to modify the object. I can think of one partial safeguard: If we check whether `last_updated_by` has been set on the instance when `save()` is called, and nullify the field if not, that should avoid reflecting a misattributed change. Though I'm not sure what potential caveats I might be overlooking.
Author
Owner

@imransobir commented on GitHub (Dec 5, 2020):

Jeremy,

It is acceptable that the last updated user be updated only through UI/API since all of the requests will be coming through those. Also in our case at least those who have access to NetBox shell already have access to the database directly anyway.

Appreciate if this feature could be implemented even if only for UI/API requests.

@imransobir commented on GitHub (Dec 5, 2020): Jeremy, It is acceptable that the last updated user be updated only through UI/API since all of the requests will be coming through those. Also in our case at least those who have access to NetBox shell already have access to the database directly anyway. Appreciate if this feature could be implemented even if only for UI/API requests.
Author
Owner

@jeremystretch commented on GitHub (Dec 5, 2020):

It may be acceptable to you, but that doesn't mean it's the right choice for everyone who uses NetBox. Many people would understandably be opposed to such behavior, which is why a robust solution would need to be identified in order for the proposed feature to be added.

@jeremystretch commented on GitHub (Dec 5, 2020): It may be acceptable to you, but that doesn't mean it's the right choice for everyone who uses NetBox. Many people would understandably be opposed to such behavior, which is why a robust solution would need to be identified in order for the proposed feature to be added.
Author
Owner

@stale[bot] commented on GitHub (Jan 21, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Jan 21, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
Author
Owner

@stale[bot] commented on GitHub (Feb 6, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Feb 6, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4324