docs(adr): ADR-045 Admin module

[Mar-Alex]

Description

This ADR defines an admin module.

---

Author Checklist

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[aaronc]

Thanks for your contribution @Mar-Alex !

So the functionality laid out here is as far as I understand it is covered by #9438, which will allow the gov module to use x/authz to delegate governance operations to other accounts.

One use case which you describe - changing the balance of a test account - sounds useful but isn't actually covered in your proposed design (because proposal handlers currently can't be arbitrary messages). I do think this an important functionality to consider. i.e. should governance be able to execute any message at all such as changing account balances? There might be different ways to deal with it, but what occurs to me is adding some admin privilege handling in x/authz.

As a general matter of process, I suggest opening an issue or discussion first before submitting an ADR because generally we'll want to talk through various solutions. We do currently have a working group on governance overseeing the work in #9438 as well as governance more broadly. I suggest we continue this discussion in #9438 or a separate issue so the working group can make sure our designs cover all the important use cases.

[alexanderbez]

I think in the context of test or dev networks, this makes a lot of sense. I mostly left linting feedback. But also have two comments:

1. We should ensure InitGenesis fails for x/admin if there exists no admin(s) in genesis.
2. Are you planning on copying the proposal types from x/gov or just use them directly? I would make note of that.

[alexanderbez]

note, it's not just validators -- any token holder can vote to accept or reject a proposal.

[alexanderbez]

I think in the context of testnets mainly, this makes a lot of sense.

[okwme]

exactly, this is really only meant for testnet environments (altho technically a chain may want it on mainnet for things like emergency upgrades)

[okwme]

Suggested change

	SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSenMsgSubmitProposalResponsedResponse, error)
	SubmitProposal(context.Context, *MsgSubmitProposal) (*MsgSubmitProposalResponsedResponse, error)

Was that a copy paste error or intended as before?

[okwme]

could be nice to have some convenience queries like isAdmin

[okwme]

maybe a command for adding the admin to the genesis file before launch?

[aaronc]

Since the SDK is already working on more comprehensive solutions to the problems identified in this ADR, my opinion is that this module doesn't belong in the SDK. Maybe there are cases where this module is useful for testnets and devnets, but it can always live in a standalone repo if there is some immediate need for it before the work in #9438 is finished. Adding a new core module to the SDK is a substantial amount of work involving a lot of QA and testing, and if the use cases are already covered elsewhere, it seems hard to justify adding this.

So with that in mind, I am going to close this PR as a duplicate. Apologies for any inconvenience and I do appreciate the effort here. As I said before, we're happy to have a more thorough discussion of the use cases motivating this work in either #9438 or another issue or discussion which you're welcome to open.