-
|
I am trying to create a policy modelling the attached flow, where an AIM can give rise to multiple EGOs and multiple Claim Sources, A Claim can be associated to one or more of each of the EGO and Claim Sources, but must be associated to a minimum of 1 of each. The relationships between the AIM and the Claim Sources (CS) as well as between the AIM and the EGO are generated. However, trying to associate the Claim with the EGO and CS documents is not working. Things I have tried:
Alex has also looked at this policy and it should create the association. He also tried multiple variations and something seems up with the IAB. I know the Trust Chain in this policy needs work. I don't need you to fix it unless you have free time. I'm more concerned about the actual chain of documents and being able to connect them than I am with displaying them in Guardian right now. I do need help with why the association between the Claim and the EGO and CS is not persisting in either relationships (why the error) or the new field (as in this policy attached). If you have other suggestions as to how the policy could be written (ie. not using the IAB but rather another block to accomplish the goal) I am happy for those suggestions as well. Thank you!
|
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 1 reply
-
|
It’s not but the symptoms are similar. This one is about the IAB not
working which makes setting relationships between the documents that way
impossible. If there are different policy blocks to use for what I’m trying
to do or if there’s some way to better use the IAB, that’s what I need to
know.
*Cyndy Montgomery*
*Director of Ecosystem Partnerships*
email: ***@***.***
…On Tue, Apr 16, 2024 at 4:32 AM Andrey (Envision Blockchain) < ***@***.***> wrote:
@CyndyMo <https://github.com/CyndyMo> is this a duplicate of #3270
<#3270>?
—
Reply to this email directly, view it on GitHub
<#3546 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2AORXJYPIP6ILBX2XCVOVTY5TV2LAVCNFSM6AAAAABGH2QNSSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCMRYGAYTM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
We worked through your policy and the description for the workflow you are trying to express in the Policy. Unfortunately at present
The good news is that it is possible through the API, i.e. you can pass an array of relationships in the corresponding API call and it'll be correctly processed by the Back End. To provide this possibility via the UI we could make Please let me know your thoughts. In any case the UI part requires some work, the absolute earliest that this could come is in the upcoming 2.24 release. |
Beta Was this translation helpful? Give feedback.
-
|
The plan is API interaction with the policy right now, so to make sure,
would I take out the associate pieces in the policy and just create the
relationships when posting to the Request VC document block for the claim?
If the answer is yes, then I'll await the discussion Alex added to the Q&A
I logged about creating relationships via API :).
…On Wed, Apr 17, 2024 at 9:52 AM Andrey (Envision Blockchain) < ***@***.***> wrote:
We worked through your policy and the description for the workflow you are
trying to express in the Policy. Unfortunately at present ActionBlock
does not allow to specify multiple relationships, i.e. when a user adds EGO
through the 'Associate EGO' and then adds a CS via the 'Add CS' tab the
value in the resulting document gets overwritten.
Screenshot.2024-04-17.at.15.36.49.png (view on web)
<https://github.com/hashgraph/guardian/assets/32775532/6ef824fe-32fc-4e3f-afeb-acf8b5b6fd23>
The good news is that it is possible through the API, i.e. you can pass an
array of relationships in the corresponding API call and it'll be correctly
processed by the Back End.
To provide this possibility via the UI we could make ActionBlock to
accept multi-select, or change the block to give user a choice between the
'overwrite' and 'append' actions (have some sort of switch in the block
config for that). In the former case the UI would have to change as shown
below, I am not sure whether this would be significant for you?
Screenshot.2024-04-17.at.15.36.55.png (view on web)
<https://github.com/hashgraph/guardian/assets/32775532/5db215f6-1018-40ba-9d08-3946295d1cb0>
Please let me know your thoughts. In any case the UI part requires some
work, the absolute earliest that this could come is in the upcoming 2.24
release.
—
Reply to this email directly, view it on GitHub
<#3546 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2AORXMIFEPWO54DLKGC2XLY52EDFAVCNFSM6AAAAABGH2QNSSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNBUGIYTK>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
We have brainstormed this case internally, thank you to @artembuslaev who have made improvements to the policy (attached):
The policy now works as described earlier, see the screenshots below (one shows how to send the data, the other ones showing the results).
Hopefully this gives you enough details to continue. |
Beta Was this translation helpful? Give feedback.
-
|
This was literally the first thing I tried and it gave me "Invalid Relationships" errors. Now I need to figure out why it worked for you and gave me errors... |
Beta Was this translation helpful? Give feedback.
-
|
I got this error in Dry Run. Is that expected? |
Beta Was this translation helpful? Give feedback.
-
|
@CyndyMo apologies if I was not clear, the solution suggested above will only work through API - as discussed earlier. |
Beta Was this translation helpful? Give feedback.
-
|
This is probably a really dumb question, but why do I need the interface
action block at all, then? Can't I just feed the relationships to the Claim
via API when I send that data to the Request VC document block?
…On Thu, Apr 18, 2024 at 12:02 PM Andrey (Envision Blockchain) < ***@***.***> wrote:
@CyndyMo <https://github.com/CyndyMo> apologies if I was not clear, the
solution suggested above will only work through API - as discussed earlier.
—
Reply to this email directly, view it on GitHub
<#3546 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2AORXONPTH47VZVPJNGED3Y574BLAVCNFSM6AAAAABGH2QNSSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNJXGYYDK>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
@CyndyMo apologies if I was not clear, the solution suggested above will only work through API - as discussed earlier.