View Issue Details

IDProjectCategoryView StatusLast Update
0007357Talerwallet (WebExtension)public2023-02-21 16:39
Reportersebasjm Assigned Tosebasjm  
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.2Fixed in Version0.9.2 
Summary0007357: all call-to-action should redirect to transaction details after starting
Descriptiondo not make the user wait, just redirect as soon it can be confirmed that the transaction is valid.

This way will make easier to have a standard flow for every action.

We need the transaction id from wallet-core on:

* AcceptWithdrawalResponse
* AcceptManualWithdrawalResult
* CreateDepositGroupResponse
* ConfirmPayResult
* ApplyRefundResponse
* AcceptTipResponse (missing)

* acceptPeerPushPaymentResponse (missing)
* AcceptPeerPullPaymentResponse (missing)
 * InitiatePeerPullPaymentResponse
* InitiatePeerPushPaymentResponse
TagsNo tags attached.


related to 0007339 feedbackFlorian Dold withdrawal triggered on insufficient balance does not work in demo (due to fees) 
related to 0007332 closedsebasjm UX for withdrawing bitcoin is awkward 



2022-09-16 16:01

developer   ~0019137

every response now returns a txId except for refund.
Refund should return an id build from: TransactionType.Refund + purchaseId + execTime.

But execTime is known in the moment of the creation.

Should we move away from execTime as part of the refund id? Could we introduce a refundGroupId to be created before the tx starts?

Florian Dold

2022-09-16 17:13

manager   ~0019138

You mean "unknown at the moment of creation", right? And you're specifically talking about applyRefund, right?

There are various cases here:
(1) we were able to check for a refund, and there is a new one
(2) we were able to check, but there is no new refund
(3) we were unable to check for a refund (merchant down, no network, ...)

For case (1), we already do know the executionTime of the new refund. But what would you suggest returning for (2) and (3) in the first place? Neither an execution time nor a refundGroupId makes sense here.


2022-09-16 19:40

developer   ~0019139

> You mean "unknown at the moment of creation", right?
Yes, typo.

> Neither an execution time nor a refundGroupId makes sense here.
That's because applyRefund tries to apply for a refund _if it find one_, which I think the more correct procedure is:
1.- check if there is refund (webex does queryAndSaveAwaitingRefund throught prepareRefund)
2.- show to the user the information about how much refund is getting (and maybe in the future how this affect the contract: show return item? is able to see the article he/she had?)
3.- applyRefund should process that known refund, avoiding receiving more refund that didn't accept/check already

Florian Dold

2022-09-19 18:19

manager   ~0019154

Okay, we could indeed introduce a new "refundGroupId" if that helps. The only limitation here is that if we accept a "refund group", all previous refunds are also applied. Do these always belong to the new refund group?

For example:
(1) User buys order XYZ
(2) Merchant gives partial refund at time t1
(3) Merchant gives another partial refund at time t2, where t2 > t1.
(4) Wallet queries for refunds

In that case, what refund groups do you think should be created?

(a) one refund group that covers both increments
(b) two refund groups

I think (a) is a bit difficult to handle with backup/sync, but probably doable. And (b) is not that much different from just having the executionTime as the key.

What do you think?


2022-09-20 04:21

developer   ~0019156

(a) I think refund should be grouped in the wallet by the user interaction, not how the merchant made it.

And this will address my main concern: the wallet will get the refund that was rendered in the screen.


2022-11-16 18:53

developer   ~0019427

After getting a refund the wallet web extension redirect to the purchase with the outdated transaction information, so it's always wrong.
We need the refund id to show updated information after accepting refund.

Florian Dold

2023-02-12 20:41

manager   ~0019809

Okay, maybe a stupid question, but we can't we just redirect the user to the details of the *order* that was refunded, since this should also contain information about refunds received? IMHO it's okay if checking the refund creates "zero or more" new transactions.

I'm not a big fan of grouping refunds by when the user obtained them and I'd rather not make a big change in how refunds work (and all the baggage that comes with it, such as way more complex merging in backup/sync).


2023-02-13 13:54

developer   ~0019814

This is the current behavior right now since wallet-core returns `makeTransactionId(TransactionType.Payment, proposalId)` in the appyRefund response.

Is not working nice since the function returns before the refund is updated.
When the user is redirected the tx status query returns the purchase without the refund applied even if the applyRefund is successful.

Florian Dold

2023-02-13 13:58

manager   ~0019815

Can we expose some additional field on the payment transaction that a refund is currently being checked (and emit a notification once that's done)? Would that help?


2023-02-13 19:45

developer   ~0019826

As discussed internally, after accepting the refund the purchase will be marked as "no refund is pending, but one refund is in progress" so the UI redirect the user to the purchase tx with proper information

Florian Dold

2023-02-14 11:19

manager   ~0019830

The wallet now exposes the refundQueryActive flag in the payment transaction. We also emit a notification ("refund-finished") when we successfully applied a refund.

Let me know if the UI needs anything else here!


2023-02-20 17:20

developer   ~0019887

applyRefund now returns the latest refund applied.


2023-02-20 17:25

developer   ~0019888

all operation return tx id

fixed 5ad96b178ee022199877b89683ceb0e930761b9d

Issue History

Date Modified Username Field Change
2022-09-11 04:51 sebasjm New Issue
2022-09-11 04:51 sebasjm Status new => assigned
2022-09-11 04:51 sebasjm Assigned To => sebasjm
2022-09-11 04:51 sebasjm Relationship added related to 0007339
2022-09-12 19:41 sebasjm Relationship added related to 0007332
2022-09-13 15:36 Christian Grothoff Assigned To sebasjm => Florian Dold
2022-09-16 16:01 sebasjm Note Added: 0019137
2022-09-16 17:13 Florian Dold Note Added: 0019138
2022-09-16 19:40 sebasjm Note Added: 0019139
2022-09-19 18:19 Florian Dold Note Added: 0019154
2022-09-19 18:20 Florian Dold Assigned To Florian Dold => sebasjm
2022-09-19 18:20 Florian Dold Status assigned => feedback
2022-09-20 04:21 sebasjm Note Added: 0019156
2022-11-16 18:52 sebasjm Priority normal => high
2022-11-16 18:52 sebasjm Target Version git (master) => 0.9.1
2022-11-16 18:53 sebasjm Note Added: 0019427
2022-11-16 18:53 sebasjm Assigned To sebasjm => Florian Dold
2023-01-10 18:36 Christian Grothoff Target Version 0.9.1 => 0.9.2
2023-02-12 20:39 Florian Dold Assigned To Florian Dold => sebasjm
2023-02-12 20:41 Florian Dold Note Added: 0019809
2023-02-13 13:54 sebasjm Note Added: 0019814
2023-02-13 13:54 sebasjm Assigned To sebasjm => Florian Dold
2023-02-13 13:58 Florian Dold Note Added: 0019815
2023-02-13 14:00 Florian Dold Assigned To Florian Dold => sebasjm
2023-02-13 19:45 sebasjm Note Added: 0019826
2023-02-13 21:25 sebasjm Assigned To sebasjm => Florian Dold
2023-02-13 21:26 sebasjm Status feedback => confirmed
2023-02-14 11:19 Florian Dold Assigned To Florian Dold => sebasjm
2023-02-14 11:19 Florian Dold Status confirmed => assigned
2023-02-14 11:19 Florian Dold Note Added: 0019830
2023-02-17 18:41 Florian Dold Target Version 0.9.2 => 0.9.3
2023-02-20 17:20 sebasjm Note Added: 0019887
2023-02-20 17:25 sebasjm Status assigned => resolved
2023-02-20 17:25 sebasjm Resolution open => fixed
2023-02-20 17:25 sebasjm Note Added: 0019888
2023-02-20 17:49 Florian Dold Target Version 0.9.3 => 0.9.2
2023-02-21 16:39 Christian Grothoff Fixed in Version => 0.9.2
2023-02-21 16:39 Christian Grothoff Status resolved => closed
2023-04-13 20:37 Florian Dold Category wallet (WebExtensions) => wallet (WebExtension)