search

dyne / reflow-os

Base scripts to run Reflow OS
7 stars 2 forks source link

Question; how to model repair #9

Open ocataco opened 3 years ago

ocataco commented 3 years ago

first i do a transfer-custody of a garment resource from a consumer agent to a repairshop agent. (transfer-custody, because the consumer still owns his garment)

next i want the repair shop agent to do a modify on the resource (to repair it) but i get the error "You cannot do this since the provider is not accountable for the resource"

please advise, thanks!

sbocconi commented 3 years ago

From the gitter discussion:

Hello, just a small question we came up during implementation, is there in ValueFlows the concept that only the primaryAccountable Agent can perform an action on a resource? If I tranfer-custody of my bike to a repair shop, can the repair show perform a modify of the bike to repair it? Or is this the wrong way of modelling it? This is related to an issue we are having in ReflowOS: dyne/reflow-os#9

Bob Haugen Valueflows does not specify permissions. You could create permissions in code based on Valueflows Agent relationships to EconomicResources (primaryAccountable, what agent has custody at the moment), and Agent Relationships and Roles. Another way you could do it is with ObjectCapabilities, which you can read a bit about here: https://gitlab.com/spritely/ocappub/blob/master/README.org With OCaps, the PrimaryAccountable Agent could give a capability to the repair shop to modify the bike. Or the repair shop could send a proposal to the PrimaryAccountable Agent with an estimate for bike repair and the PrimaryAccountable Agent could agree, and when the repair shop does the work, either they (if they have a capability or other permission) could update the bike, or send the info to the Primary Accountable who could log the information about the bike repair in FabCity OS. Does that all make sense? And Lynn what do you think?

Lynn Foster This makes sense. Basically, permissions seem to me to be network specific, based on the nature of the network and its governance. My opinion is that generally, rules like "only the primary accountable can modify a resource" should not be hard-coded into the backend code. And also specifically, that rule is too narrow for many situations. VF provides some hooks in the data that could govern permissions as needed, but not permissions themselves. My opinion is that generally, rules like "only the primary accountable can modify a resource" should not be hard-coded into the backend code. And also specifically, that rule is too narrow for many situations.

That said, of course my opinion doesn't count, it needs to be the opinion of the users of the application. In this case, my comment assumes that the backend could support many use cases and different sets of users.

sbocconi commented 2 years ago

I have modelled a similar case with transfer-custody and when I use an accept-modify action, I still indicate as the provider id the id of the primaryAccountable agent.

This for me can make sense if we consider that the provider is not necessarily the agent that performs an action, but the provider of the resource.

Or is this a wrong interpretation, @bhaugen and @fosterlynn?

bhaugen commented 2 years ago

I have modelled a similar case with transfer-custody and when I use an accept-modify action,

That part is correct.

I still indicate as the provider id the id of the primaryAccountable agent.

This for me can make sense if we consider that the provider is not necessarily the agent that performs an action, but the provider of the resource.

Or is this a wrong interpretation, @bhaugen and @fosterlynn?

I think it depends on your goals.

One aspect of a repair process is that the same resource is both an input (using the "accept" action) and an output (using the "modify" action). But there is also at least one other input, the work or service that does the repair, and also often some new parts, tools, equipment, etc. Those are usually provided by one or more other agents, not the primary accountable of the resource being repaired. That agent is the receiver of the modify (repaired) output.

The provider on the output event depends a lot on the situation. Is the repair being done by something like a repair shop? Then that's the provider of the modify event. Or if it's an internal company repair shop, it's the company or a department or unit of the company. Or it could be whoever did the repair work.

Might depend on who you want to get credit for the repair output. We've seen situations where workers get credit for outputs rather than "hours of work" inputs. And if it makes most sense to have the primary accountable agent be both provider and receiver, that might be ok too.

So some of this depends on your overall goals for accounting and what would further them. It's more utility than science, although there was some design involved in understanding that the same resource is both an input and an output. (Not designed by Valueflows, copied from a previous 1990's era system called Prism, which was the first system that I know of that modeled those situations correctly.)

Did that all make sense? @fosterlynn ? Got any improvements to offer?