Table of Contents |
---|
...
transfer-tokens.js
Plan: create new record-obt-data.js test:
Test single recordobt with bundles
Send FIO with Memo
Confirm get_obt_data returns correct record for payee and payer
Confirm content can be decrypted by payee
Include correct content for each content field and confirm it can be read by payee
Confirm status field for payee and payer
Confirm 2 bundles are deducted
Test single recordobt with no bundles
Same test as above, but with no bundles remaining
Error testing
Send with large content field that is too large
record obt with:
badly formatted
payer_fio_address
andpayee_fio_address
Send character string to fio_request_id
payee_fio_public_key
that does not own the thepayee_fio_address
Paging testing
...
Contracts Release 1 - fio.contracts (Bravo)
After this update and the initial call to migrtrx, new Request and OBT data coming in will be entered into both the old and new tables.
Step 1 introduces the new table structure and adds a new “temporary” action call called migrtrx
. This action enables the top 21 block producers to start migrating existing data over to the new formatted index tables.
...
[FIP-1.b] Step 1: Add continuous migration of request and obt data (FIO #182)
The complete migration of data has to happen before fio chain is released. An off chain validation should be done to confirm this.
Note that the partial implementation of transfer address (https://fioprotocol.atlassian.net/browse/BD-2232 ) will work after Step 1.
...
Contracts Release Part 2 - fio.contracts (migr/part2)
All fio chain nodes should be upgraded prior to rolling out Contract Step 2.
Step 2 does two things:
Modifies the Request code to stop updating the old tables. After this release, only the new tables will get updated.
Modifies the
migrtrx
call. It will now remove data from the old tables.
...
Release Verification Plan
Casey Gardiner Need this. Add info on your scripts that will verify data, etc.