search

corda / corda-solutions

Corda Solutions
28 stars 40 forks source link

Added fix for Meta Data using Java.lang classes and also added flow for Self Issuance of Membership by BNO #102

Closed bkreiser closed 5 years ago

bkreiser commented 5 years ago

This PR fixes an issue where the membership meta data in the MembershipState couldn't be a Java system class like java.lang.String. If you used a String for the meta data before this fix you would get a Null Pointer on the "this.membershipMetadata.javaClass.location" call in getAttachmentIdForGenericParam() function.

Also, added a flow for a BNO to self issue his own Membership

bkreiser commented 5 years ago

Sorry; misinterpreted what you wanted. Two transactions in my flow then and don’t mess with contract code?

On Tue, Jun 4, 2019 at 2:20 AM Ivan Schasny notifications@github.com wrote:

@ivanr3 requested changes on this pull request.

In bn-apps/memberships-management/membership-service-contracts-and-states/src/main/kotlin/com/r3/businessnetworks/membership/states/Membership.kt https://github.com/corda/corda-solutions/pull/102#discussion_r290178920:

  • is Commands.Activate -> verifyActivate(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Amend -> verifyAmend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • else -> throw IllegalArgumentException("Unsupported command ${command.value}")
  • when (tx.commands.size) {
  • 1 -> {
  • val command = tx.commands.requireSingleCommand()
  • when (command.value) {
  • is Commands.Request -> verifyRequest(tx, command, outputMembership)
  • is Commands.Suspend -> verifySuspend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Activate -> verifyActivate(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Amend -> verifyAmend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • else -> throw IllegalArgumentException("Unsupported command ${command.value}")
  • }
  • }
  • 2 -> verifySelfIssue(tx, tx.commands, outputMembership) // BNO self activate

What is the logic behind this? Why 2 commands would mean self issue? Can BNO not just self issue state and then activate it straight away? I.e. it would require 1 extra flow for example SelfIssueStateFlow that would invoke IssueStateFlow and ActivateStateFlow, and also some minimal changes to the contract code to allow BNO and Member to be the same Party.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/corda/corda-solutions/pull/102?email_source=notifications&email_token=AA2AWHUOQS3EF7KFSNIOY5LPYYQVZA5CNFSM4HQSZVI2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB2POUGI#pullrequestreview-245295641, or mute the thread https://github.com/notifications/unsubscribe-auth/AA2AWHWHYERWECIJ374MOWLPYYQVZANCNFSM4HQSZVIQ .

--

*Barry Kreiser | Director/CTO | GuildOne Inc.*

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

bkreiser commented 5 years ago

The reason I didn’t straight out just call the request and activate as subflows comes back to my original problem that I was having around with the (Do not provide flow sessions for the local node. FinalityFlow will record the notarised transaction locally). That is why I suggested making the new self issue flow.

On Tue, Jun 4, 2019 at 5:27 AM Barry Kreiser barry@guild1.com wrote:

Sorry; misinterpreted what you wanted. Two transactions in my flow then and don’t mess with contract code?

On Tue, Jun 4, 2019 at 2:20 AM Ivan Schasny notifications@github.com wrote:

@ivanr3 requested changes on this pull request.

In bn-apps/memberships-management/membership-service-contracts-and-states/src/main/kotlin/com/r3/businessnetworks/membership/states/Membership.kt https://github.com/corda/corda-solutions/pull/102#discussion_r290178920 :

  • is Commands.Activate -> verifyActivate(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Amend -> verifyAmend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • else -> throw IllegalArgumentException("Unsupported command ${command.value}")
  • when (tx.commands.size) {
  • 1 -> {
  • val command = tx.commands.requireSingleCommand()
  • when (command.value) {
  • is Commands.Request -> verifyRequest(tx, command, outputMembership)
  • is Commands.Suspend -> verifySuspend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Activate -> verifyActivate(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • is Commands.Amend -> verifyAmend(tx, command, outputMembership, tx.inputsOfType<MembershipState<*>>().single())
  • else -> throw IllegalArgumentException("Unsupported command ${command.value}")
  • }
  • }
  • 2 -> verifySelfIssue(tx, tx.commands, outputMembership) // BNO self activate

What is the logic behind this? Why 2 commands would mean self issue? Can BNO not just self issue state and then activate it straight away? I.e. it would require 1 extra flow for example SelfIssueStateFlow that would invoke IssueStateFlow and ActivateStateFlow, and also some minimal changes to the contract code to allow BNO and Member to be the same Party.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/corda/corda-solutions/pull/102?email_source=notifications&email_token=AA2AWHUOQS3EF7KFSNIOY5LPYYQVZA5CNFSM4HQSZVI2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB2POUGI#pullrequestreview-245295641, or mute the thread https://github.com/notifications/unsubscribe-auth/AA2AWHWHYERWECIJ374MOWLPYYQVZANCNFSM4HQSZVIQ .

--

*Barry Kreiser | Director/CTO | GuildOne Inc.*

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6

--

*Barry Kreiser | Director/CTO | GuildOne Inc.*

Suite 940 333-5th Avenue SW, Calgary, AB T2P 3B6