## Description
Closes: #11092
## TODOs
I'm thinking to do the 2 todos in a separate PR, or else this PR is too big. WDYT?
- [ ] #11246 This involves adding a new index ProposalsByVotingPeriodEnd, so might be better to do in another PR
- [ ] #11245 Also should be done in a separate PR (as it needs the above index)
### Main change 1: Group policy proto defs have `voting_period` and `min_execution_period`
For group policies:
```diff
- // Within this times votes and exec messages can be submitted.
- // timeout is the duration from submission of a proposal to the end of voting period
- google.protobuf.Duration timeout = 2 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false];
+ // voting_period is the duration from submission of a proposal to the end of voting period
+ // Within this times votes can be submitted with MsgVote.
+ google.protobuf.Duration voting_period = 2 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false];
+ // min_execution_period is the minimum duration after the proposal submission
+ // where members can start sending MsgExec. This means that the window for
+ // sending a MsgExec transaction is:
+ // `[ submission + min_execution_period ; submission + voting_period + max_execution_period]`
+ // where max_execution_period is a app-specific config, defined in the keeper.
+ // If not set, min_execution_period will default to 0.
+ google.protobuf.Duration min_execution_period = 3 [(gogoproto.stdduration) = true, (gogoproto.nullable) = false];
```
### Main Change 2: We don't update proposal's FinalTallyResult result on MsgVote/MsgSubmitProposal
Unless the msg has TryExec set to true, in which case the FinalTallyResult is updated ONLY if the tally is final.
### Main Change 3: Add a keeper-level `MaxExecutionPeriod`
MsgExecs will be rejected if they are sent after `voting_period_end + MaxExecutionPeriod`
---
### Author Checklist
*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*
I have...
- [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] added `!` to the type prefix if API or client breaking change
- [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [ ] added a changelog entry to `CHANGELOG.md`
- [ ] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [ ] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed
### Reviewers Checklist
*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*
I have...
- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
## Description
This follows up on #11119 and adds app wiring proto definitions for the ORM. These would be used together with an app-wiring `cosmos.app.v1.module` option like so:
```proto
package foo.bar.my_module.v1;
message Module {
option (cosmos.app.v1.module) = {
go_import: "github.com/foo/bar/x/my_module"
};
option (cosmos.orm.v1alpha1.module_schema) = {
schema_file: {
id: 1
path: "foo/bar/my_module/state.proto"
}
schema_file: {
id: 2
path: "foo/bar/my_module/memory.proto"
storage_type: cosmos.orm.v1alpha1.STORAGE_TYPE_MEMORY
}
};
}
```
This supports various alternative storage types (memory, transient, etc.) which can be scoped to individual file descriptor schemas.
This PR also removes the `references` fields currently in `cosmos.orm.v1alpha`. I do think something like that should be supported, but I don't like having a field unsupported by the tooling when the documentation says otherwise.
---
### Author Checklist
*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*
I have...
- [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] added `!` to the type prefix if API or client breaking change
- [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [ ] provided a link to the relevant issue or specification
- [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [ ] added a changelog entry to `CHANGELOG.md`
- [ ] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [ ] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed
### Reviewers Checklist
*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*
I have...
- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
Amaury
Aaron Craelius