Updated the code to create session only if the recipient is not the node initiating the flow#13
Updated the code to create session only if the recipient is not the node initiating the flow#13ajithathayahar wants to merge 3 commits intocorda:masterfrom
Conversation
ajithathayahar
commented
Mar 11, 2019
- IssueToken -> Checked and created the session only if the node running the flow is different from the owner. Please check whether I have created owningParty correctly in case if anonymous is set to true
- UpdateEvolvableToken -> Filtered the updateSubscribers list in case if the node running the flow is part of the updateSubscribers list. This will happen, if we have self-issued token.
- MoveToken -> When a token is transferred to a party, I felt that new party should be added to the distribution list hence added a subflow AddPartyToDistributionList. If this is not needed, please let me know.
…ode running the flow
…in UpdateEvolvableToken.kt
roger-that-dev
left a comment
There was a problem hiding this comment.
Thanks for the contribution! Some minor changes to make - ping me on slack if you'd like to talk through any of the comments. I realise that these flows are a bit of a mess and need tidying up. What I'd like to do in future is to make each of the flows smaller and more simple and then allow them to be composed together easily with sub flows.
| val owningParty: AbstractParty = if (anonymous) { | ||
| subFlow(RequestConfidentialIdentity.Initiator(ownerSession)).party.anonymise() | ||
| } else owner | ||
| val owningParty: AbstractParty |
There was a problem hiding this comment.
maybe this can be a conditional assignment? val owningParty = if (x) { y() } else { z() }
| } else owner | ||
|
|
||
|
|
||
| if (ownedToken is TokenPointer<*>) { |
There was a problem hiding this comment.
I'm not sure how this will work. I set up the distribution list so that only the creator of the evolvable token type has the distribution list, as they are the only ones which can update the list. Here we are setting up a distribution list on the party which is moving the token (which references the evolvable token type) to another node. So they will have a list but there is no code path in the token SDK currently which would result in this non-issuer party forwarding on the evolvable token updates.... This is where data distribution groups come in. I realise that for now, the functionality here is quite limited until we get data distribution groups. The solution is for all Partys to manually sign up with the maintainer of the evolvable token type using the RequestAdditionToDistributionList flow.
There was a problem hiding this comment.
Shall i remove this AddPartyToDistributionList? I misunderstood the concept and to enable all parties receiving the updates when an update happens on the evolvable token, I added this.