diff --git a/chain-cli/chaincode-template/src/token/__snapshots__/api.spec.ts.snap b/chain-cli/chaincode-template/src/token/__snapshots__/api.spec.ts.snap index 3b91cf5f3e..83d0a073a3 100644 --- a/chain-cli/chaincode-template/src/token/__snapshots__/api.spec.ts.snap +++ b/chain-cli/chaincode-template/src/token/__snapshots__/api.spec.ts.snap @@ -1146,6 +1146,7 @@ The key is generated by the caller and should be unique for each DTO. You can us }, }, { + "description": " Allowed roles: SUBMIT. Allowed orgs: CuratorOrg.", "dtoSchema": { "description": "Fee Verification DTO. With a valid signature from an Authoritative User, used to verify that a Fee was paid across channels. Typically, this will be a type of multi-signature DTO or a double signed DTO. That is, the \`authorization\` property contains the original authorization DTO signed by the End User. And the overall FeeVerificationDto will be signed by an Authoritative/Administrative user (i.e. a CuratorUser). The Chaincode can then verify definitively that both a) the end user did authorize a spend, and b) the Authoritative/Administrative user confirms that this authorization was successfully approved/written/burned on the assets channel.", "properties": { @@ -3860,7 +3861,7 @@ The key is generated by the caller and should be unique for each DTO. You can us }, }, { - "description": " Allowed roles: SUBMIT. Allowed orgs: CuratorOrg.", + "description": " Transaction is read only (evaluate). Allowed roles: EVALUATE.", "dtoSchema": { "description": "Fetch vesting info including balances of allocations", "properties": { @@ -4204,6 +4205,7 @@ The key is generated by the caller and should be unique for each DTO. You can us }, }, { + "description": " Allowed roles: SUBMIT. Allowed orgs: CuratorOrg.", "dtoSchema": { "description": "Experimental: After submitting request to RequestMintAllowance, follow up with FulfillMintAllowance.", "properties": {