search

DA0-DA0 / dao-contracts

CosmWasm smart contracts for Interchain DAOs.
https://docs.daodao.zone
BSD 3-Clause "New" or "Revised" License
202 stars 132 forks source link

Pending approval proposals have mutable approvers #791

Open NoahSaso opened 6 months ago

NoahSaso commented 6 months ago

The dao-pre-propose-approval-single module only stores a single approver and validates against it when a proposal is approved or rejected. Instead, it should snapshot the current approver when a pending proposal is created by storing it in its object so that it cannot be changed in the middle. This isn't a big deal but is probably a good idea.

Either way, this is important for being able to reference past approvers.

ismellike commented 1 month ago

Can be implemented as a SnapshotItem from dao-pre-propose-approval-single. When approving, the contract will query for generic proposal info added here to get the proposal's start_height and get the respective approver.

NoahSaso commented 1 month ago

Can be implemented as a SnapshotItem from dao-pre-propose-approval-single. When approving, the contract will query for generic proposal info added here to get the proposal's start_height and get the respective approver.

Is that better than just storing it in the proposal struct? I like the idea of keeping the information close to the source instead of adding another query. It also removes the need for the frontend to perform an extra query and follows the pattern in the proposal modules where the proposal struct fully defines the config being used.

ismellike commented 1 month ago

Can be implemented as a SnapshotItem from dao-pre-propose-approval-single. When approving, the contract will query for generic proposal info added here to get the proposal's start_height and get the respective approver.

Is that better than just storing it in the proposal struct? I like the idea of keeping the information close to the source instead of adding another query. It also removes the need for the frontend to perform an extra query and follows the pattern in the proposal modules where the proposal struct fully defines the config being used.

We can still avoid an extra query on the frontend by returning a ProposalResponse (Proposal + Approver) instead of just Proposal from query. If we can fight state bloat, I think we should.

NoahSaso commented 1 month ago

Can be implemented as a SnapshotItem from dao-pre-propose-approval-single. When approving, the contract will query for generic proposal info added here to get the proposal's start_height and get the respective approver.

Is that better than just storing it in the proposal struct? I like the idea of keeping the information close to the source instead of adding another query. It also removes the need for the frontend to perform an extra query and follows the pattern in the proposal modules where the proposal struct fully defines the config being used.

We can still avoid an extra query on the frontend by returning a ProposalResponse (Proposal + Approver) instead of just Proposal from query. If we can fight state bloat, I think we should.

Alright :)