Context agent overview page UI & API

[fosterlynn]

We are thinking this will be the first page to implement, per discussion in telegram. Here is the latest mockup:

First look, here are the API requirements:

general bars:

• get user
• get agent (the user agent)
• get projects (context agents) that the user agent has an association with

project overview:

• get project (context agent)
• get project members (agents)
• get count of project processes (I think only active ones?)
• get count of project recipes (later? - or include the count now, but not have it be a link?)
• get latest contributions: latest (some number? and/or by date?) of economic events related to the project; for each event, include process info
• get members who joined in the last (?) time period [edit: remove this, get it from the member list]
• get processes that have been marked finished in the last (?) time period
• get resources "owned" by the project (or with any relationship with the project?)

Thoughts?

[ivanminutillo]

get count of project processes (I think only active ones?)

instead of creating a custom endpoint for the length of total processes, we can have only an endpoint with the array of processes and the client calculate the length...in this way we have an endpoint less

get count of project recipes (later? - or include the count now, but not have it be a link?)

I think it's not prioritary in this epic we can leave a placeholder...

get latest contributions: latest (some number? and/or by date?) of economic events related to the project; for each event, include process info

Good point, I think it should be the latest economic events related to the project, which economic events we have? does are defined by a typology ? if yes, clientside I can define a different layout based for the event typology

get members who joined in the last (?) time period

Is it necessary? we can use only 'get project members' endpoint ?

[fosterlynn]

instead of creating a custom endpoint for the length of total processes, we can have only an endpoint with the array of processes and the client calculate the length...in this way we have an endpoint less

I don't think this page needs the processes for anything else, unless we drive off of processes for the latest contributions section. But I think that drives off of events instead.

Is it necessary? we can use only 'get project members' endpoint ?

Yes, makes sense.

[fosterlynn]

Good point, I think it should be the latest economic events related to the project, which economic events we have? does are defined by a typology ? if yes, clientside I can define a different layout based for the event typology

Events are defined by event types, which are Work, Use, Consume, Cite, Produce, Change (and ToBeChanged). The Work events will go on your Tasks step. We can figure out the differences - there are already methods that return a displayable thing for events, but we probably need to make some changes for the new UI.

[fosterlynn]

From chat:

@fosterlynn I was coding the project feed... I have not clear what type of item we'll include in... here what I imagined:

• processes notification |----- lynn created process ABC |----- lynn finished process ABC |----- lynn joined process ABC
• members notification |----- lynn joined project ABC |----- lynn left project ABC
• inventory notification |---- item ABC was added to project DEF |---- item ABC was removed to project DEF
• recipe notification |---- Recipe ABC was added to project DEF |---- Recipe ABC was removed to project DEF |---- Recipe ABC was edited to project DEF

Thinking about this further:

Unfortunately we can't do the members notification, we don't capture the create date on agent associations. (Of course, we could add it if we want, to the main app. Seems like it would be useful. In general, I really like the idea of having new happenings show on this page.)

Inventory notification: We can do that, and I like it.

Recipe notification: Looks like we can do that, from process type. Good idea.

Process notification: We can get process creation; process finishing would not be that accurate, we don't have a date specifically for that. We don't really have "join" a process, people commit to specific tasks and do the tasks. For process (and other) work, I wonder if we want to mostly show new events? Or would that be too much? You would see all the recent work, resource creation, resource consumption, etc. - but mostly work. I think that is generally a useful thing to see, although I'm not totally sure this is the best page for it. But I think that will be most of the new activity on a project in general. So why not? What do people think? (I will create an API for new events in any case.)

[fosterlynn]

Suggested data, not in any particular order, plus some rethinking of the above:

Inventory: I'm realizing that this is actually the same as the event part, since the way you know some resource has come into or gone out of inventory is through the events, so will put that into Process Notification.

Recipe notification: Rethinking: this is probably pretty low priority actually, maybe we should ignore it for now?

Events:

• Work (time contribution): Date, provider (agent) name, quantity/unit, skill (resource type)
• Produce: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Consume: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Use: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Change: Date, quantity/unit, resource type: resource (which I think will always be there)

Also could have process name, and/or event description (or the first x characters of it), but I'm not sure about those.... I'll put them into the API, and we can see? And of course the event type should be displayed.

Note: Work is the only different one.

[fosterlynn]

I missed process start above. That might be a good idea, it would tell people that something is being initiated and planned. We could show individual commitments too if we want, but I think that might be too much quantity, don't know. I hope we do have commitments that a person could do, based on skill, on another page.

Process start data: Name, published date, planned start date, maybe the first part of the description.

[ivanminutillo]

Recipe notification: Rethinking: this is probably pretty low priority actually, maybe we should ignore it for now?

Yeah, totally :)

I think for the mvp we can start just with the event notifications plus process start, if you all agree on... to sum up:

• Work (time contribution): Date, provider (agent) name, quantity/unit, skill (resource type)
• Produce: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Consume: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Use: Date, quantity/unit, resource type: resource (resource can be null, if so, just resource type)
• Change: Date, quantity/unit, resource type: resource (which I think will always be there)
• Process start: Name, published date, planned start date, maybe the first part of the description.

[fosterlynn]

I think for the mvp we can start just with the event notifications plus process start

Yeah, I think so, plus what do you think about:

Also could have process name, and/or event description (or the first x characters of it), but I'm not sure about those.... I'll put them into the API, and we can see? And of course the event type should be displayed.

[pospi]

What do you guys think about grouping events to the process, and having an aggregate at the top level that can be drilled down into to show all the individual contributions going on? Or an option to enable this- like "conversation view" in gmail.

[fosterlynn]

What do you guys think about grouping events to the process, and having an aggregate at the top level that can be drilled down into to show all the individual contributions going on? Or an option to enable this- like "conversation view" in gmail.

Still in the vein of showing most recent happenings, right? Like, here are the processes that had recent activity, by activity date descending?

OK by me. (I don't really have a sense of the level of event activity on processes for different groups, we don't have enough experience.)

Then, what about to-do's (simple tasks in OCP)? They don't have a process. Neither do "extra work" events, which tend to be used for "overhead" kinds of things. For both of these, there is probably an "implied" process in the real world, but it is not worth setting up all that machinery in OCP. (In ValueFlows, this has not been resolved after much discussion.)

[fosterlynn]

I was thinking about this page a little last night.... I'd like to explain the data structure a bit for agents and their relationships, thinking we may want to reflect this a bit more on this page.

So agent relationship types are user defineable, but they are assigned a hard coded behavior field which includes "member", "manager", and some others like "child" for sub-projects. So in OCP, they have several "member" relationship types: "participant", "member", "self-employed member". And they have coordinator as "manager" behavior. Both "member" and "manager" are really members and are included in most of the member methods. (Sensorica had basically only "affiliate" with "member" behavior - "manager" behavior was added by Freedom Coop because they want coordinators to have more permissions.)

Anyhow, I think in the api, a response structure for members of an organization should be more something like this:

organization
   Some Project
   participants
       Bob
       Lynn
   coordinators
       Alice
       Ivan

And we show that somehow in the UI too, @ivanminutillo your department. :)

What do you think?

[pospi]

I think it's going to be difficult to implement it with that grammar- it might be doable with generators or metaclasses, but it's going to be complicated. The reason being that the field/relationship names in graphene have to be hardcoded as attributes of the class. I've tried overloading __getattr__ but this doesn't make dynamic attributes discoverable by Graphene- we'd probably have to setup a metaclass that reads in all the relationship types and builds up a new class based on them- but there'd be no guarantee those generated field names wouldn't conflict with other core fields we might define on the agent schema.

I think instead, the better idea might be to genericse our agent -> agent relationships, and make them parameterisable similar to how I've done things with EconomicResourceCategory, but using raw strings instead. Then we could define any custom relationship type we want, and queries would look something like this:

organization {
  participants: relatedAgents(behaviour: MEMBER) { ... }
  coordinators: relatedAgents(rel: "coordinator") { ... }
}

Note the distinction between a behaviour, which would use an enum to restrict input to the hardcoded known types, and rel which would be a string matching mode that works on the user-defined relationship values.

Extra credit: we could generate the graphene.Enum for rel using a DB query and metaclass as described above, which I think gives us the best of all worlds.

[ivanminutillo]

And we show that somehow in the UI too, @ivanminutillo your department. :)

On the UI side it's not a problem, I had already prefigured a page for all the organization partecipants... actually is the 'members' section, that shows all the members with some related info, something like this:

we can add a role label under the name... So, the only change we should make at the interface is to change members into organizations on the secondary header component (Overview | Processes | Contributions | Partecipants) to be more generalist...

[bhaugen]

Ooh, Lynn, I like your picture! And you've multiplied... :stuck_out_tongue_winking_eye:

[fosterlynn]

I think instead, the better idea might be to genericse our agent -> agent relationships

Yes, they should be generic to the extent the data model is so. (I wasn't trying to be syntactically correct with my structure example, sorry about that.) I think this UI should not rely on Freedom Coop specific data choices, even though there are a bunch of hard-codings related to those that have been added to the models.

I'll try some things out in a branch. :)

[fosterlynn]

On the UI side it's not a problem, I had already prefigured a page for all the organization partecipants... actually is the 'members' section, that shows all the members with some related info,

So, could that page also have the role of each member?

And going further, should that page have all the relationships that a context agent has? Like even suppliers, etc.?

That is really another "project page" though, should we have two?

[fosterlynn]

By the way, we have a similar situation for "owned" economic resources. Actually the data structure allows for users to define any named relationship between agents and resources. And for example when a group thinks of their resources being part of the group commons, we have seen they might want a different name, like "custodian".

Again, there is a is_owner field so that we can piece out ownership roles.

(Note, VF hasn't really addressed this piece yet.)