It seems that the entity is either defined by the permission or if we
want to use the oracle the permission must be defined for any_entity.
In that case the oracle does not get the msg.sender as who/entity thus
we will use tx.origin in that case.
Allows anybody with the VETO_CONTRIBUTION_ROLE to veto a contribution
and thus prevent that the contribution can be claimed.
So far like the ADD_CONTRIBUTION_ROLE any contributor is allowed to
veto.
AppIds are used to lookup the actual contract addresses of each app.
Because of different registry names (open.aragonpm.eth vs. aragonpm.eth)
we have to use different ids in the local dev chain and in the
testnet/mainnet. To allow this we need to set the appids dynamically.
There is an open aragon issue to solve this and also allow to use
open.aragonpm.eth in the devchain by default.
https://github.com/aragon/aragen/issues/10
The contribution contract implements an ERC721 interface which
represents any contribution.
The contributions are non-fungible (as opposed to the Kredits tokens)
and can be not be transferred. The contract stores the history of any
contribution.
Contributions can be claimed which will issue the Kredits tokens to the
contributor.
This is an early implementation and misses some access control and
probably more things.
The batchVote function accepts an array of proposal ids and votes for
every one.
Normally arrays without fix length are problematic and gas usage can not be
estimated really well. So we need to see how that works or what other
pattern could be used.
Adding a voterIds array to the proposal.
This allows us to check if a user already has voted on a proposal.
As this is not directly supported by the default proposals accessor this
also adds a getProposal function to get all proposal data.
So far we only allowed calls to the Contributors contract from the
Operator. With the new registry concept we can call functions again
directly on the Contributors contract (without the need to call it through
the operator).
This changes the authentication for the contributor management functions
to allow either core contributors or the operator to call them.
In the future I envision a bit more flexible and configurable
authentication concept that can more easily evolve over time.
This allows use to call the methods with a string but still store the
name as bytes32.
I also had some issues when calling the methods from ethers.js and a
string parameter so this is easier and safer.
This allows to manage different contracts (Token, Collaborator, etc.)
with one registry.
The registry serves as main source for all contracts and versions.
Versions are independently deployed and added to the registry. From
there the proxy contract's implementation can be upgraded to the new
version.
Currently no access control is implemented.
