* web_editor
When an user saves its website, all the animations are destroyed so that
a clean DOM is saved. This is particularly important for snippets like
the latest post one that would crash the page if not cleaned before
saving.
Two cases were found where animations were not cleaned before saving and
this is what this commit fixes:
- When an user used the undo/redo system, all animations were lost as
the DOM is recreated.
- When an user duplicated a snippet, animations were not restarted on
the cloned element.
closesodoo/odoo#29159
Steps to reproduce the bug:
Let's consider a product P with a unit price = 10
- Create a SO for two lines of the same product P
- Validate the SO and create the invoice
- Refund the invoice and validate it
- Go to Reporting > Sale report and select "Invoiced amount" as measures
Bug= -20 was displayed for the invoiced amount.
Technically, the two refund invoice lines of P were used two times in function
_compute_invoice_amount because for each SO line we catched all the refund lines
of the same product.
opw:1906445
closesodoo/odoo#29095
While creating a new record, the default value of a field used with the
'html_frame' field widget was not used.
Discovered with task-1903256
closesodoo/odoo#28838
The BoM structure report is recursive, since product X might use a product X.Y,
itself built using a BoM that uses X.Y.Z, and so on.
To avoid breaking the layout in cases with too deep nestedness,
the report returned a level bounded by 6.
This is a totally arbitrary value: the layout can be broken not only
because of nestedness, but also because of the length of the product name.
So it doesn't really solve the problem.
Moreover, a presentation problem should be solved at the presentation layer,
which is CSS.
opw 1921011
closesodoo/odoo#30606
When a user/partner is deleted, their messages lose their author.
Replying to those may result in a failure to fetch the mails from the
incomming mail server.
without this commit, partner_ids == [(4, False)] and this value "goes
down" all the way to the orm method "write" of the Many2many field.
resulting in a SQL query like :
INSERT INTO mail_message_res_partner_rel (mail_message_id, res_partner_id)
(SELECT a, b FROM unnest(ARRAY[149855]) AS a, unnest(ARRAY[false]) AS b)
EXCEPT (SELECT mail_message_id, res_partner_id FROM mail_message_res_partner_rel WHERE mail_message_id IN (149855))
which fails with the ProgrammingError : EXCEPT types boolean and integer
cannot be matched
opw-1921805
closesodoo/odoo#30528
Before this commit, in the customer invoice form, when the outstanding
credits have a big reference or name, the form displayed the name in a
multiple line which made difficult to read and to understand when a
credit starts, and when a credit stops. It also overlapped the name and
the amounts.
Now, when the name is too big, it's truncated, and the full name is
shown when the mouse hovers the field.
OPW-1915966
closesodoo/odoo#30518
- Create a bank statement for a negative amount, e.g. -100.
- Click 'Reconcile'.
- Create a counterpart line for this bank statement, but specify
receivable account.
The payment created has `partner_type` set as `supplier`.
Although a receivable account is used for customers.
This use case can arise in case of a credit note to a customer: the
reimbursement should create a customer payment, not a supplier payment.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1910807
closesodoo/odoo#30232
Before this commit, in a multi-companies when the user can manage
multiple stock locations, there is an error with the default Locations
('default location' and 'default Destination Location' in an Unbuild
Orders; and 'Raw Materials Location' and 'Finished Products Location' in
a Manufacturing Orders). The default gives the stock location of the
first company, if we are working in a different company it will generate
an access error. Also, in an Unbuild Order you could choose location
that there are not internal at the company.
Now, the default location, it's the one of the first Warehouse of the
company. And the form only propose to choose internal locations.
OPW-1919771
closesodoo/odoo#30585
This revision moves the `cache_key` to the first level
dict of the cache, instead of the last one.
Doing so, we reduce the number of times the reference
to the cache key is stored in the dict.
For instance,
for 100.000 records, 20 fields and 2 env (e.g. with and without sudo)
formerly, there were 100.000 * 20 * 2 occurences of cache key references
now, there is only 2 references.
Storing references to an object consumes memory.
Therefore, by reducing the number of object references
in the cache, we reduce the memory consumed by the cache.
Also, we reduce the time to access a value in the cache
as the cache size is smaller.
The time and memory consumption are therefore improved,
while keeping the advantages of revision
d7190a3fd0
which was about sharing the cache of fields
which do not depends on the context, but
only on the cursor and user id.
This revision relies on the fact there are less different references
to the cache key then references to fields/records.
Indeed, this is more likely to have 100.000 different records stored
in the cache rather than 100.000 different environments.
Here is the Python proof of concept that was used
to make the conclusion that setting the cache_key
in the first level dict of the cache is more efficient.
```Python
import os
import psutil
import time
from collections import defaultdict
cr = object()
uid = 1
fields = [object() for i in range(20)]
number_items = 500000
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache_key = (cr, uid)
cache = defaultdict(lambda: defaultdict(dict))
for field in fields:
for i in range(number_items):
cache[field][i][cache_key] = 5.0
# cache[cache_key][field][i] = 5.0
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Using `cache[field][i][cache_key]`:
- Time: 3.17s
- Memory: 3138MB
- Using `cache[cache_key][field][i]`:
- Time: 1.43s
- Memory: 756MB
Even worse, when the cache key tuple is instantiated inside the loop,
for the former cache structure (e.g. `cache[field][i][(cr, uid)]`),
the time goes from 3.17s to 25.63s and the memory from 3138MB to 3773MB
Here is the same proof of concept, but using the Odoo API and Cache:
```Python
import os
import psutil
import time
from odoo.api import Cache
model = env['res.users']
records = [model.new() for i in range(100000)]
p = psutil.Process(os.getpid())
m = p.memory_info().rss
s = time.time()
cache = Cache()
char_fields = [field for field in model._fields.values() if field.type == 'char']
for field in char_fields:
for record in records:
cache.set(record, field, 'test')
print('Memory: %s' % (p.memory_info().rss - m,))
print('Time: %s' % (time.time() - s,))
```
- Before (`cache[field][record_id][cache_key]` and cache_key tuple instantiated in the loop):
- Time: 4.12s
- Memory: 810MB
- After (`cache[cache_key][field][record_id]` and cache_key tuple stored in the env and re-used):
- Time: 1.63s
- Memory: 125MB
This can be played in an Odoo shell, for instance
by storing it in `/tmp/test.py`, and then
piping it to the Odoo shell:
`cat /tmp/test.py | ./odoo-bin shell -d 12.0`
closesodoo/odoo#29676closesodoo/odoo#30554
Before this commit, in the filter, when using a custom filter with a
date field, the operators "is after" and "is before" were set to execute
"is after or equal" and "if before or equal" respectively. That means it
includes in the results, records with the same date as the filter.
Now, the operators 'is after' and 'is before' won't include the records
with the same date as the filter. And the operators 'is after or equal'
and 'is before or equal' will include the records with the same date as
the filter.
Fixes#29868
OPW-1921756
closesodoo/odoo#30560
Because in France the affectation depends on the result (gain or loss) for the selection of account and thus, we cannot arbitrary choose one.
Was PR #17775closesodoo/odoo#30527
Add quantity key to context instead of overwrite the entire context
If another context key was present, it would be lost
Introduced at 166a9d26e3closesodoo/odoo#30519
Suppose that a Task is added on a task via a studio customisation.
Then the _get_message_needaction method gets called on the onchange of the
toplevel task, which triggers another call to _get_message_needaction.
During that update, we get a self with a model.newID; its ids field is empty,
so the list of tasks res itself is empty.
As a result the method crashes on a malformed query.
This can in turn prevent the completion of some higher-level operation,
e.g. a state change on the task.
opw 1909043
closesodoo/odoo#29084
Have:
- Model A with a x2m to model B
- Object A with multiple objects B in x2m (that will be sorted)
- On the list view of model A, click on a column to sort by a field
- this field shall not exist in B
- open a record A (towards form view)
Before this commit, the sorting of the x2m crashed, because the key orderedBy was propagated
Due to commit e713ed2a69
After this commit, it doesn't crash
OPW 1913133
closesodoo/odoo#29094
Usecase to reproduce:
- Enable 'Managers must approve orders'
- Set agreement type as 'exclusive'
- Connect as purchase user
- Create a requisition and an RFQ linked to it
- Confirm the RFQ
It raises a usererror that ask to close other PO linked
to requisition.
It happens because the purchase requisition code do not take
care of double validation on PO. It will try to close the requisition
once button_confirm is called. However it will only write 'to approve'
on PO state and thus trigger the requistion error will be raise since
all linked PO are not 'done' or 'cancel'.
In order to fix it, the action_done on requisition should be call
on button_approve instead of button_confirm. (button_approve is
automatically called when double validation is not enable).
Task: #1884410Closes#28068closesodoo/odoo#29049
Modifying a source term in an XML/HTML translated field can lose translations
if the same term is translated in several languages.
closesodoo/odoo#29078
The other methods do test password length before verifying it, so even
if check_credentials() is not meant to be called directly, it's better
to keep it consistent with the alternatives.
Closes#29023
Suppose you have a workorder to create n units of product P,
using raw material R (suppose we use one for one, the following can be extended
to any number of raw materials and factors in a straightforward manner).
Produce j < n units of P. Next, update the quantity to produce to j < k < n.
Since any number m of units between j and n may already have been reserved,
in particular values such that m > k, the move will unreserve the material R.
However, while doing so it will unlink the move_lines, and lose the
quantity_done (j).
The newly created move lines have a quantity_done of zero by default.
Therefore, we store in a dictionary the quantities done for each move line,
and reset these values once the unreservation/reservation of k units is done.
opw 1911969
closesodoo/odoo#28990
Before this fix products in a pricelist would not be grouped when there
is a decimal value in the price.
This problem was caused by a trailing rounding error, for instance a
price of 29.90 could give a pricelist price of 29.900000000002. To solve
this we check if Math.round((price - pricelist-price)/currency-rounding)
gives 0 as a result, if so, the price is equal to the pricelist price
and the product can be grouped.
solves: https://github.com/odoo/odoo/issues/28521#issuecomment-443148920closesodoo/odoo#29185
When activating a filter on a list view,
the environment of the action contained a context with an orderedBy key
which was then used by every controller and model in the various
parallel flows, i.e. changing actions
After this commit, we prevent it by excluding the key when executing an action
OPW 1913190, 1914019
closesodoo/odoo#29186
Changing the journal of a reconcialiation model to a journal not
reconciliable resulted to the model not accessible from any
menu.
opw-1913079
closesodoo/odoo#29249
We now support version 0.12.5(.1), which is available for all recent Debian and Ubuntu versions,
and contains quite a few bug fixes. An up-to-date version of Odoo 10 or later is required, for
pixel-perfect compatibility with the result of 0.12.1.3.
See also the wiki for more info: https://github.com/odoo/odoo/wiki/Wkhtmltopdf
Firefox for android gives atraceback when clicking the print receipt
button. This traceback is caused becaus Firefox for Android does not
support printing.
This fix replaces the traceback by an explanation why it is not possible
to print.
Also backport for safari-fix
closesodoo/odoo#28919
/!\ Should not be forward-ported in *12.0* /!\
Because of the mechanism to bind change / click event in the 10.0
implementation, when we are in edit mode on a product page, the event
handlers that are in charge of updating the cart quantity can still be
triggered.
After this commit, click / change event while updating cart qty will
not be effective in edit mode.
task-1825889
Closes https://github.com/odoo/odoo/pull/24211closesodoo/odoo#29224
- Create a product A with a sales price of 40
- Create a pricelist where product A costs a fixed price of 100
- Assign this pricelist to a customer
- Connect as the customer on the eCommerce
On the eCommerce, the price for A is displayed as: ~~40~~ 100.
We only display a price difference if the pricelist price is smaller
than the sales price.
opw-1885443
closesodoo/odoo#29141
- Create a product with 2 variants A & B
- Set a weight on the variants (btw, the weight field is not available
on the template in this case)
- Create an invoice for A, validate
On the intrastat report, the weight remains 0.0.
The report clearly takes into account the weight of the template, not of
the variant. We use the product weight, and fall back on the template
weight.
opw-1913305
closesodoo/odoo#29178
- This commit fixes a crash that happens when the server receive a
JSON-P call done in two requests (a POST followed by a GET).
The issue is due to the fact that when the first request is done (POST
one) the member `params` is never initialized.
This parameter is then used in the module `auth_signup` on an override
of the method `dispatch` thus crashing the code.
To avoid the crash, we now initialize `params`.
closesodoo/odoo#27369
Have a recurring meeting, repeated until some date
Edit one of the instances and detach it (click on "update only this instance")
Edit the detached event and change some value
Save
Before this commit, a JS error was thrown saying that the field final_date was invalid
This was because the required attribute on this field was set to True, but the python
put the value of the final_date to False
After this commit, there is no error as we set this value to false, since the field
doesn't make sense for a non-recurring event anyway
OPW 1892426
closesodoo/odoo#28850
Put the browser in timezone Sao Paulo (Or like West of UTC)
Trigger the autocomplete (and the subsequent search) on a date field
by writing a date (in the locale format) in the search view
Before this commit, the domain sent to the server contained the date as the day
**before** the one asked for in the input
This is because, the string input is parsed and gives:
input = 12/02/2018
When creating the moment object:
> since there is no explicit time, moment will interpret it as 12am (midnight)
> We force moment to consider the string as being UTC (function: moment.utc())
> the moment contains, as output the time ** 2018-02-12T00:00:00 UTC **
When getting the facet value for making the domain
> we call toDate on the moment object, which, according to the browser is UTC and will
be converted to the locale timezone before formatting
> And the domain will use the date 2018-02-11T22:00:00 Brazil/SaoPaulo
which gives the day before the one we asked for
After this commit, this issue doesn't arise, because we use the string representation of
the moment object in search_inputs (i.e 2018-02-12T00:00:00 UTC), to create a new one
*BUT* we create it with a date format that excludes the time from being interpreted.
Also, the resulting moment object in this case is not flagged as UTC anymore
OPW 1903224
closesodoo/odoo#28542
Purpose
=======
Buggy example:
I have a 35h working schedule. I work every week day:
- From 8h to 12h
- From 12h to 16h
Let's say that I want to retrieve the working hours from Wednesday 14h03
to Thursday 11h03.
The working hours are:
- From 14h03 to 16h --> 1h57
- From 8h to 11h03 --> 3h03
----------------------------
TOTAL 5h
Currently the result will be 1.95, i.e. 1h57 because the second day
is not taken into account as start time > end time, and thus rrule
doesn't manage this correctly and returns only the datetime corresponding
to the first day.
Specification
=============
Force the until parameter of rrule to be set at the end of the day, do
avoid skipping the second day. Do this in the methods that compute the
work hours and the leave hours.
Add a test to ensure the robustness of the fix.
Closes#21297closesodoo/odoo#28920
This revision brings the compatibility for our reports
using wkhtmltopdf 0.12.5.
Up to now,
the supported wkhtmltopdf version was 0.12.1.
The goal of this revision is to add the compatibility
to wkhtmltopdf 0.12.5,
while keeping the same exact rendering than in 0.12.1.
There is a behavior change with the `--dpi` parameter,
which no longer has a "zoom" level effect as it did with 0.12.1.
To deal with it, we pass the `--zoom` parameter when
the detected version installed of wkhtmltopdf is after 0.12.2,
with a ratio 96:dpi. 96 being the default dpi of wkhtmltopdf.
This trick allows to render the reports with the exact same
zoom level, whatever the dpi value configured in the reports paperformat.
(at least with dpi values up to 149, after 150, included,
the dpi parameter with wkhtmltopdf 0.12.1 as a weird behavior,
it no longer zoom out)
opw-1907346
closesodoo/odoo#28864
Fixing it directly by commit since there is no es_AR on transifex.
The issue of the ticket has been solved by transifex, this is for
another similar issue that has been found.
opw-1907924
closes#28923
qsm-odoo