Should resource types, exchange types, patterns be tied to contexts like projects?

[bhaugen]

By "context", I mean "context agent", like project, cooperative, group, etc.

As of now, they are not. Resource types apply to all contexts. That is necessary if different contexts want to trade with each other.

It may also be useful to have a set of common resource types that each context does not need to re-invent.

But it can also be confusing, and if a commonly-used resource type gets changed by one project, that can affect other projects.

Possible changes could be:

• tie all resource types to a context, and limit their use to that context, or
• optionally tie resource types to contexts, and allow others to be usable by all contexts, but changes to the common resource types could only be made by Freedom Coop admins.

[fosterlynn]

To deal with the context agent of a resource type or exchange type, was needed to figure out how a coordinator will choose from existing types

In my experience, there will not be a lot of exchange types, especially as we start to allow agent specific ones. It can be a dropdown. In fact would be best as some form of simple flat list - dropdown, checkboxes, etc.

The same will be true of process patterns.

Resource types are the items that need a way to search / filter / etc. In OCP, the exchange types and process patterns do pretty well with filtering. They don't do anything for smart searching or other taxonomic type methods for finding something. So I expect there will be some usefulness in this area. I expect that if the Freedom Coop plan for self employed to sign on for various work that will be done for outside customers comes to pass, then a taxonomy tree will be a very useful way to find skills. (This does not seem to be blossoming now, and in fact is another issue, which was not prioritized in the assembly.)

And the process patterns and exchange type relations to the facet values are not easy to figure out how to do well. So that is a potential issue.

But in fact all of this makes for fairly limited selections for resource types on most pages. It can work fine for now, as dropdowns.

I want to emphasize that we did decide to do the simplest for the first phase so that collectives can actually start using the work app for planning and doing their work. Then we can go crazy with all kinds of improvements.

[bhaugen]

I want to emphasize that we did decide to do the simplest for the first phase so that collectives can actually start using the work app for planning and doing their work. Then we can go crazy with all kinds of improvements.

Yes. So if there is any way to expedite the context agent improvements and work on the General app separately, that would be the best. @bum2 I'll leave you to think about how to do that. If you don't know, @fosterlynn can usually help with these kinds of problems.

[bum2]

The testocp is now with this project-planning branch deployed, with the General trees added, basically to the Exchange process for coordinators, for all you to see and test. (If you want to test in local, please follow this order: pull the project-planning branch, migrate, then enter sqlite3 and import with .read general1.sql, then .read facets1.sql and then .read work_ocp.sql, also is needed some manual readjustments from accounting/resource-facets page to correct some facetvalues assignations, and is good to review the configuration of transfer facets for every exchange type, sorry)

That update includes a tree in the exchange type chooser (controlled from admin backend at work / Types of General Records, the 'ocp exchanges' branch) that shows 'context related' options. I've nested all projects in a mother one called OCP, so common types are set to this common context. If a exchange type is defined for a smaller project context, it only appears as an option if the user context has enough relation to it.

I have also redefined the facets (it's just to show a proposition! we've the old values safe) to use now two of them to connect to the structure at General: one facet is 'Material' and the other is 'Non-material'. Both are main classes in the general Types's tree and this was a fast solution to integrate them in ocp. The trick here is to connect facetvalues to specific tree branches, so the types are related internally using facetvalues but externally they show as trees. The dropdown trees now there are not any final widget, just the fastest way to see hierachy in a select with the default mptt widget. As soon as the tree gets big it will be also not usable and i'm preparing to make a more useful and scalable 'types' chooser widget in a next release*...

I've made a set of common exchange types (by kinds of economy), now replicating them in testocp, but the trees of Material and Non-material resource types is not yet well defined or figured-out (just some starting ideas of possible branches).

In the resource types choosers around in the exchange-logging-work page forms (so many!) the mptt trees works good, but now only works 'fruit', 'laptop' (material) and 'training' (non-material) because are the ones connected right now... to connect resource types to this tree, now i use the admin side (work app, Types of General Material and Non-material resources) but is needed to autoconnect them when created, so i want to make a 'add new resource type' page for coordinators...

[bhaugen]

Just wandering around testocp a bit. I can see a lot of General app stuff in django admin. Where's the best place to look in the coop admin (accounting) and work apps?

These will be preliminary questions, very perceptual, until I understand better. So don't worry about them much, but please do answer (unless I come back soon and say I answered it myself).

By the way, I like the unit conversion stuff. Has been needed in NRP, but I did it once for an ERP system and it was a performance drag. Did it again in Smalltalk where I used a lot of shortcuts and the code was cleaner and the performance hit wasn't so bad. Haven't tried it yet in Django because we have enuf performance problems already, and we haven't needed it much yet (but we will, I am pretty sure). Will be interested to see how this implementation works.

I see some new exchange types, but I don't understand the reason for Buy Material resources and Buy Non-material resources. In a given exchange, you could buy or otherwise exchange for both: e.g. a 3d printing design and some resins.

This question starts to become more conceptual, but I am probably still missing something: I see here https://testocp.freedomcoop.eu/admin/general/job/ some evidence of trees of skills, which I know is one of your main goals. But I don't understand how those relate to the skill resource types in OCP, which are essential economic elements.

The skills question is related to one of my overall questions, which is ontological or structural or about system models: the General app appears to duplicate sorta, or at least overlap, some of the REA classes in OCP accounting. How will those overlaps be managed?

Also, will the General trees allow multiple parents per object? Or single parents? Looks like single parents. That was why we went to faceted classification in NRP: we started out with a single Category with parents and children, that is, category trees, but it was too rigid. And multiple inheritance is a can of worms. Facets seem to be more difficult for people to understand, but are a lot more flexible even than multiple inheritance. All tradeoffs, we got complaints both ways. And a lot of people find any aspect of system configuration to be hopelessly confusing.

Possibly not related to the General app itself, but why do I see some bar graphs with contribution quanties here https://testocp.freedomcoop.eu/accounting/agent/109/ ? but no contributions here https://testocp.freedomcoop.eu/accounting/contributions/109/ ? Might be a previously-existing OCP bug...

Anyway, I'll keep digging. Back later...

[bum2]

Yes, the admin side of General is not to be used right now, it's there just for you to see it an try if you want (then it can be hidden). The only used parts in OCP are already in the Work admin part, only for the 3 branches of types used now. If is needed to add a new material, non-material and record type for ocp please only use the Work tables (not the General ones). Specially the main Types table is never to be edited directly, please only look!

To see the trees go to a project you are coordinating in the work app, and from there go to the exchanges page. There's the first tree dropdown about exchange types. Once you choose a type and create a new exchange, then you'll see the resource types trees when creating or editing transfers or commitments. They are now filtered in general as material or non-material but can be more restricted and even mixed like the Money facet applied to payments (shows physical and digital coin resources to choose from). That means that a facetvalue can be attached to a general material or non-material type, independent of the facet choosed, and the related resource types appear together as options to choose from.

I love the multiple parents we have in OCP context-agents, and in the General app the idea to reach the same was to choose one as the main parent for the types trees and all other parents (or any kind of relation) are treated as such, a relation of some kind. There're some relation tables in the General app that connect all items to others through a relation kind, from the tree of relations. In this case will be the relation of a Concept (the Type) with another concept (another Type) which a relation behaviour like 'parent' or 'child' or whatever. When showing trees is good to show direct childs and also 'related' childs in a similar way in the same tree, so they seem to have multiple parents, if that makes sense in every case of course. I think that kind of relation was not yet much facilitated at the admin GUI because was still not needed, but you'll see some of the relations 'admin inlines' in the Person or Project models...

About the bug you comment I have no idea...

[fosterlynn]

I love the multiple parents we have in OCP context-agents

If we want to do that, we should do some code reading and testing. I'm not totally sure in all the places we are using inheritance from parent agent that it will support multiple parents.

[bhaugen]

I'm not totally sure in all the places we are using inheritance from parent agent that it will support multiple parents.

I'm pretty sure it won't. We might be able to make it work, but could be pitfalls even if it looks like it is working in some cases. Will need a good set of test cases.

[bum2]

You are true @bhaugen about the cases where is difficult to choose 'material' or 'immaterial', its an old debate. I try to always use a clear answer: What is the main value part of the item? if the main value part is virtual then the resource is non-material, attached nearly always to a material item as a support. Also the other way around, many physical items have a non-material 'resource' attached to it, like the cultural value or whatever. Sometimes in an exchange the main part of the value comes from the physical part, like the tools (which have a design, or other non-materials related), and sometimes the main value come from the non-physical part of the item exchanged (like a music CD, a printed book, etc), so we can use that criteria to choose material or not in the first place. Then should be a way to move a resource around, carrying its relations to other resource types with it. All this facets and trees are just to help choosing things, once they are choosed they behave as normal ocp resource types. We can think about other main branches and not use the material-nonmaterial first separation (i'm open!), in respect to the General ontology, all them are 'Artwork'. In reality, Units and Records are also 'non-material artworks' and for speed and uid's mangement I have splitted Artwork in 4 branches, Unit and Record with their own tables and unique id's and this first two blocks of other material or non-material stuff, each of them is creating their own uids in separate tables because the Artwork class is abstract (you think makes sense to make it a real table? think about scalable and future big data...)

[bhaugen]

I try to always use a clear answer: What is the main value part of the item?

I was referring exchanges, not resources. You created material and immaterial exchanges. A particular exchange could have both.

[bum2]

About the multiple parents of the context agents i think is good now to keep things easy and restrict only one 'main' parent for the 'child' relation (the admin organization tree) and other parent relations like member or participant can be multiple and is not needed now a tree to show them in the coop admin app, but will be nice to show a nested sub tree for every project and its internal structure of agents (ruled by member/participant relations instead of child relations). I must find the places where the context parent is used in ocp, to see exactly how we can sort the code and answer the intended correct 'parent' in each case. That will need the kind of relation, and perhaps one of the relations should be unique (not multiple) if is really needed only one parent for some things. Which are the uses of the single parent agent? allways child behavior or other kinds?

[bum2]

I was referring exchanges, not resources. You created material and immaterial exchanges. A particular exchange could have both.

Oh yes, you are true. That exchanges types are really related the choosing of resource types subsets for easier finding, but a more easy UI approach can be to set both a exchange type (gift, exchange, sell-buy) AND a facetvalue or 'sector' (more than one?), before creating a new Exchange. This way the resource types are also filtered, but not by the exchange-type predefined transfers. That's a huge change i'm afraid to do and will need lot of collective thinking, but can be easier for users.

[bhaugen]

Somewhat related question: what are services? Or work? Material or immaterial?

[bum2]

As you see i've proposed services as immaterial resources: time. Also skills are very related to services, and also material or nonmaterial things. I think every material or non-material resource will have a related skill, work, job or Art to produce that (the verb) and what is traded as a 'service' is always related time. Of course every aspect is very related the others. For example, you can buy service time to produce a physical kitchen in your house, then becomes a material good. The whole 'service' concept is what i'm trying to fit or redefine here: To find a skill you can browse material or nonmaterial resource types to get the related skill for producing it, indeed is not need a separate hierachy of 'sector' for skills. In the General approach I propose to choose a verb like 'create' or 'produce' and a resource type, then you have a skill...

Another approach for the exchanges page can be to pre filter the resource types in the new exchanges only depending on the context of the agent creating it. So e.g. outgoing resources are always prefiltered with project resource types or project context related resource types. Then, the exchange types can be more general (even get rid of the context_agent field?) and the Transfers is what needs to be attached to context agents?

[bhaugen]

@bum2

To see the trees go to a project you are coordinating in the work app, and from there go to the exchanges page.

I am looking at projects I coordinate, and do not see a way to get from there to the exchanges page. For example https://testocp.freedomcoop.eu/work/agent/79/ or https://testocp.freedomcoop.eu/work/agent/96

(P.S. that last one shows up twice in https://testocp.freedomcoop.eu/work/your-projects/ - not sure why...some kind of bug...)

[edit] Here's one where you are also a coordinator. I'm not sure why I am, but I still don't see a way to get to the exchange page from there...https://testocp.freedomcoop.eu/work/agent/26/

[bhaugen]

@bum2 since we don't have that calendar now (unless I missed something), let's do a little time coordinating here. I'd like to get deeper into your General app some time when you have time for discussion. Can't do it today, too much happening on the home front. But I could do it any of the next days. When will you have some time?

[bum2]

Sorry, during some hours yesterday i putted the master branch in testocp, because I was trying a fast update very needed in prod (see #198)... now is again the project-planning branch on testocp, so you will see the 'project exchanges'.

Just now i has been able to get-up the sandstorm (the calendar, the wekans, etc), coordinating with santiddt to be able to erase non required things and make some room again in the server...

(P.S. that last one shows up twice in https://testocp.freedomcoop.eu/work/your-projects/ - not sure why...some kind of bug...)

Yes that duplicates bug is fixed in the new release, not yet in master

When will you have some time?

Today afternoon or next friday afternoon (your morning) is ok for me, i'll note in the calendar...

[bhaugen]

I'm in https://testocp.freedomcoop.eu/work/agent/96/ again and still do not see project exchanges.

Same for https://testocp.freedomcoop.eu/work/agent/26/ where @bum2 you are also a coordinator.

[bhaugen]

@bum2 what I would like to do with the General app is compare your models one by one with the OCP accounting models. I'll start working on this later today. Would be best if I could find that project exchanges link and anything else from the General app that is visible in testocp, but not totally necessary. I can work off your docs.

Then maybe we can discuss on Friday? Thanks.

[bum2]

I'm in https://testocp.freedomcoop.eu/work/agent/96/ again and still do not see project exchanges. Same for https://testocp.freedomcoop.eu/work/agent/26/ where @bum2 you are also a coordinator.

the link appears for me in both cases... let me review with a non-staff user... yes it is there too, even if only participant... oups, even if not related the project... i'll make the submenu link only for participants...

I think there are many other priorities before studying a deeper future integration with General app... we can just use it whenever needed and perhaps one day we can think about a kind of Sync system to connect OCP with General app, for the kind of records we want to have in both apps... that only if we choose one day to make the General app available to any frontend (there's not any). That is a project still to talk a lot and define if there's enough interest...

For now we need to push the project-planning when ready enough. I propose to use the exchange system now on test, but if you all like the way is going, then we need to:

• finish a 'create new resource type' page for coordinators, accesible from the new 'resource type' chooser in exchanges (transfers, commitments)... that can be part of a 'Project Resources' page (inventory) for project coordinators.
• implement the new 'resource type' chooser (+create new) in the work plans, orders, process, tasks, etc
• the 'Relations' page for project coordinators is very needed too.

That's for this release i think, and for a future release:

• facilitate the types trees management in new coop admin pages (drag'n'drop, see http://django-mptt.github.io/django-mptt/forms.html#movenodeform)
• also every project coordinator will manage the resource types related its context in a subtree on work app...
• improve the user navigation for the tree choosers: use https://github.com/arschmitz/jquery-mobile-nestedlists/ or similar 'screened' or '3 columns' tree chooser (i can't find that one yet)

[fosterlynn]

the link appears for me in both cases

Yes, I see it - it is on the right of the legend line

[bhaugen]

I don't see the legend line at all in either of those pages.

[bhaugen]

I think there are many other priorities before studying a deeper future integration with General app...

Good. @fosterlynn agrees. So do I.

[fosterlynn]

@bum2 I took a look at the exchange type drop down in testocp. It seems harder to choose to me, because of the extra detail for some exchange types. The parent categories could be helpful, if we highlighted the items a person could actually pick.

What does the "(OCP)" flag mean that you see in the admin side? Are you flagging for what to show in the work app? What wouldn't be shown in the work app if it is global? Maybe the faircoin stuff?

We should get rid of the Incoming, Outgoing, Internal sections in the filter box. (Did I put those there? If so, sorry.)

There is nothing yet for coordinators to make their own exchange types? I thought that was the priority on exchange types, making exchanges already basically worked, I thought. A related question: if there is a taxonomy, what if project coordinators want to make their own exchange types and they don't really fit into the taxonomy? Is there now a project level taxonomy?

[bhaugen]

This is interesting: on Your Projects, I see exchanges links alongside the projects where I am a participant, but not those where I am a coordinator. https://testocp.freedomcoop.eu/work/your-projects/

However, I do not see the legend banner or the exchange link on any the individual project pages, whether I am a coordinator or a participant.

Same for the projects I can join: no legend, no exchange link on the project page.

[bhaugen]

Solution to missing legend-exchange link mystery: works on firefox, does not work on chrome.

If I look in the chrome dev tools, the legend and subnav end up hidden behind the top navbar.

[bum2]

@bum2 I took a look at the exchange type drop down in testocp. It seems harder to choose to me, because of the extra detail for some exchange types. The parent categories could be helpful, if we highlighted the items a person could actually pick.

Yes ok, we can simplify that tree with only main categories, but if we want to prefilter resource types then we can put another chooser for the exchanged resource type family.... Also i wanted to highlight the 'connected' or active options (not achieved yet).

What does the "(OCP)" flag mean that you see in the admin side? Are you flagging for what to show in the work app? What wouldn't be shown in the work app if it is global? Maybe the faircoin stuff?

That's the related context agent. If is OCP is common for everybody, but it can be an exchange type for a particular project and it shows only for them or their child projects... eg. to pay the quarterly fee is only for selfemployed members (participants of a 'selfemployment' project)

We should get rid of the Incoming, Outgoing, Internal sections in the filter box. (Did I put those there? If so, sorry.)

It was me who adds that, I can get rid of them again in the filter box, but I wanted to show instead some categories of the exchange-types tree... What can happen to other internals of ocp if we transform that 3 usecases into 'gift economy', 'exchange economy' and 'monetary economy'? I see that the 'supply_xfer', 'demand_xfer' and 'intrnl_xfer' use cases identifiers are used in many other places, so I let them untouched...

There is nothing yet for coordinators to make their own exchange types? I thought that was the priority on exchange types, making exchanges already basically worked, I thought. A related question: if there is a taxonomy, what if project coordinators want to make their own exchange types and they don't really fit into the taxonomy? Is there now a project level taxonomy?

I was close to do the 'add exchange type' for coordinators, but stopped and now is proposed as a common set of exchange types to start with, and a note to ask for a new custom exchange type to admins. The resource-type creation is more needed I think, and is what i'm focusing now. They first will create a type in the general tree (perhaps also create new subcategories in the tree), the intended context agent or scope and after that they can define the ocp fields for the new exchange type. That process should end with a new custom resource type (both in ocp and general) to choose, when creating a new exchange. Will be very good to have all this "resource type chooser widget with option for creating a new one" in one or two single code blocks or forms, because there are so many 'resource type' choosers around to update (when ready enough).

If I look in the chrome dev tools, the legend and subnav end up hidden behind the top navbar.

Is very strange, I see them good in chrome too... perhaps browser versions? mine is 50.0.2661.102

[bhaugen]

perhaps browser versions? mine is 50.0.2661.102

Probly, I'm on 49 something, and will need to upgrade ubuntu to upgrade chrome, and am not motivated yet. So I'll stop worrying about it and use firefox.

[fosterlynn]

This is what an exchanges page looks like on my computer, in testocp. Ubuntu, Firefox.

[fosterlynn]

I deleted my previous comment about proliferating detail, I see that this is more how you have structured the exchange types, will study more carefully.

[fosterlynn]

Blew up creating a transfer. Conditions: Picked Exchange Material for Material exchange type. Creating transfer on top section. Filled out for creating a new resource. The formset on the bottom of the new resource is what is missing.

When I tried it again and didn't fill in anything for creating a new resource, it worked.

There may be some other things to think about, as part of making this work for many agents trading within the same installation. A resource that is transferred to another agent within Freedom Coop may be created as a new resource within the agent that is receiving the resource, although that sounds not intuitive. This is because they may want to identify it differently, for example. So it isn't a different physical resource, but it can be a different instance of a Resource in OCP because the context is different.

Error: NameError at /accounting/add-transfer/94/16/

global name 'resource_role_context_agent_formset' is not defined

Request Method: POST Request URL: https://testocp.freedomcoop.eu/accounting/add-transfer/94/16/ Django Version: 1.8.15 Exception Type: NameError Exception Value:

global name 'resource_role_context_agent_formset' is not defined

Exception Location: /home/ocp/app/valuenetwork/valuenetwork/valueaccounting/views.py in add_transfer, line 6104 Python Executable: /usr/bin/python Python Version: 2.7.9 Python Path:

['/home/ocp/app/valuenetwork', '/home/ocp/app/env/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages/django_mptt-0.8.6-py2.7.egg', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/home/ocp/app/valuenetwork/']

Server time: Sat, 31 Dec 2016 18:26:24 +0000

[fosterlynn]

Something to think about: If 2 collectives within Freedom Coop are exchanging with each other, shouldn't that just be one exchange? So one collective's purchase is another collective's sale, just for an example. But from the independent view, it is just one exchange - a trade, not a purchase or a sale. And I would think that the 2 collectives would like to reference just the one exchange too.

The only time a purchase is just a purchase is when you are purchasing from someone outside the scope of the installation, i.e. not in Freedom Coop. Which may or may not even be a valid thing in Freedom Coop.

This will take some thought in terms of implementation.....

The data structure has some things that will support this, a transfer has 2 economic events, a give and a receive. One agent gives, another agent receives. Might help.

[fosterlynn]

Noticing the Incoming Total and Outgoing Total on the exchange list page don't seem to be meaningful. They are using quantity, which won't ever add up. They could use value, but I wonder if that is useful, or not. I'm guessing not that useful, but I don't know

The original purpose was to double check the entry, validate from an accounting perspective, and it was in the condition of one side of the exchange always being money.

[fosterlynn]

I created a new exchange type just for my LynnTest project. It doesn't show up in the list for me to pick it in the work app, to create a new exchange.

Is it your intention that collectives can define their own?

[fosterlynn]

In creating a new transfer in a new exchange, the resource type dropdown includes that whole new taxonomy of generally applicable resource types.

I see how you made this work, in mapping your taxonomy to the facet values. You did some careful study @bum2 ! :)

I think we need some discussion with the admins and coordinators of some collectives to see what will make sense to people. To me, I didn't want to see all that stuff, only a small part of which might make sense in my imaginary collective. Maybe "fruit" or "raw animal" is not relevant to us. The point of the facet values and patterns or pattern stuff in the exchange types is so that people can tailor the resource type dropdowns to their situations, as specifically as they need to, and eliminate noise. I'll try to go back and see if I can re-capture the discussion around Dezentrale, where we saw pretty specific needs.

On the other hand, I think the taxonomy could be valuable in some situations. I think of where people need to categorize requests or offers, this is much better than the categorization I've seen in timebanks, say.

And I like the inheritance from parent agents, that could be very useful. The thinking around the organizational structure is helpful.

[fosterlynn]

A note about the New Resource button on the Resources page - in general, OCP is designed so that resources enter the system as a result of an event - they are created in a process, donated, traded, etc. This is part of the accountability / accounting part, so people can trace the history of all resources.

Occasionally people do need a way to just correct the computer system, like if you take inventory and the system doesn't match reality. Or you might need to create resources directly when you are starting in the system, if you do have resources on hand obtained before starting the system. But these are exceptions.

[fosterlynn]

Error on creating exchange: Difference from yesterday (when it worked) was I picked a different exchange type to create: Sell non-material resources. Blew up saving the exchange on the left side of the exchange page.

DoesNotExist at /work/agent/39/exchange-logging-work/0/96/

EconomicResourceType matching query does not exist.

Request Method: GET Request URL: https://testocp.freedomcoop.eu/work/agent/39/exchange-logging-work/0/96/ Django Version: 1.8.15 Exception Type: DoesNotExist Exception Value:

EconomicResourceType matching query does not exist.

Exception Location: /home/ocp/app/env/lib/python2.7/site-packages/django/db/models/query.py in get, line 334 Python Executable: /usr/bin/python Python Version: 2.7.9 Python Path:

['/home/ocp/app/valuenetwork', '/home/ocp/app/env/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages/django_mptt-0.8.6-py2.7.egg', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/home/ocp/app/valuenetwork/']

Server time: Sun, 1 Jan 2017 19:52:50 +0000 Error during template rendering

In template /home/ocp/app/valuenetwork/work/templates/work/exchange_logging_work.html, error at line 249 EconomicResourceType matching query does not exist. 239

{% trans "Log a new " %}{{ slot.name }}

240

[bhaugen]

@fosterlynn wrote upthread:

I created a new exchange type just for my LynnTest project. It doesn't show up in the list for me to pick it in the work app, to create a new exchange.

I had the same problem. I created this exchange type: https://testocp.freedomcoop.eu/accounting/change-exchange-type/20/

For this context agent: https://testocp.freedomcoop.eu/work/agent/96/ for which I am the coordinator.

When I go to create an exchange: https://testocp.freedomcoop.eu/work/agent/96/exchanges/ I don't see my exchange type in the selection list.

Actually, all I want to see in that selection list is exchange types I have created. I might want to see a lot of inherited exchange types very occasionally, by exception, but would want to have some control over whether to see them all or only the ones I have created for my context.

[bum2]

For one side, there's lot of config work pending, and connect exchange types with the tree options... now only the ones with > are connected and should work... The idea here was to have common exchange types for all projects or users. The idea of custom exchange types for every project is not developed at all (when we need them we can do it). Don't know how you've created new exchange types from the work app... You can create a new exchange of some of the common types (if connected yet to ocp's), and then the resource types are filtered by big trees (material, non-material and skills groups now only)... it's just a starting point... My focus has merged more into the Resource types themselves (see https://github.com/FreedomCoop/valuenetwork/issues/184)... and after having the system more clear in the Resources page, then i want to focus again the exchanges page to adapt, and i want to make a proposal about the skills and the new skills suggestion system (to connect with this common trees, etc)... When Resources page and Exchanges page becames + or - finished, then we have to see again all the Plan Work system in order to make a coherent big new release: "Project-planning" (which includes such big things like exchanges, the resource types management for projects of all kinds or sectors, and also the process tasks, plan work and so on)... Don't know when it will be everything ready to publish... If you like the approach i'm going and the added tools, and if we have time to invest in this, then maybe we can get ready this release in few weeks... If you don't like where is going, please stop me!

You are true that is better to avoid showing big trees for a regular user, they can be hidden in many ways, but now i'm showing the huge work-in-progress of doing the common ontology (see resources page filtering panel, not finished)... The definition of the branches and the trees is a totally pending task... we need to really think about which branches we need, step by step and case by case...

I see how you made this work, in mapping your taxonomy to the facet values. You did some careful study @bum2 ! :)

I haven't studied any facetvalue to type organization, just trying to connect some of them to test this new system... Whenever we have clear the tree's branches and sub-branches, then we can make and adapt the facetvalues to them...

[bhaugen]

The idea here was to have common exchange types for all projects or users. The idea of custom exchange types for every project is not developed at all (when we need them we can do it).

The idea of custom exchange types is that many projects will trade only a small number of items, so to present long selection lists wastes time and is confusing.

Don't know how you've created new exchange types from the work app...

Did it from the other side.

By the way, I don't know if anybody has explained this clearly to you yet, but the whole reason for the faceted classification setup was to filter selection lists so people would only see those that were useful in whatever situation they were in. It was not to present hierarchical taxonomies. I think the taxonomies might help the project coordinators who need to set up the custom exchange types etc, but I don't think they will be useful to somebody who just wants to do an exchange for a project.

But what do I know? You'll need to get a lot of feedback from freedom coop admins and collectives who want to use the system, I don't count.

[fosterlynn]

The idea here was to have common exchange types for all projects or users. The idea of custom exchange types for every project is not developed at all (when we need them we can do it).

@bum2 I gotta say, I don't understand this at all! The whole point of this issue is to make it so agents that are projects / collectives can create their own set of specificly configured items and not be bothered by a whole long list of others' specific items! This was discovered very clearly by working for some hours on the actual use cases of Dezentrale and of @skoria 's definition of what the nodes need. Those were put on hold because we couldn't segregate their needs from everyone else. There would be no need to create all these context agent FKs if we didn't intend to use them to limit by context agent! I don't think this is made up, this was a requirement summarized from actual working sessions.

The point of working as first phase of just making it work by context agent (project / collective) without adding anything new was to get these groups up and running as quickly as possible. Now we are weeks if not months down the road and nothing to help these groups actually do their configuration so they can use the OCP.

We could have created common exchange types and resource types with the system as it was before we started this issue, and filtered using facet-values and patterns. There was no development work needed for this, and the trees could be a nice-to-have improvement added on later.

I don't know how we ended up understanding this so differently..... please tell me if you think I am wrong. Even better, we can ask Chris and Ale and other admins and coordinators, and make sure we have a collective understanding of what is the real requirement. And perhaps we need a better ongoing process for this.

[bum2]

is just not finished the branch yet... also the trees are not yet introduced nowhere in master...

I don't think this is made up, this was a requirement summarized from actual working sessions.

the filtering by context is working in the exchanges! that was one of the first thing i did in the exchanges page...

please let me time to develop and time to explain before judging... the whole types trees will not be for every user, only parts of them (if they are related a branch) or their custom authored types... here in testocp i'm showing the whole trees now for you to see and finally say something... now with some feedback i can continue better than before..

About the exchanges, i want to change the way they are setup: the user should choose a kind of exchange (not related resource types) and also a branch (facet+facetvalue) or a particular resource type to set up a new exchange (using that filters). That will be good but I can't do it because is a deep ocp structure, maybe you can do it if that's possible?

The testocp is running master again... i keep working a bit more on the branch but maybe is better if i stop and go for many other pending things? maybe you can take control of the whole new release and i can contribute later or do other stuff?

[bum2]

All what i'm adding is to not touch the internal ocp structure... some bits are inevitable, but trying to keep at minimum the internal structure changes... The intention is to simplify everything, but in many places is needed to choose a resource type, and they can be filtered by the facetvalues like always (even with the trees)... see a purchase or a sell exchange with money facet in one tranfer, it shows only money related types...

the Resource page is a work-in-progress as many times i told you... just to show the trees to somebody... i'll keep them in local meanwhile i try to finish this proposal with your feedback in mind.

the resources page in work app was needed mainly to hold a place where adding new custom resource types is doable (not very good to place that in the exchanges pages, but link from there)...

[fosterlynn]

I tried the Resources page New Resource Type button. It didn't save my resource type (don't see it in django admin). I was trying to see if I could create one within my context (LynnTest).