Uniform transaction list view (Transaction List v2)

[lukasschor]

What is this feature about? (1 sentence)

This makes sure that transaction list behave the same across both mobile clients and the web and also that the new tx list layout is implemented.

Why is it needed? What is the value? For whom do we build it?

• Web and mobile are quite different in terms of sorting of transactions.
• The mobile clients use the client gateway, the web has lots of logic in the frontend.

High-level overview of the feature

• Web and mobile should use the client gateway.
• Txs with the same nonce should be handled properly
• New layout should be implemented
• This ticket is about the tx list, tx details and rejections will be touched another follow up ticket.

Misc

• Mobile ticket: Uniform transaction list view safe#353
• Working doc: https://docs.google.com/document/d/1IFewa3cqblEC4TG_cjjFJ6wJUXcRP0luw39QuKua3eU/edit#

[fernandomg]

From the specs in the mobile's epic:

Safe app information is not shown at all - It will be as “contract interaction”

I assumed the idea is to continue supporting safe-apps on the browser app.

While refactoring I realize that the origin field (which provides the safe-app information to recover it's logo/name) is not available in the gateway-client returned data.

---

In the current WIP I'll treat it as custom, but I'm assuming this field must be provided before this epic is finished.

Is that correct @tschubotz?

[tschubotz]

Long term, the goal is, that Safe app txs are properly marked as such, both on mobile and on web.

Now there are different ways towards that goal. The mobile apps decided to do it iteratively, i.e. in v1 it'll be a contract interaction and afterwards it'll be made into a proper Safe app tx. That's ok since Safe app tx weren't marked as such before anyway.

Now on web, we did have Safe app txs before. So from my end, if possible, it would be good to have them in already in a v1. That implies that the client gateway returns that, yes.
If you and the dev team say it's just much more convenient to also do it step by step on web (i.e. in won't be in a v1), that would be ok for me as well. I'd ask you to evaluate that and come up with a proposal :)

So what I suggest: Treat it as custom in your current WIP. (i.e. no need to merge data on the client between client gateway and old tx endpoint or sth. like that)
And we ask @jpalvarezl and @rmeissner what would be a realistic timeline for adding the Safe app info to the result set of the client gatway.

also cc and fyi @sche since we talked about this in the context of #1638 / 5afe/safe#337 yesterday

[fernandomg]

For the history list, how should we display/use times? user's specific TZ or +UTC as Etherscan does?

If we go with the +UTC, there will be this (probably) unexpected outcome. Say I'm in UTC-3 if I execute a tx on Jan-29 09:01 PM, the tx will be listed under Jan-30 12:01 AM +UTC.

@posthnikova @tschubotz

[tschubotz]

For the history list, how should we display/use times? user's specific TZ or +UTC as Etherscan does?

User/device TZ specific time please.

There is a timezone param on the client gateway which would return the times in the right time zone as far as I understand it https://github.com/gnosis/safe-client-gateway/wiki/transactions_history @rmeissner @jpalvarezl please correct me if I'm wrong.