ledger transaction history should have receipt links

[diracdeltas]

follow-up to #3473, #2994

[diracdeltas]

@willy-b are you taking this one?

[willy-b]

yep! thanks

[mrose17]

@willy-b - do you have a timeframe for this one? just checking, thanks!

[willy-b]

yes, will update this afternoon (asked Q's in slack instead, updating today 09/10/16)

(pardon the radio silence, went down a bit of a rabbit hole messing with ledger-client to try and make it easier to generate the synopsis data locally to test this. always feel free to prod me if you want an update :-)! )

[mrose17]

@willy-b - thanks. no worries, just checking in... i integrated your changes into the ledger-publisher package with an update to handle the usual corner cases (-;

[willy-b]

Hey @mrose17, this is NOT at all a blocker, but do we still plan to have a ballots field on the transactions object like we used to? (I have a workaround, so not depending on this.)

In a comment when you were adding the contribution field, you gave an example transaction (#2994 (comment)):

 {
      "viewingId": "f0dfd6dc-b8ac-4635-b0df-36ffde8524dd",
      "contribution": {
        "fiat": {
          "amount": 5,
          "currency": "USD"
        },
        "rates": {
          "USD": 581.33
        },
        "satoshis": 850362,
        "fee": 9735
      },
      "submissionStamp": 1472170952704,
      "count": 49,
      /** BALLOTS FIELD BELOW! **/
      "ballots": {
        "wsj.com": 3,
        "st-george-melkite.org": 1,
        "jsonprettyprint.com": 1
      }
    }

Which has a ballots field with vote counts.

The current transaction I am seeing (LMK if my code is just out of date, etc), has no ballots field (BUT does have enough data for me to work around this):

{ viewingId: '51812a6b-677b-4e41-aec8-67bb20727f4b',
  surveyorId: '6+BcBKuLcgzYginI1+HJtOGk/QVpuTN1gLXWTiPl2xJ',
  contribution: 
   { fiat: { amount: 5, currency: 'USD' },
     rates: { USD: 626.37 },
     satoshis: 788524,
     fee: 9726 },
  submissionStamp: 1473465726257,
  submissionDate: '2016-09-10T00:02:06.257Z',
  submissionId: '133d4a975cf4d58f298529b09dcc67dedc8e468c3655f64c754be8dff0af56f2',
  credential: '[...]',
  surveyorIds: 
   [ '4xMzVmq3h3uovZKA0JT7mQRp1VTyA4vVQWD7qgZ5w2g',
     'D46qlIjWeYYoQ4PsoX6z2oyIO361bwkTbEmA/gkJD9J',
     '8Bq3sja8bvx9SIG5UoXs6Exlb9AHcxJikAYhBW1aPg5' ],
  count: 3,
  satoshis: 788524,
  votes: 3 
 /** NO BALLOTS HERE **/
}

I am working around this by associating surveyorIds with client.state.ballots myself but this will be unnecessary if the ballots field is added.

[diracdeltas]

@mrose17 what's the status on ^ ? just want to make sure @willy-b is not blocked

[mrose17]

@diracdeltas - my understanding is that this isn't a blocker.

@willy-b do you agree? please let me know, thanks!

[diracdeltas]

@willy-b i moved this to 0.12.2; let me know if that's a reasonable timeframe. if not i can pick up this issue.

[willy-b]

Yes, @diracdeltas, 0.12.2 works for me.

Sorry for delay -- was on a cross-country bus trip & broke my phone, completely lost internet access for a couple of days for first time in a while :-).

Confirming: ballots field issue I mentioned to @mrose17 is not a blocker, though I have changes in my fork of ledger-client that'll have to come in.

[willy-b]

Yeah, sorry, this is still not ready. @diracdeltas, @mrose17 feel free to take this if you want to -- I've been holding it a while.
I'm getting bogged down with issues around reconciliation and a very, very slow testing cycle.
Whenever the ledger data format / related code changes upstream it can take me up to ~1.5hrs to get Brave to reconcile and allocate a payment in order to start testing the Payment History UI.
Obviously, I/we should set up mock ledger data (always in latest format) so we can skip the slow reconciliation step for pure UI work / tests.

[mrose17]

sorry, i closed the issue earlier by accident...

@willy-b: understood, thanks for the update!

[diracdeltas]

no problem, i'll assign to myself

[willy-b]

Thanks, sorry! Didn't want to hold up dev on this (especially now that I have ended up somewhere where I can't even get on the internet reliably).

[willy-b]

@diracdeltas, in case you were busy with other issues and didn't dig into this yet, I pushed a branch that implements the CSV export of contribution breakdown by publisher:
https://github.com/willy-b/browser-laptop/tree/payment-history-receipt-links-3477

This depends on a ledger-client branch:
https://github.com/willy-b/ledger-client/tree/support-browser-laptop-3477

You can ignore these if you have your own WIP or want to wait to do the PDF, you can use it for reference, or I can turn them into PRs against browser-laptop & ledger-client. Just sharing in case it is useful / etc!

[willy-b]

So I used a file:// link to the generated CSV, and it's a little awkward (it triggers a download instead of opening):

Seems like there must be a better way.
(With a PDF this won't be an issue, it'll open in-browser, in pdfjs.)
Is there a different IPC message that would trigger opening the local file directly in the 3rd party app?

[diracdeltas]

closed by 7c44c28

[aekeus]