New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add payroll app to all templates #124
Conversation
…parameters occur first
Left a few comments, would you mind updating this branch with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, we can work out some improvements for the tests later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looked at the company template's changes, since the other template changes are quite similar.
A couple suggestions :)
templates/trust/package.json
Outdated
@@ -43,6 +43,7 @@ | |||
"@aragon/apps-agent": "^1.0.0", | |||
"@aragon/apps-vault": "^4.1.0", | |||
"@aragon/apps-voting": "^2.1.0", | |||
"@aragon/apps-payroll": "^1.0.0-rc.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think we need this dependency here 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's something weird going on, if that dependency isn't there, Trust doesn't compile. Or at least that was the case with the CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I see, the contract resolution algorithm is a bit tricky with how npm works (and it's why we can't hoist contracts when using lerna).
Not sure if truffle@5 has made any inroads to fixing this, but for now I've moved the unused apps into the dev dependencies.
address denominationToken = _toAddress(_payrollSettings[0]); | ||
IFeed priceFeed = IFeed(_toAddress(_payrollSettings[1])); | ||
uint64 rateExpiryTime = _payrollSettings[2].toUint64(); | ||
address employeeManager = _toAddress(_payrollSettings[3]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One small thing is perhaps doing this coercion at the start of newInstance()
instead, so the user doesn't waste gas creating an entire org before their input fails here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my summary comment bellow
I've been wasting a lot of time dealing with Note that the code looks completely awkward due to how we need to load from storage, pass by argument, and the rest of ticks and tricks that we needed to do to avoid compiling issues, it definitely won't look good for inexperienced users as an example of how to build a template :/ |
@facuspagnuolo IDEA: What about implementing a very simple system in which any template can be initialized with 2 transactions, no matter how basic or complex it is. tx 1) The user deploys a "configuration contract" that simply holds state in a bunch of public variables that can be read later by a template being initialized. tx 2) The template's initialize function, instead of getting its settings from parameters in a function call, retrieves them from the configuration contract by reading state. The template could even selfdestruct the configuration contract, getting a bit of gas refunded. The configuration contract could also contain booleans like "installPayrollApp", so that much of the modular functionality of installing a particular combination of apps could be abstracted to the BaseTemplate, making templates even simpler to read and understand. |
const ONE_DAY = 60 * 60 * 24 | ||
const ONE_WEEK = ONE_DAY * 7 | ||
const THIRTY_DAYS = ONE_DAY * 30 | ||
const TWO_MONTHS = ONE_DAY * 31 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit misleading; perhaps MORE_THAN_ONE_MONTH
would be clearer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohhh, it definitely should be ONE_MONTH
|
||
function _setupPermissions(Voting _shareVoting, TokenManager _shareTokenManager, Vault _agentOrVault, Finance _finance, bool _useAgentAsVault) internal returns (Voting) { | ||
Kernel dao = _fetchDaoCache(); | ||
ACL _acl = ACL(dao.acl()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we name this as just acl
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup
{ | ||
Kernel dao = _popDaoCache(msg.sender); | ||
_setupApps(dao, _boardMembers, _shareHolders, _shareStakes, _boardVotingSettings, _shareVotingSettings, _financePeriod, _useAgentAsVault); | ||
function setupShare(string _id, address[] _holders, uint256[] _stakes, uint64[3] _votingSettings, uint64 _financePeriod, bool _useAgentAsVault) external { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand it correctly now, the flow is:
prepareInstance()
setupBoard()
setupShare()
Is it not possible to combine prepareInstance()
with setupBoard()
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be possible since they cost 5e6 and 1.3e6 respectively, which means they should fit in a single tx
templates/trust/package.json
Outdated
@@ -43,6 +43,7 @@ | |||
"@aragon/apps-agent": "^1.0.0", | |||
"@aragon/apps-vault": "^4.1.0", | |||
"@aragon/apps-voting": "^2.1.0", | |||
"@aragon/apps-payroll": "^1.0.0-rc.1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I see, the contract resolution algorithm is a bit tricky with how npm works (and it's why we can't hoist contracts when using lerna).
Not sure if truffle@5 has made any inroads to fixing this, but for now I've moved the unused apps into the dev dependencies.
Would ABI encoder V2 help with the stack issues? There's probably not too much we can do on that regard since we only get 16 slots?
I'm not sure if this would be cheaper than just passing along arguments; the main benefit I see with deploying a configuration contract (or writing to a global, shared one), would be ease of recovering if you only sent 1 / 3 transactions during onboarding or etc. |
@facuspagnuolo I've pushed a few commits that are mostly cosmetic / small fixes. Looking into changing the initialization structure of the company with board template (#124 (comment)) to see if I can come up with something more intuitive :). |
I made a quick experiment in remix to see if a configuration contract would help with the stack too deep problem, and it looks like the technique produces the errors even sooner than when using plain old function parameters. If you want to have a look and play with it yourselves: https://remix.ethereum.org/#version=soljson-v0.5.1+commit.c8a2cb62.js&optimize=false&gist=17461f2c1dbd9edb598acba1a46ea412 |
That is definitely not a good sign for the configuration contract... it's probably because doing a call involves quite a lot of stack variables. |
🚧 WIP 🚧
Tasks