diff --git a/docs/source/advice_for_writers.md b/docs/source/advice_for_writers.md index bfbf058345a..452a5dea002 100644 --- a/docs/source/advice_for_writers.md +++ b/docs/source/advice_for_writers.md @@ -17,7 +17,7 @@ In this topic, we're going to cover: Before you make a documentation change, you might like to connect with other people working on the Fabric documentation. Your [Linux Foundation -account](./contributing.html#getting-a-linux-foundation-account) will give you +account](./CONTRIBUTING.html#getting-a-linux-foundation-account) will give you access to many different resources to help you connect with other contributors to the documentation. @@ -67,7 +67,7 @@ Each workgroup has a list of members and their contact information. Hyperledger Fabric has many other collaboration mechanisms such as mailing lists, contributor meetings and maintainer meetings. Find out about these and -more [here](./contributing.html). +more [here](./CONTRIBUTING.html). Good luck getting started and thanks for your contribution. diff --git a/docs/source/capabilities_concept.md b/docs/source/capabilities_concept.md index f166a833e98..7b31ba7eccf 100644 --- a/docs/source/capabilities_concept.md +++ b/docs/source/capabilities_concept.md @@ -36,7 +36,7 @@ As we discussed earlier, there is not a single capability level encompassing an While it is possible to create an ordering service using a legacy process in which a "system channel" administered by the ordering service is created before any application channels are created, the recommended path is to create a channel without using a system channel. -If you do use the [legacy system channel process](./create_channel/create_channel.html), the **orderer** and **channel** capabilities of a channel are inherited by default from the ordering system channel, where modifying them are the exclusive purview of ordering service admins. As a result, peer organizations should inspect the genesis block of a channel prior to joining their peers to that channel. Although the channel capability is administered by the orderers in the orderer system channel (just as the consortium membership is), it is typical and expected that the ordering admins will coordinate with the consortium admins to ensure that the channel capability is only upgraded when the consortium is ready for it. Note: because the ordering system channel does not define an **application** capability, this capability must be specified in the channel profile when creating the genesis block for the channel. +If you do use the [legacy system channel process](./create_channel/create_channel_test_net.html), the **orderer** and **channel** capabilities of a channel are inherited by default from the ordering system channel, where modifying them are the exclusive purview of ordering service admins. As a result, peer organizations should inspect the genesis block of a channel prior to joining their peers to that channel. Although the channel capability is administered by the orderers in the orderer system channel (just as the consortium membership is), it is typical and expected that the ordering admins will coordinate with the consortium admins to ensure that the channel capability is only upgraded when the consortium is ready for it. Note: because the ordering system channel does not define an **application** capability, this capability must be specified in the channel profile when creating the genesis block for the channel. If you use the recommended process to [Create a channel](./create_channel/create_channel_participation.html), all these capability levels are specified in the application channel genesis block that is created. diff --git a/docs/source/config_update.md b/docs/source/config_update.md index feb79469659..c4ca4fa4773 100644 --- a/docs/source/config_update.md +++ b/docs/source/config_update.md @@ -941,7 +941,7 @@ However, as you'll see, this conceptual simplicity is wrapped in a somewhat conv We have two tutorials that deal specifically with editing a channel configuration to achieve a specific end: * [Adding an Org to a Channel](./channel_update_tutorial.html): shows the process for adding an additional organization to an existing channel. -* [Updating channel capabilities](./updating_a_channel.html): shows how to update channel capabilities. +* [Updating channel capabilities](./updating_capabilities.html): shows how to update channel capabilities. In this topic, we'll show the process of editing a channel configuration independent of the end goal of the configuration update. @@ -994,7 +994,7 @@ At this point, you have two options of how you want to modify the config. 1. Open ``modified_config.json`` using the text editor of your choice and make edits. Online tutorials exist that describe how to copy a file from a container that does not have an editor, edit it, and add it back to the container. 2. Use ``jq`` to apply edits to the config. -Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_a_channel.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly. +Whether you choose to edit the config manually or using `jq` depends on your use case. Because `jq` is concise and scriptable (an advantage when the same configuration update will be made to multiple channels), it's the recommend method for performing a channel update. For an example on how `jq` can be used, check out [Updating channel capabilities](./updating_capabilities.html#Create-a-capabilities-config-file), which shows multiple `jq` commands leveraging a capabilities config file called `capabilities.json`. If you are updating something other than the capabilities in your channel, you will have to modify your `jq` command and JSON file accordingly. For more information about the content and structure of a channel configuration, check out our [sample channel config](#Sample-channel-configuration) above. diff --git a/docs/source/create_channel/create_channel_config.md b/docs/source/create_channel/create_channel_config.md index d93ab8301a9..9423cc7adf2 100644 --- a/docs/source/create_channel/create_channel_config.md +++ b/docs/source/create_channel/create_channel_config.md @@ -17,7 +17,7 @@ You can use this tutorial to learn how to use the `configtx.yaml` file to build Because different sections of the file work together to create the policies that govern the channel, we will discuss channel policies in [their own tutorial](channel_policies.html). -Building off of the [Creating a channel tutorial](create_channel.html), we will use the `configtx.yaml` file that is used to deploy the Fabric test network as an example. Open a command terminal on your local machine and navigate to the `test-network` directory in your local clone of the Fabric samples: +Building off of the [Creating a channel tutorial](create_channel_participation.html), we will use the `configtx.yaml` file that is used to deploy the Fabric test network as an example. Open a command terminal on your local machine and navigate to the `test-network` directory in your local clone of the Fabric samples: ``` cd fabric-samples/test-network ``` diff --git a/docs/source/create_channel/create_channel_test_net.md b/docs/source/create_channel/create_channel_test_net.md index 65aaf9624a1..ab0f8f99d8f 100644 --- a/docs/source/create_channel/create_channel_test_net.md +++ b/docs/source/create_channel/create_channel_test_net.md @@ -61,7 +61,7 @@ By default, when you start the test network, it does not contain any channels. T ### Set up the configtxgen tool -Channels are created by generating a channel creation transaction in a genesis block, and then passing that genesis block to an ordering service node in a join request. The channel creation transaction specifies the initial configuration of the channel and can be created by the [configtxgen](../commands/configtxgen.html) tool. The tool reads the `configtx.yaml` file that defines the configuration of our channel, and then writes the relevant information into the channel creation transaction and outputs a genesis block including the channel creation transaction. When you [installed Fabric](install.html), the `configtxgen` tool was installed in the `fabric-samples\bin` directory for you. +Channels are created by generating a channel creation transaction in a genesis block, and then passing that genesis block to an ordering service node in a join request. The channel creation transaction specifies the initial configuration of the channel and can be created by the [configtxgen](../commands/configtxgen.html) tool. The tool reads the `configtx.yaml` file that defines the configuration of our channel, and then writes the relevant information into the channel creation transaction and outputs a genesis block including the channel creation transaction. When you [installed Fabric](../install.html), the `configtxgen` tool was installed in the `fabric-samples\bin` directory for you. Ensure that you are still operating from the `test-network` directory of your local clone of `fabric-samples` and run this command: diff --git a/docs/source/developapps/gateway.md b/docs/source/developapps/gateway.md index 88737d06db6..cfaf8bf3f82 100644 --- a/docs/source/developapps/gateway.md +++ b/docs/source/developapps/gateway.md @@ -39,7 +39,7 @@ A gateway can be used by an application in two different ways: these roles in the connection profile [topic](./connectionprofile.html). The SDK will use this static topology, in conjunction with gateway - [connection options](./connectionoptions), to manage the transaction + [connection options](connectionoptions.html), to manage the transaction submission and notification processes. The connection profile must contain enough of the network topology to allow a gateway to interact with the network on behalf of the application; this includes the network channels, diff --git a/docs/source/developapps/transactionhandler.md b/docs/source/developapps/transactionhandler.md index f8d3a4a9e5d..cad1cc91c9a 100644 --- a/docs/source/developapps/transactionhandler.md +++ b/docs/source/developapps/transactionhandler.md @@ -85,7 +85,7 @@ shows you the exact form of these handlers. Once a handler has been added to the smart contract, it will be invoked during transaction processing. During processing, the handler receives `ctx`, the -[transaction context](./transationcontext.md), performs some processing, and +[transaction context](transationcontext.html), performs some processing, and returns control as it completes. Processing continues as follows: * **Before handler**: If the handler completes successfully, the transaction is diff --git a/docs/source/developapps/wallet.md b/docs/source/developapps/wallet.md index c2b692705f2..1aa60440df7 100644 --- a/docs/source/developapps/wallet.md +++ b/docs/source/developapps/wallet.md @@ -144,7 +144,7 @@ particular `identityLabel`. The `Gateway` class only requires the `mspId` and `type` metadata to be set for an identity -- `Org1MSP` and `X.509` in the above example. It *currently* uses the MSP ID value to identify particular peers from a [connection profile](./connectionprofile.html), -for example when a specific notification [strategy](./connectoptions.html) is +for example when a specific notification [strategy](./connectionoptions.html) is requested. In the DigiBank gateway file `networkConnection.yaml`, see how `Org1MSP` notifications will be associated with `peer0.org1.example.com`: diff --git a/docs/source/kafka_raft_migration.md b/docs/source/kafka_raft_migration.md index 99cb2e00dc8..4e63eb4840d 100644 --- a/docs/source/kafka_raft_migration.md +++ b/docs/source/kafka_raft_migration.md @@ -185,7 +185,7 @@ channel, and elect a leader on each channel. **Note**: Since the Raft-based ordering service uses client and server TLS certificates for authentication between orderer nodes, **additional configurations** are required before you start them again, see -[Section: Local Configuration](./raft_configuration.md#local-configuration) for more details. +[Section: Local Configuration](raft_configuration.html#local-configuration) for more details. After restart process finished, make sure to **validate** that a leader has been elected on each channel by inspecting the node logs (you can see diff --git a/docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md b/docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md index 526747b183c..9b31b502882 100644 --- a/docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md +++ b/docs/source/secured_asset_transfer/secured_private_asset_transfer_tutorial.md @@ -4,7 +4,7 @@ This tutorial will demonstrate how an asset can be represented and traded betwee Each on-chain asset is a non-fungible token (NFT) that represents a specific asset having certain immutable metadata properties (such as size and color) with a unique owner. When the owner wants to sell the asset, both parties need to agree to the same price before the asset is transferred. The private asset transfer smart contract enforces that only the owner of the asset can transfer the asset. In the course of this tutorial, you will learn how Fabric features such as state based endorsement, private data, and access control come together to provide secured transactions that are both private and verifiable. This tutorial will deploy the [secured asset transfer sample](https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-secured-agreement/chaincode-go) to demonstrate how to transfer a private asset between two organizations without publicly sharing data. You should have completed the task -[Install Samples, Binaries, and Docker Images](./install.html#install-samples-binaries-and-docker-images). +[Install Samples, Binaries, and Docker Images](../install.html#install-samples-binaries-and-docker-images). ## Scenario requirements diff --git a/docs/source/tutorial/commercial_paper.md b/docs/source/tutorial/commercial_paper.md index 6b58eccf868..54168be8765 100644 --- a/docs/source/tutorial/commercial_paper.md +++ b/docs/source/tutorial/commercial_paper.md @@ -404,7 +404,7 @@ and approve the chaincode as administrators of both MagnetoCorp and DigiBank. administrator installs a copy of the `papercontract` onto a MagnetoCorp peer.* Smart contracts are the focus of application development, and are contained -within a Hyperledger Fabric artifact called [chaincode](../chaincode.html). One +within a Hyperledger Fabric artifact called [chaincode](../chaincode4ade.html). One or more smart contracts can be defined within a single chaincode, and installing a chaincode will allow them to be consumed by the different organizations in PaperNet. It means that only administrators need to worry about chaincode; @@ -854,7 +854,7 @@ All the time, the underlying Fabric SDK handles the transaction endorsement, ordering and notification process, making the application's logic straightforward; the SDK uses a [gateway](../developapps/gateway.html) to abstract away network details and -[connectionOptions](../developapps/connectoptions.html) to declare more advanced +[connectionOptions](../developapps/connectionoptions.html) to declare more advanced processing strategies such as transaction retry. Let's now follow the lifecycle of MagnetoCorp 00001 by switching our emphasis