The "Events" page for accounts now shows the transaction history. It would make sense to find a place that makes sense where one can browse the account_objects too, like the open escrows and the offers. The user should then be offered context related buttons, eg. in case of an offer: cancel, in case of an escrow: finish / cancel (if possible).

When showing results, show the data source as reported by the API (small)

For EscrowFinish transactions:

• Get the DeletedNode.LedgerEntryType = Escrow for tx.meta
• Check if the FinalFields.Destination = own account
• Show +FinalFields.Amount (To XRP) as transaction value

Sample: TX: 8AD4A1E7B1E138ECB6C6A3A9BF450A9F26E73797379C15C55E37754FC1DB7602, escrow from TipBot to account rKLhe74ERouyMADhiRvZaya6266b2wxZjy, released by the TipBot. Balance mutated with +5.

For EscrowCreates TO own account, show a "light/grey/..." amount, because it's not final yet.

When using the "send" flow, entering the destination/search box, typing a substring, only the XUMM backend service is queried, while the entered substring may also match someone in the address book (eg. name or address).

These results should (if matches) be combined under their respective own "title", eg.

[Contacts]
..
..
[Search results]
..
..

Describe the bug
When opening and focusing the amount, it scrolls towards the field but it's not really visible as only the top pops out from under the keyboard

Expected
When focussing on the amount, keep the amount in the visible viewport

Screenshots
https://gqubonl.dlvr.cloud/trim.53DD5ACF-246B-4AAE-AD61-00B64803949D.MOV

Environment

iPhone X

Complete e2e tests and make screenshot from all screens.

• Send
• Enter amount
• Scan destination QR, eg. XV5sbjUmgPpvXv4ixFWZ5ptAYZ6PD2q1qM6owqNbug8W6KV or rPEPPER7kfTD9w2To4CQk6UCfuHM9c6GDY:495
• Select destination
• Next screen: Destination Tag field is empty ❗️

Describe the bug
I renamed one of the imported accounts from Arwèn to XUMM Donations. After renaming, viewing the TX history, the old account name is displayed.

The account is not in my address book (so it can't come from there). When force closing the app and restarting the Events show the right (new) account name.

Expected behavior
The renamed account is listed in the events with the new, renamed, name

Push notifications can be sent translated as well, by getting the device_appLanguage on a per user-per device basis.

Describe the bug
When opening the app (when started and minimized before) the open screen (with balances, if home screen) is visible for a short period of time, after the blur comes into effect and the PIN/Face/FingerprintId has to be used to unlock the app.

This should be blurred in the first place, or show the start/lock screen (logo) until the app is unlocked to prevent people from accidentally exposing details for a short instance (account holdings / transactions) when opening the app from the background (and it's less confusing)

See (screencap): https://eqymxe3.dlvr.cloud/RPReplay_Final1585130709.mp4

Users will try to add their exchange hot wallets as a read only account to XUMM, assuming they can somehow track their exchange balance by destination tag.

When adding a read only wallet, we should give a big fat warning message in the screen to inform the user that they can NOT track their own transactions from an exchange hotwallet using this feature.

Allow users to select (on a per account basis) to get (background) push notifications for incoming transactions (for full access accounts, so ownership is verified)

This will be added in the future, but probably only for XUMM Pro subscriptions (as we'd need to provide infrastructure to run this).

The last 50 records are currently displayed. When devs want to debug older requests they should be able to browse back in the request log.

When starting the app, during the app splash screen, XUMM is connecting to the configured XRPL node. If there's trouble with the network, this may take a while.

So, during the splash screen:

• After 3 seconds, add text: Connecting to the XRP ledger...
• After 3 more (so 6) seconds, add text: This is taking more time than usual...
• After timeout (10 seconds): Error out with the "cannot connect" + Please check your internet connection screen, allow users to try again. If that doesn't work, allow users to switch node.

Better app performance guideline :

https://github.com/wix/react-native-crash-course/blob/master/docs/App.performance.md

When at the Events / Profile / Settings page, allow a swipe from the left screen edge to right to return back home (just like the "Send" screen now does).

Describe the bug
When closing the input doesn't blur so the keyboard is over the close modal.

Expected behavior
Blur when tapping the Close button, thus closing the keyboard as well

Screenshots
https://lufunlq.dlvr.cloud/trim.3C6995DB-30E3-4CD9-B3B0-0B64F127470D.MOV

Environment

iPhone X

Allow users to review all XUMM apps with push access, and allow a user to revoke push access. When revoking, somehow allow the user to report the app as well. Too many reports for a specific app = trigger (to XRPL Labs) to review the app.

• Add push permission to Sign Request (App, API)
• Add push permission request to xApp commands (SDK, App, API)
• Add settings with permissions & revoke (App, API)

@WietseWind notes:

• App Endpoint: get all tokens, expiration, icon, title, description, permissions
• App Endpoint: assign/revoke perms: xApp push, revoke entire user token for app (revokes general push)
• App Payload: meta: show current permissions, so Sign in screen can reflect current status
• App endpoint PATCH (sign in): add permission fields (allow / disallow, also able to take away given perms)
• OTT: return perms
• OTT (xApp env): request perms (push)
• xApp SDK: request perms (push)

Push Test scenarios

• Regular xApp
  • xApp Push
  • xApp Event + Push
  • Backend API: event with user token push
  • xApp JWT: event with push
  • Non xApp JWT (OAuth2): event with push
• Permissioned (xApp / regular app)

• When DEX exchange tab is opened, always fetch new rate (is preserved now when closed and reopened)
• When focussed: remove -0 (make empty) as now one may try to backspace without reason https://aoelg9f.dlvr.cloud/IMG_3618.png
• Blurring value should be possible by tapping outside of the input, so the "exchange" button becomes fully visible again. https://aoelg9f.dlvr.cloud/IMG_3618.png

Currently, when a payload contains a return URL for app, this return URL is only triggered when a user signs the payload.

If a user declines the payload (rejects), the user returns to the app home screen. This results in the user never returning to the originating application (if they are using a deeplink app to app flow).

So: when the payload contains an app return URL, and the user fully declines (not closes) the payload, ask the user if they want to return home, or want to go back to `.

Describe the bug
When trying to open the SessionLog, the App crashes. But only when a XRPL transaction was executed before

To Reproduce
Steps to reproduce the behavior:

1. Open Xumm App
2. Execute a XRPL transaction scanned through QR code or received via push notification
3. Go to Settings -> Advanced -> SessionLog
4. App Crashes

Expected behavior
SessionLog should be shown.

Environment

What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).

• XUMM version: 0.1.6.1

What device are you running XUMM on?

• Manufacturer: Apple
• Model: iPhone SE
• OS version: 13.3.1
• Platforms
  • [ x ] iOS
  • Android

Additional context

Attach crash logs if available. Please ensure that these files do not contain any personal information.

Describe the bug
When sending or handling a sign request sending an IOU, XUMM checks if the sender (you) and the recipient have the same trust line setup (for that IOU). If so, the amount will be sent as the IOU currency. If not, a conversion will take place sending XRP to the destination (using DEX).

However, when depositing the IOU back to the issuer (eg. sending Bitstamp USD back to Bitstamp for fiat withdrawal) the recipient DOESN'T have the trust line, as they are the issuer.

To Reproduce
Send eg. USD / BTC IOU back to IOU deposit address @ Bitstamp, eg.

Sample TX:
5456C8D189A58D0BBC3D932527DAB3522C78D6516AEF37287AA971D240E3305C

Expected behavior
IOU sent as is, Bitstamp USD sent, Bitstamp USD delivered.

What actually happens: USD sent, XRP delivered.

Screenshots
If applicable, add screenshots or a video to help explain your problem.

Proposed fix:

Sending the IOU as-is (without conversion to XRP) if (we need to check for two things):

• Do they have the Trust Line
  or
• The destination address is the currency issuer address

When accepting the first ever Sign request and/or when sending the first ever Payment (Send from Homescreen), if not asked before: trigger the App Store / Play store rating request.

Recap:

account_info (if a master key is disabled Y/N, if a regular key is set Y/N) isn't always up to date, resulting in signing with or without a regular key while that's no longer required (or no longer possible).

@N3TC4T Easy workaround "fix" = after all transactions involving AccountSet / SetRegularKey, force a fetch account info for all accounts.

Description
Signing of new Transactions via XUMM fails when:

1. Regular Key is set and you disable the Master Key
2. you Enable back the Master Key and delete the Regular Key

To Reproduce
Steps to reproduce the behavior:

There are two ways to reproduce it:

A:)

1. open the XUMM app and go to "Settings"
2. Receive a push notfication to set Account B as Regular Key of Account A and open + sign the transaction
3. Receive a push notification to "Disable Master Key" of Account A and open + sign the transaction
4. Receive a push notification to "Enable Master Key" of Account A and open + sign the transaction
5. Error occures from the XRPL saying "Master key is disabled"

OR

B:)

1. Precondition: Account B is the Regular Key for Account A. Account A has it's Master Key Disabled
2. Receive a push to Enable Master Key for Account A. Open and Sign
3. Receive a push to Delete Regular Key of Account A. Open and Sign
4. Receive a push to sign a transaction (like setting a Domain). Open and Sign
5. Transaction fails with "Transaction's public key is not authorized"

Expected behavior
The transaction should be signed with the Regular Key/Master Key. But instead it seems XUMM tries to sign with the Master Key/Regular Key

Screenshots
See above!

Environment

What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).

• XUMM version: 0.1.6.1

What device are you running XUMM on?

• Manufacturer: Apple
• Model: iPhone SE
• OS version: 13.3.1
• Platforms
  • [ x ] iOS
  • Android

Additional context

Session Logs can not be provided because App crashes when opening the Session Log (separate Issue)

@N3TC4T

When a user imports an account, and the derived r... address has the master key disabled and a regular key configured, explain to the user (in the setting up flow) that to make transaction signing work for this account, they will have to import the regular key account as well.

There is two new Alternative JS core for android

Hermes and V8

base on this post looks like v8 is a really good option.

Right now realm doesn't support other alternative js cores , so we have to wait to they implement this feature

realm/realm-js#2455

Create a pack with images and logos (for on white, dark, etc.) and create a collateral page on the website + link the docs there, eg. for press and if people want to implement on their site and use a "Sign with XUMM" button.

https://f-droid.org/docs/FAQ_-_App_Developers/?title=FAQ_-_App_Developers

When filtering (text) the events, searching doesn't filter the account names (from address book / lookup / ...), just transaction account and hash. People will definitely try to search for the name, so it should filter the name as well.

When a deeplink opens the app and the transaction is expired (eg. try the link at https://wietse.nodum.io/test/expired-deeplink) the app shows a message that the transaction has been "handled by another client", which is not the case: the message should be different when expired.

If expired: "The request expired"
If not expired, but handled by another client: "This request is already resolved"

Describe the bug
When trying to delete an IOU in the Xumm App, an error is shown

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Home'
2. Click on 'IOU'
3. Click on 'Remove'
4. See error

Expected behavior
The IOU should have been deleted

Screenshots

Environment

What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).

• XUMM version: 0.1.6.1

What device are you running XUMM on?

• Manufacturer: Aple
• Model: IPhone SE
• OS version: 13.1
• Platforms
  • iOS
  • Android

Additional context

Session Log:

[10:57:55.830] XUMM version 0.1.6.1 
[10:57:55.866] Storage current schema version: 1 
[10:57:55.867] Storage is on latest schema version 
[10:57:55.872] Locale set to: EN 
[10:57:55.880] Syncing time with network [time.google.com]... 
[10:57:55.919] NTP Sync success, Network time offset UTC 29 
[10:57:55.929] Start Syncing with backend 
[10:57:56.136] Syncing contacts ... 
[10:57:56.166] Connected to Rippled Node wss://testnet.xrpl-labs.com 
[10:57:56.167] Sending Socket Payload {"command":"account_info","account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","ledger_index":"validated","signer_lists":true,"id":4}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","ledger_index":"validated","signer_lists":true,"id":5}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","ledger_index":"validated","signer_lists":true,"id":6}
[10:57:56.168] Subscribed to rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF,r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk,rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG,rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7 accounts ["rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7"]
[10:57:56.168] Sending Socket Payload {"command":"subscribe","accounts""rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7"],"id":7}
[10:57:56.168] Sending Socket Payload {"command":"account_info","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","ledger_index":"validated","signer_lists":true,"id":8}
[10:57:56.203] Account info rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF {"account_data":{"Account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","Balance":"669665384","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"FF924879F2E6F94B5099FFA5B57245D67F06637C53C88D1FA8F1C8CB26927F2E","PreviousTxnLgrSeq":5698147,"Sequence":13,"index":"1021D8793852E3D22434F6B3990EA53FDC00353A649EBE0E2BE2324775E3F248","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":36}
[10:57:56.214] Sending Socket Payload {"command":"account_lines","account":"rNixerUVPwrhxGDt4UooDu6FJ7zuofvjCF","id":9}
[10:57:56.215] Account info r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk {"account_data":{"Account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","Balance":"419999988","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"FD3CC50A88337E2D2113002067615BD2C11223D358E140A0DB1079874D9DF07D","PreviousTxnLgrSeq":5596198,"Sequence":2,"index":"95D62098A420099A9E77910749453FE82A3595AB34B880BACC0B5526B8661E7A","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":46}
[10:57:56.221] Sending Socket Payload {"command":"account_lines","account":"r9N4v3cWxfh4x6yUNjxNy3DbWUgbzMBLdk","id":10}
[10:57:56.222] Account info rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7 {"account_data":{"Account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","Balance":"20999989","Flags":0,"LedgerEntryType":"AccountRoot","OwnerCount":0,"PreviousTxnID":"996D8D8AC0311E393943F8899FA716F7BE66475DD4423C886FD1632998A3E912","PreviousTxnLgrSeq":5667529,"Sequence":15,"index":"51F4B62FBF5A007EC0BDD76F38057F3D72A976A7CFDDB1069201C01ECFAA9E11","signer_lists"]},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"command":"account_info","replyMs":54}
[10:57:56.229] Sending Socket Payload {"command":"account_lines","account":"rpLyiTZR4xQnzcyZeXWJPoq3PgcdPVHPb7","id":11}
[10:57:56.230] Account info rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG {"account_data":{"Account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","Balance":"92498004","Domain":"68747470733A2F2F78756D6D2E636F6D6D756E697479","EmailHash":"351107F80DE5E43F95C720D96BB5C737","Flags":65536,"LedgerEntryType":"AccountRoot","OwnerCount":3,"PreviousTxnID":"FF924879F2E6F94B5099FFA5B57245D67F06637C53C88D1FA8F1C8CB26927F2E","PreviousTxnLgrSeq":5698147,"Sequence":84,"index":"51C3512735E28DF6165266F2A2709E49F6028E6382D0D6D70D0DE404CAB39BD5","signer_lists"],"urlgravatar":"http://www.gravatar.com/avatar/351107f80de5e43f95c720d96bb5c737"},"ledger_hash":"27604AA65EF1CB59DCBDB32AA5C6B8AF98B00ECC60A614E93D043CDA2671B6ED","ledger_index":5723433,"validated":true,"__command":"account_info","__replyMs":62}
[10:57:56.248] Sending Socket Payload {"command":"account_lines","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","id":12}
[10:57:56.352] Sending Socket Payload {"command":"account_info","account":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","ledger_index":"validated","signer_lists":true,"id":13}
[10:57:56.353] Sending Socket Payload {"command":"account_info","account":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","ledger_index":"validated","signer_lists":true,"id":14}
[10:58:00.536] Submit TX: {"TransactionType":"TrustSet","Account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","Flags":2147614720,"LimitAmount":{"currency":"EUR","issuer":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","value":0},"Fee":"12","Sequence":84}
[10:58:00.538] Sending Socket Payload {"command":"account_info","account":"rBnjStKwLFmpSye3z4hJkrB1Lhk45RuWnG","ledger_index":"validated","signer_lists":true,"id":17}
[10:58:00.706] Sending Socket Payload {"command":"submit","tx_blob":"1200142280020000240000005463800000000000000000000000000000000000000045555200000000002ADB0B3959D60A6E6991F729E1918B716392523068400000000000000C732102A896AC755006AC8F3BCC86D4816DCEC43808C1A576E9B52FDF8017E3F24AAF53744730450221008D9E3F7FACAC4D51F4C0543C34E4E74125ED3DCC7CE73B2C977F83A07CFC26AE022057FC3A4742E849347457BE8B36FE95E7495A84A3FC7F4191A5A42BA70FC59CAE81146E965AA3CC658518E579480DFD81D8CB06085602","id":18}

If the Event-detail page (transaction detail view) gets updated to show more clear (tx instruction vs. outcome) information & context aware (#10) buttons (eg. escrow: if possible: release/cancel, if not possible yet: show when. If AccountSet, set flag: clear flag & reversed, if Offer: cancel offer, if possible) »

Once a transaction has been successfully sent, allow users to select (if not by sign request with redirect URL for app) where they want to go: Home or Transaction details » and link them to the improved TX detail screen just mentioned.

Other ideas:

• Show human friendly transaction name type name
• Account: store in address book / send to, share (if not there yet)
• Resolve account name in API
• Link (browser): Open in explorer (eg, Bithomp/XRPScan/...)
• In case of IOU: show issuer + icon if trusted

Describe the bug
When exchanging an IOU for XRP (or the other way around), you can enter any amount (even more than you own, which is OK and works just fine as the transaction will exchange as much as possible based on the amounts entered).

But: after conversion, the ENTERED amounts are returned to the user, not the effective OUTCOME amounts. It should display the outcome (effective, real workd) results from the finished transaction.

To Reproduce

1. Open an IOU with a limited balance
2. Switch
3. Enter a (way) higher amount to exchange than the balance allows
4. Convert successfully, and check the results in the alert,

Expected behavior
Display the ACTUAL consumed balance and credited value.

Screenshots

1. Show only the AVAILABLE balance everywhere, with an (i) icon to:
2. Show a breakdown + total balance including reserves in a separate panel

When tapping XRP balance: show dialog with split down in reserve, extra reserve (owners) & spendable balance.

When (XUMM home screen) tapping "add" (Other currencies), a currency + issuer that is already present (Trust line already exists) is still offered. It doesn't make sense to offer adding the currency again.

Describe the bug
Some parts/movdment of the interface scroll the content panel up, and some parts the actual content. Maybe we should fix the panel when focused in the amount (or any other input for that matter)

Expected behavior
Swiping the screen up/down without moving the panel. Maybe keep the panel fixed when focussed at the input.

Screenshots
https://lufunlq.dlvr.cloud/trim.3C6995DB-30E3-4CD9-B3B0-0B64F127470D.MOV

Environment

iPhone X

1. Go to events
2. Filter (type something, select only Payments, etc.)
3. Open a transaction
4. Return » now (async, wait half a second) all transactions are displayed, while the filter is still displayed too (but not applied)

Report by @nixer89

I opened the app. had an account A and an Account B. I set Account B as regular key for account A. Then I disabled the master key for Account A. Then I tried to enable the master key for Account A back and the transaction failed. (as info: I never left the "events" screen of the Xumm App!)
But once I navigate to the "Home" screen, transactions are possible. My conclusion: After transaction submission and verification to the XRPL ledgter, the app does not refresh the account settings of all accounts, therefore is not aware that a regular key was set
because it does not know of the new regular key, the app still tries to sign the next transaction with the master key
once I navigate to the "Home" screen, the account_info's of all accounts are refreshed and the app is aware of the regular key relation and can sign the next transaction with the regular key
so is it possible to refresh the account_info (and even account_objects) after transaction verification?

Suggested solution: refresh account info after sending a transaction that affects the account state, eg. AccountSet, SetRegularKey, ...

Describe the bug
See title

To Reproduce

1. Add IOU
2. Remove
3. See home screen

Expected behavior
Removed currency gone

Environment

@nixer89

Right now, when sending XRP, first the source account, currency and amount are entered.
After that, the destination is selected (enter account / scan a QR).
Then, one goes to the final screen to enter meta info and ... The destination tag.

That doesn't make sense; the Destination tag is part of the destination so it belongs on the screen where the destination account is entered and selected. It can even be very confusing to end users as they can't find a place to enter the tag when selecting the destination.

Here's what we should do (imo) (screenshots by @thisistriss from the original designs).

• if user originates from pasting/scanning an r-address / x-address WITH destination tag:
  1. Select address
  2. Skip (mockup) destination tag entry popup
  3. Show the tx summary (but with tag DISPLAYED) in the "To" section, with a "edit" icon, triggering the (mockup) destination tag entry popup
• if user originates from pasting/scanning an r-address WITHOUT destination tag:
  1. Select address
  2. SHOW (mockup) destination tag entry popup, if tag for the account is mandatory: require a tag (next disabled if not entered) and show the "requires a ..." text. If the tag for the account is NOT mandatory, allow entry but also allow NEXT without tag.
  3. Show the tx summary (but with tag DISPLAYED) in the "To" section, with a "edit" icon, triggering the (mockup) destination tag entry popup. Show "No destination tag" with edit icon if none is entered.

When a user imports an account, check the derived r... address, if master is disabled and a signer list is setup (instead of a regular key #15) inform the user (in the account import flow) that XUMM doesn't natively multi sign, and that they can use one of the existing XRPL toolkits with XUMM support to handle multi signing).

In the future: eg. allow the user to view a "XUMM Tools" webpage (specific Multi Sign category?) where we may track all available toolkits/apps with XUMM support » https://xrpl-labs.canny.io/xumm/p/create-a-xumm-tools-webpage

After the "Not executed due to lack of liquidity" message @ exchanging on DEX, check if the transaction is at least partially fulfilled.

If not fulfilled: take the user back to the home screen. If partially fulfilled: take them to the transaction details screen where they can see the outcome, so at least they know what actually happened (how much was exchanged anyway).

In my sample case, I ordered 0.25 BTC to be exchanged but only 0.06 made it (as XUMM allows at most a 10% difference between the best exchange rate and the amount to be spent). Without taking people to details they may try it again not knowing that it already partially fulfilled.

** Would be considered a bug by end users. **

Right now, when a user uses the QR scanner icon from the home screen, when scanning a QR code containing an XRPL destination (r-address, X-address) nothing happens. Scanning a destination only works from the "Send" flow.

I'm 100% positive this will result in a crazy amount of bug reports/questions. Users should just be able to scan without having to think about what they are scanning.

So: when a user scans a destination from the home screen scanner, route the user to the Send flow with the destination address (and tag if present, see #17 + #18) already prefilled.

Describe the bug
When sending a TrustSet transaction to Xumm, an weird error is shown after signing the transaction

To Reproduce
Steps to reproduce the behavior:

1. Send a TrustSet transaction to Xumm
2. Sign the transaction
3. See error

Expected behavior
Even if the TrustSet transaction is not valid, a proper Error message should be shown

Screenshots

Environment

What build of XUMM are you running? Please provide the full version (you can find it in Settings > Advanced).

• XUMM version: 0.1.6.1

What device are you running XUMM on?

• Manufacturer: Apple
• Model: IPhone SE
• OS version: 13.1
• Platforms
  • iOS
  • Android

Additional context

the submitted payload looks like this (and was signed with testnet account):

{"options":{"expire":5},"txjson":{"TransactionType":"TrustSet","LimitAmount":{"issuer":"rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq","currency":"ABC","value":"100"}},"custom_meta":{"instruction":"- Issuer Address: rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq\n- IOU currency code: ABC"}}

SessionLog cannot be copied because the app shows only a white screen. Only after force closing the app it's working again but SessionLog is overwritten.

Describe the bug
See:
https://kcokjkv.dlvr.cloud/trim.1BD74FCA-660E-43BF-B638-690307A34803.MOV

Expected behavior
Message that at least one drop should be sent.

Screenshots
https://kcokjkv.dlvr.cloud/trim.1BD74FCA-660E-43BF-B638-690307A34803.MOV

1. Connect with Github account
2. Select language + region to translate (tool forks + creates/edits file)
3. Tool fetches EN and diffs keys, removing/adding keys from the translation to sync up with the latest version
4. Tool highlights missing/changed translations based on EN for review
5. User can translate and save (commits on own fork)
6. User can finish (pull request)

Describe the bug
When redirecting a user to the next.always URL of the payload response (as example on desktop) a QR code is shown. If the QR code is expired, the website (https://xumm.app/sign/:payloadId) does not redirect back to the original application and the user is "stuck" in this screen.

When scanning the expired QR code, there will be a proper error message in the app but the website says "Waiting for you to resolve (accept / deny) the "Payment" request in XUMM app."
But that is not possible because the payload has expired before it was opened/scanned.

To Reproduce
Steps to reproduce the behavior:

1. Create a payload with expiry time of 1 minute
2. redirect the user to the 'next.always' URL of the payload submit response
3. wait more than one minute to let the payload expire

Expected behavior
It would be cool if the website (https://xumm.app/sign/:payloadId) shows an error/warning when the
payload has expired and offers the possibility to redirect to the original page like:
"The payload has expired and cannot be signed anymore. Click here to return to the previous website"

Environment

(not so important here. Not app bug :-) )

When filtering events, you type something, the events are filtered. So far so good.

Now (by tapping outside of the filter textbox (input)) the keyboard will still be displayed, focus still in the filter search input. This limits the amount of screen space available to review the found transactions. Look eg. at Bunq: to apply (text) filter, one has to press the "search" button @ keyboard, then the input blurs, keyboard goes away and filter starts.

Describe the bug
Rare condition: account status is updated (eg. flag is set, @nixer89 ;) ) while the app was offline / in the background / ... Now a sign request comes in (so the user doesn't pass through the home screen of the app, where the account info is updated).

This could result in signing a payload based on old information (eg. master disabled + regular key, thus making XUMM using the regular key, while in fact the master disabled has already been cleared & regular key unset).

Expected behavior
If (async, in the background) the most recent account info is updated when opening a sign request (besides the already present subscription to account updates on the XRPL, as the event may be missed if the app is offline / in the bg) we make sure we are always working with the most recent account info when handling a sign request.