Extract colony metadata from colony model #296
Conversation
| @@ -27,7 +27,7 @@ input ProfileMetadataInput { | |||
| emailPermissions: [String!]! | |||
| } | |||
|
|
|||
| input MetadataInput { | |||
| input ChainMetadataInput { | |||
There was a problem hiding this comment.
Renamed to avoid confusion between all the different metadatas we now have
jakubcolony
force-pushed
the
port/282-edit-domain
branch
from
1896dbf
to
2eaf5fb
Compare
|
Does this need to be rebased ? as it shows 70 changed files. I don't think that correct ? |
jakubcolony
force-pushed
the
refactor/292-colony-metadata
branch
from
112b547
to
3ba7c0a
Compare
|
@rdig Done |
| @@ -253,7 +257,25 @@ const createMetacolony = async (singerOrWallet) => { | |||
| if (metacolonyQuery?.errors) { | |||
| console.log('METACOLONY COULD NOT BE CREATED.', metacolonyQuery.errors[0].message); | |||
| } else { | |||
| console.log(`Creating metacolony { name: "meta", colonyAddress: "${utils.getAddress(metacolonyAddress)}", profile: { displayName: "Metacolony" }, nativeToken: "${utils.getAddress(metacolonyTokenAddress)}", version: "${metacolonyVersion.toString()}" }`); | |||
| console.log(`Creating metacolony { name: "meta", colonyAddress: "${utils.getAddress(metacolonyAddress)}", nativeToken: "${utils.getAddress(metacolonyTokenAddress)}", version: "${metacolonyVersion.toString()}" }`); | |||
There was a problem hiding this comment.
Is the temp script necessary anymore ?
We should decide what to do with it. Either:
- remove it and create everything manually
- keep it, but update it so that it creates proper colonies (with extensions, token authorities and everything)
There was a problem hiding this comment.
Yeah, maintaining it is a bit of a pain. But it's nice to have the script that bootstraps everything for you.
One option could be to use some headless browser (cypress, puppeteer) to programmatically click through the user and then colony creation wizard, but I don't know how feasible that would be
There was a problem hiding this comment.
We had that before, and it more or less worked, however it provided quite a bit of overhead and ate alot of resources.
I guess once we stabilize the core features, maintaining this won't be as much of a problem anymore
Description
This PR extracts the colony metadata (the information that is not available on the chain) into its own model, allowing the client to write it separately from the "core" colony details.
To achieve this, I removed the Colony<>Profile relation. The display name, avatar, and thumbnail are now properties of Colony Metadata. This is to reduce complexity (you don't need either an extra mutation to create profile, or a custom lambda function like
createUniqueColony) and allow for easier tracking of the changes (similarly to domain metadata's changelog).I don't think it is yet possible to move the entire colony creation mutation to block-ingestor and only write the metadata in the saga (as we do with the domain). The problem I faced is that colony name isn't available on chain but at the same time it has to be unique and indexable (since we want to get colony by name reliably and fast). This needs further thought but one idea could be to create some mapping between given names and colony addresses (as well as chains possibly).
Testing
Testing mostly focuses on double-checking I haven't broken anything. Please create some colonies using both the creation wizard and
temp-create-datascript. Inspect the CDapp to make sure none of the previous profile data (just display name for now) isn't missing/wrong.Resolves #292