(Feature) [Spending Limit] List of beneficiaries#1261
(Feature) [Spending Limit] List of beneficiaries#1261fernandomg merged 80 commits intofeature/#413-SpendingLimit-in-appfrom
Conversation
- marked `isValid` as optional, with default `true` value - marked `initialValue` as optional - migrated to hooks for material-ui styles
- migrated to hooks for material-ui styles - make `label` parametrized and optional, with default value - make `setIsValidAddress` optional
- migrated to hooks for material-ui styles
…w-SpendingLimit # Conflicts: # src/routes/safe/components/Apps/index.tsx
Also: - fixed styles - handled form state while going back and forth between create and review - had to change `Review` Button as submitting wasn't triggered on the first click.
- also refactored `ScanQRWrapper` so it uses the specified icon
…w-SpendingLimit # Conflicts: # package.json # src/routes/safe/components/Apps/index.tsx # yarn.lock
- if the module is not enabled it will be enabled on the first tx - beneficiary is added to the delegate list in the contract - allowance is set Still several things to address, like informing the user about an existing allowance, code cleanup
- create - verify existent and inform the user
…dingLimit state issue
…m multiSend txs - Added notifications messages (this is extremely verbose, not sure if I should only use the Settings messages)
|
Travis automatic deployment: |
|
Travis automatic deployment: |
1 similar comment
|
Travis automatic deployment: |
…ist-SpendingLimit
|
Travis automatic deployment: |
@lukasschor, ah. I just tried to be aligned with the owners' table. Starting with the long-shortened view and shrinking to If it's not valid, then I'll definitively remove those behaviors. |
|
We should generally move to standardize the addresses and either show full length or abbreviated with 4 chars (which should be the default, full address should only be an exception). We have started doing so here: #1174 |
|
Travis automatic deployment: |
|
We should not display "UNKNOWN" for addresses where there is no address book entry. See this ticket for reference: #1068 UPDATE: It seems like this is already the case, right? At least when I tested it did not show UNKNOWN. |
| export const TIMEOUT = process.env.NODE_ENV === 'test' ? 1500 : 5000 | ||
| export const ETHERSCAN_API_KEY = process.env.REACT_APP_ETHERSCAN_API_KEY | ||
| export const SPENDING_LIMIT_MODULE_ADDRESS = | ||
| process.env.REACT_APP_SPENDING_LIMIT_MODULE_ADDRESS || '0x9e9Bf12b5a66c0f0A7435835e0365477E121B110' |
There was a problem hiding this comment.
This address should be named. I understand this is something will be removed later
There was a problem hiding this comment.
exactly, this is there to make the feature work while on dev, as the variable is not set in the CI builds
There was a problem hiding this comment.
I created a task in [Backlog] - Stability saying that this should be reviewed before deployment
|
Travis automatic deployment: |
|
Travis automatic deployment: |
…ist-SpendingLimit # Conflicts: # package.json # src/logic/safe/store/actions/fetchSafe.ts # src/routes/safe/components/Layout/index.tsx # yarn.lock
ESLint Summary View Full Report
Report generated by eslint-plus-action |
|
Travis automatic deployment: |


This PR closes #1039, by listing the beneficiaries and its spending limits.
Also, closes #692, by allowing the limit removal.
Also, will wait for this PR complete feedback to properly close #690.
Still WIP.Refactored the code, for better organization. It's almost all contained in the
src/routes/safe/components/Settings/SpendingLimitdirectory, as a first iteration I think it's ok and helps to find patterns and improvement points easily.Some tweaks around tx creation: it'll be using
multiSendtxs only when it's needed (enable SpendingLimit module or adding a new delegate)