diff --git a/docs/source/advice_for_writers.md b/docs/source/advice_for_writers.md index 19ad75182de..f3b83706171 100644 --- a/docs/source/advice_for_writers.md +++ b/docs/source/advice_for_writers.md @@ -67,9 +67,9 @@ 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. \ No newline at end of file +https://creativecommons.org/licenses/by/4.0/ --> diff --git a/docs/source/config_update.md b/docs/source/config_update.md index 5b8e11b2af9..88faf1fb2cd 100644 --- a/docs/source/config_update.md +++ b/docs/source/config_update.md @@ -9,7 +9,7 @@ Like many complex systems, Hyperledger Fabric networks are comprised of both **s * **Structure**: encompassing users (like admins), organizations, peers, ordering nodes, CAs, smart contracts, and applications. * **Process**: the way these structures interact. Most important of these are [Policies](./policies/policies.html), the rules that govern which users can do what, and under what conditions. -Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.0/sampleconfig/configtx.yaml). +Information identifying the structure of blockchain networks and the processes governing how structures interact are contained in **channel configurations**. These configurations are collectively decided upon by the members of channels and are contained in blocks that are committed to the ledger of a channel. Channel configurations can be built using a tool called `configtxgen`, which uses a `configtx.yaml` file as its input. You can look at a [sample `configtx.yaml` file here](http://github.com/hyperledger/fabric/blob/release-2.2/sampleconfig/configtx.yaml). Because configurations are contained in blocks (the first of these is known as the genesis block with the latest representing the current configuration of the channel), the process for updating a channel configuration (changing the structure by adding members, for example, or processes by modifying channel policies) is known as a **configuration update transaction**. @@ -951,7 +951,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. diff --git a/docs/source/create_channel/create_channel.md b/docs/source/create_channel/create_channel.md index 003a148bf07..6352b6e268a 100644 --- a/docs/source/create_channel/create_channel.md +++ b/docs/source/create_channel/create_channel.md @@ -63,7 +63,7 @@ You can find the `configtx.yaml` file that is used to deploy the test network in The `configtxgen` tool uses `configtx.yaml` file to create a complete genesis block for the system channel. As a result, the system channel profile needs to specify the full system channel configuration. The channel profile used to create the channel creation transaction only needs to contain the additional configuration information required to create an application channel. -You can visit the [Using configtx.yaml to create a channel genesis block](create_channel_genesis.html) tutorial to learn more about this file. For now, we will return to the operational aspects of creating the channel, though we will reference parts of this file in future steps. +You can visit the [Using configtx.yaml to build a channel configuration](create_channel_config.html) tutorial to learn more about this file. For now, we will return to the operational aspects of creating the channel, though we will reference parts of this file in future steps. ## Start the network diff --git a/docs/source/developapps/gateway.md b/docs/source/developapps/gateway.md index 88737d06db6..46cd5cd00a7 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/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/policies/policies.md b/docs/source/policies/policies.md index 48e78d5adc5..a9944c3304a 100644 --- a/docs/source/policies/policies.md +++ b/docs/source/policies/policies.md @@ -235,7 +235,7 @@ are satisfied, that ALL are satisfied, or that a MAJORITY are satisfied. This format lends itself to much better, more natural defaults, so that each organization can decide what it means for a valid endorsement. -Further granularity and control can be achieved if you include [`NodeOUs`](msp.html#organizational-units) in your +Further granularity and control can be achieved if you include [`NodeOUs`](../msp.html#organizational-units) in your organization definition. Organization Units (OUs) are defined in the Fabric CA client configuration file and can be associated with an identity when it is created. In Fabric, `NodeOUs` provide a way to classify identities in a digital 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 2bf134876d9..80335cf3b32 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/master/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 114c643eccc..eae36d39649 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