Party Categories as Tags / Viewing parties that have two categories in common

Hello,

As I started categorizing my Parties, I realized that the number of categories required could be reduced very much if they could be used sort of like tags.
I know that a party can have multiple categories, but I do not know how to display parties that are a part of two categories.

Let me explain:

I have customers, who are consumers and distributors.
Each of these, use or sell the products they buy from me as packaging, or for binding waste bales.

So I have:

Customer
    \ Reseller
        \ Packaging
        \ Baler
    \ Consumer
        \ Packaging
        \ Baler
Lead Customer
    \ Reseller
        \ Packaging
        \ Baler
    \ Consumer
        \ Packaging
        \ Baler
Competitor
    \ Packaging
    \ Baler

But like this I can not see all Parties who use my products for balers in one list.

or I could have:

Customer
Competitor
Lead
Reseller
Consumer
Baler
Packaging

and if for example I wanted to see a list of parties that are lead customers that use my products for balers I could look up the parties that are in the Lead, consumer, baler categories.

Programmatically using for ex. proteus I can solve the problem, but I want to ask if it is possible through Tryton GTK client to for example view parties who are both members of Consumer category and Baler category.
Perhaps through editing the Url?
Perhaps this is too slow/computationally intensive.

It can be possible to write a wizard that builds the required domain to search all parties that match all the categories (using the selected records).

Such wizard can be added on the relate button or even add it to the tree_open.

I do not think it is required to write a wizard.
Indeed we just need to be able to use the tree_open with multiple records. The UI does not allow that but I think by making the action also a form_relate it should work.

Indeed I proposed to add a wizard because from what I understand the requirement is to show partis that have all the selected categories, which requires to use a custom domain with multiple causes (as ‘in’ will return the party that is in any category).

Thank you for confirming that this is not possible in the client.

I posted in User support because I was expecting it to be possible, just not knowing how. Probably the right place to post would have been feature ideas.

This is what I meant.

If I understand correctly, Cedric proposed being able to display more than one category in the same tree. For me this could also help, but only with the first example:

I do not have a strict requirement, and I can manage very well with just being able to see party lists from only one category at a time.

My final question on this topic is if this is a feature that other users consider to be useful to have in Tryton, or if it brings too much complexity and should be delegated to a custom module/report.

You can take a look to this custom module.

For sure we should improve the category usage and power to allow to do better party selection.
But someone needs to find a good generic way to do that.

Thank you Sergyo. This modules does exactly what I was describing.
Perhaps the only addition I would do is to have a Not in addition to All and Any mode, this way you can find parties that are not a part of a category.
But perhaps there is a different way to achieve this.

I am aware that any feature/creation is composed of 1% inspiration, and 99% transpiration.

To me the trytond-party_category_form_relate is made probably better than I would be able to make it, and since I am sure there is a reason why this has not been included in upstream I will comment only if I figure out a better way to do it (unlikely).

Thank you @ced for keeping/moderating the quality of Tryton at a very high level.

glad to hear that.

Please feel free to do a MR.

I have not managed to do what I proposed in an elegant way without rewriting most of your module so I will scrap the idea for now.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.