Enables the use of aliases in one to many XEC send txs, including inline validation when there is a mix of ecash address and aliases in the multi recipient input.
Details
Details
- Reviewers
bytesofman - Group Reviewers
Restricted Project
- npm test
- enable alias in ticker.js
- npm start
- navigate to Send.js and input a multi recipient input with a mixture of valid ecash address and valid aliases and ensure successful broadcast of the send tx. Sanity check via explorer
- enter a multi input of valid ecash address but with at least one invalid alias format and ensure the Ensure each alias is valid and has 1 confirmation validation error is displayed
- enter a multi input of valid ecash address and aliases but with at least one value below 5.5 XEC and ensure the Ensure each tx is at least 5.5 XEC validation error is displayed
- enter a multi input with valid and registrered aliases being the first row and ensure no validation errors
- enter a multi input with valid and registrered aliases being the last row and ensure no validation errors
- enter a newline amongst the multi input and ensure the Empty spaces and rows must be removed validation error is displayed
- enter a space as part of an address or alias and ensure the Empty spaces and rows must be removed validation error is displayed
- register a new alias and whilst it is still in the pending state, attempt to include it in a multi recipient input and ensure the Ensure each alias is valid and has 1 confirmation validation error is displayed
- wait for the newly registered alias above to receive 1 confirmation and ensure it is now accepted as part of a multi recipient input and sends successfully
- disable alias in ticker.js and ensure no regression to existing one to many send XEC txs
Diff Detail
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- aliasOneToMany2
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 23063 Build 45746: Build Diff cashtab-tests Build 45745: arc lint + arc unit
Event Timeline
Comment Actions
This is a pretty complicated change for something of questionable impact. It should be in there. But, I think we should table this until the prod implementation is ready. It's just another ball to juggle if we change other details about parsing and storing the aliases.
Please mark changes planned and we'll revisit when aliases launch.