View Issue Details

IDProjectCategoryView StatusLast Update
0007357Talerwallet (WebExtensions)public2022-11-16 18:53
Reportersebasjm Assigned ToFlorian Dold  
PriorityhighSeveritymajorReproducibilityalways
Status feedbackResolutionopen 
Product Versiongit (master) 
Target Version0.9.1 
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.

Relationships

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

Activities

sebasjm

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.

sebasjm

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?

sebasjm

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.

sebasjm

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.

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