For companies not working with variants,
it is important to be able to search in the
Products menu (product.template) using
product codes.
It is useful as well to see the codes
in the default kanban view too, even if
it is only the code of the first variant.
When a stale XML ID exists in the database, `_update_dummy()`
must consider it as missing entirely, and the next call
to `_update()` will take care of cleaning up the old XML ID.
Failing to do so for `noupdate` records means the `_update`
will never happen, and as soon as another record is created
or updated with a relationship to that stale XML ID, it will
plainly crash the installation/update.
Takes care of resetting it from older versions
e.g. rev d97e7a6a4e
and c0076916f3, as
the old `variants` field that was used does not
exist anymore, crashing at opening.
Completes/improves fd6dde7ca
Because Werkzeug uses/provides flow-control exceptions via
HTTPException (which can be used as straight responses) they are used in
a few places of the web client, when triggering some redirections for
instance.
Breaking into the debugger for such mundane situations is surprising and
inconvenient for developers trying to debug actual issues in the system,
even though HTTPExceptions are by and large not error per-se, and
shouldn't warrant triggering post-mortem debugging.
So in the non-RPC dispatcher, don't post-mortem on HTTPException either.
If the report was printed from the tax codes list
Accounting > Configuration > Taxes > Tax codes
There is no information concerning what should be displayed (periods, details, etc.)
as the user did not printed the report from the wizard
(from Accounting > Reporting > Generic Reporting > Taxes > Taxes report)
We therefore set default values, in order the report to not crash
Nevertheless, the user has obviously to go through the wizard
if he wants to set a configuration different than the default one
While keeping the compatibility for reportlab 2.5.
Splitting the text node on line breaks '\n' leaded to orphans ending tags,
like '</font>', which is regarded by reportlab 3.0 as a paragraph,
and reportlab therefore surrounded these tags by <para> tags,
which leaded to not syntax correct html like
<para></font></para>
To test this patch:
- While having reportlab > 3.0
- Create a rml report containing (at least) '<font>\n</font>'
- Then print the report. It must not crash (obviously)
Debian does not allow fetching data from external website at runtime.
This fixes the privacy-breach-generic lintian warnings for Debian packaging.
The removed youtube url was a dead link...
Some .xml,.csv,.po,.woff,.ttf,.png,.eot,.svg had perm 755, provocating
'executable-not-elf-or-script' lintian warning for Debian packaging.
Set permission to 644 for those files.
Also remove unnecessary executable permissions on some .py:
-addons/l10n_fr_hr_payroll/report/fiche_paye.py
-addons/l10n_ro/res_partner.py
-addons/l10n_ro/__openerp__.py
-addons/l10n_ro/__init__.py
-addons/l10n_do/__openerp__.py
-addons/l10n_do/__init__.py
Use the local copy of those libraries instead of fetching them at runtime.
This fix was required for Debian packaging. It fixes the
privacy-breach-may-use-debian-package lintian error.
This reverts commit d970cc40f8.
point_of_sale does not depends on share. This domain can therefore not be applied.
It works for new databases as the module share is auto installed.
But as soon as the module share is uninstalled, this domain will lead to a crash
There is no way to "solve" this issue, other than by a view customization
if the issue is critical for the customer.
I did not pay enough attention when I reviewed the PR.
Do not write on the function field when you are writing on the function field.
- Now you do know what orders is right?
- I think I know...
- Orders is orders.
- I guess no one ever taught you not to use the word you're defining in the definition.
~~Lucky Number Slevin
From reportlab 3.0, empty plaintext paragraphs do not lead to a break line anymore.
Before release 3.0, paragraphs having tags but no plaintext leaded to a break line.
This patch aims to recover the behavior of reportlab releases < 3.0, as
<para><font color="white"> </font></para> is used in allmost all rml reports
The current patch is not considered as clean, but we did not find any better solution.
If someone find a parameter to pass to reportlab in order to bring back the old behavior of reportlab
he is welcome to provide the better patch.
Besides, in reportlab 3.0, splitlongwords has been introduced as parameter,
to allow to break long words. The default value is True.
This parameter seems to break the columns headers
(it splits the text within the column header)
We therefore take the choice to not activate it, as it was not present anyway in reportlab < 3.0
To test the good behavior of this patch:
While having reportlab < 3.0 (2.5 for instance), print a draft invoice
Then, upgrade to reportlab > 3.0 (3.1.8 for instance), print the same draft invoice.
The generated pdf must be (allmost) identical, in particular concerning spaces.
Specifically, the space between the partner address and his phone.
[IMP] base: safer locking at user login
When a users connects, a lock is taken on the res_user table to modify the last login date. If another running transaction uses a foreign key to res.users (e.g. write_uid column), postgres may detect the update as a concurrent update and rollback the transaction.
In pg 9.3, the lock_strength parameter 'NO KEY' allows a weaker lock which is less likely to break another transaction.
Fixes#552
These revs. introduced an API change in the _name_search method.
Indeed, the 'operator' attribute used to have 'ilike' as default value.
This cannot be changed, as every modules overriding this method
overrided it using the signature with operator='ilike'
For instance, _name_search method of addons/base/ir/ir_model.py
expects having 'ilike' as operator.
As it was not anymore the case,
it leaded to a crash when performing a name_search call on the model ir.model,
like when adding a new custom field to a model, from the web client.
opw-626161
This log line is only useful when debugging registry
loading, a limited use case now that Odoo 8 is stable.
It makes the debug log more difficult to read and causes
a small performance penalty when debug[_rpc] is on.
(+0.2s i.e. 10% extra time for loading a registry with 47
modules on a core i5-4200U machine)
[IMP] models: speedup registry loading (25% less time)
The field setup on models is improved: only new-api fields are determined when building the model's class; the final _columns dict is derived from the fields once they are set up. This avoids setting up fields and columns at the same time, and finally overriding columns with the result of field setup.
This branch also fixes the model setup in general: with the former code, a model could be introspected while it was only partially set up, and not all its fields were known.
It incidentally fixes the "loss" of parameter partial that is necessary when loading custom fields. And during a partial setup, one2many custom fields are not introduced if their counterparts (model and many2one field) are not ready.
Olivier Dony
Josse Colpaert
Arthur Maniet
Xavier Morel
Denis Ledoux
Christophe Simonis
Christophe Simonis
Aaron Bohy
Raphael Collet
Martin Trigaux
Martin Trigaux
Goffin Simon