| 3 | Ensure that QR codes behave as expected when scanned with wallet app | Al, Stephen | ASAP | Someone with a wallet app should scan each QR code and ensure that the correct crypto address for the correct cryptocurrency is populated in the app, in whichever manner is expected - this should not require us to further ensure that the wallet app itself acts as intended, unless that is desired |
| 4 | Post-transaction screen deemed acceptable (and if we have to make one, we make it) | Al, Stephen | ASAP (before sue's vacation) | Al? makes a transaction, livestreams or screenshots result |
| 5 | Sue confirms that transaction has gone through to Tor wallet | Al, Sue | ASAP | Al/Stephen make a transaction, Sue confirms receipt
| 5 | Sue confirms that transaction has gone through to Tor wallet | Al, Sue | ASAP | Al/Stephen make a transaction, Sue confirms receipt |
### Mock transaction testing
...
...
@@ -538,9 +538,11 @@ the CiviCRM backend. It handles those types of transactions:
when recurring donations lapse)
- Mailing list subscriptions (essentially middleware between
https://newsletter.torproject.org and CiviCRM, so users have a way
to click a "confirm subscription" URL without exposing CiviCRM to the open web)
to click a "confirm subscription" URL without exposing CiviCRM to
the open web)
- Mailing list actions, such as "unsubscribe" and "optout" (acting as
middleware, as above, so that newsletters can link to these actions in the footer)
middleware, as above, so that newsletters can link to these actions
in the footer)
The Redis server runs on the CiviCRM server, and is accessed through
an IPsec tunnel, see the [authentication](#authentication) section below as
