feat(gno/daokit): new dao sdk pkg (conditions based w/ roles) #1487
Conversation
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
Signed-off-by: Norman <[email protected]>
✅ Deploy Preview for teritori-dapp ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for gno-dapp ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
… old dao realm examples
MikaelVallenet
changed the title
|
ADD unit test & link to vote or execute when the proposal is ready to be execute |
| } | ||
|
|
||
| proposal.state.HandleEvent(e, proposal.votes) | ||
| proposal.votes[voter.String()] = daocond.Vote(vote) |
There was a problem hiding this comment.
maybe a bad idea, but what do you think of handling the vote record inside the p realm ? like that is not resposability of the realm caller to register that vote.
If the vote is not registered it could lead to bugs right ? (for example we could be able to vote multiple times )
There was a problem hiding this comment.
I disagree, i don't see any advantage to let the realm handle the voting records
I think we should have minimal realm and abstract all dao related logic in the daokit package
| panic("proposal not found") | ||
| } | ||
|
|
||
| if proposal.status != ProposalStatusOpen { |
There was a problem hiding this comment.
Something to discuss during our point:
State and status seems like too close one to another maybe we need to rename one or another
Co-authored-by: Miguel Victoria Villaquiran <[email protected]>
MikaelVallenet
changed the title
DAO Roles & Conditions Based
This Pull Request follows the discussion between zooma, norman and myself to define the management of votes on DAOs that have a role system.
This PR implements the chosen solution, which is that in order to be validated, a vote must fulfill a set of conditions (see #1479) that are defined by the DAO. Each resource/action that the DAO can perform has a linked set of conditions (example: posting an article on the social feed might require validation by 1 community manager and 2 members).
Implementation choices
I decided to implement this under a single package that communicates with the conditions package & the role manager package.
The DAO is simple to create, which makes it easier for the user to generate contracts during deployment.
DAO example: https://github.com/TERITORI/teritori-dapp/blob/d221981f1ef875376a163eb5caeadf4c87bb59ec/gno/r/dao_realm/dao_realm.gno
Conditions & resources are sent in JSON format as this is easier to write/generate in my opinion.
Using the DAO
Once the DAO contract has been deployed, there are four ways to interact with it: new proposal, vote, execute & instant execute.
All four actions require DAO membership.
Gnoweb UI
The Gnoweb interface has 5 pages
Home Page
Config Page (Roles & Resources of the org.)
Member Detail Page (List role of a member)
Proposal Detail Page
List all proposals
