Add tests for the different modules provided in shared like the deployer, helpers, libs, etc

I'm running npm test or npm install and getting the following errors from docker

> npm run docker:build && npm run docker:run && test `docker-compose ps -q | xargs docker inspect -f '{{ .Name }} {{ .State.ExitCode }}' | grep deploy | cut -d' ' -f 2` = 0


> @aragon/[email protected] docker:build /Users/xxx/xxx/dao-kits/kits/beta
> docker build -t aragon/templates-beta -f Dockerfile ../..


    at Promise.all.then.arr (/Users/xxx/xxx/dao-kits/node_modules/execa/index.js:236:11)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)
  code: 1,
  killed: false,
  stdout: '\n> @aragon/[email protected] test /Users/xxx/xxx/dao-kits/kits/beta\n> npm run docker:build && npm run docker:run && test `docker-compose ps -q | xargs docker inspect -f \'{{ .Name }} {{ .State.ExitCode }}\' | grep deploy | cut -d\' \' -f 2` = 0\n\n\n> @aragon/[email protected] docker:build /Users/xxx/xxx/dao-kits/kits/beta\n> docker build -t aragon/templates-beta -f Dockerfile ../..\n\n',
  stderr: 'time="2018-08-07T13:08:01+07:00" level=error msg="failed to dial gRPC: cannot connect to the Docker daemon. Is \'docker daemon\' running on this host?: dial unix /var/run/docker.sock: connect: no such file or directory" \ncontext canceled\nnpm ERR! code ELIFECYCLE\nnpm ERR! errno 1\nnpm ERR! @aragon/[email protected] docker:build: `docker build -t aragon/templates-beta -f Dockerfile ../..`\nnpm ERR! Exit status 1\nnpm ERR! \nnpm ERR! Failed at the @aragon/[email protected] docker:build script.\nnpm ERR! This is probably not a problem with npm. There is likely additional logging output above.\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /Users/tom/.npm/_logs/2018-08-07T06_08_01_382Z-debug.log\nnpm ERR! code ELIFECYCLE\nnpm ERR! errno 1\nnpm ERR! @aragon/[email protected] test: `npm run docker:build && npm run docker:run && test `docker-compose ps -q | xargs docker inspect -f \'{{ .Name }} {{ .State.ExitCode }}\' | grep deploy | cut -d\' \' -f 2` = 0`\nnpm ERR! Exit status 1\nnpm ERR! \nnpm ERR! Failed at the @aragon/[email protected] test script.\nnpm ERR! This is probably not a problem with npm. There is likely additional logging output above.\n\nnpm ERR! A complete log of this run can be found in:\nnpm ERR!     /Users/tom/.npm/_logs/2018-08-07T06_08_01_414Z-debug.log\n',
  failed: true,
  signal: null,
  cmd: 'npm run test',
  timedOut: false,
  exitCode: 1 }
npm ERR! Test failed.  See above for more details.

Trying to run npm run deploy:devnet i am getting the following error :
Error: Cannot find module '@aragon/templates-shared/truffle.js' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15) at Function.Module._load (internal/modules/cjs/loader.js:562:25) at Module.require (internal/modules/cjs/loader.js:690:17) at require (internal/modules/cjs/helpers.js:25:18) at Object.<anonymous> (/Users/rodrigoperez/Development/1Hive/dandelion-org/truffle.js:1:18) at Module._compile (internal/modules/cjs/loader.js:776:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3)

I think that the truffle.js is not being published

Current multisig template tests can only be run with geth. We should provide support for ganache as well. Additionally, there are multiple steps along the suite that can be simplified using some of the helpers provided in test-helpers and templates-shared.

The TemplatesDeployer currently hardcodes four parameters as the constructor parameters to each template.

We should loosen this to allow a user to describe their templates' own constructor parameters. For contracts that we deploy, like the test ENS and aragonID, we can export symbols and check for them.

The expected behaviour when dealing with a multisig is that only signers are allowed to propose new actions. BetaTemplateBase has the same permission for creating votes:

acl.createPermission(ANY_ENTITY, voting, voting.CREATE_VOTES_ROLE(), voting);

We decided to rename "DAO kit" to "template" so we can call them "Aragon templates", "organization templates", or simply, "templates".

Use the contract-helpers truffle package once release

Create a CONTRIBUTING.md file and contributor guidelines for this repo.

Would be nice to have it in a state where it's also updated to pragma 0.4.24. I don't think a redeployment on rinkeby is necessary though.

• Tokens
  • Non-changeable defaults: Non-transferable, uncapped, 18 decimals
• Voting
  • Non-changeable default: Controls minting and burning tokens
  • Changeable defaults: 50% relative support, 0% absolute support, 7 day duration
• Finance
  • Non-changeable defaults: 30 day budget duration
• Payroll: Enable opting out of its installation
  • Changeable defaults: Dai as denomination token (not changeable after initialization)

It's becoming more common for templates to pull from multiple aragonPM registries (e.g. aragonpm.eth and hatch.aragonpm.eth).

It would be nice to allow the user to specify the aragonPM instances they'd like created, and the registries that an app should be published onto.

Following the new BaseTemplate helpers, we should add support for the Payroll app

New templates introduce the usage of the Agent app in favor of the Vault app. We should allow the user to stay with the Vault app. We can introduce a new boolean to the templates interface to decide whether to install a Vault or an Agent app

There might be a problem when checking for multi-component parameters such as votingSettings in templates like company: https://github.com/aragon/dao-templates/blob/master/templates/company/contracts/CompanyTemplate.sol#L197

I believe that Web3 is always setting the length to 3 and filling it with zeroes, or something like that. To demonstrate, I set up an example, in which the last 2 tests fail: https://github.com/ajsantander/arraylen/blob/master/test/arraylen.test.js#L15

Seems like it could be a good way to avoid having to recreate kits if the DAOFactory changes over time.

Could be done in a similar manner to how the apps in the beta kits are fetched through aragonPM.

Hello,
Do you plan to create a template which can be started via the Aragon CLI to create Vuejs boilerplate application?

The comment in https://github.com/aragon/dao-kits/blob/master/kits/survey/contracts/SurveyKit.sol#L27 is a little bit precarious.

Hopefully should be as simple as require(_fac.regFactory == address(0))...

Membership template hangs after I create a DAO. It gets stuck on the "Launching your organization" screen. I am new to the project so I am not sure how to begin troubleshooting this issue.

Although we don't need it in our own templates, most other users of the helpers package will be first publishing their apps onto open.aragonpm.eth and therefore need to have their apps published on this registry locally when testing as well (to avoid having to change appIds between testing and real deployments).

Anyone who knows the URL of my organisation (it's blockchain so it's probably publicly visible) can create new votes.

These are the default settings:

I suggest only an account who owns a token in the organisation can create votes.

How did I discovered this issue?

I was testing the app and wanted to onboard some friends. Gave them instructions:

Visit: https://rinkeby.aragon.org
Open an existing organisation: foobar

I was planning to ask them for ETH address so that I could assign them tokens.

Realised that they can create an assignment themselves.

The process feels weird.

Real life analogy:
Onboarding at a company, it's the admin who creates [email protected]

Or is it me filling the form to HR?

What if HR is publicly open and anyone can submit the form?

All the templates we're providing implement this logic, we should be able to provide that from the BaseTemplate contract

Add some mock data so we can start testing the background script and integration with frontend.

New templates (reputation, membership, and both company templates) do not allow the user to specify some variables that should be customizable. These are:

• voting duration
• voting support
• voting acceptance
• finance period duration (use 0 for 30 days default)
• token name
• token symbol

Both multisig and democracy templates have a test gas script that are broken, they are importing a relative file ../index_local.js that doesn't exist.

Current templates are tested with a geth node, mainly used by the CI, using an Aragon's geth-devnet docker image. Tests are run relying on a previous step that basically waits until the gas limit of the node has increased to 8M gas. To avoid waiting time for that, we are committing the ethereum-data dir within the shared sub-repo. This dir will hold all the information related to the geth instance being run, thus files will be changing and git will keep tracking them.

We should improve this flow, either updating our geth image or exploring a painless way to deal with ethereum-data

Current BaseTemplate contract installs applications performing 2 transactions, one for the installation per se and another one to initialize the new app. We could leverage the install + initialization function of the Kernel to reduce gas costs

Current architecture lacks documentation, we should add/improve documentation of:

• Contracts inline documentation
• Helpers
• Deployment scripts
• Shared components
• Readme basic instructions (deploying templates, creating DAOs, publishing, etc)

"Democracy" implies a one member, one vote organization, whereas the democracy template is actually a one token, one vote organization. A better name for this would be "Token Democracy" template.

With a Token Wrapper instance (so projects can use their existing ERC20s) and an Agent instance.

Marketing claim: "Meet your new onlyOwner"

Current democracy template tests can only be run with geth. We should provide support for ganache as well. Additionally, there are multiple steps along the suite that can be simplified using some of the helpers provided in test-helpers and templates-shared.

• Tokens
  • Non-changeable defaults: Transferable, uncapped, 18 decimals
• Voting
  • Changeable defaults: 50% relative support, 0% absolute support, 7 day duration
• Finance
  • Non-changeable defaults: 30 day budget duration
• Payroll: Enable opting out of its installation
  • Changeable defaults: Dai as denomination token (not changeable after initialization)

Following the new BaseTemplate helpers, we should add support for the Survey app

Here and here.
Check that all of these worked:
https://github.com/aragon/dao-kits/blob/master/kits/multisig/contracts/MultisigKit.sol#L72
https://github.com/aragon/dao-kits/blob/master/kits/democracy/contracts/DemocracyKit.sol#L65
https://github.com/aragon/dao-kits/blob/master/kits/beta-base/contracts/BetaKitBase.sol#L140
https://github.com/aragon/dao-kits/blob/master/kits/beta-base/contracts/BetaKitBase.sol#L141

Run the tests against a client with the EVM under Istanbul consensus rules with an 8m gas limit to ensure that the templates will keep running as expected (everything that can be done in one transaction can still be done in one transaction)

Currently, it is possible to run tests against a ganache node, but you have to do all the set up manually. We can provide scripts to start a ganache node, deploy the template being tested, run the tests, and cleanup everything at the end.

• Tokens
  • Non-changeable defaults: Non-transferable, capped to 1 per address, 18 decimals
• Voting
  • Non-changeable default: Controls minting and burning tokens
  • Changeable defaults: 50% relative support, 0% absolute support, 7 day duration
• Finance
  • Non-changeable defaults: 30 day budget duration
• Payroll: Enable opting out of its installation
  • Changeable defaults: Dai as denomination token (not changeable after initialization)

The script currently registers each repo involved in the deployment process that was not already registered on the aragonPM registry by default. The particular line of code that does that: here

This is an issue cause the registration data is malformed and provoke the following RPC error: Error: Invalid JSON RPC response: ""

We do need to refactor the deployment scripts, there's code duplicated and they are not working flawless.

aragon/aragonOS#392 splits the roles of EVMScriptRegistry into two: REGISTRY_ADD_EXECUTOR_ROLE and REGISTRY_MANAGER_ROLE.

Now EVMScriptRegistryFactory completely removes permissions after setting it up. These permissions are too dangerous to leave uninitialized as anyone with the CREATE_PERMISSIONS_ROLE could create them at any time.

Kits should create the permissions for both roles and assign them to an entity with significant power (for beta kits, that would be the Voting app)