- removing the need of the use of search when groupby is set on a relation
field.
- creation and use of dedicated helper method to compute the orderby clause
for easier reading
bzr revid: acl@openerp.com-20140217140144-2rm3o00g76tyhqxn
This does not allow to use a database with unicode to run openerp but does not fail (was getting an empty list of existing databases)
bzr revid: mat@openerp.com-20140214144444-0tjcz14rhlw94i50
This was problematic when the admin or a mutlicompany user in parent company set a value for a property field on any record shared through companies. The change would remove the property already set on child companies instead of only replacing the current value.
The test requires previous revision (rev-id mat@openerp.com-20140213121853-mbbk6pkya92hy4xd) of server to avoid commiting changes in _field_create call.
bzr revid: mat@openerp.com-20140213134838-sia2s9vybq5oep65
Featuring:
- [FORWARD] [FIX] Forward port of revision 6920 of 6.1 addons branch, revid:odo@openerp.com-20120727150051-e1q0m92tyrazz82f. Purpose: some fixes and more robuts handling of incoming emails
- [IMP] mail: mail_thread: message routing: raise exceptions instead of using asserts. Indeed assert are statements meant to be used when developping, for debug purpose. In a production environment it is safer to use real exceptions that can be managed accordingly.
- [FIX] mail: fixed tests, no more AssertionError, but ValueError
- [IMP] fetchmail: try / except each email processing. This allows to print an exception in the logs for every failed email processing, without crashing the whole stack. Any failed or succeeded email is set as seen, to avoid crashing every time the scheduler runs.
bzr revid: tde@openerp.com-20140213115922-33vxgj7nfy86ashw
found during processing. This way, all emails in the queue are managed and
all failed emails have their own exception in the logs, allowing easier
debugging.
Note that a failed email is set as seen to avoid processing it every time
the scheduler runs.
bzr revid: tde@openerp.com-20140213095717-tcwgkl143i3ujw8h
Instead returns undefined which is handled below.
This does not solve the issue when records are not loaded properly but gives a better information on the reason.
bzr revid: mat@openerp.com-20140213085008-pnq4r0ebfl072u78
Indeed assert are statements meant to be used when developping, for
debug purpose. In a production environment it is safer to use real
exceptions that can be managed accordingly.
bzr revid: tde@openerp.com-20140212152737-c7q339psd9hi4iwd
account_id is mandatory, and is set thanks to an onchange of partner_id. But partner_id is not required, therefore, if you do not set a customer/supplier, there is no
account_id set by default.
On the purchase, the account_id was always invisible. Therefore, it was impossible to set the account_id if you did not set any supplier
On the sale, the account_id was invisible if you set the pay_now to pay later. Therefore, it was impossible to set an account_id if you did not set any customer and set pay later.
Anyway, now, account_id is always displayed, so the user can change the value of account_id if the default value provided is not was he wants, whatever the value of the other fields
bzr revid: dle@openerp.com-20140212142737-ox2l9twg3x6ywvqg
Some filters needs to be evaluated with the same
language as their author, e.g. when searching on
translatable field values. When a time-based
action is processed by the scheduled task,
we should thus attempt to reuse the same
language as the author of the corresponding
filter.
bzr revid: odo@openerp.com-20140212113924-77sh4oj6dl2qwqka
The previous behaviour used the uom of the product while it is not necessary the one selected (eg: by default the purchase unit of measure for purchase orders).
This was an issue especially when having a different uom with supplier info lines setting degressive prices. The price should be computed based on selected uom and not the product uom.
bzr revid: mat@openerp.com-20140211152703-twnzco2dwxeqt8hz
The previous behaviour used the uom of product while it could be a different one selected (by default the purchase unit of measure for purchase orders).
This was an issue especially when having different uom with supplier info lines setting degressive prices. The price should be computed based on selected uom and not the product uom.
bzr revid: mat@openerp.com-20140211145703-9uut4hw9aqh7326o
Anael Closson
Denis Ledoux
Cecile Tonglet
Launchpad Translations on behalf of openerp
Martin Trigaux
Olivier Dony
Thibault Delavallée
Mohammed Shekha (OpenERP)
Christophe Simonis
Amit Dodiya (OpenERP)