feat: filter historical transactions

[iamacook]

What it solves

Requesting filtered transactions.

How this PR fixes it

The chosen filter is now applied to the historical transactions, as well as being appended to the URL (with the added benefit of being able to share).

Screenshots

How to test it

Filter the transactions and observe the filtered data. The filter should also be appended to the URL. Opening the filter-appended URL should load the historical transactions, filtered.

[github-actions]

CLA Assistant Lite All Contributors have signed the CLA.

[github-actions]

ESLint Summary View Full Report

Annotations are provided inline on the Files Changed tab. You can also see all annotations that were generated on the annotations page.

Type	Occurrences	Fixable
Errors	0	0
Warnings	0	0
Ignored	4	N/A

• Result: ✅ success
• Annotations: 0 total

---

^{Report generated by eslint-plus-action}

[github-actions]

Deployment links

🟠 Rinkeby	⚪ Mainnet	🟣 Polygon	🟡 BSC	⚫ Arbitrum	🟢 Gnosis Chain

[francovenica]

Some early feedback while the ticket is still in peer review.

Safe for testing:
https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history

Suggestion:
And empty state when nothing is found when filtering. Right now it shows the default image with the message "History transactions will appear here". A "no results found" image for example.

Issue:
1 - The date is not saved after filtering. The inputs return to the default state, but they are still there, since if you try to add another input (like nonce) and apply the filter it will use the dates again.

2 - The from/to filter is not working properly for outgoing tx. In the safe I filtering by outgoing tx, from May 2021 to Dec 2021 and the results still show tx from 2022. The payload only shows the "greater or equal than" parameter, but in the URL all the parameters are there

A gif to show how I'm filtering. In this case it actually have the "less or equal" in the payload, something that didn't happen before, but the results still show tx from 2022:

3 - Filtering by outgoing tx seems to filter only by those tx that send the main token of the network (ETH in this case)
Try to search in that safe the nonce 1000
Then try to search by this address as recipient rin:0x6E45d69a383CECa3d54688e833Bd0e1388747e6B
The tx with nonce 1000 is a "Send funds" to that address, but DAI were sent. When searching for that address, you only see "Send funds" of ETH tokens.

[iamacook]

@franco, thanks for the early testing!

• I've added a 'No results found' message.
• The date fields now use the values in the URL as their default values.
• I've checked the swagger and when directly querying the transaction service, the correct period is returned. However, it isn't via the gateway. cc @fmrsabino
• This also happens on the transaction service (after checking the swagger) so I'm not too sure about this one. I'll have to confer with backend on this as well. (Here's the gateway query if we need it).

[iamacook]

Maybe this could be the filtered state indication:

Altered accordingly:

[katspaugh]

Nice!
Is there are more neutral-looking button style? All-grey looks like it's disabled. Not a big deal tho, it is in a way inactive.

[iamacook]

Is there are more neutral-looking button style? All-grey looks like it's disabled.

This is the 'secondary' colour. The only other 'neutral' button in the Safe is the contract interaction afaik:

What do you think?

[katspaugh]

Yes, that's more appropriate IMHO.

[iamacook]

@katspaugh, I've updated it:

[katspaugh]

In v2 we should make the Recipient field auto-complete from the Address Book, and the Token Address – from the hodled tokens.

[iamacook]

In v2 we should make the Recipient field auto-complete from the Address Book, and the Token Address – from the hodled tokens.

Both should autocomplete from the address book already. Are you testing on the PR?

I like the idea of the token address from the asset list. We can add it to the list for when we enable date filtering. What do you think? I can, of course, implement it in this version though.

[katspaugh]

Ah, I don't have an AB on there. Nice touch then!
Tokens we can do with dates, yes. 👍

[francovenica]

Safe used for testing:
https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808

Some minor stuff
If the name is too long in the recipient it reaches the "X". maybe you can cut the name with a "..." before the X.

The X shows in the recipient to clear the field, but after doing a filter it doesn't show again until you start to write something there or delete a character from the previous filter attempt. This wouldn't be such a hassle if selecting all the text and pressing backspace would not fail to delete what is written (but this is an issue present even in the contract interaction form)

Major issue:
If in the safe given as example you filter by "incoming" and "1" in the amount you get a single result of a spending limit sent to the safe itself
https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history?type=Incoming&value=1

If you search for only incoming with no amount you get a ton of results, many with "1's" in them:
https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history?type=Incoming

Why so many of those results are ignored when searching with the amount of 1 in the first try?

[iamacook]

If the name is too long in the recipient it reaches the "X". maybe you can cut the name with a "..." before the X.

I will look into this.

The X shows in the recipient to clear the field, but after doing a filter it doesn't show again until you start to write something there or delete a character from the previous filter attempt. This wouldn't be such a hassle if selecting all the text and pressing backspace would not fail to delete what is written (but this is an issue present even in the contract interaction form)

As it is "an issue present even in the contract interaction form", I would argue that this is out of scope. MUI adds the button as it is related to current user interaction so I personally think it's intended behaviour. However, I will look into this.

Major issue: If in the safe given as example you filter by "incoming" and "1" in the amount you get a single result of a spending limit sent to the safe itself https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history?type=Incoming&value=1

If you send funds to yourself, you are effectively creating an icoming and outgoing transaction. Afair, the gateway shows these only as incoming transactions. This was discussed with @johannesmoormann and, as it is a backend-related issue and an edge case (users won't be sending funds to themselves), it is fine.

If you search for only incoming with no amount you get a ton of results, many with "1's" in them: https://pr3870--safereact.review-safe.gnosisdev.com/app/rin:0x9913B9180C20C6b0F21B6480c84422F6ebc4B808/transactions/history?type=Incoming

Why so many of those results are ignored when searching with the amount of 1 in the first try?

We aren't converting the value to wei. I'll adjust it.

Findings to tackle

• Truncate field text if passing the clear button
• Convert value to wei

[iamacook]

@francovenica, the value is now converted to wei which mirrors what you see in the transaction list. It should seem 'correct' now from the user's perspective.

I've also adjusted the clear button to always show when there is a value in the field and the text truncates if it goes beyond the button, as seen here:

[usame-algan]

Great feature, good work on this! 🚀

[francovenica]

The issues reported (the X for the clear and searching for an amount of 1) where fixed. Nice

Issues/Questions:

Suggestion: We should probably think about a range for the amount input; if somebody sent you 123 USDC, unless you remember that exact number you are not going to find the tx
Probably something we can do in a later version of the filter.

Question/Suggestion: The "recipient" input for an incoming type of filter is skewing the result, since the only recipient for incoming tx is the safe itself, so the only value that it works is the safe address.
Maybe we can grey out that input if the user chooses the incoming type of filter

We still have the issue of the "outgoing tx" filter only searching for the base token (ETH in rinkeby). I mentioned this in an older comment. Do we still need input from people from the backend about this?

[iamacook]

Thanks for the concise testing @francovenica!

Suggestion: We should probably think about a range for the amount input; if somebody sent you 123 USDC, unless you remember that exact number you are not going to find the tx Probably something we can do in a later version of the filter.

I like the idea but this would require adjustments to the gateway. I've checked the swagger and both incoming-/multisig-transaction endpoints support value__lt and value__gt. I'll propose this for the next iteration which will include date filtering. cc @fmrsabino

Question/Suggestion: The "recipient" input for an incoming type of filter is skewing the result, since the only recipient for incoming tx is the safe itself, so the only value that it works is the safe address. Maybe we can grey out that input if the user chooses the incoming type of filter

Theorertically, you can filter by any Safe address. However, it makes total sense to not allow the user to do this on the frontend. I have removed the to field from the incoming filter. As such, it should use the Safe address by default.

We still have the issue of the "outgoing tx" filter only searching for the base token (ETH in rinkeby). I mentioned this in an older comment. Do we still need input from people from the backend about this?

In order to filter tokens, you need to include the token address in the filter.

Please let me know about the removal of the recipient field. Hopefully we can get this merged.

[francovenica]

Ok, the input is gone from the incoming type of filtering

I was told regarding the rest of the feedback it requires intervention from the backend.

Looks good to me

[iamacook]

Just a follow up: I misunderstood the searching of tokens for outgoing transactions. It's incoming that has the tokenAddress filter.

I cannot see a query for it on the outgoing-transaction swagger. This is something that needs to be discussed with backend as well. cc @fmrsabino

[fmrsabino]

@iamacook The issue with the date filters has been resolved and it is live on staging