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.
different networks might require different apm domains. We set those in
the arapp.json file which we can reuise to init the kredits instance in
the helper scripts.
This dynamically hashes the app id which makes it easier to manually set
contract addresses. This is useful in development environments with no
default network ids.
The used apm (which is part of the app id hash) is configurable.
usage:
new Kredits(provider, signer, { addresses: { Kernel: '0x...' }, apm: 'aragonpm.eth' })
Ideally eth-provider checks which connection is available and uses the
available one.
frame => local node => infura
But it seems there is still a bug and it raises an error if frame is not
available.
But at least we can use frame now for testnet/mainnet deployments
this mainly allows us to check if an account has a certain role and thus
if the account can call specific contract functions.
At some point we might want to extend that to support the check if an
account can call the function. For that we would need to have a mapping
between function names and roles, which we have not right now.
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.
This allows to filter contributors by the account entries.
For example:
```js
Contributor.filterByAccount({site: 'github.com'}); // returns all
contributors with github account
Contributor.filterByAccount({site: 'github.com', username: 'bumi'});
// returns bumi
```
This moves the whole checks if everything is running into its own class
and is no longer inside the different functions.
Makes the functions smaller and the healthcheck can be used from the
client only if wanted/needed.
This reuses the kredits library functions in the helper scripts and
seeds. We no longer need to add IPFS hashes manually but simply can
provider contributor/proposal data.
This moves the Kredits initialization to the instance which allows us to
be more flexible with handling contract addresses.
Example:
var k = new Kredits(provider, signer, {Registry: '0xabc'});
k.init().then((kredits) { ...});
var k = new Kredits(provider, signer, {Contributors: '0xabc'})
k.Contributor.add(...);
This allows to provide options like gas price/limit settings for the
state changing contract calls.
These options are simply passed to the ethers contract instance.
We need to provide the gas limit when using the jsonrpc provider.
(ganache failed with revert if not enought gas was provider)
This makes it easier to handle truffle arguments which we for example
need to specify the network.
So we ask the user for input instead on using the argv array which might
change.
This persists the state of the ganache db and uses a fixed mnemonic
code to create accounts.
It now acts more like a local presistent database and no need to
send funds to the accounts after restart.
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.
bumi
