follow the change of r36616 (store a list of simulation movements to be solved instead of delivery movements in a Solver Decision document).


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36618 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36617 20353a03-c40f-0410-a6d1-a30d3c3de9de

store a list of simulation movements to be solved instead of delivery movements in a Solver Decision document, that is more efficient and consistent with the way to find appropriate target solvers whose predicate's context is a simulation movement.
XXX now using 'delivery' category to store simulation movements does not sound good.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36616 20353a03-c40f-0410-a6d1-a30d3c3de9de

* modify egov table to be generic for erp5_egov bt and catalog methods
* remove specific portal_type in filter expressions of z_catalog_egov_list

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36614 20353a03-c40f-0410-a6d1-a30d3c3de9de

* remove tenderer in Folder_viewEgovContentList (unused)

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36613 20353a03-c40f-0410-a6d1-a30d3c3de9de

* modify catalog table egov and use generic attributes in z_catalog_egov_list and z_create_egov

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36611 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36610 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36609 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36608 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36607 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36606 20353a03-c40f-0410-a6d1-a30d3c3de9de

the condition was wrong in r35806 (if delivery category is used in root applied rule, we don't want to check if we have delivery in the first level simulation movement to determine if the simulation is mutable or deletable).


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36604 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36603 20353a03-c40f-0410-a6d1-a30d3c3de9de

*Give anonymous access to a portal_type that does not require authentication

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36602 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36601 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36600 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36599 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36598 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36595 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36594 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36592 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36591 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36590 20353a03-c40f-0410-a6d1-a30d3c3de9de

Use instead of 'All' -> 'All Documents' (which is what actually is meant).

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36589 20353a03-c40f-0410-a6d1-a30d3c3de9de

Business Process is in the same direction than the Simulation Tree flow.

First look up simulation tree ancestors to see if movements related
to business path ancestors are indeed in this ancestor set.
Most of the time this check is enough. Conveniently, it's also cheap.

And if we're unlucky and have a Business Process going upwards, we
go through descendants of the movement (which is costly) to check
buildability.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36588 20353a03-c40f-0410-a6d1-a30d3c3de9de

ancestors or descendants of said movement.

Instead of computing a closure of a set of nodes, and in a second step
filter nodes to only match those "related" to self, it's better to
compute directly a smaller closure, only consisting of [self]

That's about 3-4 times faster.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36587 20353a03-c40f-0410-a6d1-a30d3c3de9de

 BusinessPath.isCompleted calls are quite expensive

Removing it with the previous improvements actually leads
to before performance.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36586 20353a03-c40f-0410-a6d1-a30d3c3de9de

since the closure will stay the same among all business paths,
transform
 for path in previous_path_list:
   for movement in path.getRelatedMovementValueList():
into:
 closure = current_path.getBusinessPathClosure()
 for movement in closure:

This means that number of simulation tree walks is reduced by a factor of
 len(previous_path_list)


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36585 20353a03-c40f-0410-a6d1-a30d3c3de9de

instead of walking all descendants of root applied rules, we now only
walk the ancestors of related movements and their descendants.

This means that a few branches get pruned, namely the branches stemming
from ancestors of related movements that dont include such related
movements as descendants.


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36584 20353a03-c40f-0410-a6d1-a30d3c3de9de

This commit alone represents a performance drop by 300% (3 times slower),
and is kept only to track changes.
The next 5 commits will improve performance, leading to an
overall 500% improvement (5 times faster than before this commit)


git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36583 20353a03-c40f-0410-a6d1-a30d3c3de9de

When creating object always pass editable_mode so user is redirected explicitly to objects edit form.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36581 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36580 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36574 20353a03-c40f-0410-a6d1-a30d3c3de9de

*use portal_type as expression kache key

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36572 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36571 20353a03-c40f-0410-a6d1-a30d3c3de9de

* use lambda expression to filter objects without portal_type in z_catalog_egov_list filter

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36570 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36567 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36566 20353a03-c40f-0410-a6d1-a30d3c3de9de

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36565 20353a03-c40f-0410-a6d1-a30d3c3de9de

The erp5_barcode is not required anymore, once it also fails using the erp5_core. Using proper API instead of portal_catalog.

git-svn-id: https://svn.erp5.org/repos/public/erp5/trunk@36564 20353a03-c40f-0410-a6d1-a30d3c3de9de