Spamming the save button when creating a new custommer in point-
of-sale create duplicate users. This PR disable the button once
clicked and re-enable it when all the processing is done.
opw-1895302
close#23919
This commit adds a compatibility file which can be added on demand by
enabling its associated view. This will basically map old BS3 classes
and structures to the related style with BS4.
closesodoo/odoo#27981
For some unknown reasons, the text-primary class was added on each
card-header of that snippet... while the default link color is already
primary by default.
This was however breaking some themes whose primary color would not fit
in card-header while the link color (different from the primary one)
would.
closesodoo/odoo#28627
Let's consider a customer C with payment terms P1 set on it
Steps to reproduce the bug:
- Create a SO for C with payment terms P2
- Confirm the SO and generate the invoice
Bug:
The payment terms on the invoice was P1 instead of P2
This fix allows to keep the same behavior as in 11.0
Introduced by: f1b2d165fb
opw:1905710
closesodoo/odoo#28585
The new product configurator introduces the possibility to create
variants dynamically. One of the main goal is to be able to create
product templates with **many** attributes and values, but not generate
all variants automatically. Only the necessary variants are created
on-the-fly.
However, it turns out that **many** dynamic attributes and values still
fails. For example, create a product with 10 attributes, 10 values for
each. This allows 10^10 theoretical combinations; although the variants
are not created, the creation of the product template fails.
The reason is that the `variant_matrix` contains the list of all
combinations, which causes a `MemoryError`.
An easy modification to improve the process is to keep an iterator
instead of generating the list. This avoids the `MemoryError`, but it
remains necessary to go through all combinations three times, which
would take too much time.
Therefore, some refactoring is necessary in order to keep the same
logic, but avoid going through any huge list. Here are the improvements:
1. Skip the creation part if nothing will be created.
If any attribute is dynamic, no variant is created. Therefore, we can
perform the check upfront and skip the variant creation part if
possible.
2. Stop the creation loop as soon as possible.
There is an hardcoded limit of maximum 1000 variants to create. We
can perform this check along with the list creation instead of
checking at the end.
3. Determine if a product has valid attributes in a different way.
The existing logic is safe but expensive: we check that all attribute
values of a product are part of the possible combinations. This can
be simplified by checking if (1) all attribute values of a variant
are part of the accepted attribute values of the template and (2) a
variant uses all attributes of the template. The second check is
mandatory to delete existing variants when an attribute is added to
the template.
Thanks to these modifications, we at worst go through 1000 possible
attribute values combinations. It might still be possible to optimize
step 3 with a fancy SQL query which would retrieve all (in)valid
products at once. Hopefully this won't be necessary and the optimized
logic will be enough.
opw-1902392
closesodoo/odoo#28530
This optimizes the confirmation of a sale_order in the ecommerce by ~73%,
for a cart with 160 unique items, the processing time goes from
7m46s to 39s, which is roughly the same amount of processing time if the
module `sale_coupon` is not installed.
This optimization is achieved in two steps:
1. By validating promotional/discounted products in batch instead of
validating each product one at a time.
2. By performing an unlink() on invalid reward lines instead of sending
a delete command by writing to the one2many, as delete commands are not
(yet) performed in batch, which means record recomputation after every
delete.
opw-1893277
closesodoo/enterprise#2905
For the special case of is_blacklisted, and due to
the size of the tablers to handle, it's faster to
filter some records rather than searching the whole
res.partner table
closesodoo/odoo#28028
Compatibility: rebuilding a correct modal from user database content.
Since the first version, the modal is saved in databases directly but
has never used a correct structure. While it was working with BS3, it is
not with BS4. This was breaking the design and prevented the modal to
be able to close.
task-1889341
closesodoo/odoo#28589
When opening the customize menu as soon as the page became visible, an
RPC crashed and the toggable options did not appear anymore. This
happened:
1) DOM is ready.
2) The user click on the menu.
3) At the same time, the customize menu is initialized (`attachTo`),
its event handlers are bound and the async `willStart` method is
called.
4) The event handler for the user click is called... and crashes as
requires a variable which would have been set in the `start` method.
The bug did not appear in previous versions as the handler was not using
the standard system and bound the event handler "by hand" in the `start`
method.
Maybe `attachTo` should not bind event handlers before the `willStart`
method is completed; this would be a subject for the master branch. This
commit solves the problem by setting the required variable in the
`willStart` method instead of the `start` method.
closesodoo/odoo#28578
In a multiple company account, when a parter is doesn't have a
company, the mails he revieved have "Send by using odoo" as footer.
This PR correct that by setting the footer to "Send using odoo" when
there is no company.
opw-1894825
In a multiple company account, when creating an event without
company, the emails sent contain "Send by False" as footer, this
PR correct that by disabling the footer in case there is no company
opw-1894825
On res.config.settings for website, when removing a language from language_ids, if this language is defined as default_lang_id, the default language will be updated by an onchange to prevent any inconsistency.
The same should happen when doing this directly on the form view of a website record.
closesodoo/odoo#27727
Until v12, doing this is wrong. The currency_id field of account.journal should only be used if the journal is in a different currency. Otherwise, this field should stay empty.
//NOTE FOR FORWARD-PORT: this commit should not be ported to 12.0 and further.
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
When sending notifications by batch one notification email can be send
up to 50 people. For one mail_mail entry to handle 50 emails can be sent
as those are sent independently for each recipient.
In some cases a bounce may occur while the whole batch of recipients is
not completely mailed. In that case the mailgateway will update the
notification status to bounced. When the cron finishes to send the whole
batch of emails it tries to update the notifications of all recipients.
However as a notification has already been updated due to the bounce we
face a concurrent update, meaning the transaction is rollbacked.
Emails have been sent but notifications are not considered as sent as they
have not been updated accordingly. Next time the cron runs it will send the
same batch again, with probably the same bounce and rollback. We could
therefore face an email loop.
This commit add test for this use case.
This commit is linked to task ID 1893054.
For unknown [1] reason, phantomjs starts to segfault when running qunit
tests.
Be radical with simply not using phantomjs anymore.
[1] Any guidance on tracking the root cause may help...
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
When computing coverage, the tests are slowed down and the timeout is
often exceeded.
With this commit, HttpCase headless Chrome tests timeout is increased if
coverage is detected.
When Odoo receive a SIGXCPU (CPU time limit reached), it shuts down
immediately. If a headless Chrome is running, it stays alive after the
Odoo shutdown.
With this commit, the signal is intercepeted and the Chrome browser is
properly closed before shutting down the Odoo server.
In some situations, Chrome remote debugging is sending an empty list of
opened tabs. In that case, an orphan Chrome process stays alive.
With this commit, Chrome is stopped properly in those situations.
Martin Trigaux