Minor styling fixes for documentation

docs/Permissioning/Contract Design.md

@@ -3,6 +3,7 @@ The permissions model is completely built on smart contracts. The smart contract
 ![contract design](images/ContractDesign.png)
 
 The permissions smart contract design follows the Proxy-Implementation-Storage pattern which allows the implementation logic to change without changing the storage or interface layer. A brief description of the smart contracts is below:
+
 * `PermissionsUpgradable.sol`: This contract stores the address of current implementation contract and is owned by a custodian (an Ethereum account). Only the custodian is allowed to change the implementation contract address. 
 * `PermissionsInterface.sol`: This is the interface contract and holds the interfaces for permissions related actions. It has no business logic and forwards requests to the current implementation contract
 * `PermissionsImplementation.sol`: This contract has the business logic for the permissions actions. It can receive requests only from a valid interface as defined in `PermissionsUpgradable.sol` and interacts with all the storage contracts for respective actions.

docs/Permissioning/Overview.md

@@ -1,5 +1,5 @@
 # Introduction
-The [current permission model](../Old%20Permissioning.md) within Quorum is limited to node level permissions only and allows a set of nodes which are part of `permissioned-nodes.json` to join the network. The model has been enhanced to cater for enterprise level needs to have a **smart contract based permission model**; this has the flexibility to manage nodes, accounts and account level access controls. The overview of the model is as depicted below:
+The [current permission model](../Old%20Permissioning) within Quorum is limited to node level permissions only and allows a set of nodes which are part of `permissioned-nodes.json` to join the network. The model has been enhanced to cater for enterprise level needs to have a **smart contract based permission model**; this has the flexibility to manage nodes, accounts and account level access controls. The overview of the model is as depicted below:
 ![permissions mode](images/PermissionsModel.png)  
 ### Key Definitions
 * Network - A set of interconnected nodes representing an enterprise blockchain which contains organizations

docs/Permissioning/Permissioning apis.md

@@ -175,10 +175,11 @@ quorumPermission.approveOrg("ABC", "enode://3d9ca5956b38557aba991e31cf510d4df641
 ```
 #### quorumPermission.updateOrgStatus
 This api can only be executed by a network admin account and is used for temporarily suspending an organization or re-enabling a suspended organization. This activity can be performed for master organization only and requires majority approval from network admins.
+
 * Input: organization id, action (1 for suspending the organization and 2 for activating a suspended organization)
 * Output: Status of the operation
 * Example:
-```$xslt
+```
 > quorumPermission.updateOrgStatus("ABC", 1, {from:eth.accounts[0]})
 {
   msg: "Action completed successfully",
@@ -190,7 +191,7 @@ This api can only be executed by a network admin account and is used for approvi
 * Input: organization id, action (1 for suspending the organization and 2 for activating a suspended organization)
 * Output: Status of the operation
 * Example:
-```$xslt
+```
 > quorumPermission.approveOrgStatus("ABC", 1, {from: eth.accounts[0]})
 {
   msg: "Action completed successfully",
@@ -227,6 +228,7 @@ It should be noted that, parent org id should contain the complete org hierarchy
 ```
 #### quorumPermission.addNewRole
 This api can be executed by an organization admin account to create a new role for the organization.
+
 * Input: organization id or sub organization id, alphanumeric role id, account access ([access values](#account-access-types))(, isVoter, isAdminRole
 * Output: Status of the operation
 * Example:
@@ -244,6 +246,7 @@ This api can be executed by an organization admin account to create a new role f
 ```
 #### quorumPermission.removeRole
 This api can be executed by an organization admin account to create a new role for the organization.
+
 * Input: organization id or sub organization id, role id
 * Output: Status of the operation
 * Example:
@@ -256,6 +259,7 @@ This api can be executed by an organization admin account to create a new role f
 ```
 #### quorumPermission.addAccountToOrg
 This api can be executed by an organization admin to add an account to an organization and assign a role to the account
+
 * Input: Account id, organization id or sub organization id, role to be assigned
 * Output: Status of the operation
 * Example:
@@ -267,7 +271,7 @@ This api can be executed by an organization admin to add an account to an organi
 }
 ```
 The account can at best be linked to a single organization or sub organization and cannot belong to multiple organizations or sub organizations
-```$xslt
+```
 > quorumPermission.assignAccountRole("0xf017976fdf1521de2e108e63b423380307f501f8", "ABC.SUB1", "TRANSACT", {from: eth.accounts[1]})
 {
   msg: "Account already in use in another organization",
@@ -276,6 +280,7 @@ The account can at best be linked to a single organization or sub organization a
 ```
 #### quorumPermission.changeAccountRole
 This api can be executed by an organization admin account to assign a role to an account.
+
 * Input: Account id, organization id or sub organization id, role to be assigned
 * Output: Status of the operation
 * Example:
@@ -289,6 +294,7 @@ This api can be executed by an organization admin account to assign a role to an
 
 #### quorumPermission.updateAccountStatus
 This api can be executed by an organization admin account to update the account status.
+
 * Input:  organization id or sub organization id, Account id, action (1 for suspending the account, 2 for activating a suspended account, 3 for blacklisting the account)
 * Output: Status of the operation
 * Example:
@@ -302,7 +308,8 @@ This api can be executed by an organization admin account to update the account
 Once a account is blacklisted no further action is allowed on it.
 
 #### quorumPermission.assignAdminRole
-This api can be executed by the network admin to add a new account as network admin or change the org admin account for an organization. 
+This api can be executed by the network admin to add a new account as network admin or change the org admin account for an organization.
+
 * Input: organization id to which the account belongs, account id, role id (it can be either org admin role or network admin role)
 * Output: Status of the operation
 * Example:
@@ -316,6 +323,7 @@ This api can be executed by the network admin to add a new account as network ad
 
 #### quorumPermission.approveAdminRole 
 This api can be executed by the network admin to approve the organization admin or network admin role assignment to an account. The role is approved once majority approval is received.
+
 * Input: organization id to which the account belongs, account id
 * Output: Status of the operation
 * Example:
@@ -330,6 +338,7 @@ This api can be executed by the network admin to approve the organization admin
 
 #### quorumPermission.addNode
 This api can be executed by the organization admin account to add a node to the organization or sub organization.
+
 * Input:  organization id or sub organization id, enode id
 * Output: Status of the operation
 * Example:
@@ -344,6 +353,7 @@ A node cannot be part of multiple organizations.
 
 #### quorumPermission.updateNodeStatus
 This api can be executed by the organization admin account to update the status of a node.
+
 * Input:  organization id or sub organization id, enode id, action (1 for deactivating the node, 2 for activating a deactivated node and 3 for blacklisting a node)
 * Output: Status of the operation
 * Example:
@@ -381,7 +391,7 @@ The table below indicates the numeric value for various account statuses.
 | Blacklisted     |               5 |
 | Revoked         |               6 |
 
-#### Account access types
+### Account access types
 The table below indicates the numeric value for each account access type.
 
 | AccessType      |           Value |

docs/Permissioning/setup.md

@@ -4,7 +4,7 @@ The steps to enable new permissions model are as described below:
 * Deploy the `PermissionsUpgradable.sol` in the network. The deployment of this contract will require a custodian account to be given as a part of deployment. 
 * Deploy the rest of the contracts. All the other contracts will require the address of `PermissionsUpgradable.sol` contract as a part of deployment.
 * Once all the contracts are deployed create a file `permission-config.json` which will have the following construct:
-```$xslt
+```json
 {
            "upgradableAddress": "0x1932c48b2bf8102ba33b4a6b545c32236e342f34",
            "interfaceAddress": "0x4d3bfd7821e237ffe84209d8e638f9f309865b87",
@@ -38,12 +38,11 @@ The steps to enable new permissions model are as described below:
 > * `subOrgDepth` indicates the maximum depth of sub org hierarchy allowed in the network
 
 * Once the contracts are deployed `init` in `PermissionsUpgradable.sol` need to be executed by the custodian account. This will link the interface and implementation contracts. A sample script for loading the upgradable contract at `geth` prompt is as given below
-```$xslt
+```javascript
 ac = eth.accounts[0];
 web3.eth.defaultAccount = ac;
 var abi = [{"constant":true,"inputs":[],"name":"getPermImpl","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_proposedImpl","type":"address"}],"name":"confirmImplChange","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"constant":true,"inputs":[],"name":"getCustodian","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":true,"inputs":[],"name":"getPermInterface","outputs":[{"name":"","type":"address"}],"payable":false,"stateMutability":"view","type":"function"},{"constant":false,"inputs":[{"name":"_permInterface","type":"address"},{"name":"_permImpl","type":"address"}],"name":"init","outputs":[],"payable":false,"stateMutability":"nonpayable","type":"function"},{"inputs":[{"name":"_custodian","type":"address"}],"payable":false,"stateMutability":"nonpayable","type":"constructor"}];
-var upgr = web3.eth.contract(abi).at("0x1932c48b2bf8102ba33b4a6b545c32236e342f34"); // address of the upgradable contr
-acts
+var upgr = web3.eth.contract(abi).at("0x1932c48b2bf8102ba33b4a6b545c32236e342f34"); // address of the upgradable contracts
 var impl = "0xfe0602d820f42800e3ef3f89e1c39cd15f78d283" // address of the implementation contracts
 var intr = "0x4d3bfd7821e237ffe84209d8e638f9f309865b87" // address of the interface contracts
 ```