Show net results of exited offers

[samsiegart]

What is the Problem Being Solved?

If an offer is "exited" by the user, the assets may or may not have already been exchanged by the contract. Additionally, completed offers may not have actually taken all of the give, or may have given more than the want. It would be helpful for the users to see the net results of each offer after they are exited.

Current Screenshot:

Description of the Design

Idea 1: Show a section at the bottom that displays the amount of each asset actually transferred by the contract.
Idea 2: Show the amount transferred next to the give/want amounts after the offer is exited.

Alternative consideration: Show a "refunded"/"exited" state for some offers instead of a completed state in all cases.

Initial discussion:

@michaelfig: "This is a good idea, maybe a "refunded" state. Zoe currently doesn't do anything to distinguish this result, so it would take some work on the Zoe service to be able to report it. We could instead hack together something in the wallet backend to heuristically determine that it was a refund (not my preference)."

@erights "'Cancelled' seems a terrible word if the proposed trade could have already happened... 'I cancelled my offer, but my offered assets are still gone'"

Details TODO

Security Considerations

Test Plan

[michaelfig]

I presume that this issue also includes labelling a button "exit offer" instead of "cancel"?

[erights]

I like option 2. Something like a transition from

Give Bid
3.00 Run
Want Assets
1 cardStore.Card

to

Gave Bid	Partial Refund
3.00 Run	2.50 Run
Wanted Assets	Assets Received
1 cardStore.Card	1 cardStore.Card

[michaelfig]

I like option 2. Something like a transition from

We probably need some more design work around how receiving the following is represented:

1. wanted assets
2. wanted assets + additional assets
3. full refund
4. full refund + additional assets

[Tartuffo]

Sam to re-write this, especially to highlight any possible MN-1 issues this might address.

[Tartuffo]

@samsiegart and @rowgraus Please mock this up. Lowish prio for MN-1.

[erights]

See #3056

[michaelfig]

Tentative design:

gains vs. losses are AmountRecords updated in the offer throughout the lifetime of the offer, gleaned from what has been initially escrowed by Zoe vs. what we were able to get back, associate returned payment objects with the offer record ID.

For now, we will just display "accepted" (got at least what we wanted) versus "refused" (the contract did not give us what we wanted).

In the backend, only have a complete state, at which point the changing gains+losses (AmountRecords) are attached to the offer record, and remove the accept state (which is a construct of the UI based on the gains+losses).

[erights]

What happens if you get at least what you wanted and at least a full refund?

[michaelfig]

What happens if you get at least what you wanted and at least a full refund?

Then the offer state is "accepted" with 0 losses.

[michaelfig]

What happens if you get at least what you wanted and at least a full refund?

But this does suggest a useful dichotomy that I was reaching for. A complete offer is either "accepted" or "refused".