Add a full workflow in the docs

CHANGELOG.md

@@ -59,6 +59,7 @@ All notable changes to this project will be documented in this file. The format
 
 - Transfer Filter Hook. The transfer filter modality, if enabled, specifies a contract package hash pointing to a contract that will be called when the `transfer` method is invoked on the contract.
 
+- Added the `ACL` option to the `minting_mode` modality. This option allows only whitelisted accounts or contracts to mint tokens. More information can be found [here](./docs/modalities.md#minting).
 - Added the `ACL` option to the `minting_mode` modality. This option allows only whitelisted accounts or contracts to mint tokens. More information can be found [here](./docs/modalities.md#minting).
 
 ## Release 1.3.0
@@ -77,9 +78,10 @@ All notable changes to this project will be documented in this file. The format
 
 ### Added
 
+- Added a new modality named `EventsMode` that dictates how the installed instance of CEP-78 will handle the recording of events. Refer to the [README](./docs/modalities.md#eventsmode) for further details
 - Added a new modality named `EventsMode` that dictates how the installed instance of CEP-78 will handle the recording of events. Refer to the [README](./docs/modalities.md#eventsmode) for further details
 
-- Added the ability for the contract to specify one or more metadata schemas, with the option to further specify optional metadata schemas. Additional required metadatas are specified by `additional_required_metadata`, while additional optional metadata schemas can be specified using `optional_metadata`. Refer to the [`Installing the Contract`](./docs/using-casper-client.md#installing-the-contract) section of the README for more information on using these arguments.
+- Added the ability for the contract to specify one or more metadata schemas, with the option to further specify optional metadata schemas. Additional required metadatas are specified by `additional_required_metadata`, while additional optional metadata schemas can be specified using `optional_metadata`. Refer to the [`Installing the Contract`](./docs/tutorials/getting-started/full-installation-tutorial.md) section of the README for more information on using these arguments.
 
 - When upgrading from a contract instance, you may now change the `total_token_supply` to a number higher than the current number of minted tokens, but lower than your previous total. The number cannot be zero. More information is available in the upgrade tutorials.
 
@@ -91,6 +93,7 @@ All notable changes to this project will be documented in this file. The format
 
 ### Changed
 
+- `OwnerReverseLookupMode` now contains an additional option, `TransfersOnly`, which begins tracking ownership upon transfer. More information can be found [here](./docs/modalities.md#ownerreverselookupmode).
 - `OwnerReverseLookupMode` now contains an additional option, `TransfersOnly`, which begins tracking ownership upon transfer. More information can be found [here](./docs/modalities.md#ownerreverselookupmode).
 
 - Optimized the `set_approval_for_all` entrypoint implementation to reduce gas costs.
@@ -114,6 +117,7 @@ All notable changes to this project will be documented in this file. The format
   - To allow isolation of the additional costs, or tracking individual owners, the reverse lookup mode supports a register entrypoint which is used to register owners prior to minting or receiving a transferred token. In either `Assigned` or `Transferable` mode, this register entrypoint can be called by any party on behalf of another party.
 
   - As a result of this change, the previously used `owned_tokens` dictionary is now deprecated. Moving forward, token ownership will be tracked using the `OwnerReverseLookupMode` modality and [CEP-78 Page System](./docs/reverse-lookup.md#the-cep-78-page-system).
+  - As a result of this change, the previously used `owned_tokens` dictionary is now deprecated. Moving forward, token ownership will be tracked using the `OwnerReverseLookupMode` modality and [CEP-78 Page System](./docs/reverse-lookup.md#the-cep-78-page-system).
 
 ### Changed
 

README.md

@@ -70,10 +70,10 @@ The following are the optional parameters that can be passed in at the time of i
 
 #### Example deploy
 
-The following is an example of installing the NFT contract via a deploy using the Rust CLI Casper client. You can find more examples [here](/docs/using-casper-client.md).
+The following is an example of installing the NFT contract via a deploy using the Rust CLI Casper client. You can find more examples [here](/docs/tutorials/getting-started/full-installation-tutorial.md).
 
 ```bash
-casper-client put-deploy -n http://65.108.0.148:7777/rpc --chain-name "casper-test" --payment-amount 500000000000 -k keys/secret_key.pem --session-path contract/target/wasm32-unknown-unknown/release/contract.wasm \
+casper-client put-deploy -n https://rpc.testnet.casperlabs.io/ --chain-name "casper-test" --payment-amount 500000000000 -k keys/secret_key.pem --session-path contract/target/wasm32-unknown-unknown/release/contract.wasm \
 --session-arg "collection_name:string='enhanced-nft-1'" \
 --session-arg "collection_symbol:string='ENFT-1'" \
 --session-arg "total_token_supply:u64='10'" \
@@ -104,15 +104,15 @@ folder within the project folder.
 
 ### Checking Token Ownership
 
-[Learn to check token ownership](./tutorials/token-ownership-tutorial.md) starting with version [v1.1.1](https://github.com/casper-ecosystem/cep-78-enhanced-nft/releases/tag/v1.1.1). The `OwnerReverseLookupMode` modality must be set to `Complete` as described [here](/docs/reverse-lookup.md).
+[Learn to check token ownership](./docs/tutorials/token-ownership-tutorial.md) starting with version [v1.1.1](https://github.com/casper-ecosystem/cep-78-enhanced-nft/releases/tag/v1.1.1). The `OwnerReverseLookupMode` modality must be set to `Complete` as described [here](/docs/reverse-lookup.md).
 
 ### Upgrading to Version 1.1.1
 
-Upgrade to v1.1.1 using a [Standard NamedKey Convention](./tutorials/standard-migration-tutorial.md) or a [Custom NamedKey Convention](./tutorials/custom-migration-tutorial.md).
+Upgrade to v1.1.1 using a [Standard NamedKey Convention](./docs/tutorials/standard-migration-tutorial.md) or a [Custom NamedKey Convention](./docs/tutorials/custom-migration-tutorial.md).
 
 ## Installing and Interacting with the Contract using the Rust Casper Client
 
-You can find instructions on installing an instance of the CEP-78 contract using the Rust CLI Casper client [here](/docs/using-casper-client.md).
+You can find instructions on installing an instance of the CEP-78 contract using the Rust CLI Casper client [here](/docs/tutorials/getting-started/full-installation-tutorial.md).
 
 ## Test Suite and Specification
 

docs/modalities.md

@@ -296,8 +296,8 @@ The `OwnerReverseLookupMode` modality is set at install and determines if a give
 This modality provides the following options:
 
 1. `NoLookup`: The reporting and receipt functionality is not supported. In this option, the contract instance does not maintain a reverse lookup database of ownership and therefore has more predictable gas costs and greater scaling.
-2. `Complete`: The reporting and receipt functionality is supported. Token ownership will be tracked by the contract instance using the system described [here](reverse-lookup.md).
-3. `TransfersOnly`: The reporting and receipt functionality is supported like `Complete`. However, it does not begin tracking until the first transfer. This modality is for use cases where the majority of NFTs are owned by a private minter and only NFT's that have been transferred benefit from reverse lookup tracking. Token ownership will also be tracked by the contract instance using the system described [here](reverse-lookup.md).
+2. `Complete`: The reporting and receipt functionality is supported. Token ownership will be tracked by the contract instance using the system described [here](../docs/reverse-lookup.md#owner-reverse-lookup-functionality).
+3. `TransfersOnly`: The reporting and receipt functionality is supported like `Complete`. However, it does not begin tracking until the first transfer. This modality is for use cases where the majority of NFTs are owned by a private minter and only NFT's that have been transferred benefit from reverse lookup tracking. Token ownership will also be tracked by the contract instance using the system described [here](../docs/reverse-lookup.md#owner-reverse-lookup-functionality).
 
 Additionally, when set to `Complete`, causes a receipt to be returned by the `mint` or `transfer` entrypoints, which the caller can store in their account or contract context for later reference.
 

docs/reverse-lookup.md

@@ -1,6 +1,6 @@
 # Owner Reverse Lookup Functionality
 
-In version 1.0 of the CEP-78 Enhanced NFT Standard contract, tracking minted tokens consisted of a single, unbounded list that would grow in size with each additional token. As a result, gas costs would increase over time as the list must be overwritten with each new minting. The related tutorial can be found [here](../tutorials/token-ownership-tutorial.md).
+In version 1.0 of the CEP-78 Enhanced NFT Standard contract, tracking minted tokens consisted of a single, unbounded list that would grow in size with each additional token. As a result, gas costs would increase over time as the list must be overwritten with each new minting. The related tutorial can be found [here](../docs/tutorials/token-ownership-tutorial.md).
 
 In an effort to stabilize the gas costs of larger NFT collections, version 1.1 of CEP-78 includes the use of a pre-allocated page system to track ownership of NFTs within the contract.
 

tutorials/custom-migration-tutorial.md → docs/tutorials/custom-migration-tutorial.md

@@ -8,11 +8,11 @@ This tutorial uses the Casper command-line client to upgrade *and* migrate from
 - Your v1.0.0 NFT contract instance uses custom NamedKeys for the contract package hash and contract package access URef.
 - You have the v1.0.0 contract package hash stored under a custom NamedKey in the account that installed the contract.
 - You have the v1.0.0 contract package access URef stored under a custom NamedKey in the account that installed the contract.
-- You understand what is new in [Version 1.1](https://github.com/casper-ecosystem/cep-78-enhanced-nft/releases/tag/v1.1.1) of the CEP-78 Enhanced NFT Standard.
+- You understand what is new in [Version 1.1.0](https://github.com/casper-ecosystem/cep-78-enhanced-nft/releases/tag/v1.1.0) of the CEP-78 Enhanced NFT Standard.
 
 ## Upgrading and Migrating Terminology
 
-The upgrade to version 1.1.1 involves a data migration to a new [page system](../docs/reverse-lookup.md#the-cep-78-page-system) tracking token ownership. The usual [upgrade](https://docs.casper.network/developers/writing-onchain-code/upgrading-contracts/) process triggers the data migration. For more information, see [Standard Migration Tutorial](standard-migration-tutorial.md#upgrading-and-migrating-terminology).
+The upgrade to version 1.1.1 involves a data migration to a new [page system](../reverse-lookup.md#the-cep-78-page-system) tracking token ownership. The usual [upgrade](https://docs.casperlabs.io/dapp-dev-guide/writing-contracts/upgrading-contracts/) process triggers the data migration. For more information, see [Standard Migration Tutorial](standard-migration-tutorial.md#upgrading-and-migrating-terminology).
 
 ## Steps to Upgrade to Version 1.1.1
 
@@ -22,7 +22,7 @@ The `cep-78-wasm` folder contains the `contract.wasm` to send to the network to
 
 ### Custom NamedKeys before Migration
 
-The custom migration path assumes that the contract has modified the NamedKey entries created during the v1.0.0. See the example below as well as the [NamedKeyConvention](../docs/modalities.md#namedkeyconventionmode) modality. 
+The custom migration path assumes that the contract has modified the NamedKey entries created during the v1.0.0. See the example below as well as the [NamedKeyConvention](../modalities.md#namedkeyconventionmode) modality. 
 
 | NamedKey Pre-Migration | Explanation |
 |-------------|-------------|
@@ -38,8 +38,8 @@ The custom migration path assumes that the contract has modified the NamedKey en
 
 When upgrading using the `casper-client`, you must provide four runtime arguments:
 
-- `named_key_convention`: The [NamedKeyConvention](../docs/modalities.md#namedkeyconventionmode) runtime argument as a u8 value equal to 2: `--session-arg "named_key_convention:u8='2'"`. See the [ARG_NAMED_KEY_CONVENTION](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L1991).
-- `collection_name`: The collection name specified when the contract was [installed](../docs/using-casper-client.md#installing-the-contract) using the `collection_name` option. See the [contract code](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L93) for details. 
+- `named_key_convention`: The [NamedKeyConvention](../modalities.md#namedkeyconventionmode) runtime argument as a u8 value equal to 2: `--session-arg "named_key_convention:u8='2'"`. See the [ARG_NAMED_KEY_CONVENTION](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L1991).
+- `collection_name`: The collection name specified when the contract was [installed](./getting-started/full-installation-tutorial.md) using the `collection_name` option. See the [contract code](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L93) for details. 
 - `hash_key_name`: The custom contract package hash NamedKey as a String. See the [ARG_HASH_KEY_NAME_1_0_0](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L2006).
 - `access_key_name`: The custom contract package access NamedKey as a String. See the [ARG_ACCESS_KEY_NAME_1_0_0](https://github.com/casper-ecosystem/cep-78-enhanced-nft/blob/408db77c3b9ca22752c7f877ea99a01dfca03a7b/contract/src/main.rs#L2005).
 
@@ -64,7 +64,7 @@ Here is the full list of required arguments:
 - `secret-key`: The file name containing the secret key of the account paying for the deploy.
 - `payment-amount`: The payment for the deploy in motes.
 - `session-path`: The path to the compiled Wasm on your computer. When using the [cep-78-wasm.tar.gz](https://github.com/casper-ecosystem/cep-78-enhanced-nft/releases/download/v1.1.1/cep-78-wasm.tar.gz) provided, this would be the path to the `contract.wasm` file.
-- `named_key_convention`: Argument that specifies the use of the `V_1_0_standard` [NamedKeyConvention](../docs/modalities.md#namedkeyconventionmode).
+- `named_key_convention`: Argument that specifies the use of the `V_1_0_standard` [NamedKeyConvention](../modalities.md#namedkeyconventionmode).
 - `collection_name`: Argument that specifies the collection name as a String.
 - `hash_key_name`: The custom contract package hash NamedKey as a String.
 - `access_key_name`: The custom contract package access NamedKey as a String.
@@ -85,7 +85,7 @@ The following is an example of upgrading and migrating to version 1.1.1 of a pre
 
 ```bash
 casper-client put-deploy \
---node-addres http://65.21.235.219:7777 \
+--node-addres https://rpc.testnet.casperlabs.io/ \
 --chain-name "casper-test" \
 --secret-key ~/KEYS/secret_key.pem \
 --payment-amount 300000000000 \