Add Reimbursement app #198
@ -21,8 +21,8 @@ contract Contribution is AragonApp {
|
||||
bytes32 public constant KERNEL_APP_ADDR_NAMESPACE = 0xd6f028ca0e8edb4a8c9757ca4fdccab25fa1e0317da1188108f7d2dee14902fb;
|
||||
|
||||
// ensure alphabetic order
|
||||
enum Apps { Contribution, Contributor, Proposal, Token }
|
||||
bytes32[4] public appIds;
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
bytes32[5] public appIds;
|
||||
|
||||
struct ContributionData {
|
||||
uint32 contributorId;
|
||||
@ -54,7 +54,7 @@ contract Contribution is AragonApp {
|
||||
event ContributionClaimed(uint32 id, uint32 indexed contributorId, uint32 amount);
|
||||
event ContributionVetoed(uint32 id, address vetoedByAccount);
|
||||
|
||||
function initialize(bytes32[4] _appIds) public onlyInit {
|
||||
function initialize(bytes32[5] _appIds) public onlyInit {
|
||||
appIds = _appIds;
|
||||
blocksToWait = 40320; // 7 days; 15 seconds block time
|
||||
initialized();
|
||||
|
||||
@ -28,14 +28,14 @@ contract Contributor is AragonApp {
|
||||
uint32 public contributorsCount;
|
||||
|
||||
// ensure alphabetic order
|
||||
enum Apps { Contribution, Contributor, Proposal, Token }
|
||||
bytes32[4] public appIds;
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
bytes32[5] public appIds;
|
||||
|
||||
event ContributorProfileUpdated(uint32 id, bytes32 oldHashDigest, bytes32 newHashDigest); // what should be logged
|
||||
event ContributorAccountUpdated(uint32 id, address oldAccount, address newAccount);
|
||||
event ContributorAdded(uint32 id, address account);
|
||||
|
||||
function initialize(address root,bytes32[4] _appIds) public onlyInit {
|
||||
function initialize(address root, bytes32[5] _appIds) public onlyInit {
|
||||
appIds = _appIds;
|
||||
|
||||
initialized();
|
||||
|
||||
@ -20,8 +20,8 @@ contract Proposal is AragonApp {
|
||||
|
||||
bytes32 public constant KERNEL_APP_ADDR_NAMESPACE = 0xd6f028ca0e8edb4a8c9757ca4fdccab25fa1e0317da1188108f7d2dee14902fb;
|
||||
// ensure alphabetic order
|
||||
enum Apps { Contribution, Contributor, Proposal, Token }
|
||||
bytes32[4] public appIds;
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
bytes32[5] public appIds;
|
||||
|
||||
struct Proposal {
|
||||
address creatorAccount;
|
||||
@ -46,7 +46,7 @@ contract Proposal is AragonApp {
|
||||
event ProposalVoted(uint32 id, uint32 voterId, uint16 totalVotes);
|
||||
event ProposalExecuted(uint32 id, uint32 contributorId, uint32 amount);
|
||||
|
||||
function initialize(bytes32[4] _appIds) public onlyInit {
|
||||
function initialize(bytes32[5] _appIds) public onlyInit {
|
||||
appIds = _appIds;
|
||||
initialized();
|
||||
}
|
||||
|
||||
1
apps/reimbursement/.gitattributes
vendored
Normal file
@ -0,0 +1 @@
|
||||
*.sol linguist-language=Solidity
|
||||
7
apps/reimbursement/.gitignore
vendored
Normal file
@ -0,0 +1,7 @@
|
||||
node_modules
|
||||
artifacts
|
||||
.cache
|
||||
cache
|
||||
dist
|
||||
ipfs.cmd
|
||||
package-lock.json
|
||||
34
apps/reimbursement/arapp.json
Normal file
@ -0,0 +1,34 @@
|
||||
{
|
||||
"roles": [
|
||||
{
|
||||
"name": "Add reimursements",
|
||||
"id": "ADD_REIMBURSEMENT_ROLE",
|
||||
"params": []
|
||||
},
|
||||
{
|
||||
"name": "Veto reimbursement",
|
||||
"id": "VETO_REIMBURSEMENT_ROLE",
|
||||
"params": []
|
||||
}
|
||||
],
|
||||
"environments": {
|
||||
"default": {
|
||||
"network": "development",
|
||||
"appName": "kredits-reimbursement.open.aragonpm.eth"
|
||||
},
|
||||
"rinkeby": {
|
||||
"registry": "0x98df287b6c145399aaa709692c8d308357bc085d",
|
||||
"appName": "kredits-reimbursement.open.aragonpm.eth",
|
||||
"wsRPC": "wss://rinkeby.eth.aragon.network/ws",
|
||||
"network": "rinkeby"
|
||||
},
|
||||
"production": {
|
||||
"registry": "0x314159265dd8dbb310642f98f50c066173c1259b",
|
||||
"appName": "kredits-reimbursement.aragonpm.eth",
|
||||
"wsRPC": "wss://mainnet.eth.aragon.network/ws",
|
||||
"network": "mainnet"
|
||||
}
|
||||
},
|
||||
"appName": "kredits-reimbursement.aragonpm.eth",
|
||||
"path": "contracts/Reimbursement.sol"
|
||||
}
|
||||
34
apps/reimbursement/buidler.config.js
Normal file
@ -0,0 +1,34 @@
|
||||
const { usePlugin } = require('@nomiclabs/buidler/config')
|
||||
const hooks = require('./scripts/buidler-hooks')
|
||||
|
||||
usePlugin('@aragon/buidler-aragon')
|
||||
|
||||
module.exports = {
|
||||
// Default Buidler configurations. Read more about it at https://buidler.dev/config/
|
||||
defaultNetwork: 'localhost',
|
||||
networks: {
|
||||
localhost: {
|
||||
url: 'http://localhost:8545',
|
||||
},
|
||||
},
|
||||
solc: {
|
||||
version: '0.4.24',
|
||||
optimizer: {
|
||||
enabled: true,
|
||||
runs: 10000,
|
||||
},
|
||||
},
|
||||
// Etherscan plugin configuration. Learn more at https://github.com/nomiclabs/buidler/tree/master/packages/buidler-etherscan
|
||||
etherscan: {
|
||||
apiKey: '', // API Key for smart contract verification. Get yours at https://etherscan.io/apis
|
||||
},
|
||||
// Aragon plugin configuration
|
||||
aragon: {
|
||||
appServePort: 8001,
|
||||
clientServePort: 3000,
|
||||
appSrcPath: 'app/',
|
||||
appBuildOutputPath: 'dist/',
|
||||
appName: 'expenses',
|
||||
hooks, // Path to script hooks
|
||||
},
|
||||
}
|
||||
119
apps/reimbursement/contracts/Reimbursement.sol
Normal file
@ -0,0 +1,119 @@
|
||||
|
|
||||
pragma solidity ^0.4.24;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
import "@aragon/os/contracts/apps/AragonApp.sol";
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
import "@aragon/os/contracts/kernel/IKernel.sol";
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
contract Reimbursement is AragonApp {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bytes32 public constant ADD_REIMBURSEMENT_ROLE = keccak256("ADD_REIMBURSEMENT_ROLE");
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bytes32 public constant VETO_REIMBURSEMENT_ROLE = keccak256("VETO_REIMBURSEMENT_ROLE");
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bytes32 public constant KERNEL_APP_ADDR_NAMESPACE = 0xd6f028ca0e8edb4a8c9757ca4fdccab25fa1e0317da1188108f7d2dee14902fb;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
// ensure alphabetic order
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bytes32[5] public appIds;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
struct ReimbursementData {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
address recipient;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint256 amount;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
address token;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bool claimed;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bytes32 hashDigest;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint8 hashFunction;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint8 hashSize;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint256 confirmedAtBlock;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bool vetoed;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
bool exists;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
mapping(uint32 => ReimbursementData) public reimbursements;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint32 public reimbursementsCount;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint32 public blocksToWait;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
event ReimbursementAdded(uint32 id, address indexed addedByAccont, uint256 amount);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
event ReimbursementClaimed(uint32 id, uint256 amount);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
event ReimbursementVetoed(uint32 id, address vetoedByAccount);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function initialize(bytes32[5] _appIds) public onlyInit {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
appIds = _appIds;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
blocksToWait = 40320; // 7 days; 15 seconds block time
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
initialized();
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function getContract(uint8 appId) public view returns (address) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
IKernel k = IKernel(kernel());
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
return k.getApp(KERNEL_APP_ADDR_NAMESPACE, appIds[appId]);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function totalAmount(bool confirmedOnly) public view returns (uint256 amount) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
for (uint32 i = 1; i <= reimbursementsCount; i++) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
ReimbursementData memory r = reimbursements[i];
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
if (!r.vetoed && (block.number >= r.confirmedAtBlock || !confirmedOnly)) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
amount += r.amount; // should use safemath
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function getReimbursement(uint32 reimbursementId) public view returns (uint32 id, address recipient, uint256 amount, address token, bool claimed, bytes32 hashDigest, uint8 hashFunction, uint8 hashSize, uint256 confirmedAtBlock, bool exists, bool vetoed) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
id = reimbursementId;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
ReimbursementData storage r = reimbursements[id];
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
return (
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
id,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.recipient,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.amount,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.token,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.claimed,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashDigest,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashFunction,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashSize,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.confirmedAtBlock,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.exists,
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.vetoed
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function add(uint256 amount, address token, bytes32 hashDigest, uint8 hashFunction, uint8 hashSize) public isInitialized auth(ADD_REIMBURSEMENT_ROLE) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
uint32 reimbursementId = reimbursementsCount + 1;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
ReimbursementData storage r = reimbursements[reimbursementId];
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.exists = true;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.amount = amount;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.token = token;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.claimed = false;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashDigest = hashDigest;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashFunction = hashFunction;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.hashSize = hashSize;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.confirmedAtBlock = block.number + blocksToWait;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
reimbursementsCount++;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
emit ReimbursementAdded(reimbursementId, msg.sender, amount);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function veto(uint32 reimbursementId) public isInitialized auth(VETO_REIMBURSEMENT_ROLE) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
ReimbursementData storage r = reimbursements[reimbursementId];
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(r.exists, 'NOT_FOUND');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(!r.claimed, 'ALREADY_CLAIMED');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(block.number < r.confirmedAtBlock, 'VETO_PERIOD_ENDED');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.vetoed = true;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
emit ReimbursementVetoed(reimbursementId, msg.sender);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function claim(uint32 reimbursementId) public isInitialized {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
ReimbursementData storage r = reimbursements[reimbursementId];
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(r.exists, 'NOT_FOUND');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(!r.claimed, 'ALREADY_CLAIMED');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(!r.vetoed, 'VETOED');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
require(block.number >= r.confirmedAtBlock, 'NOT_CLAIMABLE');
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
r.claimed = true;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
// TODO
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
// transfer using vault
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
emit ReimbursementClaimed(reimbursementId, r.amount);
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
function exists(uint32 reimbursementId) public view returns (bool) {
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
return reimbursements[reimbursementId].exists;
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
}
|
||||
(Although I'm not sure if something like ```suggestion
event ReimbursementAdded(uint32 id, address indexed addedByAccount, uint256 amount);
```
(Although I'm not sure if something like `submittedBy` isn't nicer for a name there.)
Maybe we should just call this Maybe we should just call this `get`, analog to `add` below?
I think until we actually have the financial code done, we should not add this function or the I think until we actually have the financial code done, we should not add this function or the `claimed` property. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).
yeah, thought about that, too. but we had yeah, thought about that, too. but we had `getContribution` in the contribution contract.
do you think that's the best pattern? :+1:
Yeah, I think it should be consistent, and Yeah, I think it should be consistent, and `contribution.add` is nicer for clients than `contribution.addContribution`. May as well imply the scope for all functions then. (We actually throw a deprecation warning for `addContribution` still. :))
|
||||
16
apps/reimbursement/manifest.json
Normal file
@ -0,0 +1,16 @@
|
||||
{
|
||||
"name": "kredits Reimbursement",
|
||||
"author": "Placeholder-author",
|
||||
"description": "An application for Aragon",
|
||||
"details_url": "/meta/details.md",
|
||||
"source_url": "https://<placeholder-repository-url>",
|
||||
"icons": [
|
||||
{
|
||||
"src": "/meta/icon.svg",
|
||||
"sizes": "56x56"
|
||||
}
|
||||
],
|
||||
"screenshots": [{ "src": "/meta/screenshot-1.png" }],
|
||||
"start_url": "/index.html",
|
||||
"script": "/script.js"
|
||||
}
|
||||
30
apps/reimbursement/package.json
Normal file
@ -0,0 +1,30 @@
|
||||
{
|
||||
"name": "kredits-reimbursement",
|
||||
"version": "1.0.0",
|
||||
"description": "",
|
||||
"scripts": {
|
||||
"start": "npm run start:aragon:ipfs",
|
||||
"start:aragon:ipfs": "aragon run",
|
||||
"start:aragon:http": "aragon run --http localhost:8001 --http-served-from ./dist",
|
||||
"start:app": "",
|
||||
"compile": "aragon contracts compile",
|
||||
"sync-assets": "",
|
||||
"build:app": "",
|
||||
"build:script": "",
|
||||
"build": "",
|
||||
"publish:patch": "aragon apm publish patch",
|
||||
"publish:minor": "aragon apm publish minor",
|
||||
"publish:major": "aragon apm publish major",
|
||||
"versions": "aragon apm versions",
|
||||
"test": "truffle test"
|
||||
},
|
||||
"dependencies": {
|
||||
"@aragon/os": "^4.4.0"
|
||||
},
|
||||
"devDependencies": {
|
||||
"@aragon/test-helpers": "^2.1.0",
|
||||
"eth-gas-reporter": "^0.2.17",
|
||||
"ganache-cli": "^6.9.1",
|
||||
"solidity-coverage": "^0.5.11"
|
||||
}
|
||||
}
|
||||
61
apps/reimbursement/test/helpers/dao.js
Normal file
@ -0,0 +1,61 @@
|
||||
const { hash } = require('eth-ens-namehash')
|
||||
const { getEventArgument } = require('@aragon/contract-test-helpers/events')
|
||||
const Kernel = artifacts.require('@aragon/os/build/contracts/kernel/Kernel')
|
||||
const ACL = artifacts.require('@aragon/os/build/contracts/acl/ACL')
|
||||
const EVMScriptRegistryFactory = artifacts.require(
|
||||
'@aragon/os/build/contracts/factory/EVMScriptRegistryFactory'
|
||||
)
|
||||
const DAOFactory = artifacts.require(
|
||||
'@aragon/os/build/contracts/factory/DAOFactory'
|
||||
)
|
||||
|
||||
const newDao = async (rootAccount) => {
|
||||
// Deploy a DAOFactory.
|
||||
const kernelBase = await Kernel.new(true)
|
||||
const aclBase = await ACL.new()
|
||||
const registryFactory = await EVMScriptRegistryFactory.new()
|
||||
const daoFactory = await DAOFactory.new(
|
||||
kernelBase.address,
|
||||
aclBase.address,
|
||||
registryFactory.address
|
||||
)
|
||||
|
||||
// Create a DAO instance.
|
||||
const daoReceipt = await daoFactory.newDAO(rootAccount)
|
||||
const dao = await Kernel.at(getEventArgument(daoReceipt, 'DeployDAO', 'dao'))
|
||||
|
||||
// Grant the rootAccount address permission to install apps in the DAO.
|
||||
const acl = await ACL.at(await dao.acl())
|
||||
const APP_MANAGER_ROLE = await kernelBase.APP_MANAGER_ROLE()
|
||||
await acl.createPermission(
|
||||
rootAccount,
|
||||
dao.address,
|
||||
APP_MANAGER_ROLE,
|
||||
rootAccount,
|
||||
{ from: rootAccount }
|
||||
)
|
||||
|
||||
return { dao, acl }
|
||||
}
|
||||
|
||||
const newApp = async (dao, appName, baseAppAddress, rootAccount) => {
|
||||
const receipt = await dao.newAppInstance(
|
||||
hash(`${appName}.aragonpm.test`), // appId - Unique identifier for each app installed in the DAO; can be any bytes32 string in the tests.
|
||||
baseAppAddress, // appBase - Location of the app's base implementation.
|
||||
'0x', // initializePayload - Used to instantiate and initialize the proxy in the same call (if given a non-empty bytes string).
|
||||
false, // setDefault - Whether the app proxy is the default proxy.
|
||||
{ from: rootAccount }
|
||||
)
|
||||
|
||||
// Find the deployed proxy address in the tx logs.
|
||||
const logs = receipt.logs
|
||||
const log = logs.find((l) => l.event === 'NewAppProxy')
|
||||
const proxyAddress = log.args.proxy
|
||||
|
||||
return proxyAddress
|
||||
}
|
||||
|
||||
module.exports = {
|
||||
newDao,
|
||||
newApp,
|
||||
}
|
||||
17
apps/reimbursement/test/helpers/permissions.js
Normal file
@ -0,0 +1,17 @@
|
||||
const ANY_ADDRESS = '0xffffffffffffffffffffffffffffffffffffffff'
|
||||
|
||||
const setOpenPermission = async (acl, appAddress, role, rootAddress) => {
|
||||
// Note: Setting a permission to 0xffffffffffffffffffffffffffffffffffffffff
|
||||
// is interpreted by aragonOS as allowing the role for any address.
|
||||
await acl.createPermission(
|
||||
ANY_ADDRESS, // entity (who?) - The entity or address that will have the permission.
|
||||
appAddress, // app (where?) - The app that holds the role involved in this permission.
|
||||
role, // role (what?) - The particular role that the entity is being assigned to in this permission.
|
||||
rootAddress, // manager - Can grant/revoke further permissions for this role.
|
||||
{ from: rootAddress}
|
||||
)
|
||||
}
|
||||
|
||||
module.exports = {
|
||||
setOpenPermission
|
||||
}
|
||||
1
apps/reimbursement/truffle.js
Normal file
@ -0,0 +1 @@
|
||||
module.exports = require("../../truffle.js");
|
||||
8716
apps/reimbursement/yarn.lock
Normal file
@ -7,12 +7,12 @@ contract Token is ERC20Token, AragonApp {
|
||||
bytes32 public constant MINT_TOKEN_ROLE = keccak256("MINT_TOKEN_ROLE");
|
||||
|
||||
// ensure alphabetic order
|
||||
enum Apps { Contribution, Contributor, Proposal, Token }
|
||||
bytes32[4] public appIds;
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
bytes32[5] public appIds;
|
||||
|
||||
event LogMint(address indexed recipient, uint256 amount, uint32 contributionId);
|
||||
|
||||
function initialize(bytes32[4] _appIds) public onlyInit {
|
||||
function initialize(bytes32[5] _appIds) public onlyInit {
|
||||
appIds = _appIds;
|
||||
name = 'Kredits';
|
||||
symbol = '₭S';
|
||||
|
||||
@ -38,6 +38,8 @@ const contractCalls = [
|
||||
['Contribution', 'add', [{ contributorId: 1, contributorIpfsHash: 'QmWKCYGr2rSf6abUPaTYqf98urvoZxGrb7dbspFZA6oyVF', date: '2019-04-11', amount: 5000, kind: 'dev', description: '[67P/kredits-contracts] Introduce contribution token', url: '' }, { gasLimit: 350000 }]],
|
||||
['Contribution', 'add', [{ contributorId: 2, contributorIpfsHash: 'QmcHzEeAM26HV2zHTf5HnZrCtCtGdEccL5kUtDakAB7ozB', date: '2019-04-11', amount: 1500, kind: 'dev', description: '[67P/kredits-web] Reviewed stuff', url: '' }, { gasLimit: 350000 }]],
|
||||
['Contribution', 'claim', [1, { gasLimit: 300000 }]],
|
||||
|
||||
['Reimbursement', 'add', [{title: 'Server Hosting', description: 'All the serverz', amount: 1, token: '0xa3048576e296207eb0141f2803590ad044f81928', currency: 'WBTC', date: '2020-05-28'}, { gasLimit: 300000 }]],
|
||||
];
|
||||
|
||||
const funds = [
|
||||
|
||||
@ -10,17 +10,18 @@ import "../apps/contribution/contracts/Contribution.sol";
|
||||
import "../apps/contributor/contracts/Contributor.sol";
|
||||
import "../apps/token/contracts/Token.sol";
|
||||
import "../apps/proposal/contracts/Proposal.sol";
|
||||
import "../apps/reimbursement/contracts/Reimbursement.sol";
|
||||
|
||||
contract KreditsKit is KitBase {
|
||||
|
||||
// ensure alphabetic order
|
||||
enum Apps { Contribution, Contributor, Proposal, Token }
|
||||
bytes32[4] public appIds;
|
||||
enum Apps { Contribution, Contributor, Proposal, Reimbursement, Token }
|
||||
bytes32[5] public appIds;
|
||||
|
||||
event DeployInstance(address dao);
|
||||
event InstalledApp(address dao, address appProxy, bytes32 appId);
|
||||
|
||||
constructor (DAOFactory _fac, ENS _ens, bytes32[4] _appIds) public KitBase(_fac, _ens) {
|
||||
constructor (DAOFactory _fac, ENS _ens, bytes32[5] _appIds) public KitBase(_fac, _ens) {
|
||||
appIds = _appIds;
|
||||
}
|
||||
|
||||
@ -41,13 +42,18 @@ contract KreditsKit is KitBase {
|
||||
Contribution contribution = Contribution(_installApp(dao, appIds[uint8(Apps.Contribution)]));
|
||||
contribution.initialize(appIds);
|
||||
|
||||
Proposal proposal = Proposal(_installApp(dao, appIds[uint8(Apps.Proposal)]));
|
||||
proposal.initialize(appIds);
|
||||
|
||||
acl.createPermission(root, contribution, contribution.ADD_CONTRIBUTION_ROLE(), this);
|
||||
acl.createPermission(root, contribution, contribution.VETO_CONTRIBUTION_ROLE(), this);
|
||||
acl.grantPermission(proposal, contribution, contribution.ADD_CONTRIBUTION_ROLE());
|
||||
|
||||
Proposal proposal = Proposal(_installApp(dao, appIds[uint8(Apps.Proposal)]));
|
||||
proposal.initialize(appIds);
|
||||
|
||||
Reimbursement reimbursement = Reimbursement(_installApp(dao, appIds[uint8(Apps.Reimbursement)]));
|
||||
reimbursement.initialize(appIds);
|
||||
acl.createPermission(root, reimbursement, reimbursement.ADD_REIMBURSEMENT_ROLE(), this);
|
||||
acl.createPermission(root, reimbursement, reimbursement.VETO_REIMBURSEMENT_ROLE(), this);
|
||||
|
||||
uint256[] memory params = new uint256[](1);
|
||||
params[0] = uint256(203) << 248 | uint256(1) << 240 | uint240(contributor);
|
||||
acl.grantPermissionP(acl.ANY_ENTITY(), contribution, contribution.ADD_CONTRIBUTION_ROLE(), params);
|
||||
@ -67,6 +73,8 @@ contract KreditsKit is KitBase {
|
||||
acl.setPermissionManager(root, contribution, contribution.ADD_CONTRIBUTION_ROLE());
|
||||
acl.setPermissionManager(root, contribution, contribution.VETO_CONTRIBUTION_ROLE());
|
||||
acl.setPermissionManager(root, contributor, contributor.MANAGE_CONTRIBUTORS_ROLE());
|
||||
acl.setPermissionManager(root, reimbursement, reimbursement.ADD_REIMBURSEMENT_ROLE());
|
||||
acl.setPermissionManager(root, reimbursement, reimbursement.VETO_REIMBURSEMENT_ROLE());
|
||||
|
||||
acl.createPermission(root, token, token.MINT_TOKEN_ROLE(), this);
|
||||
acl.grantPermission(contribution, token, token.MINT_TOKEN_ROLE());
|
||||
|
||||
1
lib/abis/Reimbursement.json
Normal file
@ -1,4 +1,5 @@
|
||||
|
Are these supposed to be committed? Are these supposed to be committed?
Are these supposed to be committed? Are these supposed to be committed?
arg, noo. of course not. arg, noo. of course not.
arg, noo. of course not. arg, noo. of course not.
```suggestion
"4": "0x76e069b47b79442657eaf0555a32c6b16fa1b8b4"
```
```suggestion
"4": "0x76e069b47b79442657eaf0555a32c6b16fa1b8b4"
```
|
||||
{
|
||||
"4": "0x76e069b47b79442657eaf0555a32c6b16fa1b8b4",
|
||||
"8653663": "0x0Dd2b0F3F8Cba588fa865abf289594e2cfE30995",
|
||||
|
Are these supposed to be committed? Are these supposed to be committed?
arg, noo. of course not. arg, noo. of course not.
```suggestion
"4": "0x76e069b47b79442657eaf0555a32c6b16fa1b8b4"
```
|
||||
"18335577": "0xeE10a87d8D758B563E301F5C5d029bDD21166DCC"
|
||||
}
|
||||
@ -1,4 +1,5 @@
|
||||
```suggestion
"4": "0xc34edf7d11b7f8433d597f0bb0697acdff55ef14"
```
```suggestion
"4": "0xc34edf7d11b7f8433d597f0bb0697acdff55ef14"
```
|
||||
{
|
||||
"4": "0xc34edf7d11b7f8433d597f0bb0697acdff55ef14",
|
||||
"8653663": "0x1F65f1E2d293c7773811b7016987f51683881703",
|
||||
```suggestion
"4": "0xc34edf7d11b7f8433d597f0bb0697acdff55ef14"
```
|
||||
"18335577": "0x29E33B66108fa2DC3a018f3DdE41D295eB0922D5"
|
||||
}
|
||||
@ -3,6 +3,7 @@ module.exports = {
|
||||
Contribution: require('./contribution'),
|
||||
Proposal: require('./proposal'),
|
||||
Token: require('./token'),
|
||||
Reimbursement: require('./reimbursement'),
|
||||
Kernel: require('./kernel'),
|
||||
Acl: require('./acl'),
|
||||
};
|
||||
|
||||
45
lib/contracts/reimbursement.js
Normal file
@ -0,0 +1,45 @@
|
||||
const Record = require('./record');
|
||||
const ExpenseSerializer = require('../serializers/expense');
|
||||
|
||||
class Reimbursement extends Record {
|
||||
get count () {
|
||||
return this.functions.reimbursementsCount();
|
||||
}
|
||||
|
||||
getById (id) {
|
||||
return this.functions.getReimbursement(id)
|
||||
.then(data => {
|
||||
return this.ipfs.catAndMerge(data, ExpenseSerializer.deserialize);
|
||||
});
|
||||
}
|
||||
|
||||
getData (id) {
|
||||
return this.functions.getReimbursement(id);
|
||||
}
|
||||
|
||||
async add (attrs, callOptions = {}) {
|
||||
const reimbursement = new ExpenseSerializer(attrs);
|
||||
|
||||
try { await reimbursement.validate(); }
|
||||
catch (error) { return Promise.reject(error); }
|
||||
|
||||
const jsonStr = reimbursement.serialize();
|
||||
|
||||
return this.ipfs
|
||||
.add(jsonStr)
|
||||
.then(ipfsHashAttr => {
|
||||
let reimbursement = [
|
||||
attrs.amount,
|
||||
attrs.token,
|
||||
ipfsHashAttr.hashDigest,
|
||||
ipfsHashAttr.hashFunction,
|
||||
ipfsHashAttr.hashSize,
|
||||
];
|
||||
|
||||
console.log(reimbursement)
|
||||
return this.functions.add(...reimbursement, callOptions);
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = Reimbursement;
|
||||
@ -6,6 +6,7 @@ const deprecate = require('./utils/deprecate');
|
||||
const ABIS = {
|
||||
Contributor: require('./abis/Contributor.json'),
|
||||
Contribution: require('./abis/Contribution.json'),
|
||||
Reimbursement: require('./abis/Reimbursement.json'),
|
||||
Token: require('./abis/Token.json'),
|
||||
Proposal: require('./abis/Proposal.json'),
|
||||
Kernel: require('./abis/Kernel.json'),
|
||||
@ -16,6 +17,7 @@ const APP_CONTRACTS = [
|
||||
'Contribution',
|
||||
'Token',
|
||||
'Proposal',
|
||||
'Reimbursement',
|
||||
'Acl',
|
||||
];
|
||||
const DaoAddresses = require('./addresses/dao.json');
|
||||
@ -121,6 +123,10 @@ class Kredits {
|
||||
return this.contractFor('Contribution');
|
||||
}
|
||||
|
||||
get Reimbursement () {
|
||||
return this.contractFor('Reimbursement');
|
||||
}
|
||||
|
||||
get Acl () {
|
||||
return this.contractFor('Acl');
|
||||
}
|
||||
|
||||
@ -29,7 +29,7 @@ class KreditsKit {
|
||||
|
||||
appIdFor (contractName) {
|
||||
// see appIds in KreditsKit.sol for more details
|
||||
const knownContracts = ['Contribution', 'Contributor', 'Proposal', 'Token'];
|
||||
const knownContracts = ['Contribution', 'Contributor', 'Proposal', 'Reimbursement', 'Token'];
|
||||
return this.contract.functions.appIds(knownContracts.indexOf(contractName));
|
||||
}
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
const schemas = require('kosmos-schemas');
|
||||
const schemas = require('@kosmos/schemas');
|
||||
const validator = require('../utils/validator');
|
||||
|
||||
/**
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
const schemas = require('kosmos-schemas');
|
||||
const schemas = require('@kosmos/schemas');
|
||||
const validator = require('../utils/validator');
|
||||
/**
|
||||
* Handle serialization for JSON-LD object of the contributor, according to
|
||||
|
||||
98
lib/serializers/expense.js
Normal file
@ -0,0 +1,98 @@
|
||||
let schemas = require('@kosmos/schemas');
|
||||
schemas['expense'] = require('@kosmos/schemas/schemas/expense.json');
|
||||
const validator = require('../utils/validator');
|
||||
|
||||
/**
|
||||
* Serialization and validation for JSON-LD document of the Expense
|
||||
*
|
||||
* @class
|
||||
* @public
|
||||
*/
|
||||
class Expense {
|
||||
|
||||
constructor (attrs) {
|
||||
Object.keys(attrs).forEach(a => this[a] = attrs[a]);
|
||||
}
|
||||
|
||||
/**
|
||||
* Serialize object to JSON
|
||||
*
|
||||
* @public
|
||||
*/
|
||||
serialize () {
|
||||
let {
|
||||
title,
|
||||
description,
|
||||
currency,
|
||||
amount,
|
||||
date,
|
||||
url,
|
||||
tags,
|
||||
details,
|
||||
} = this;
|
||||
|
||||
let data = {
|
||||
'@context': 'https://schema.kosmos.org',
|
||||
'@type': 'Expense',
|
||||
title,
|
||||
description,
|
||||
currency,
|
||||
amount,
|
||||
date,
|
||||
'tags': tags || [],
|
||||
'details': details || {},
|
||||
};
|
||||
|
||||
if (url) {
|
||||
data['url'] = url;
|
||||
}
|
||||
|
||||
// Write it pretty to ipfs
|
||||
return JSON.stringify(data, null, 2);
|
||||
}
|
||||
|
||||
/**
|
||||
* Validate serialized data against schema
|
||||
*
|
||||
* @public
|
||||
*/
|
||||
validate () {
|
||||
const serialized = JSON.parse(this.serialize());
|
||||
console.log(schemas['expense']);
|
||||
const valid = validator.validate(serialized, schemas['expense']);
|
||||
return valid ? Promise.resolve() : Promise.reject(validator.error);
|
||||
}
|
||||
|
||||
/**
|
||||
* Deserialize JSON to object
|
||||
*
|
||||
* @public
|
||||
*/
|
||||
static deserialize (serialized) {
|
||||
let {
|
||||
title,
|
||||
description,
|
||||
currency,
|
||||
amount,
|
||||
date,
|
||||
url,
|
||||
tags,
|
||||
details,
|
||||
} = JSON.parse(serialized.toString('utf8'));
|
||||
|
||||
return {
|
||||
title,
|
||||
description,
|
||||
currency,
|
||||
amount,
|
||||
date,
|
||||
url,
|
||||
tags,
|
||||
details,
|
||||
ipfsData: serialized,
|
||||
};
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
module.exports = Expense;
|
||||
16
package-lock.json
generated
@ -97,6 +97,14 @@
|
||||
}
|
||||
}
|
||||
},
|
||||
"@kosmos/schemas": {
|
||||
"version": "2.2.1",
|
||||
"resolved": "https://registry.npmjs.org/@kosmos/schemas/-/schemas-2.2.1.tgz",
|
||||
"integrity": "sha512-zYUctQ91sYhzoJ0ujO73odBSsnwvdLlS6ENA/U/4/IzRKVZBj9cS4RpgFh1xOQXNN+HB4pUu8u7Su/Xtked+vg==",
|
||||
"requires": {
|
||||
"brfs-babel": "^1.0.0"
|
||||
}
|
||||
},
|
||||
"@resolver-engine/core": {
|
||||
"version": "0.2.1",
|
||||
"resolved": "https://registry.npmjs.org/@resolver-engine/core/-/core-0.2.1.tgz",
|
||||
@ -4888,14 +4896,6 @@
|
||||
"graceful-fs": "^4.1.9"
|
||||
}
|
||||
},
|
||||
"kosmos-schemas": {
|
||||
"version": "2.2.1",
|
||||
"resolved": "https://registry.npmjs.org/kosmos-schemas/-/kosmos-schemas-2.2.1.tgz",
|
||||
"integrity": "sha512-bZRbwLmJVeaaLqIyJsHbUf7wCjgHP2IhKXH12fD5+1tcw6/bdtZF4nZ41SoVCmdnZnSXh6Fv8nIRT0HksSlj8w==",
|
||||
"requires": {
|
||||
"brfs-babel": "^1.0.0"
|
||||
}
|
||||
},
|
||||
"ky": {
|
||||
"version": "0.15.0",
|
||||
"resolved": "https://registry.npmjs.org/ky/-/ky-0.15.0.tgz",
|
||||
|
||||
@ -62,7 +62,7 @@
|
||||
"dependencies": {
|
||||
"ethers": "^4.0.47",
|
||||
"ipfs-http-client": "^41.0.1",
|
||||
"kosmos-schemas": "^2.2.1",
|
||||
"@kosmos/schemas": "^2.2.1",
|
||||
"node-fetch": "^2.6.0",
|
||||
"tv4": "^1.3.0"
|
||||
},
|
||||
|
||||
@ -11,6 +11,7 @@ const files = [
|
||||
'Kernel',
|
||||
'Proposal',
|
||||
'Token',
|
||||
'Reimbursement',
|
||||
'ACL'
|
||||
];
|
||||
|
||||
|
||||
54
scripts/list-reimbursements.js
Normal file
@ -0,0 +1,54 @@
|
||||
const promptly = require('promptly');
|
||||
const Table = require('cli-table');
|
||||
|
||||
const initKredits = require('./helpers/init_kredits.js');
|
||||
|
||||
module.exports = async function(callback) {
|
||||
let kredits;
|
||||
try {
|
||||
kredits = await initKredits(web3);
|
||||
} catch(e) {
|
||||
callback(e);
|
||||
return;
|
||||
}
|
||||
|
||||
console.log(`Using Reimbursement at: ${kredits.Reimbursement.contract.address}`);
|
||||
|
||||
const table = new Table({
|
||||
head: ['ID', 'Title', 'Description', 'Amount', 'Token', 'Recipent', 'Confirmed?', 'Vetoed?', 'Claimed?', 'IPFS']
|
||||
})
|
||||
|
||||
try {
|
||||
let blockNumber = await kredits.provider.getBlockNumber();
|
||||
let reimbursements = await kredits.Reimbursement.all({page: {size: 1000}});
|
||||
|
||||
let kreditsSum = 0;
|
||||
console.log(`Current block number: ${blockNumber}`);
|
||||
reimbursements.forEach((r) => {
|
||||
const confirmed = r.confirmedAtBlock <= blockNumber;
|
||||
|
||||
table.push([
|
||||
r.id.toString(),
|
||||
`${r.title}`,
|
||||
`${r.description}`,
|
||||
r.amount.toString(),
|
||||
`${r.token}`,
|
||||
`${r.recipient}`,
|
||||
`${confirmed} (${r.confirmedAtBlock})`,
|
||||
r.vetoed,
|
||||
r.claimed,
|
||||
r.ipfsHash
|
||||
])
|
||||
});
|
||||
|
||||
console.log(table.toString());
|
||||
|
||||
let totalAmountUnconfirmed = await kredits.Reimbursement.functions.totalAmount(false);
|
||||
let totalAmountConfirmed = await kredits.Reimbursement.functions.totalAmount(true);
|
||||
console.log(`Total: ${totalAmountConfirmed} (confirmed) | ${totalAmountUnconfirmed} (including unconfirmed)`);
|
||||
} catch (err) {
|
||||
console.log(err);
|
||||
}
|
||||
|
||||
callback();
|
||||
}
|
||||
(Although I'm not sure if something like
submittedByisn't nicer for a name there.)(Although I'm not sure if something like
submittedByisn't nicer for a name there.)Maybe we should just call this
get, analog toaddbelow?Maybe we should just call this
get, analog toaddbelow?I think until we actually have the financial code done, we should not add this function or the
claimedproperty. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).I think until we actually have the financial code done, we should not add this function or the
claimedproperty. Both because it will actually be out of sync with what we actually send around from the Gnosis safe, and also because we may want to adopt a different approach here as well (probably similar to the contributions, and maybe even combined with dividend payouts, so you only pay for a single tx when withdrawing everything at once).yeah, thought about that, too. but we had
getContributionin the contribution contract.do you think that's the best pattern? 👍
yeah, thought about that, too. but we had
getContributionin the contribution contract.do you think that's the best pattern? 👍
Yeah, I think it should be consistent, and
contribution.addis nicer for clients thancontribution.addContribution. May as well imply the scope for all functions then. (We actually throw a deprecation warning foraddContributionstill. :))Yeah, I think it should be consistent, and
contribution.addis nicer for clients thancontribution.addContribution. May as well imply the scope for all functions then. (We actually throw a deprecation warning foraddContributionstill. :))