We extract the tax creation from the AML creation in an external method,
in order to be able to call it separately.
This is necessary for the subsequent commit.
opw-1938623
Before this commit, when new messages were posted in a new
livechat, the operator received them after a delay. This
may take up to a minute before receiving the notification.
This behaviour was causing a bigger issue: those notifications
may never be received by the operator. This case happened when
the operator was receiving more recent notifications while
notifications from new livechats were pending.
The delay was caused by the operator not yet subscribed to
notifications on the newly created livechat. It is only on
the next poll of longpolling that the subscription occurred,
then followed by dispatching the notifications to the operator.
This commit fixes the issue by dispatching new messages of new
livechats directly to the operator. This is done by enforcing
the operator to make another polling when a new livechat is created,
so that he is always subscribed to those livechats. As a result,
new messages are received instantaneously.
opw-1933951
closesodoo/odoo#31191
This commit has been backported in 11.0 [1] and then reverted [2],
because it introduced a regression in web_studio, discovered at opw-1947380
As no forward-port has been done between the backport and the revert,
the forward-port of the revert also contains the patch itself, resulting
in a noop.
Actually revert 06d73eab62 in branch `12.0`.
[1] d855e3911f
[2] 1748b46718closesodoo/odoo#31637
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this commit, when printing an invoice, the taxes were grouped
by their tax group (NOT by their parent tax)
Summing the base of each tax in the process.
This was largely insufficient, as tax groups can have taxes
with different rates or computation method within them
The summing of the base of each tax for reach tax group was in this case plain wrong
This commit aims at grouping by
group > computation method > amount
Which makes more sense
OPW 1947202
OPW 1945353
closesodoo/odoo#31617
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When duplicating a project, every task linked to the project is
duplicated too but the link between sub-tasks and their parent
task is not updated thus they are left linked to the task of
the original project.
opw-1937371
closesodoo/odoo#31154
When duplicating a journal, the alias is kept. Therefore, when the user
tries to change it, it updates the value on both records.
opw-1941717
closesodoo/odoo#31242
If the stage breadcrumb on the portal view is too long, it could get on
two lines but since they are righ-aligned in inversed order, the second
line (or more) will be the first stages.
With this fix, the breadcrumbs are left-aligned so on two line the
second line are the last breadcrumbs.
Also there was possibly a different order than backend since the order
is on "sequence, name, id" in backend but was just "sequence" here.
opw-1934497
closes#31237
Before this patch, cancelling a PO of 2000 lines would take a **very,
very** long time to process... so long that I terminated it before it
finished... yikes.
This was due to the call to `_do_unreserve` on every single move when
calling `_action_cancel`, this meant that n² calls to unlink where being
made (at least), which also meant n² calls to
`stock.move._recompute_state` were being made... that's a lot of
recomputes... = bad performance
The patch simply calls unlink once, which means `_recompute_state` is
called only once, saving a lot of time.
Cancel time for a PO containing 2000 lines:
- Before patch: 1h30min+ (process terminated before finishing)
- After patch: 7min
Other modules making use of stock and `_action_cancel` should also see
benefits from this patch
closesodoo/odoo#31787
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For every line in a RFQ, we create a stock.move upon confirmation of the
RFQ. This create, in turn, triggers a lot of recomputes that are not
needed for the creation of the next moves and thus should only be
triggered once.
This commit disables the recompute during the step that creates the
moves and then manually triggers the recompute **once**, after all the
moves have been created.
Confirmation time for a PO with 2000 lines:
- Before patch: ~1h
- After patch: ~9min
This patch is similar to the one introduced at [1], however the
previously mentioned patch uses batch create which is not available in
this version, so we manually emulate batch create's behavior.
[1] https://github.com/odoo/odoo/pull/31471
The reference fields is supposed to contain the reference number in the vendor's
system. E.g. if the vendor is using Odoo, it could be SO0744.
Therefore this reference is not supposed to change once written by the user.
However there is the _onchange_origin that uses the origin purchase order lines
to populate the reference fields on invoice_line_ids changes.
We remove entirely this behaviour for reference,
essentially reverting 052a5702c5.
Instead we put a default for origin and reference in action_view_invoice
so that these values are initially used at create.
opw 1920747
opw 1944840
closesodoo/odoo#31757
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Let's assume a form view with a clickable statusbar, in readonly.
When the user clicks on a status, the change is saved directly.
When the save fails (e.g. access rights), the statusbar widget
is in an inconsistent state and must be reloaded.
This rev. reloads the whole record and re-render the form when
this happens.
Related to Issue: #1915391closes#29519
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
As the message was set globally in the file, a _lt was needed for a lazy
translation
Fixesodoo/odoo#26288closesodoo/odoo#31761
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Search for orders that are not abandoned
Before this commit, the same results for abandoned and not abandoned were returned
This was because the not abandoned domain was not negated with the '!' operator that
expression.distribute_not() relies on
After this commit, the abandoned domain is negated
OPW 1942311
closesodoo/odoo#31739
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, users wasn't able to input values in some
input elements like password, email and phone in mobile.
Steps to reproduce:
- Go to user
- Select Preferences
- Select Change password
- Try to input something
=> The focus was lost and the keyboard disappeared
In fact, a hidden input always have the focus when no other fields
need it. This input is used to intercept a value from a barcode
scanner.
So now, we added some input types to avoid to set the focus on the
barcode input.
It's quite difficult to test this feature because we aren't allow
to simultate a keyboard to write in a input field.
See https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent
Plus, we don't have the focus in mobile except if we have the cursor
inside the window.
So, we can't test focused elements or input values.
opw-1936712
opw-1948266
closesodoo/odoo#31566
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
On /shop, we access the image field to generate the image widget, but we don't
actually need the image content, we just need its url. When `bin_size` is added
we don't compute all the resize for nothing.
opw-1923999
task-1922055
PR: #30274
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The `_get_combination_info` override in website_sale_stock is only necessary
when we want to get the stock, which is on the product page RPC.
Before this commit, the stock would be computed all the time, which slowed down
the requests for no reason.
opw-1923999
task-1922055
PR: #30274
In order to increase performance, it was decided to avoid computing the first
combination on the /shop page, because it has to be done for many products in a
loop. Instead, we only display the template data, which is faster to get.
This implies that when using only one variant, we need to always write on the
template image instead of the variant image. This is needed because when there
is only one variant, the user doesn't know there is a difference between
template and variant, he expects both images to be the same.
To achieve this, we also had to change how the quick buttons work on the /shop
page ("add to cart", "add to wishlist" and "add to compare"). Indeed it was
decided that their behavior should be the same, no matter how many combinations
existed or not on the template. Therefore, the standard behavior of those
buttons is to always do their action on the first possible variant, that is
cached so we can use this logic without ever needing to read anything else than
the template data (and the cache).
opw-1923999
task-1922055
PR: #30274
If user has blocked odoo push notifications
then there's no way to enable via the OdooBot notification in the systray as it depends on the navigator
so display the alert message under users preference section.
Related Task ID: 1929547
closesodoo/odoo#30496
Active currencies are given in session_info, in the page source.
When the user activated a new currency, he had to reload the page
to make the browser aware of that new currency (without reloading,
there was no currency symbol displayed next to the amounts).
This rev. forces a reload of the currencies each time a currency is
edited.
Task #1838654closesodoo/odoo#31192
This commit will add tests for the PR #30656 which added the following commit:
7daa85dd12
The tests in the current commit achieve 100% code coverage for:
- the `image.mixin`
- the overridden `image.mixin` methods in `product.product`
- the `_get_images` methods of ecommerce
- the size logic in method `content_image` (route `/web/image`)
PR: #31181
Change the domain to not include `.id` and to use `in` to prevent subqueries
to be ran by the ORM for each attribute value.
On the filter, directly use `attribute_value_ids` instead of the computed field
`product_template_attribute_value_ids` that leads to the same result, to prevent
unnecessary compute of that non-stored field.
Cache the result of the method. The cache is invalidated when the configuration
of attributes and values change.
We can remove all cache invalidation from the tests since it is done at the
appropriate times in the business code now.
opw-1923999
task-1922055
PR: #30274
Take advantage of prefetch and api.multi, instead of calling plenty of methods
that didn't cache their result and did separate queries for each record.
opw-1923999
task-1922055
PR: #30274
The method was doing an unnecessary sort since the _order has been fixed in
f8dad1bb4b
Moreover, it tried to find the ptav through the attribute_id related field and
a map on the other side, instead of directly relying on the ids of the ptv.
opw-1923999
task-1922055
PR: #30274
We replace `_get_first_possible_combination` by a generator. By iterating it, we
can find as many possible combinations as we want, as suggested in task 1936680.
So if we need to get or to know if any arbitrary number of combinations exists,
we can just iterate on the generator multiple times, without having to start
over from the start every time.
opw-1923999
task-1922055
PR: #30274
Before this commit, the list view of variant didn't use `_get_combination_info`
so the displayed price was not taking into account important settings such as
B2B/B2C and currency convert.
In Odoo, create a user John@example.com (the cap is on purpose)
In Google Calendar, create an event and invite john@example.com
Sync your Google calendar.
Before this revision,
the event created in Odoo did not add John@example.com,
but created a new attendee, john@example.com, because
of the sensitive casing.
Besides, give the priority to partners having
users, so if there are two partners with the same email,
one of them having a user,
e.g. John@example.com (with user) & john@example.com (without user),
set the partner having the user as attendee,
as its the one with the user who use the Odoo calendar,
and potentially the Google sync as well.
opw-1925592
closesodoo/odoo#31111
Since the invoice validation is well separated from the account entries creation (and made before), the chatter was showing too much status change upon an invoice validation.
This commit makes sure we never consider an invoice paid when its move hasn't been created yet.
closesodoo/odoo#31100
In some case, when the user enter by mistake an account move line
with an amount of 0,the reverse operation does not works properly.
The issue happenned during the reverse operation because it tries to
reconcile a 0 account move line with no matches (credit or debit).
See opw-1931961
When search on partner_id return thousands of records, thousands of
_name_get are performed, and there's a great chance to not use them at
all. Using the lazy_name_get seems more efficient in terms of memory and
cpu.
closesodoo/odoo#31075
Signed-off-by: Christophe Simonis <chs@odoo.com>
Commit 6d67ce5b7c refactored the JS from multiple website modules including
`website_links`.
A few error needed to be fixed:
- recent links would not appear anymore
- graphs would not be displayed anymore
- graph resize on tab change would not be fired
This commit fixes it and also add some tests to be sure this module is now
strongly tested.
Note: tests are skipped for now as there is a race condition happening only
with docker and this fix is getting urgent for Odoo.com
closesodoo/odoo#31507
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30357
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
note: backport of 11.0's 7a453b0b7a
In 10.0 this trigger could cause a "blur" which in some instance is not
wanted (eg. inside a newline of a list view).
opw-1906581
closes#31078
The html widget automatically replace an empty field value by
`<p><br></p>` to be able to add content.
But this may cause unintended "onchange", since the value has "changed"
and the onchange themself could cause error when triggered at the wrong
time (eg. inside a list view with required fields).
With this changeset, the onchange is averted when the value was false
and is now `<p><br></p>`.
opw-1906581
closes#31078
Revert commit 296c5a2106
which was half-right: the accounting logic is correct but it overlooked
that it broke the reconciliation of cash returns
i.e. the client gives more money, and you return the change
Given that this latter use case may occur more frequently we focus on that
while we break freight returns
i.e. the client returns a product, and you give the money back
It is not possible to support both use cases because
ultimately we don't know from which order an account.move.line comes
the related PR #23356 should support both use cases
but adds a field on account.move.line
OPW 1925607
closesodoo/odoo#31037
This commits adds a message to the module import wizard to make it more
clear what kind of modules can be imported through the front end.
project : RD feedback
task : [base_import_module] what it is not for.
opw-1939967
closesodoo/odoo#31057
Nicolas Martinelli