Capture Filter: wallet filter is broken

[gwynndp]

No description provided.

[gwynndp]

Example filter data:

startDate: 2023-02-17
endDate: 2023-02-18
device_identifier: something
wallet: gweeple@yahoo.com
organization: test1
organization_id: ["8b2628b3-733b-4962-943d-95ebea918c9d"]
grower_account_id: 93a026d2-a511-404f-958c-a0a36892af0f
tag: Any
whereNotNulls: ["tag_id"]

[nmcharlton]

This might be caused by double-conversion of the where object described here.

[OlhaD]

Currently, 'wallet' can be filtered only as a full match.
For example: we enter 'wal' into the filter field. Then, we will get only captures where 'wallet' is exactly 'wal', not 'wallet' or 'something_wal'.
@gwynndp Is it correct behaviour? Or should we show all captures, where 'wallet' field includes the value from the filter?

[nmcharlton]

For me, exact matching is appropriate here, but we need to improve the UI to make it clearer.
I'd suggest an autocomplete that queries wallets (case-insensitive, partial match) when the user starts typing, and forces them to select a valid wallet from the list.

[OlhaD]

@nmcharlton Sounds good, could you please assign this ticket to me?

[OlhaD]

I asked Sebastian Gärtner about the amount of wallet data in the production database and he told that the current amount is 6500 records which should grow up quickly. It seems to be too much to load all at once to the dropdown when page loads (like we do in other autocomplete components like Tags or Organizations).
@nmcharlton Should we maybe fetch data asynchronously on every keystroke? I would also propose loading the data only if the user entered at least one or two symbols. It will increase the number of requests but they should return a smaller amount of data.

[nmcharlton]

@OlhaD I agree with that approach. It's how Tags used to work, with a limit of 25. But it was simplified (I think) as the number of tags remained fairly manageable in production.

We can query on each keystroke and limit the results to what sensibly fits in a dropdown.

If wallet queries take some time to complete, it might be worth denouncing requests as well to cut down on unnecessary ones.

[nmcharlton]

If you're feeling really flashy, you could even use pagination to add more results in the autocomplete as the user scrolls down 😀

[OlhaD]

@nmcharlton I tried several solutions with tracking scrolls down, but all of them worked not stable. For example, the same event fired only a couple of times and it worked not with all browser zoom.
Instead, I've added the 'Load More' button to the end of the list which is only shown when there is some more data to load.

Also, I added a new API to get only wallets from 'treetracker.grower_account'. It allows us to avoid not needed joins and returns data much faster (at least 2.5 times on my local machine). I created this ticket for it: Greenstand/treetracker-query-api#299

[OlhaD]

'Wallet' filter was also updated on Growers page.