Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Deprecation] Treasury Proposal Dispatchables #138

Closed
7 tasks done
muharem opened this issue Aug 8, 2023 · 5 comments
Closed
7 tasks done

[Deprecation] Treasury Proposal Dispatchables #138

muharem opened this issue Aug 8, 2023 · 5 comments
Assignees
Labels
D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. T1-FRAME This PR/Issue is related to core FRAME, the framework. T13-deprecation The current issue/pr is, or should be, part of a deprecation process.

Comments

@muharem
Copy link
Contributor

muharem commented Aug 8, 2023

The old treasury pallet's dispatchables to create/reject/approve a proposal now replaced by the spend dispatchable.

Deprecated dispatchables:

  • pallet_treasury.propose_spend
  • pallet_treasury.reject_proposal
  • pallet_treasury.approve_proposal

The pallet_treasury.remove_approval dispatchable is not deprecated since its still can be used to remove an approved proposal by the spend.

Tasks

Preview Give feedback
@muharem
Copy link
Contributor Author

muharem commented Aug 10, 2023

@oshakarishvili can you help me with finding the existing examples and tutorials concerning the deprecated dispatchables?

@oshakarishvili
Copy link

Following our transition from Gov1 to OpenGov, comprehensive updates have already been made to all our documentation and guidelines (you can find one of several examples on our wiki or Scribehow for detailed step-by-step). Due to these updates, the usage of the propose_spend call has become quite rare, given the evolved context. The remaining two calls (reject_proposal and approve_proposal) primarily found use within the council, hence detailed documentation for these calls has been limited historically.

@juangirini juangirini transferred this issue from paritytech/substrate Aug 24, 2023
@the-right-joyce the-right-joyce added T1-FRAME This PR/Issue is related to core FRAME, the framework. D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. and removed T1-runtime labels Aug 25, 2023
@the-right-joyce the-right-joyce added T13-deprecation The current issue/pr is, or should be, part of a deprecation process. and removed I11-deprecation labels Sep 21, 2023
@muharem muharem self-assigned this Feb 13, 2024
@ozgunozerk
Copy link
Contributor

Hi @muharem! I'm confused by the explanations provided for the deprecation:

  • propose_spend will be removed in February 2024. Use spend instead.
  • reject_proposal will be removed in February 2024. Use spend instead.
  • approve_proposal will be removed in February 2024. Use spend instead.

My confusion is, from what I understood, it was possible to propose a spend previously (but not approve it yet), and there was a proposed, but not approved state tracked with the Proposals storage item.

Now, all the to be deprecated functions above, and Proposals storage item will be removed, along with Proposed and Rejected events.

So, after this change, it will be impossible to solely propose (but not approve) a spend?

My understanding is that, only approved proposals will be tracked on this pallet. What about proposed but not yet approved spends? Where will they be tracked? Or if they won't be tracked, why? Is there an explanation on these that I can follow?

From the docs and sourcecode, these remained unclear to me.

Thanks in advance!

@ozgunozerk
Copy link
Contributor

ozgunozerk commented Mar 29, 2024

Another relevant question about the diff between spend_local and spend dispatchables:

  • spend_local function proposes and approves the spend. In the sourcecode, we can see that there is this line:
    Approvals::<T, I>::try_append(proposal_index)
  • however, in spend function, I couldn't find any clues that lead to the proposal being appended to Approvals storage item.

Also, why is there a valid_from field in spend, but not in spend_local?

@muharem
Copy link
Contributor Author

muharem commented Apr 2, 2024

Hi @ozgunozerk
Yes, you are right, without those calls, there wont be a way to track un approved proposals solely with this pallet.
The idea to use this pallet with some other pallet which will provide that functionality. For Polkadot it's OpenGov (referenda and conviction voting pallets).
The storage items wont be removed though for now, because they are used for spend_local.

spend_local is renamed old spend calls, and it has not changes like valid_from for backward compatibility.
You can find here more details on how we use new spend call - https://forum.polkadot.network/t/multi-asset-treasury-and-milestone-based-spends/6780

jonathanudd pushed a commit to jonathanudd/polkadot-sdk that referenced this issue Apr 10, 2024
…ain (paritytech#138)

* Error::TryingToFinalizeSibling

* cargo fmt --all

* updated PruningStrategy comment
@muharem muharem closed this as completed Jul 30, 2024
@github-project-automation github-project-automation bot moved this from Backlog to Done in Runtime / FRAME Jul 30, 2024
claravanstaden added a commit to claravanstaden/polkadot-sdk that referenced this issue Sep 19, 2024
* update rust version to stable

* pin to rust 1.76

* fix tests and warning

* fix import

* update nightly version

---------

Co-authored-by: claravanstaden <Cats 4 life!>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
D0-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder. T1-FRAME This PR/Issue is related to core FRAME, the framework. T13-deprecation The current issue/pr is, or should be, part of a deprecation process.
Projects
Status: Done
Development

No branches or pull requests

5 participants