This is to help forum moderators to fight against
spammers. It was previously difficult as the spammer
profile became unreachable as soon as their karma
went below 1, even if they had other questions
or answers still published.
It looks there is a bug in Firefox concerning responsive images in table. See bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=975632
Bootstrap advises to use width: 100% for .img-responsive as workaround were needed.
The @moz-document is to apply this for Mozilla only.
opw-617582
opw-618659
The field account_id was inherited with position="replace" meaning we erased
future changes made into hr_timesheet_sheet (41f2eba missed "type in []" and
65f31b9 missed use_timesheets).
Replace by position="attributes" to only change what matters: the on_change.
Fixes#3974
The website name is by default "localhost" (used in the page title in the format
"Current Page | Website Name") but there were no way to change it.
Fixes#3493
During rev. cbe2dbb, type2journal was refactored, and set as a global variable in the top of the file, as it was use everywhere accross the file.
But, in this specific method _get_journal_analytic, this type2journal dict wasn't the same as everywhere else, as you can see at rev. d2ff95f for example. We must therefore set a specific type2journal dict for this specific method.
Reminder emails are generated based on the list of attendees.
The email_to field used to be a string with a list of emails separated by spaces
while the comma is the valid separator (RFC2822).
Fixes#3933#3784#2033
Button "Save and continue" was wrongly named as it worked only once the template
is not in edit mode (so already saved).
Hide the button to only get it in readonly mode and rename it for better
understanding of its purpose. (opw 614563)
See issue #3964 for more detail. Main problem was caused by commit
f0e331e005. It set the key name+'__display' to false when reloading
a record for all field types, but it was only concerned with many2many.
As opposed to before, the source package includes requirements.txt,
LICENCE and the README.md. Note: avoiding to chip openerp.egg-info
leads to weird issues so let's just keep it at the moment.
PyChart is now in the EPEL repo so we now list it as required in
setup.cfg. The other mandatory lib not provided by EPEL are
pyPdf, vatnumber and pydot and are now installed by easy_install
during the post install.
By default, the package was installed in /usr/local/lib/python2.7 in CentOS7.
It is problematic because most of other python packages are installed in /usr/lib
and also because /usr/local/lib is not in the default PYTHONPATH. It's fixed by
overriding the install script and forcing prefix to be /usr.
Added a minimal systemd unitfile.
Adapted tests accordingly.
a blog will receive notifications only for published posts. They
will not receive all comments of all posts anymore.
When commenting a post users will receive the answers.
Added tests to try to test this behavior.
QWeb monetary widget uses the precision of the currency to know the number of
digits to display on a price. The number of digits is based on log10(rounding).
For currency with rounding different than 10^x (e.g. in Switzerland 0.05
to allow 5 cents coins only), the number of displayed digits should be rounded
up. e.g. log10(0.05) is -1.3, rounded up to 2 digits.
Fixes#3233
This fix is related to c12a2e1d16
Mutex allow to wait sequentially for mutex
Besides, if one of the onchanges deferreds fails, it does not resolve the mutex until all deferreds of the mutex are resolved.
Besides, we now wait for the onchanges mutex between each field commited value (line 596) in case the commited value leaded to a new onchanges, that we should wait for before commiting the rest of the values.
When deleting a partner with some contacts, if the contacts had selected
the "use parent address" checkbox, the address of the contacts was stucked in
readonly mode (no checkbox to disable it).
Disable use_parent_address for orphan partners.
Fixes#3611#3613
For instance, when a context was passed to a method, but no lang was defined in the context, it did not tried to fallback to other places where we could have find the user language.
Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.
An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.
Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.
This problem was initially solved using an extra rounding.
However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)
At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.
Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.
Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.
Two extra tests have been added to cover Example 1 and Example 2.
--
Related to #2072, #1125, #1126, #2672Closes#2495, #2498
Jeremy Kersten
Olivier Dony
Denis Ledoux
Antoine Huvelle
vrenaville
Martin Trigaux
Frédéric Van der Essen
Frédéric van der Essen
Christophe Simonis
Eddy Ernesto del Valle Pino
Ravi Gohil
Jacques-Etienne Baudoux
Géry Debongnie
Loïc Bellier
Aaron Bohy
Simon Lejeune
sve-openerp
Amit Vora
Goffin Simon
Xavier Morel
Andrius Preimantas
Antony Lesuisse
Akash Balar
Arthur Maniet