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

Additional query parameters for efficient searching of klantcontacten by digitaleAdressen #359

Open
felixcicatt opened this issue Mar 11, 2025 · 0 comments
Labels
enhancement New feature or request triage

Comments

@felixcicatt
Copy link

Thema / Theme

Klantinteracties API

Omschrijving / Description

Context

In KISS / PodiumD Contact there is a use case where the employee can search for a specific klantcontact based on the digitaleAdressen that have been provided by the betrokkene. Specifically, only klantcontacten matching the following conditions are shown:

  • The betrokkene specified digitaleAdressen matching the search query by the employee
  • The klantcontact resulted in interneTaken
  • The betrokkene was NOT a partij

These klantcontacten need to be sorted descending on plaatsgevondenOp (I believe this is the default behavior for the api endpoint for klantcontacten).

Right now, the most efficient way to do this seems to be to

  • Start at /digitaleadressen
  • Use adres__icontains to filter on the search query by the employee
  • Expand to verstrektDoorBetrokkene.hadKlantcontact.leiddeTotInterneTaken
  • Aggregate all pages and deduplicate all klantcontacten (client-side)
  • Filter out klantcontacten without interneTaken (client-side)
  • Filter out klantcontacten with a betrokkenen that is a partij (client-side)
  • Sort on plaatsgevondenOp (client-side)

Possible solution

The following query parameters on the /klantcontacten endpoint would be a big improvement for this use case. In order of priority:

  1. hadBetrokkene__verstrektedigitaalAdres__adres__icontains: this would allow us to use the pagination and sorting of the api endpoint as-is, removing the need to aggregate all pages and deduplicate klantcontacten. We would still need to filter out specific records, possibly resulting in inconsistent page sizes. This can be solved by the next point:
  2. hadBetrokkene__wasPartij=false and leiddeTotInterneTaken=true: this would remove the need to do any filtering client-side, allowing us to offer consistent page sizes.

Toegevoegde waarde / Added value

KCC employees handling questions about customers regarding existing klantcontacten would be able to find the klantcontact they are looking for a lot quicker.

Aanvullende opmerkingen / Additional context

No response

@felixcicatt felixcicatt added enhancement New feature or request triage labels Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage
Projects
None yet
Development

No branches or pull requests

1 participant