296 custom type object dynamic fields filter

[ifoughal]

closes #296

[Copilot]

Pull request overview

This pull request adds dynamic filtering capabilities for custom object type fields, allowing users to filter custom objects based on their field values. The changes introduce a flexible filter specification system that maps each custom field type to an appropriate django-filter Filter class.

Changes:

• Introduced a FilterSpec dataclass and field type-to-filter mapping system in filtersets.py
• Added build_filter_for_field function to dynamically generate filters for custom fields
• Implemented get_filterform_field methods for Object and MultiObject field types in field_types.py
• Changed decimal field precision from 2 to 4 decimal places
• Fixed incorrect module name from "database.filtersets" to "netbox_custom_objects.filtersets"

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
netbox_custom_objects/filtersets.py	Adds FilterSpec dataclass, FIELD_TYPE_FILTERS mapping, and build_filter_for_field function to dynamically create filters for custom fields; fixes module name bug
netbox_custom_objects/field_types.py	Implements get_filterform_field methods for DecimalFieldType, ObjectFieldType, and MultiObjectFieldType; increases decimal precision from 2 to 4 places

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[arthanson]

Couple simple changes, could you also add some simple test cases for filtering, maybe create a field of each type, create records with the different types then do a filter on each type that checks the correct instance is returned.

[arthanson]

Please see previous comments.

[arthanson]

@ifoughal any updates on this? See my latest comments.

[ifoughal]

@ifoughal any updates on this? See my latest comments.

@arthanson apologies, i didn't have much time lately to work on this. I'll get back on it as soon as I get some bandwidth.

[arthanson]

Not sure on here - normally we do something like:
created = django_filters.DateTimeFilter()
created__before = django_filters.DateTimeFilter(
field_name='created',
lookup_expr='lte'
)
created__after = django_filters.DateTimeFilter(
field_name='created',
lookup_expr='gte'
)
the base does not have a lookup_expr. if we could add the __before, __after that would be great but probably beyond the scope of this - maybe add that as a FR.

[ifoughal]

I have a draft for this logic, but it would require multiple changes, also to note on models.py

1272)  # TODO: Move all this logic to field_types.py get_filterform_field methods

maybe a refactor would be needed prior to implementing this?

Then, this logic should be added:

if self.type in (
        CustomFieldTypeChoices.TYPE_DATE,
        CustomFieldTypeChoices.TYPE_DATETIME,
    ):
        before_filter = self.to_filter(lookup_expr="lte")
        if before_filter is not None:
            filters[f"{self.name}__before"] = before_filter

        after_filter = self.to_filter(lookup_expr="gte")
        if after_filter is not None:
            filters[f"{self.name}__after"] = after_filter

[arthanson]

These filter cases should probably have tests for them as well.

The JSON filter could probably be expanded instead of just a char filter, see netbox (https://github.com/netbox-community/netbox/blob/main/netbox/netbox/filtersets.py#L367) as an example.

[ifoughal]

These filter cases should probably have tests for them as well.

The JSON filter could probably be expanded instead of just a char filter, see netbox (https://github.com/netbox-community/netbox/blob/main/netbox/netbox/filtersets.py#L367) as an example.

Should we do this in a different PR? or do you want me to implement it in this PR?

[ifoughal]

@arthanson could you please review this when you get the chance? I've left some comments regarding your remarks.

[arthanson]

Thanks @ifoughal I'm going to take your changes and expand on them, adding in test suite and such, also there were merge conflicts with recent changes in main. Opened up PR: #437 - closing this one as it's tied to your remote branch.