update UX to include transaction history

[mrose17]

allow the user to see recent transactions (date, amount, publishers)

[diracdeltas]

@mrose17 does this require more changes on the ledger side? the transactions field of ledger-state is an empty array for me

[willy-b]

@diracdeltas ,
With the most recent master the transactions field is populated for me (in my ~/.config/brave/ledger-state.json file, the Brave main process, and in the renderer process).
It may be necessary to create a wallet, fund it, and navigate to pages, though.

Screenshot showing transactions field populated at page JS level (page level dev tools, debugging preferences.js):

Out of curiosity, is there any mockup for this transaction table yet?

[diracdeltas]

@willy-b i noticed it showed up for me too, thanks for confirming. @bradleyrichter can provide the latest mockups for the transaction table. If you'd like to volunteer to take this task, let me know!

[bradleyrichter]

Here is a mockup of the transaction log. It references monthly statements that could exist in the form of CSV or PDF files. (TBD) The info within these files is essentially the same data that is viewable in the ledger on the reconciliation date.

[willy-b]

Thanks for the mockup @bradleyrichter!

Yes, @diracdeltas , happy to volunteer to take this one -- BUT first I want to make sure I'm on the same page as you all, especially about what should be in the generated PDF and how that should be generated (see my questions and vague proposal below).

Here's my thinking on and questions for each of the 3 columns in @bradleyrichter's mockup.

• "Date"
  <Month> <Day>, <Year> format
  This data would come from the submissionStamp column in each transactions row, this seems easy

• "Total amount"
  $<amount> USD/<amount> satoshis format
  This data would come from the satoshis column in each transactions row

  Question: Would we use the BTCUSD exchange rate that applied at time of reconciliation (given by submissionStamp), from BitGo?
  (only the satoshis value is stored, so we have to choose which BTCUSD exchange rate to use)

• "Receipt link"
  Link to a generated PDF, with a filename formatted brave_ledger<MMDDYY>.pdf

  I imagine the PDF would be generated clientside with Electron's printToPDF API from a hidden frame.
  (see https://github.com/electron/electron/blob/master/docs/api/web-contents.md#contentsprinttopdfoptions-callback)
  Does that approach sound reasonable? I haven't tried this locally yet,, but from scanning discussions online, it looks feasible.

  PDF contents:
  For first pass, the PDF could contain a table with 4 columns: Rank, Site, % Paid, $ Paid
  and 1 row per publisher (derived from ledger-state.json info at time of reconcilation, perhaps from ledger-log.json?).
  What do you think?

[bradleyrichter]

@willy-b sounds great to me. If you can find a way to add a PDF template (mostly a header and possible fine print paragraph), I will design one.

@mrose17 - we need your chime-in here in regards to PDF being acceptable, currency reported, and time of reconciliation vs time of adding BTC to the brave wallet. (concern about price fluctuation delta in record keeping)

[diracdeltas]

@willy-b thanks, that sounds reasonable. @mrose17 can comment on BTC exchange rates to use. I haven't tried the electron printToPDF API but if it doesn't work, CSV is fine.

[diracdeltas]

actually i think we shouldn't show the # of satoshis at all. the average person won't know what that is.

[willy-b]

@bradleyrichter , using the printToPDF approach we can build the PDF in React/HTML, the same as the Payments tab or other pages in app. (It would just be another web page rendered in background that is turned into the final PDF.)

How about I investigate the printToPDF approach this AM and if there aren't any big surprises then you go ahead with designing the PDF?
On the other hand, if there are technical surprises, I would suggest we just do CSV for the first pass, which would mean the design wouldn't be needed just yet.

[willy-b]

Sweet. I did a quick test using the existing Payments tab Ledger Table and printToPDF approach works:

So @bradleyrichter , feel free to design the PDF as you would any other app component.

[willy-b]

Hey @diracdeltas, I see this just got assigned to you by @mrose17.

I'm pretty far along on this. Here's a screenshot of the transaction modal that I have so far:

I'm happy to pick this one up, I can give estimates and a more complete status update if you like. Of course no worries if you want to take it.

[diracdeltas]

@willy-b looks great, i'm not sure why @mrose17 assigned this to me. i'll unassign.

[mrose17]

@diracdeltas - I didn't know I could assign @willy-b (-;

Are we ready to commit?

[mrose17]

Or more accurately... @willy-b : what's a good ETA for a PR?

[mrose17]

@willy-b - thus looks good... I'm happy to see you drive this to conclusion...

[willy-b]

Hey @mrose17,

I'm aiming to open a WIP PR tomorrow (happy to do it sooner if you like), but let me also give you a status update and ask some questions.

What's done:

• Basic Payment History modal with correct columns and data displayed (see screenshot from prev comment, update UX to include transaction history #2994 (comment))
• Preliminary work on generating the Receipt PDFs

Stuff I need to finish:

• Remaining Payment History modal UI work to match mockup
  Adding OK button to bottom of modal
  Adding "Your next payment submission is " message in footer.
  Adding a gray modal header background and making the table header border extend to modal edges.
• PDF receipts for "Receipt Link" column
  There's no mockup here so I imagine I'll be making changes after feedback :-)
  See bottom of earlier comment (update UX to include transaction history #2994 (comment)) for proposal on what columns will be in the PDF.
• Reset button which clears Ledger transactions
  I am tempted to suggest this go in a separate issue just to keep the PR as small as possible.
• Ledger change: Need to save historical BTC price
  I added btcPrice to the ledgerInfo object in browser-laptop/app/ledger.js (means ledgerData has btcPrice in the UI code)
  A similar addition is needed for transactions array entries so that the historical price at time of reconciliation can be shown.
  I think this is necessary because otherwise the value of past contributions will fluctuate in the UI, which is surprising (since they already happened we don't expect them to change).

Questions I have:

• Where can I find when the next payment will be submitted? (@mrose17)
  This is needed for Payment History modal footer spec'd to read "Your next payment submission is , ."
• Are the payments/reconcilations currently scheduled monthly? (@mrose17)
  They seem to go out at [0,10] minute intervals once account is funded instead, disagreeing with @bradleyrichter's mockup
• What does the "Export" button in the upper right of the Payment History modal do? (@bradleyrichter)
  Does it export a PDF of the modal contents? Or does it bring in the receipt contents into one super PDF?
  Maybe this should go in a separate issue/PR.

(By the way, as an outsider, I can't assign issues to myself :-) )

[mrose17]

@willy-b: thanks for the reply. here's what i suggest:

1. if we can get a work-in-progress PR by close-of-business wednesday evening (us/pacific), that'd be great...
2. ask @bradleyrichter about the mockup for the PDF receipt and see if the two of you can converge
3. put the 'Clear' button in another issue -- it will be useful, but isn't "an essential user-optional feature"
4. it seems to me that the ledger-client ought to record the desired fee, e.g., fee: { currency: USD, amount: 5 } -- why would we need to record that in the ledgerInfo? i'm pretty sure that we're not going to show the current exchange rate to the user.
5. the next contribution is scheduled for ledgerInfo.reconcileStamp
6. when we officially do beta, payments will be every 30 days (not every month, i dislike calendar math...) this is configured in the ledger.
7. i would ask @bradleyrichter about the "Export" button.

any other questions?

thanks for helping!

/mtr

ps: i can't assign you to this issue either, so i've assigned myself just to manage it...

[bradleyrichter]

Ok, I'll mockup a PDF statement quickly. Regarding export, that was a thought for when 3 years of payments accumulate and your accountant wants to see a summary. We can certainly shelve that feature for now.

[bradleyrichter]

And @willy-b - thanks for your gracious contribution!

[willy-b]

Sweet. @mrose17 you answered all my questions. Your timeline sounds good, I'm working on PDF now.

The Payment History modal UI is getting closer to the mockup:

[willy-b]

Thanks @bradleyrichter , love these designs so happy to help with implementation!
Take your time on the PDF mockup, it's not a big deal for me to sketch it out without a mockup and restyle it afterwards.

Quick question: Where do you want the "Show Payment History" button?
I temporarily threw it in the account balance box for testing, but pending input I'm going to move it to the upper right of Payments tab before opening the WIP PR.

[mrose17]

@willy-b - i have submitted #3397 that includes using brave/ledger-client@10c6582

what this does is make each transaction look like this:

{
  "viewingId": "..."
  "surveyorId": "..."
  "contribution": {
    "fiat": {
      "amount": 5,
      "currency": "USD"
    },
    "rates": {
      "USD": 579.37
    },
    "satoshis": 1593828,
    "fee": 7272
  },
  "submissionStamp": 1472101139534,
  "submissionId": "..."
}

so i don't think that you need btcPrice anywhere now!

[bradleyrichter]

@willy-b Here is a mockup of the PDF statement. This is not final. The layout is solid but the copy and column content is still being discussed.

[willy-b]

Nice @bradleyrichter These are gorgeous.

Thanks @mrose17, with that change btcPrice is no longer needed.

[willy-b]

@mrose17,
After the latest ledger-client changes I am confused about how to count the votes for each publisher. We need this for the transaction level PDF/CSV files.

In the old format (ledger-state.json) it was easy to see the fraction for each publisher.
For example, here we have 75% for brave.com and 25% to othersite.com:

      "count": 5,
      "satoshis": 838869,
      "votes": 4,
      "ballots": {
        "brave.com": 3,
        "othersite.com": 1
      }

In the new format (as of yesterday), I am not seeing a "ballots" field in the transactions object:

      "count": 49,
      "satoshis": 850628,
      "votes": 49
    }

There is a ballots field at the top level but I don't know what the right way to associate it with an individual transaction is anymore.

Is this a local error? It doesn't seem to match what is documented in docs/state.md which was updated recently.

If you do suspect it is local and that I need to regenerate, could you tell me the easiest way to trigger a reconcilation after wiping the ledger*.json files and establishing a new wallet?

Thanks!

[mrose17]

@willy-b sorry for the delay in replying and for the confusion. first, the ballots at the top-level is internal state, don't worry about it!

i probably didn't whitelist enough from the transaction. brb.

[mrose17]

ok, i am about to put this hot patch directly in to master. before i do, let me explain what it does: each transaction will look like this:

    {
      "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": {
        "wsj.com": 3,
        "st-george-melkite.org": 1,
        "jsonprettyprint.com": 1
      }
    }

[mrose17]

here is now to interpret it:

viewingId is the unique identifier for this contribution

contribution shows all of the financial information and exchange rates: satoshis that the user transferred, the fee that the network took, the fiat.amount for the user's fiat.currency and the exchange rate (rates.USD) in effect.

submissionStamp is the timestamp that the contribution took place

count is the total number of votes that the contribution will get

ballots is the ballots that have been actually cast.

so, here is a question for you: i can either have ballots reflect the total ballots (some not yet cast... each is cast independently after a pseudo-random delay), or i can leave it as is, or i can add another structure of ballots remaining to be cast.

which do you prefer @willy-b? i suspect it will be the third

[mrose17]

@willy-b - my bad, ballots is supposed to have everything. that's a bug, it should total up to 49. i will figure out why it isn't and then do the hot patch. sorry!

[willy-b]

@mrose17, thanks so much for the detailed answer and in advance for the rapid patch!

[mrose17]

@willy-b - thanks! it's now in `master' ... 55c0e10

[diracdeltas]

Closed by #3473. Follow-up: #3477