Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify the declaration of custom field support in models #8373

Closed
jeremystretch opened this issue Jan 17, 2022 · 2 comments
Closed

Simplify the declaration of custom field support in models #8373

jeremystretch opened this issue Jan 17, 2022 · 2 comments
Labels
type: housekeeping Changes to the application which do not directly impact the end user

Comments

@jeremystretch
Copy link
Member

Proposed Changes

Currently, a NetBox model must meet two conditions for custom fields to function properly:

  1. Inherit from CustomFieldsMixin
  2. Register as having custom fields via the extras_features() decorator

The second step is redundant, given that it should be assumed that any model inheriting from CustomFieldsMixin supports custom fields. However, failing to register via extras_features() excludes the model from the list of available models when creating a custom field, and from other such selections.

We can obviate the need to register the model explicitly by instead connecting a receiver function to Django's class_prepared signal and checking for custom field support on the class.

Justification

Eliminates redundant code and reduces the possibility for human error.

@jeremystretch jeremystretch added type: housekeeping Changes to the application which do not directly impact the end user status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Jan 17, 2022
@jeremystretch
Copy link
Member Author

A similar issue exists with the declaration of support for tags: A model must both inherit from TagsMixin (to receive the appropriate manager) and register via extras_features().

@jeremystretch
Copy link
Member Author

This has been resolved under #8392.

@jeremystretch jeremystretch removed the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Jan 28, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 29, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: housekeeping Changes to the application which do not directly impact the end user
Projects
None yet
Development

No branches or pull requests

1 participant