If a category acts as a relation and a classification tree, there is an issue with acquisition.
Ex. product_line of a movement M is product_line of resource of M because it is acquired from the resource. This is great, because we have on movement the same classification we have on resources. This allow for applying predicates or doing reporting.
But if we use resource category for both classification and relationship, the acquistion thing cannot work, because resource classification cannot be acquired at movement level, as movement already have a resource in that case.
I think, that it would be good to remove tree from portal_categories/resource from BT. It's little confusing and I assumed that category resource shall be used such way (to categorise Components). Same problem is in SalePackingList_fastInputForm, which fetches packing components.
Another problem (?). When there was 'resource' category for Component and 'product_line' for Product it was easy to differ them. Now I'm using 'product_line' for both and it's messing a little - there are many categories to select. Proposed resolutions:
- add category 'component_line'
- in 'product_line' use prefix 'component/' for Components and/or use prefix 'product/' for Products
If you choose any solution let me know - I'd like to be compatibile as most as possibile.
IMHO FastInput could be hardcoded; change to 'product_line' wasn't so hard.
+1 for removing categories. Don't know how to fix the fast input, depending on hardcoded categories is a more general problem. Maybe in a custom script or a preference ? /jerome