|
|
Where should we put the option, and how should we show the JSON? I think putting both things in the transaction list would take a lot of space. Even a button that shows the JSON in a dialog would take a lot of space, especially if shown below the existing action button. Putting both things in the transaction details pages would involve repeating them all over. |
|
|
I agree we should avoid showing this in the transaction list. if the error is related to one transaction, we could show it in the details page. Otherwise, for errors in response to things, we sometimes show a dismissable bottom sheet dialog and sometimes render it as the empty state message. |
|
|
How do we get the full JSON of the error? Currently, we're serializing the error to TalerErrorCode. Fields not present in this class will get discarded by the serializer, so we can't show them to the user. |
|
|
Congratulations! You found the tricky part of this implementation request :) I also don't know, but in the worst case we need a custom class wrapping TalerErrorInfo with a custom serializer storing the entire json. |
|
|
The serialization part of this request was implemented in 23dd3cd9e783955b2badc5dab850468512e6cae7. Unknown fields in every error object are added to the `extra` field. Now we need to write a serializer for TalerErrorInfo that will return the string that we need to show. |
|
|
TalerErrorInfo can be either embedded in each transaction, or happen as a result of a wallet-core request. How should we handle both cases in the UI? |
|
|
Expanding JSON errors for each transaction is now implemented in `dev/ivan-avalos/master`. |
|
|
Screenshot_20230310_002032.png (112,871 bytes) |
|
|
It doesn't look as nice for XML fragments, but I didn't want to create a custom dialog layout only to change the body text to monospace. Screenshot_20230310_002217.png (118,120 bytes) |
- Anonymous
