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

Feature/256 filter klantcontact on betrokkenen #285

Merged
merged 8 commits into from
Nov 26, 2024

Conversation

bart-maykin
Copy link
Contributor

Fixes #256

Changes

Add two filter fields to the klantcontact api endpoint:

  • had_betrokkene__was_partij__url
  • had_betrokkene__was_partij__uuid

Copy link
Contributor

@SonnyBA SonnyBA left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Functionality wise I think the changes are good! I do think we can add these changes and remove some repeated code and give the test suite some love.

@@ -92,6 +107,48 @@ def setUp(self):
onderwerpobjectidentificator_code_register="5",
)

def test_filter_partij_url(self):
partij_url = (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using reverse here in combination with http://testserver would be nice.

@bart-maykin bart-maykin force-pushed the feature/256-filter-klantcontact-on-betrokkenen branch 2 times, most recently from 3ec6e17 to f07fdb4 Compare November 21, 2024 12:13
@bart-maykin bart-maykin force-pushed the feature/256-filter-klantcontact-on-betrokkenen branch from f07fdb4 to 6662711 Compare November 21, 2024 12:30
…ri, decided to use this not so elegant way to set this data because using extend_schema_field on the URLViewFilter would remove the help_texts of the filters. The other solutions were to use the extend_view to set every parameter for the views we use this fields by hand, to define one generic description or to let the queryparam type be wrongly defined and give a warning in the help_text.
Copy link
Collaborator

@stevenbal stevenbal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's still a lot of hardcoded URLs in the test, please replace them with reverse

Comment on lines 20 to 21
if parameter["name"].endswith("__url"):
parameter["schema"] = {"type": "string", "format": "uri"}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SonnyBA I discussed this with @bart-maykin, because the underlying field that is referred to is a uuid, drf-spectacular adds format: uuid for all these fields in the OAS. It's not possible to set the format via the filter class, so that leaves us with this workaround or to add extend_schema_field for all fields and override the format (and add the help text). What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a workable solution but I would make a separate FilterExtension for it to make things a bit more explicit. These changes currently are hidden away in the CamelizeFilterExtension which should only camelize the parameters in my opinion (like the name suggests).

Maybe we could also do a bit more filtering, like checking for the parameters type (string) and the in value (query) to prevent changing parameters that should not be affected.

Some inspiration:

class UUIDURLFilterExtension(DjangoFilterExtension):
    priority = 2

    def get_schema_operation_parameters(self, auto_schema, *args, **kwargs) -> list[dict]:
        parameters: list[dict] = super().get_schema_operation_parameters(
            auto_schema, *args, **kwargs
        )

        for parameter in parameters:
            parameter_name = parameter["name"]

            is_query = parameter["in"] == OpenApiParameter.QUERY
            is_string = parameter["schema"]["type"] == "string"
            is_url_field = parameter_name.endswith("__url")

            if all((is_query, is_string, is_url_field,)):
                parameter["schema"] = {"type": "string", "format": "uri"}

        return parameters

Comment on lines 20 to 21
if parameter["name"].endswith("__url"):
parameter["schema"] = {"type": "string", "format": "uri"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a workable solution but I would make a separate FilterExtension for it to make things a bit more explicit. These changes currently are hidden away in the CamelizeFilterExtension which should only camelize the parameters in my opinion (like the name suggests).

Maybe we could also do a bit more filtering, like checking for the parameters type (string) and the in value (query) to prevent changing parameters that should not be affected.

Some inspiration:

class UUIDURLFilterExtension(DjangoFilterExtension):
    priority = 2

    def get_schema_operation_parameters(self, auto_schema, *args, **kwargs) -> list[dict]:
        parameters: list[dict] = super().get_schema_operation_parameters(
            auto_schema, *args, **kwargs
        )

        for parameter in parameters:
            parameter_name = parameter["name"]

            is_query = parameter["in"] == OpenApiParameter.QUERY
            is_string = parameter["schema"]["type"] == "string"
            is_url_field = parameter_name.endswith("__url")

            if all((is_query, is_string, is_url_field,)):
                parameter["schema"] = {"type": "string", "format": "uri"}

        return parameters

src/openklant/components/utils/filters.py Show resolved Hide resolved
@bart-maykin
Copy link
Contributor Author

@SonnyBA I did add the extra filtering for the DjangoFilterExtension but decided to only use 1 DjangoFilterExtension instead of your suggested 2 separate extentions, because they didn't take the processed data of the other into account.

@bart-maykin bart-maykin requested a review from SonnyBA November 22, 2024 13:45
@SonnyBA
Copy link
Contributor

SonnyBA commented Nov 26, 2024

@bart-maykin see #292

@SonnyBA SonnyBA merged commit 9ece5c6 into master Nov 26, 2024
17 checks passed
@SonnyBA SonnyBA deleted the feature/256-filter-klantcontact-on-betrokkenen branch November 26, 2024 10:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a filter parameter to filter klantcontacten on a betrokkene's partij
3 participants