Add one more select_dict case: when there is no direct hint given, but the query implicitely favors a table over the other.


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

- add a column which mapping is ambiguous (could happen on 2 tables)
- add a utility method to generate SQLExpression instances from parameters


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

Cleanup "items" in that relation field instance. It was not allowing to choose between multiple ambigous results

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

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

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

Also fix a typo (missing colon at end of method definition).


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

Split buildSQLQuery into 2 parts: one responsible for building the EntireQuery (and responsible for parameter backward compatibility), and a second to just render that EntireQuery as a dict. This will help testing EntireQuery.
Update interface accordingly.


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

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

of ERP5


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

* Add new report in order to have global overview of milestones

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

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

- specify in IMetadataDiscoverable.getContentInformation that the return type
  is a dictionnary


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

here, x[0] is a Products.ERP5Type.Message.Message object, so we need to sort by str(x[0]) otherwise the sort result is unexpectable.


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

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

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

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

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

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

Until now, when using, for example, VAT, you put like this:

price=0.196, efficiency=1.0

so the result by getAggregatedAmountList is, if the base is 100:

price=0.196, efficiency=1.0, quantity=100

Thus, the total price is 19.6.

This works but not compatible with rounding, as, for instance, if we want to 
round it up to 20, the result is not saved at anywhere.

So, from now on, we do like this instead:

price=1.0, efficiency=0.196

so the result is:

price=1.0, efficiency=0.196, quantity=100, total price=19.6

The total price does not change. When we apply a rounding method, it would 
result in:

price=1.0, efficiency=0.196, quantity=100, total price=20

--

This modification is approved by YO and Yusei.

TODO: write some test-cases



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

* Change the usage of
price, quantity and efficiency in Trade Model Line

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

* Fix commit  forgetting

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

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

Implement a getGlobalTranslationService replacement for Zope 2.12, but use the one Zope 2.8 if available (approved by jm).

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

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

Create a new ERP5Type/Workflow.py file to house all changes needed as we progressively remove DCWorkflow dependencies. For now it contains the non-patches part of patches/DCWorkflow.py and a conditional replacement for addWorkflowFactory() function that disappeared on CMF 2. Adjust other import locations to point to this function. Adjust ERP5Type product initialization to register Zope2-style factories for workflows registered with the substitute addWorkflowFactory when on CMF2 (approved by jm and jerome)

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

Tools can be used for anything, not only for UI.

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

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

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

* Dead proxy fields are already tested by test_deadProxyFields so other tests
  should ignore them.
* Some fields may have complex TALES that require specific context.
  They should be considered enabled.
* In test_moduleListMethod, list all wrong modules instead of failing on the
  first one.

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

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

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

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

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

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

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

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

Provides an API to record properties, such as those of simulation movements after accepting decision and forcing properties.

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

Progressing towards the completion of divergence testers API. It is now understood that divergence testers provide comparison functions which can be used both as a way to test divergence and to match existing simulation movements with prevision movements generated by rules.

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

SolverSelection is a generic property sheet which can be used to associate a document to a list of solver portal types. It will be used in Divergence Testers (to provide a list of applicable solvers to solve a given type of divergence). It will be used in Resolution Decision to (to specify which solver to use).

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

Divergence testers can provide matching to Rules which need to find a way to match existing simulation movements with aggregated amount lists.

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