- send transferred keyuids instead of number of transferred files
- updating keypair's operability for transferred keypairs
- unnecessary check of a number of transferred keystore files
There is a desktop app feature where we need to transfer keystore files for selected
keypair/s only via local network using a QR code (of course, which are not migrated
to a keycard, otherwise we wouldn't need to do that).
If user followed onboarding flow to recover his account using seed phrase or keycard,
then `ProcessBackedupMessages` property of node config json object should be set to
`true`, otherwise it should be set to `false` or be omitted.
- old `accounts` table is moved/mapped to `keypairs` and `keypairs_accounts`
- `keycards` table has foreign key which refers to `keypairs.key_uid`
- `Keypair` introduced as a new type
- api endpoints updated according to this change
* sync local deleted messages
* rebase
* add REPLACE
* fix lint
* defer rows.Close() / rename function
* add local pair test
* replace unused clock with _
This commit replaces `os.MkdirTemp` with `t.TempDir` in tests. The
directory created by `t.TempDir` is automatically removed when the test
and all its subtests complete.
Prior to this commit, temporary directory created using `os.MkdirTemp`
needs to be removed manually by calling `os.RemoveAll`, which is omitted
in some tests. The error handling boilerplate e.g.
defer func() {
if err := os.RemoveAll(dir); err != nil {
t.Fatal(err)
}
}
is also tedious, but `t.TempDir` handles this for us nicely.
Reference: https://pkg.go.dev/testing#T.TempDir
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Additionally to allow this process flow I refactored RawMessagePayloadReceiver and InstallationPayloadHandler to use a dedicated Marshaller type. Also added a fix to struct extention functionality, we want to ignore the process if there is no public key because that will key encoding. Seems an unnecessary bug to have to handle when you know there is no key.
This uses Load, MarshalProtobuf and encrypt process flow for any PayloadMounter type. In fact the concept of a PayloadMounter type is only useful now in the instantiation context.