View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007357||Taler||wallet (WebExtensions)||public||2022-09-11 04:51||2022-09-20 04:21|
|Product Version||git (master)|
|Target Version||git (master)|
|Summary||0007357: all call-to-action should redirect to transaction details after starting|
|Description||do 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:
* AcceptTipResponse (missing)
* acceptPeerPushPaymentResponse (missing)
* AcceptPeerPullPaymentResponse (missing)
|Tags||No tags attached.|
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?
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.
> You mean "unknown at the moment of creation", right?
> 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
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?
(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?
(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-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|