Finalise fulfillment & satisfaction data structures about hrea

[fosterlynn]

Made some changes to those records in the current VF release, fyi. Should be stable for now from that side.

[pospi]

@fosterlynn I'm going to have to set this up so that fulfillments can only be managed via the planning DNA for now... does that sound like the most sensible course of action?

Can't have it work both ways- see https://forum.holochain.org/t/bidirectional-bridging/705

[fosterlynn]

@pospi I can't respond from the technical HC side, but will say from the data/functional side that Fulfillments are only created when EconomicEvents are created, never from the planning side. For many use cases, EconomicEvent to Commitment is M:1, so in a lot of UI's, people will be either entering their EE, and picking what Commitment it fulfills (and assuming the same qty), or starting from the Commitment on the UI and entering an EE that fulfills the Commitment (again assuming the same qty). For other use cases the M:M will come into play, and people will be entering an EE, and picking more than one Commitment it fulfills and entering the fulfillment quantities. At least that is how I picture it for use cases I am aware of.

(For all process related things, it will pretty much be M:1, for exchange related things, it can frequently be M:M. We decided to keep the structure consistent (one way to do it) rather than two ways to do it, one of which is simpler.)

So as a gut response from the functional side without knowledge of the ins and outs of DNAs, I'd say manage Fulfillment from the Observation side, and make it part of that module.

[pospi]

I've actually done it the other way around, which I think makes more sense. A participant has no reason to log fulfillments if not for commitments they are aware of, correct? So should it not be something that is done in the planning DNA?

I think I see it as "fulfilling a commitment" is an action which happens in the planning module, and observation modules are notified (retroactively) by planning modules that their events have gone to fulfill other commitments.

To be clear- the records end up on both sides. See complete test case to get a sense of the data and links involved.

[fosterlynn]

A participant has no reason to log fulfillments if not for commitments they are aware of, correct? So should it not be something that is done in the planning DNA?

A fulfillment makes no sense without both commitment and event in all cases.

I looked at your test case, and it looks like the event is recorded first in observation, then the fulfillment, which goes first to planning then to observation. So it still seems to me more clean to record the event and record the fulfillment in the same module, then duplicate it into the (already existing and known) planning data. But I suppose it doesn't really make a lot of difference. So you can ignore my gut sense of it, I'm not there. :)

[pospi]

I think it should be bidirectional, ideally- participants with access to either network should be able to trigger saving the fulfillment. But we'll see what the core team says about cyclic dependencies in DNA bridging configurations.

[fosterlynn]

I think it should be bidirectional, ideally- participants with access to either network should be able to trigger saving the fulfillment.

What is the use case you imagine for coming at it from the commitment side instead of when logging an event? And what is the use case when would someone saving a fulfillment not have access to both observation and planning?

[pospi]

I think I'll split this out and log as a separate issue when it becomes an important detail. For now it's a minor technical thing- someone saving a fulfillment should always have access to both DNAs; the concern is only for others reading.

The basic implementation is more or less complete now, I just need to loosen the validation on the Satisfaction satisfiedBy Commitment links, since they are optional (can also reference an EconomicEvent in a foreign DNA). Expect a PR tomorrow some time.

[fosterlynn]

I just need to loosen the validation on the Satisfaction satisfiedBy Commitment links, since they are optional (can also reference an EconomicEvent

That's probably one I forgot earlier, one of those has to be present (Commitment or EE).

[pospi]

Completed in #59.