Repository navigation
feat(APP-1165): Add native Safe governance proposals - #1437
thekidnamedkd wants to merge 8 commits into
Conversation
|
🚀 Preview Deployment: View Here |
|
E2E results (preview) Smoke
|
thekidnamedkd
changed the title
milosh86
left a comment
milosh86
left a comment
There was a problem hiding this comment.
just a couple of comments for now, I have more to check
| link: `${baseUrl}/members`, | ||
| icon: IconType.APP_MEMBERS, | ||
| hidden: !(isSupported && hasBodyPlugin), | ||
| hidden: !(isSupported && (hasBodyPlugin || hasSafeProcess)), |
There was a problem hiding this comment.
should we just mark safe plugin with isBody: true on the backend?
There was a problem hiding this comment.
yeah, now after reviewing the previous PR, I get that in the context of a workspace a Safe always is both a process and a body, but in the context of a DAO, it could be one or another. Also it seems that if it has EXECUTE permission and it is added as a process then it should automatically be a body too. In the other case, if it is a body in a SPP process, then it's just a body.
|
|
||
| const { result, isLoading } = useSimulateProposalCreation({ | ||
| plugin: process, | ||
| enabled: process.interfaceType !== PluginInterfaceType.SAFE, |
There was a problem hiding this comment.
can GOVERNANCE_BUILD_CREATE_PROPOSAL_DATA slot be implemented for Safe so we don't have this branching logic?
| useEffect(() => { | ||
| checkWalletConnected(); | ||
| }, [checkWalletConnected]); | ||
| if (enabled || checkWalletConnection) { |
There was a problem hiding this comment.
isn't checkWalletConnection always non-null?
| */ | ||
| fullExecuteOnly?: boolean; | ||
| /** Include native Safe accounts in proposal creation only. */ | ||
| allowNativeSafe?: boolean; |
There was a problem hiding this comment.
do we have a case where we don't want to show Safe process?
|
|
||
| return ( | ||
| <Page.Container> | ||
| <SafeDaoProposalDetails |
There was a problem hiding this comment.
An important question for workspaces: how much is this implementation tied to DAO? Is it easy to make a SafeProposalDetails which works for any Safe transaction?
Another question, does it make sense to port some of the safeTransaction->proposal mapping to backend so we consume a common abstraction?
This branch was successfully deployed
2 participants
Description
Implements APP-1165. Stacked on #1397; base branch is
safe-biz-logic.Safes with DAO Execute permission appear as governance processes. Their Proposals tab pages through stored pending and executed DAO transactions from backend #1587.
SAFE-<nonce>labels are display-only; links identify the Safe and transaction hash, so competing transactions remain separate. Old hash links also look up superseded and removed transactions.Creation uses the action-only wizard. Details show decoded DAO.execute actions and reuse the multisig voting presentation, with Safe envelope review and owner signing inside Aragon. Decoded actions are checked against the transaction's local action tuples; pending or mismatched decoding falls back to raw actions. Process settings and members reuse the Safe-body views. Assets and Transactions are unchanged.
The list verifies DAO.execute targets, including known MultiSend batches, and reports stale, partial or unindexed reads. Pagination remains usable when a backend page has no matching DAO actions or the next request fails. Signing retains fresh queue/history reconciliation and checks the reviewed hash, owner, chain and nonce.
Dependencies: #1397 supplies the Safe review/signing primitives. Backend #1587 is merged and its stored transaction/actions endpoints responded successfully in development. Native process discovery requires Execute-grant indexing from backend #1588; historical grants need registration/backfill.
Verification:
07cf805a5. Application and preview workflows have not started for this commit; their earlier results do not verify this update.Type of Change
Developer Checklist:
Review Checklist: