[X] Exchange invitation for email@organisation!
./release/bm-client account create --account john@testorg1\! --name "john @ testorg1" --token YjhlN2JiMzQ2ZWIxNjEx.....
X error occurs on server when uploading the account to the server
X error when uploading to the key resolver: org token not found
[X] Update information for email@organisation! by the user
[ ] Remove resolver information for email@organisation! (ie: disabled flag?)
[X] Can we re-add email@organisation by the current user? (using the same invitation)
[X] Can we create a new invitation for a new user of the account?
[X] send mail from org->reg
[X] send mail from reg->org
----------------
TODO:
[X] Add/rem/list validations to orgs?
[X] change create-organisation-invite to invite
[X] account in create-org-invite must be mandatory
[X] spinner added to proof-of-work
[-] when adding account name, we must use the whole address: john@example\! instaed of just "john"..
[X] create user account does not work
[X] need mnemonic display in info
[X] need validation display in info
[X] Make sure the mailserver accepts organisation tokens, only when it wants to (organisation whitelist)
[ ] ~~Remove resolver information for email@organisation! (ie: disabled flag?)
Do we remove the data from the resolver directly? Or do some soft-delete? What are the pro's en cons?
Proposal: we do a soft-delete (deleted_at column to the db). Later we can see if we want to hard-delete old records (say > 6months)~~
[X] Can we re-add email@organisation by the current user? (using the same invitation)
When we are removed from an organisation, can we reuse the same invitation to readd ourselves again? Do we somehow need to add the hash of the invitation to make sure that we can add only once (do we want to do this?)
Proposal: we can just re-add, for as long as the token hasn't expired. We will not solve this issue just yet.
[X] Can we create a new invitation for a new user of the account?
Can we give somebody else an invitation for the same account?
Proposal: works the same was as above: we don't care about expiries.
Maybe add a unique number in the serial to differentiate between the different invitation tokens.
[X] Add/rem/list validations to orgs?
How do we add or remove validations from an organisation:
bm-client organisation validate add --org testorg1 --type dns --value test.org
bm-client organisation validate remove --org testorg1 --type dns --value test.org
bm-client organisation validate list --org testorg1 ?
./release/bm-client organisation create --org testorg1 --name "test org 1"
X (should be --org instead of --organisation?)
X needs mnemonic display
X needs validations
./release/bm-client organisation create-organisation-invite --routing-id 323250728593e92f50bf1572d10318912fd611dd0f4e5d36726c0c0757b29e03 -o testorg1 --account john@testorg1\!
./release/bm-client account create --account john@testorg1\! --name "john @ testorg1" --token YjhlN2JiMzQ2ZWIxNjEx.....
X error occurs on server when uploading the account to the server X error when uploading to the key resolver: org token not found
Remove resolver information for email@organisation! (ie: disabled flag?)----------------
TODO:
[ ] ~~Remove resolver information for email@organisation! (ie: disabled flag?) Do we remove the data from the resolver directly? Or do some soft-delete? What are the pro's en cons? Proposal: we do a soft-delete (deleted_at column to the db). Later we can see if we want to hard-delete old records (say > 6months)~~
[X] Can we re-add email@organisation by the current user? (using the same invitation) When we are removed from an organisation, can we reuse the same invitation to readd ourselves again? Do we somehow need to add the hash of the invitation to make sure that we can add only once (do we want to do this?) Proposal: we can just re-add, for as long as the token hasn't expired. We will not solve this issue just yet.
[X] Can we create a new invitation for a new user of the account? Can we give somebody else an invitation for the same account? Proposal: works the same was as above: we don't care about expiries.
Maybe add a unique number in the serial to differentiate between the different invitation tokens.