Implement bidirectional links between Commitment.satisfies & Intent.satisfiedBy

[pospi]

This is a good first relationship to implement as it deals with same-DNA field links. Implementation requires:

• CREATE methods for Commitment & Intent in the planning DNA
  • Ability to create Satisfaction records as sub-records of a new Commitment
  • Ability to create Satisfaction records as sub-records of a new Intent
• CREATE method for Satisfaction
• UPDATE methods for Commitment & Intent (non-relational fields only)
• UPDATE method for Satisfaction
• DELETE method for Satisfaction
• DELETE methods for Commitment & Intent

I don't think there is any need to implement an ability to modify Satisfaction records via manipulation of Commitment or Intent- the client needs to be responsible for tracking which records to CREATE / DELETE anyway, so at that point they might as well call UPDATE / DELETE on Satisfaction directly. I do still think it's a nice convenience thing to have an ability to author them at Commitment / Intent logging time but am open to having my mind changed on that. I thought if nothing else it would be a good way to encourage splitting abstractions out.

We also need to define a naming convention for our zome API methods going forward, part of this issue is deciding on those naming conventions.

(BTW: if you think we need to define acceptance criteria for this and other issues I'm about to log, please let me know; otherwise happy for those tests to emerge as makes sense.)

[fosterlynn]

I don't think there is any need to implement an ability to modify Satisfaction records via manipulation of Commitment or Intent

Agree.

I do still think it's a nice convenience thing to have an ability to author them at Commitment / Intent logging time but am open to having my mind changed on that.

Up to you guys of course, and I'm kind of like you @pospi , it would be nice, but not essential. A couple thoughts.

One step farther, another thing that is part of committing to an intent is that if the commitment completely satisfies the intent, then the intent can be marked finished=true.

Another possible convenience, maybe going too far, is that probably most of the time, the satisfiedQuantity will be the same as the commitment quantity, so if not sent in as a parameter, that could be just assumed if you have the intent that was satisfied. Same with fulfilledQuantity and the event quantity.

Not recommending in any direction, just providing info.

[pospi]

I see finished as a special field... not editable on the main record. But I could be wrong. What do you all think about-

• autoset finished=true if the satisfied / fulfilled quantity matches or exceeds the requested quantity?
• ability to manually trigger intent_satisfied as a separate mutation (which would set finished=true), independently of create_intent & create_satisfaction?

[fosterlynn]

I see finished as a special field... not editable on the main record.

autoset finished=true if the satisfied / fulfilled quantity matches or exceeds the requested quantity?

No, finished needs to be human editable. It is there because we can't count on logic such as the above. There are many reasons that satisfied / fulfilled quantities won't match, including inaccurate estimates, changes of direction, etc. Depending on the situation, planned quantity is almost never right, think software development work estimates. :) On the other hand, the number of parts consumed in a manufacturing process will be much more often accurate. So it would be good to accommodate both of those scenarios smoothly.

[pospi]

Completed in #32.