v.4.1: primaryAccountable, transfer-complete > transfer

[fosterlynn]

Intermediate VF release v.4.1

• added primaryAccountable to EconomicResource (the agent who "owns" the resource - or is responsible for reporting on accounting reporting)
• changed name of action transfer-complete to just transfer (dev request)

@pospi I'm not sure I covered the first one correctly in mutations, I added to EconomicResourceCreateParams but not to EconomicResourceUpdateParams. Trying to follow the pattern I see, but don't know how these are exactly used. Please correct as needed, thanks.

[pospi]

@fosterlynn it depends on how the field is supposed to work. I don't see any way of updating it via events, but it also seems like an accounting field that shouldn't be updateable directly. Do you agree? Perhaps it should be modified via transfer or transfer-all-rights, but I don't think so... that's just moving things between already existing inventories.

Basically it seems like it should be a non-editable field that requires zeroing a resource and starting again in order to change... does that seem sensible at this stage?

[fosterlynn]

I don't see any way of updating it via events, but it also seems like an accounting field that shouldn't be updateable directly.

Yes, thanks, should specify. Here's what I think, not tested yet obviously. We'll have to find out in practice if there are edge cases I haven't thought of.

On resource creation (produce, etc.), it can be set to the event receiver agent. When there is a transfer or transfer-all-rights event, it (now the toResourceInventoriedAs, whether a new one or not) can be set to the receiver agent.

Does that mean it shouldn't go in either of those param sets? Or both?

[pospi]

Neither, then. I'll take it out and file an issue for Holo-REA.

[fosterlynn]

Neither, then. I'll take it out and file an issue for Holo-REA.

Thanks! And now I start to understand how those work...

[pospi]

Actually, could be more to consider. How does it get initialised for raise events? It might imply making receiver a required field in some cases.

Perhaps it should be present on EconomicResourceCreateParams so that it can be initialised when the agent responsible for the accounting of a resource is not the agent who is logging it in inventory?

I dunno, would be good to read through the original VF issue link to understand what this parameter is for. It feels like a simplification of inScopeOf in some ways...

[fosterlynn]

How does it get initialised for raise events?

I think it is consistent and safe for the receiver on a raise event to be the primaryAccountable, if the resource is being created. Can't think of any times that a raise wouldn't have the main agent on both provider and receiver. And a raise never transfers agents.

[pospi]

@fosterlynn I think the validation might have to be: if we're creating a new resource, receiver must be present. That will cover all these cases as a side-effect.

[fosterlynn]

I think the validation might have to be: if we're creating a new resource, receiver must be present.

I thought provider and receiver are both required on all events?

[pospi]

touche

On Tue, 11 Feb 2020 at 23:18, Lynn Foster notifications@github.com wrote:

I think the validation might have to be: if we're creating a new resource, receiver must be present.

I thought provider and receiver are both required on all events?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/valueflows/vf-graphql/pull/65?email_source=notifications&email_token=AADK2JB4ASMMZBK3GVJAYXDRCKQUDA5CNFSM4KSBYPQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELML6VY#issuecomment-584630103, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADK2JHUPSNL3YZWLCSVWJDRCKQUDANCNFSM4KSBYPQQ .

-- writings http://pospi.spadgos.com/ | twitter https://twitter.com/pospigos | github https://github.com/pospi ← where to find me ValueFlows https://www.valueflo.ws/ | Holo-REA https://github.com/holo-rea/ ← things I'm working on

[pospi]

Superceded by #69