The release notes say something I think support this belief:
“In addition any contracts visible to any party in act_as or read_as may be accessed during interpretation. For example, if act_as = [Alice], readAs = [PricingObserver], Alice can submit a transaction with a Fetch on a price contract only visible to PricingObserver.”
How doeas this look like in practice?
I want to use this in a Script.
I’m stuck, because submitMulti needs Commands as argument, but queryContractKey what I need returns a Script.
First, if all you want is to fetch a single contract, you can pass the party to queryContractKey directly. The party argument is overloaded so you can also pass multiple parties, e.g., as a list and if the contract is visible to any of them it will succeed:
queryContractKey [alice, bob] key
Now let’s move on to submitMulti. The documentation here you quoted refers to contract fetches within a transaction. By default, each contract that you fetch must be visible to the submitting parties. That’s why the following example will fail even though the fetch is authorized by Bob (by virtue of him being a signatory).
module Main where
import Daml.Script
template T
with
p : Party
where
signatory p
template FetchTpl
with
p1 : Party
p2 : Party
where
signatory p1, p2
nonconsuming choice Fetch : T
with
cid : ContractId T
controller p1
do fetch cid
test = do
alice <- allocateParty "Alice"
bob <- allocateParty "Bob"
fetchCid <- submitMulti [alice, bob] [] $ createCmd (FetchTpl alice bob)
tCid <- submit bob $ createCmd (T bob)
submit alice $ exerciseCmd fetchCid (Fetch tCid)
pure ()
However, if we use submitMulti and add Bob to the readAs parties (or actAs which implies readAs), the scenario succeeds:
test = do
alice <- allocateParty "Alice"
bob <- allocateParty "Bob"
fetchCid <- submitMulti [alice, bob] [] $ createCmd (FetchTpl alice bob)
tCid <- submit bob $ createCmd (T bob)
submitMulti [alice] [bob] $ exerciseCmd fetchCid (Fetch tCid)
pure ()