search

FreedomCoop / valuenetwork

Fork coming from NRP-Sensorica to use and work for FREEDOM COOP
http://fair.coop
GNU Affero General Public License v3.0
31 stars 12 forks source link

Simplify the process of creating an Exchange in work app #184

Open bum2 opened 7 years ago

bum2 commented 7 years ago

Now in the project-planning branch we have this exchange creation feature (now testing in testocp), but i think it can be improved:

In the project editor page (work/agent/x) we go to the exchanges page (work/agent/x/exchanges) and there we can choose the 'exchange type' to create a new exchange (step 1). When you click there you go to another page (exchange-logging-work) that asks for a date, a link and a comment (step 2). After saving, the form appears finally, but the left data is always the same.

My proposition will be to join step 2 and 3 in the same page, because now makes no sense (because the context agent is already known?) to have that in separate steps... Please correct me if i'm wrong and is needed like this for other reasons.

fosterlynn commented 7 years ago

To clarify: facet values often do not have anything to do with resource type trees themselves.

I edited this sentence, and it still might not be totally clear. I mean facet values have only indirectly to do with resource types, in that you can relate them to resource types - they do not themselves correspond to resource types or resource type parents as usually defined. (Hard to explain.)

fosterlynn commented 7 years ago

Here is more info on facets: https://en.wikipedia.org/wiki/Faceted_classification

bum2 commented 7 years ago

Yes, faceting is needed and is already implemented. The facetvalues can work as classified Tags, isn't it?. The way i'm trying to go is to have 'both' the Tree and the Tags (tags are in a tree). If the Tags or facetvalues are in a Tree they can confer properties to the objects from two sources:

Imho i think we need the flexibility of tags or facetvalues AND to be able to organise the information in trees. So, my idea is to have all the types in trees, and when a type becames also a grandparent of other types, then its created a facetvalue with the same name (and applied to childs, still ToDo). That means that facet values will have also a hierachy (less detailed than types, only branches). The main point is that we can set many facetvalues (as 'tags' or 'type branches') to a single object, and the faceting system already does this. For this purpose i'm linking the EconomicResourceType's in the general.Type tree but also linking to FacetValue's when the general.type is a branch or 'category' for other types, and when a general.type is a root branch is linked to a Facet. This way we can set a resource type like a child of 'various parents' (inheriting things if needed), having one main parent (defined as parent type) and the other parents are like Tags (defined as facetvalues for that resource_type).

The easy way to manage this is by just:

bum2 commented 7 years ago

By the way, I'm trying to separate the new ocp release with only the exchanges part shown for endusers, so i've created a new branch 'exchanges' and there i'm hidding the planwork and the orders pages, related to project-planning extrictly...

This way we will first open only the 'exchanges' part, which includes 'resources' and so many updates about the management of Types, etc. This new wip branch can be seen and tested at testocp (i'm deploying there often)...

One of the things i did to make live much easier is to reorder the functions at work/views.py (5527 lines) in blocks for the different features... Will be good if @fosterlynn or @bhaugen can review that groupings, but:

My main worry is related the splitting-the-app process already started. Can it be done with the sources after we merge 'exchanges' into 'master'? or can it be done the splitting from the branch? there are plenty more things to split in this branch (compared to actual master)...

bum2 commented 7 years ago

Shouldn't this be the opposite, or an explicit choice? Default to the chosen project. There is no reason to think that some other project wants what you are creating, it could easily be just spam.

Ok now new exchange types defaults to project context when not specifyed by the related resource type or branch (was getting the context defined from the parent exchange type, mainly general OCP). So only main branches are shown for exchange types...