How is this second argument of [Party] supposed to be used?
The first argument is the actAs party of your trigger, the second argument are the readAs parties of your triger.
If a contract is submitted as a submitMulti (multiple signatories), can the trigger receive these multiple parties, as the signature is a single Party for actAs?
Triggers cannot submit commands with multiple actAs parties.
But they can definitely read contracts created that way. Triggers don’t really care how the contract was created, as long as one of the readers (union of actAs and readAs) is a stakeholder on the contract, they’ll receive the contract.
Okay then I must be missing a concept here… I have read the docs and trigger lib doc multiple times, and confused on this concept:
If you have a trigger that receives “AllInDar”, the trigger is activated per applicable transaction? Where the ACS represents the contracts created/modified within the transaction? If yes, then how does a trigger execute a multi-party submit back into the ledger without the rule passing in the multiple actAs from the transaction?
In the chat example, the echo message was sent with:
T.dedupExercise sender (User.SendMessage p "Please, tell me more about that.")
where p is coming from the lambda of the rule (rule = \p -> do).
(without multiSubmit are you not losing the ability to keep passing the chain?, and if it is a multi-submit, which actAs is passed into the trigger? the first?)
Is this a limitation by design?
If yes, then how does a trigger execute a multi-party submit back into the ledger without the rule passing in the multiple actAs from the transaction?
The trigger doesn’t pass multiple actAs back to the ledger. The parties used on command submissions are exactly the single actAs party + the readAs parties of your trigger. Just because you can read a contract does not mean you can create it. A very simple example to demonstrate that consider a contract with one signatory & one observer: The trigger might only be an observer but if they’re not the signatory they’re not going to be able to create (a copy of) that contract.
thank you. So to recap:
This comment i think solved the design issue for me:
-
Triggers are run as a defined party when setting up the trigger (thus not necessarily needing multi ActAs)
-
Triggers are only to act on the data within the ACS: They cannot query the ledger and they cannot receive the async response of a choice (so you cannot fetch from the ledger through a choice).
Is that accurate?
If yes, this relates back to my contract-role question(s): Where if you cannot have multiple ActAs and you cannot fetch from the ledger, you end up having to create “more and more” contract layers to get enough info into the ACS: such as:
- Pool
- Pool member
- Choice on Pool Member to “Validate Membership” controlled by a trigger party. and the choice runs some logic and generates a “ValidatedMembership” contract (where to validate the Member, the choice would have to fetch the Pool and compare signatories and pool data)
- A second trigger instance picks up on the ValidatedMembership and adds the member into the user service. The validation Logic is executed in the Contract choice instead of being executed in the trigger.
If that flow is correct, the confusion is the amount of layering (contracts and trigger instances) that is required to perform typical business flows feels “not-typical”. It takes a departure in “traditional” design.
Your trigger description sounds right.
As for the specific flow, I think I don’t understand your model well enough to comment on whether that’s the best flow. Maybe you can provide a minimal example to demonstrate the issue?
Generally, I view multi-party actAs as something that is useful during development but usually not something you should do in production. Providing someone else full actAs authorization over your party is usually not a reasonable option in a production system. Multi-party readAs on the other hand can be reasonable. That also matches what triggers provide: They don’t allow for multi-party actAs but they do allow for multi-party readAs.