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

docs: fix broken links #20766

Merged
merged 3 commits into from
Jun 25, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions docs/build/building-apps/01-app-go-v2.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,13 +7,13 @@ sidebar_position: 1
:::note Synopsis

The Cosmos SDK allows much easier wiring of an `app.go` thanks to App Wiring and [`depinject`](../packages/01-depinject.md).
Learn more about the rationale of App Wiring in [ADR-057](../../architecture/adr-057-app-wiring.md).
Learn more about the rationale of App Wiring in [ADR-057](../architecture/adr-057-app-wiring.md).

:::

:::note Pre-requisite Readings

* [ADR 057: App Wiring](../../architecture/adr-057-app-wiring.md)
* [ADR 057: App Wiring](../architecture/adr-057-app-wiring.md)
* [Depinject Documentation](../packages/01-depinject.md)
* [Modules depinject-ready](../building-modules/15-depinject.md)

Expand Down
2 changes: 1 addition & 1 deletion docs/build/building-modules/03-msg-services.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ A Protobuf `Msg` service processes [messages](./02-messages-and-queries.md#messa

Each module should define a Protobuf `Msg` service, which will be responsible for processing requests (implementing `sdk.Msg`) and returning responses.

As further described in [ADR 031](../../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.
As further described in [ADR 031](../architecture/adr-031-msg-service.md), this approach has the advantage of clearly specifying return types and generating server and client code.

Protobuf generates a `MsgServer` interface based on the definition of `Msg` service. It is the role of the module developer to implement this interface, by implementing the state transition logic that should happen upon receival of each `transaction.Msg`. As an example, here is the generated `MsgServer` interface for `x/bank`, which exposes two `transaction.Msg`s:

Expand Down
2 changes: 1 addition & 1 deletion docs/build/building-modules/11-structure.md
Original file line number Diff line number Diff line change
Expand Up @@ -83,7 +83,7 @@ x/{module_name}
* `module/`: The module's `AppModule` implementation.
* `autocli.go`: The module [autocli](https://docs.cosmos.network/main/core/autocli) options.
* `simulation/`: The module's [simulation](./14-simulator.md) package defines functions used by the blockchain simulator application (`simapp`).
* `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../../spec/SPEC_MODULE.md).
* `README.md`: The module's specification documents outlining important concepts, state storage structure, and message and event type definitions. Learn more how to write module specs in the [spec guidelines](../spec/SPEC_MODULE.md).
* The root directory includes type definitions for messages, events, and genesis state, including the type definitions generated by Protocol Buffers.
* `codec.go`: The module's registry methods for interface types.
* `errors.go`: The module's sentinel errors.
Expand Down
2 changes: 1 addition & 1 deletion docs/build/building-modules/13-upgrade.md
Original file line number Diff line number Diff line change
Expand Up @@ -62,4 +62,4 @@ func (m Migrator) Migrate1to2(ctx sdk.Context) error {
}
```

To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/migrations/v2/store.go#L55-L76). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../../architecture/adr-028-public-key-addresses.md).
To see example code of changes that were implemented in a migration of balance keys, check out [migrateBalanceKeys](https://github.com/cosmos/cosmos-sdk/blob/v0.50.0-alpha.0/x/bank/migrations/v2/store.go#L55-L76). For context, this code introduced migrations of the bank store that updated addresses to be prefixed by their length in bytes as outlined in [ADR-028](../architecture/adr-028-public-key-addresses.md).
2 changes: 1 addition & 1 deletion x/auth/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ This module is used in the Cosmos Hub.

## Concepts

**Note:** The auth module is different from the [authz module](../authz/).
**Note:** The auth module is different from the [authz module](../modules/authz/).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarify the module distinction more concisely.

The explanation about the differences between the auth and authz modules could be more concise to enhance readability.

- **Note:** The auth module is different from the [authz module](../modules/authz/).
- 
- The differences are:
- 
- * `auth` - authentication of accounts and transactions for Cosmos SDK applications and is responsible for specifying the base transaction and account types.
- * `authz` - authorization for accounts to perform actions on behalf of other accounts and enables a granter to grant authorizations to a grantee that allows the grantee to execute messages on behalf of the granter.
+ **Note:** The `auth` module handles authentication (base transaction and account types), while the `authz` module manages authorization (granting permissions to execute messages on behalf of another account).
Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
**Note:** The auth module is different from the [authz module](../modules/authz/).
**Note:** The `auth` module handles authentication (base transaction and account types), while the `authz` module manages authorization (granting permissions to execute messages on behalf of another account).


The differences are:

Expand Down
2 changes: 1 addition & 1 deletion x/authz/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ on behalf of one account to other accounts. The design is defined in the [ADR 03
A *grant* is an allowance to execute a Msg by the grantee on behalf of the granter.
Authorization is an interface that must be implemented by a concrete authorization logic to validate and execute grants. Authorizations are extensible and can be defined for any Msg service method even outside of the module where the Msg method is defined. See the `SendAuthorization` example in the next section for more details.

**Note:** The authz module is different from the [auth (authentication)](../auth/) module that is responsible for specifying the base transaction and account types.
**Note:** The authz module is different from the [auth (authentication)](../modules/auth/) module that is responsible for specifying the base transaction and account types.

```go reference
https://github.com/cosmos/cosmos-sdk/blob/v0.47.0-rc1/x/authz/authorizations.go#L11-L25
Expand Down
Loading