For a compute store field with new records (e.g. during an 'onchange'),
the compute method can be called multiple times on the same records
without changing the dependencies. Moreover, it can lead to have N² / 2
complexity for a trivial compute on N records.
With partial (where we don't always change the value) compute method:
```
@api.depends('reward')
def _compute_has_been_rewarded(self):
for rec in self:
if rec.reward:
rec.has_been_rewarded = 'Yes'
```
If every `reward` of `self` (N records) is `False`, when the ORM needs
to recompute `has_been_rewarded` of `self`: the compute will be batched,
but only the first record in the batch will be set (to `False`) each
time (due to the current fallback - "fallback to null value if compute
gives nothing"). This means that we will call the compute method N
times, and the compute itself will loop on an average of N/2 records
(the prefetch set decreasing at each step).
Fix this quadratic behavior by setting the cache to `False` for every
record not set during the compute method (instead of just the current
record).
closesodoo/odoo#142162
X-original-commit: 1604ee983aadc0cbee0cd50cbea2b09572905b04
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Odoo periodically updates the user online status. This is
done every minute and is throttled in order to ensure it won't
be triggered more than it should.
Since [1], the underscore `throttle` function has been replaced
by the `throttleForAnimation` function. This is not equivalent:
the function won't be triggered if there is no animation which
result in an outdated user status.
This issue was highlighted by the live chat: the button does
not show up when there is no available operator.
Steps to reproduce the issue:
- Log in on Odoo with live chat installed
- Go to a web page that uses the live chat widget
- Wait more that one minute and refresh the page
- The live chat button is not shown anymore: the only
operator is considered as disconnected.
This PR fixes that issue by re-introducing the underscore
throttle function: it is robust and can be needed, not all
throttles are linked to animations.
[1]: https://github.com/odoo/odoo/pull/120437.
opw-3578517
closesodoo/odoo#142160
X-original-commit: f64a7cbad3dee3ffc365b931306b1c13c8bff536
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
When we are importing a module and we need to create an attachment from
a file in static. We get an error if the file path of the file contains
a space.
We get this error becuase it takes the path to generate an xml id and
the name of an xml_id cannot contains spaces.
closesodoo/odoo#142113
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Before this commit in large database, the time to unlink some lot can take lot of time.
closesodoo/odoo#142105
X-original-commit: 654ee5c54db6d2cdf7a9d6797899d25a5b156059
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
A traceback was being thrown when multiple recurrent events were being updated by a batch microsoft update due to a `self.ensure_one()` validation:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2003, in __call__
response = request._serve_db()
File "/home/odoo/src/odoo/odoo/http.py", line 1589, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1616, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 1820, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/addons/website/models/ir_http.py", line 237, in _dispatch
response = super()._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/microsoft_calendar/controllers/main.py", line 55, in sync_data
need_refresh = request.env.user.sudo().with_context(sync_context)._sync_microsoft_calendar()
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/res_users.py", line 106, in _sync_microsoft_calendar
synced_events, synced_recurrences = self.env['calendar.event']._sync_microsoft2odoo(events) if events else (self.env['calendar.event'], self.env['calendar.recurrence'])
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/microsoft_sync.py", line 385, in _sync_microsoft2odoo
update_events = odoo_event._update_microsoft_recurrence(mevent, microsoft_events)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/microsoft_sync.py", line 319, in _update_microsoft_recurrence
odoo_event.with_context(dont_notify=True).write(dict(event_values, need_sync_m=False))
File "/home/odoo/src/odoo/addons/base_automation/models/base_automation.py", line 401, in write
return write.origin(self, vals, **kw)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/calendar.py", line 180, in write
self._recreate_event_different_organizer(values, sender_user)
File "/home/odoo/src/odoo/addons/microsoft_calendar/models/calendar.py", line 203, in _recreate_event_different_organizer
self.ensure_one()
File "/home/odoo/src/odoo/odoo/models.py", line 5161, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: calendar.event()
```
After this commit, this traceback is now fixed because the validation iterates over each event, avoiding the batch conflict with the `self.ensure_one()` function and skipping the validation of recurring events since these updates are exclusively on the Microsoft side, which does not allow changing the organizer.
Issue from: 3450045
closesodoo/odoo#142099
X-original-commit: 7c064a1
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Current behavior:
When you link a printer to the sales detail report. The report will
contains no order. This happens because we are trying to assign docids
to the session_id.
Fix:
Docids represent the session_id only when the report is called from the
PoS directly. So we want to use it only when it's the only data passed
to `_get_report_values`. If session_id is not set in the data, but other
values are (date_start/stop, config_id) we should use those value in
priority.
When called from the frontend directly, docids doesn't represent a
session_id.
Steps to reproduce:
-Install pos_iot
-Link a printer from the demo iot to the sales_detail report (go in
settings > reporting > reports)
-Do some orders on the PoS, and close it
-Go in the backend, and print the sales detail report
-You will see that the report is empty (You can put a breakpoint in
get_sale_details method to see that it will be empty)
opw-3247196
closesodoo/odoo#142093
X-original-commit: d93ffa4c770364c31b2a2e0ad855bf8801f23c24
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Until now, only Eyropean tax numbers were taken into account.
Now, Indian numbers are also considered valid and sent to IAP
for link creation.
This commit takes advantage of IAP changes, which now integrates
the Indian GST tax number system.
closesodoo/odoo#142082
X-original-commit: 1a1b9b27efda49fce6a61c0aeb8deb60e040771e
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Damien Decleire (deda) <deda@odoo.com>
The recruitment settings were using the iap_buy_more_credits widget,
even tho there is no hard dependency between IAP and Recruitment. Which
was causing a traceback when IAP was not installed.
The widget has been moved to the enterprise module
`hr_recruitment_extract`.
Closes#114747closesodoo/odoo#142073
X-original-commit: 12f0730d75c2d3316fd7dc06f33a17d9b6ffd963
Related: odoo/enterprise#50658
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Before this PR, the dropzone background was not showing on
the embed live chat. The dropzone is displayed as a `main
component`. In the Odoo frontend, the main component container
is displayed outside of the live chat shadow dom, where the
`bg-view` class is not available. This commit replaces this
class by the `bg-100` one that is almost the same and available
in the frontend.
task-3595537
closesodoo/odoo#142055
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
An object was defined before a conditional return statement and as a
variable rather than a constant.
closesodoo/odoo#142049
X-original-commit: d6478d9af76422eccecffb79bfd6be90cc714342
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
This commit addresses a traceback that occurs when trying to serialize a
node that has no `oid` property because it was added to the DOM while
the mutation observer was not active (eg, using `observerUnactive`).
This is the case with technical nodes added for managing the selection
around links ("link zws spans").
When serializing a node, we expect it and its descendants to have an
`oid` property so we throw an error if such is not the case. But we now
have a legitimate case where nodes have no `oid` property so this
removes the error. If the `oid` was in fact really supposed to be
defined (eg, the node we tried to serialize was the direct target of a
mutation), an error will be thrown soon enough after when trying to
access said property.
Note that other, more ad-hoc fixes specific to the link zws spans would
have been possible (and might still be useful in the future), such as:
- skipping said link zws spans when serializing
- adding a fake `oid` property to the link zws spans
task-3593081
X-original-commit: ba6a7fa4cf5ad422816e49b4d3b941297841ed3f
Part-of: odoo/odoo#142049
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Opening the Overview of manufacturing orders containing work orders
without expected duration gives a division by zero.
closesodoo/odoo#141944
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Enable 3 step delivery (pick,pack,ship) in inventory settings
- Create and confirm an SO with a consumable product
- Put the first transfer (PICK) in pack
(check show detailed operation will make it easier to see the bug)
- Result package is correctly set and will be correctly set as source
package for the following transfer (PACK)
Bug:
result package is not set on the following transfers
Fix:
propagate the package by default (if it's disposable) since consumable
product do not have a stock.quant _check_move_lines_map_quant_package
will fail and package_level will not be created and result will not be
assigned
opw-3513870
closesodoo/odoo#141914
X-original-commit: 83996db3adaf44f5d4428d602071224095cd4790
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This commit fixes the following issues:
1. Before this commit, when adding a new move in a repair order, its
default quantity was equal to the repair order's product quantity.
The move's quantity should be 1 by default;
2. The `forecast_availability` is renamed from "Reserved" to
"Forecasted";
3. Removes the "Clear Quantities" button since it does basically the
same thing than the "Unreserve" button.
closesodoo/odoo#141849
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
For multi steps batch pickings, the package is not forwarded
like it is for 'simple' pickings.
closesodoo/odoo#141822
Related: odoo/enterprise#50532
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit only purpose is to propagate the CLA that was
stopped manually in the FW.
The cart is a table with 3 columns: Product / Quantity / Price
Product and Price words are editable while Quantity is not.
This PR fixes that.
Fixes https://github.com/odoo/odoo/issues/135163
X-original-commit: 03e4648b94b262508b7eceb969d91d7033e28834
Part-of: odoo/odoo#141810
Steps to reproduce:
- Add a date field in a model with `tracking=True`
- Log with a user with timezone set to UTC+2
- Create a record and set the date field to any date.
- Update the date value to another date
(Should have logged a message in the chatter with changes)
- Log with a user with timezone set to `America/Los Angeles`
- Check the chatter of the record created above
Issue:
New date value displayed in the chatter is wrong (set to one day
before).
Cause:
The value displayed in the chatter is the date value converted first
as datetime (with Luxon library), then the system timezone is set on
it and therefore might change the day.
Solution:
Use `deserializeDate` instead, who has the same computation as
`deserializeDatetime` (with the sole difference of date vs datetime)
and therefore will not apply a timezone on the date.
opw-3427502
closesodoo/odoo#142034
X-original-commit: ca3254f8c7700fe78053072710f0c57fee60af5b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Install DHL delivery and enable batch transfers
- Create 2 SO with adding shipping
- Select the 2 delivery orders and add them to the same batch
- Put the batch in a pack
- Only movelines of the first delivery are put in the pack
Bug:
when delivery is Installed a Delivery Package Type has to be chosen
this will in turn put the active picking mls in pack
the case of batch picking was disregarded
https://github.com/odoo/odoo/pull/55096/files#r469780148
Fix:
implementing a method to get the movelines to pack will allow to simply
make an override in stock_picking_batch instaed of creating a new module
this has also the added benefit of unifiying the behavior accross the
different methods
opw-3357423
closesodoo/odoo#141473
X-original-commit: 2d2bfe7f01379beb695b1c8756be393e17faf7de
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Following #133759 - The code will fail if the purchase_order has NO
date.
This is because
max(
po.date_order.date_order and po.date_order.date(),
fields.Date.today()
)
will try to compare False with a date, resulting in:
closesodoo/odoo#140006
Typeerror: '>' not supported between instances of 'datetime.date' and 'bool'
X-original-commit: 0831f6d0f2763e1ca8966c9a0b6c3186a847e733
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Before this commit, recurrences were being cut off after being fetched when their length exceeded the range of the current calendar view. This was because we were fetching the new events within the `get_events_delta` function, but skipping their fetch at the `_get_occurrence_details` function for occurrences outside the current calendar view range, leaving them not created when they should have been. Additionally, the last day within the weekly view was not being fetched because the API request ignored the "23:59" hour/minute information and fetched events up to the "00:00" hour/minute of the respective day.
After this commit, they are now entirely created during their search in the `_get_events_delta` function call. This solves the problem of leaving occurrences uncreated and maintains the improvement of not fetching all recurrences every time as in the previous code after the performance task. In addition, to correct the substitution of the hour/minute "00:00", a day is now being added to the end date to fix the interval obtained.
Benchmark test with 300 recurrences of 500 events each (150.000 events):
- Before the performance task: 01:02:09 (hour/min/sec)
- After this PR: 00:09:51 (hour/min/sec)
Issue from task-id: 3525764
closesodoo/odoo#142014
X-original-commit: 18b978e7a87e36b21449a7981720e4f24630b1c6
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
Payment acquirers don't have an `active` field, which makes users
confused when they try to delete an acquirer, and the error message
suggests archiving it instead.
opw-3579946
closesodoo/odoo#142000
X-original-commit: 69166117073f1bf255b62b81eaa744f81353f6b4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
- adapt test to ensure consistent (scroll) state at each step
The issue is hard to reproduce, so the complete resolution of the issue
is not guaranteed, but the current change should do the job, and if it
doesn't, it will help to pinpoint the issue.
Estimated issue: the thread doesn't load more messages when scrolling to
bottom because the scroll to bottom is overriden by the auto-scroll top
when clicking on pin. Adding extra wait point should solve the issue.
runbot-24512
closesodoo/odoo#141999
X-original-commit: 477b1c3aa1da7261273341338f3d37ee828715f8
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit add and test the support for string format with %d. this
is because python will fail if a string is passed to a %d, and
therefore we can consider it safe.
closesodoo/odoo#141993
X-original-commit: 37157cfa5df1201ffd51520969a3fb6b8a9dfdb1
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
When you open a Send and Print dialog, if the partner had no email,
then the form to edit the partne appears.
We're removing this behaviour and let the user decide if he wants
to check the partners or not
closesodoo/odoo#141549
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce the bug:
- Go to inventory > operation > batch Transfer > new:
- Select 2 picking out
- Confirm
- Try to validate
Problem:
A traceback is triggered:
ValueError: Expected singleton: stock.picking(7, 2)
“self.hide_picking_type = self.state != "draft" and self.ids and
'default_picking_type_id' in self.env.context “
opw-3583908
closesodoo/odoo#141975
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, the builder called `this._super` which is not
defined anymore by `patch` and thus caused an error.
The call to `this._super` was useless as it does not use the returned
steps so this commit simply removes the line.
Fixes#141112closesodoo/odoo#141968
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Since commit 550595d, it's no longer necessary to change the endpoint to
the IAP services test server.
closesodoo/odoo#141930
X-original-commit: 16a649231fcf98f2b3bae9e297ea892b9c93e3f9
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
For existing users who had previously disabled the "Lots & Serial
Numbers" settings, by applying this fix: https://github.com/odoo/odoo/pull/138907/commits/376ee1289eba840f1d8b2b6149d933bdedd47518
They will get the user error each time they try to access the settings.
Therefore, we prefer to prevent this and trigger the error only when
necessary.
opw-3452946
closesodoo/odoo#141921
X-original-commit: 608439b09cb68409dec10427d5b927ce0a27d526
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a tracked product with BoM “P1”:
- component: add any storable product e.g “C1”
- byproduct: add any storable product e.g “B1”
- Update the stock of C1
- Update the stock of “P1” with two SN
- use the 2 SN of P1 as component in any MO and mark the MO as done
- Create a new MO to produce 2 units of P1
- Confirm the MO
- Click on “Mass produce”
- Generate two new SN
* First error : The byproduct quantity is not set
- Try to Mark as done the new MO
Problem:
A user error is raised: 'This serial number for product P1 has already
been produced'
When splitting the MO into two, a “stock.move.line” are created with
a qty_done = 1, leading to an error when verifying if the serial_number
of the move_finished has already been produced.
When clicking the "mark as done" button on the MO, the function
"_check_sn_uniqueness" is triggered and since the finished product is
tracked and there is a serial number set in the MO, the function
"_is_finished_sn_already_produced" is called:
https://github.com/odoo/odoo/blob/c84d80cc71ca0e7120dd293bfc56f9027bfdf9fc/addons/mrp/models/mrp_production.py#L2158-L2162
Within this function, we verify if the move lines of the finished move
have a lot and qty_done set. If this condition is met and we do not need
to exclude this move, an error is triggered.
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2063https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2086
Solution:
Set "qty_done" to 1 only within the move lines of the components.
Opw-3566259
closesodoo/odoo#141521
X-original-commit: e0e6aed35d0f75c3ad01fbc329d7189f9e8d82f4
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Create a kit product
- Create a storable product without BoM “P1”
- Create a MO to produce one unit of “P1”
- Add the kit product as component
- confirm the MO
Problem:
The Manufacturing Order is cancelled. This is because the MO contains
a kit product, and we need to generate moves based on its Bill of
Materials. However, at the same time, we cancel and remove the move
associated with the original product, which is no longer relevant.
But We remove it before creating the moves generated from the phantom
product. Consequently, since we cancel the move, the 'compute_state'
of the MO is triggered, and as there is only one 'move_finished' status
in 'cancel,' the status of the MO is set to 'cancel:
https://github.com/odoo/odoo/blob/5c238bbb18c682ff2d25f740aad604feb7bb5bbc/addons/mrp/models/mrp_production.py#L462-L463
Opw-3548464
closesodoo/odoo#140016
X-original-commit: baa0924974fee0115a0bce117141a8096455b88d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
In some undeterministic circumstances the tests in
`test_wysiwyg_collaboration.js` tried to load an image with a wrong
url (`/web/image?model=res.users&field=avatar_128&id=undefined`). It
is `undefined` because in the testing context, `this.getSession().uid`
is `undefined`.
It is not necessary to load these images in these tests so this commit
prevents the loading of these images.
runbot-24600
task-3566600
closesodoo/odoo#139958
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Nicolas Bayet (nby) <nby@odoo.com>
Before this commit, the warning to inform the user that a product has
become unavailable was the same, whether the user was on the cart or on
the product page. This commit makes sure that the message is adapted to
the context.
closesodoo/odoo#139332
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When adding items to the cart, the server returns warnings that are
never displayed to the customer. This commit makes use of the new
notification system of website_sale to display it.
task-3502911
Part-of: odoo/odoo#139332
Steps to reproduce:
- Install Accounting
- Create a Company located in Italy (e.g. Company A)
- Create another company located in Italy (e.g. Company B)
- Switch to Company A and set its fiscal localization to Italy in Accounting settings
- Switch to Company B and set its fiscal localization to Italy in Accounting settings
- Try to install "Italy - E-invoicing (Withholding)" module (10n_it_edi_withholding")
=> An User Error is raised:
"Incompatible companies on records:
- 'account.tax.repartition.line,688' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company.
- 'account.tax.repartition.line,690' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company.
- 'account.tax.repartition.line,692' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company.
- 'account.tax.repartition.line,694' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company.
- 'account.tax.repartition.line,696' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company."
Cause:
When installing "10n_it_edi_withholding" module, some tax data are updated
for each Italian company.
These data are "generic" (not linked to any company) data, but some treatment
is performed on them for the first Italian company, linking them to the account
ids of that company.
The following companies are then updated with data linked to the first company.
opw-3538921
closesodoo/odoo#141898
X-original-commit: 9939789fd7024d864c365fe8f3ce311b96ba652c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
The demo data of point_of_sale module was failing to load when pos_iot
module was installed due to proxy_ip validation error. In fact, the iot
module overrides this field by creating a relationship to iot_ip.
When the demo data is created in the pos, the iot does not yet exist,
so proxy_ip is empty, so it trigger the validation error.
Error validation is triggered only when proxy_ip is empty and
printer_type is set to "iot". In the point_of_sale data demos, we set
printer_type to false, which fixes the problem.
closesodoo/odoo#140457
X-original-commit: 2f1af3a39b0d61dbf7c70e4fbc6421af906854d0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: David Monnom (moda) <moda@odoo.com>
On live youtube videos, url are in reality like this:
`https://www.youtube.com/live/<video_id>` which was not properly
caught by the regex in its compute
Reported during OXP
closesodoo/odoo#141910
X-original-commit: fd348c6778138240d67aa778866cd9e4d49c5021
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Each failing of the test "activity menu widget: activity menu with 2 models"
was close to midnight. And that was actually the cause of the error.
Actually, when executing that test very close to midnight, the test activities
are set up for a day and the check happens the day after (actually a few second
after). As we check in this test "overdue", "planned" and "today" activities,
the tested value are not inline anymore with the test setup when switching from
a day to the next (passing midnight). For example, "today" activities become
"overdue" activities. To avoid that we patch the date to be far from midnight.
Task-3592798
closesodoo/odoo#141762
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The support for IAP sandbox platform will soon be dropped, so all
references to it need to be removed.
This reference wasn't necessary in the first place since, in test mode,
the service doesn't require credits to run.
closesodoo/odoo#141939
X-original-commit: 66fcf2bc1360d42baa346d7447caa87ac511d127
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
The cog menu in the control panel (displayed next to breadcrumbs)
has a shortcut, so it is available in the command palette. However,
as is has no text content and no title/tooltip, the command palette
displays "No description provided". This commit adds a tooltip on
the icon, which is thus also displayed in the command palette.
closesodoo/odoo#141913
X-original-commit: 991e2e75d20bbb56b080c97e6b5ca96b746de3f3
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, the templates of the embed live chat were
not translated. This is due to the live chat embed app being
mounted without giving any `translateFn`.
This commit fixes this issue.
opw-3509309
closesodoo/odoo#141869
X-original-commit: 27aa2cb0ad1d279f72838000932d94e91cb436f3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When selecting a purchase order on a vendor bill,
the payment_reference is replaced even it was
manually filled.
Steps:
- Create and confirm a PO
- Create a vendor bill, set the bill ref and
the payment reference (different than bill ref)
- Select PO as purchase_vendor_bill_id
-> payment_reference is replaced by bill ref value
With this commit, we keep the payment_reference
as it is if not empty.
opw-3549673
closesodoo/odoo#141853
X-original-commit: 77a0449938dafdd234ecd5bf469ef3800336ba27
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This commit removes an undesired background on collapsible categories
when they are displayed in the left filter sidebar
task-3593419
closesodoo/odoo#141826
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Versions:
---------
- 15.0+
Steps to reproduce:
-------------------
1. install project & hr_timesheet;
2. create a follower-only project with timesheets enabled;
3. assign a task to a non-follower with user-level access rights;
4. log in as user;
5. go to timesheets app;
6. add a line.
Issue:
------
The assigned task doesn't show in the search results.
Cause:
------
The task's `allow_timesheets` field is set to be `related` to its
project's `allow_timesheets` field. This field is inaccessible for
private projects the user doesn't follow, so it doesn't show up when
searching tasks assigned to user where `allow_timesheets=True`.
Solution:
---------
Add compute and search methods to have `sudo` access without having to
make to field storable.
opw-3450671
closesodoo/odoo#141760
X-original-commit: 06e67687cf944ea14d38d3bf0272aece15d44faf
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, for some synced users, a weird behavior was happening when an event was created in Microsoft: the event info was being sent to Odoo with a different organizer than 'self.env.user' even though it was the same user creating the event.
After this commit, a condition checking if the event was created in Microsoft is added for skipping the checking since only events created in Odoo can have different organizers during their creation.
Issue from: 3450045
closesodoo/odoo#141481
X-original-commit: 176ca9789b0c2e032773f3ba2c72ab7e2ed24d91
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.
This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.
I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.
Benchmark
|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3 | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80 | 80 | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|
closesodoo/odoo#141301
X-original-commit: 9ed2b69cc06b1da481dfdc376dab50738a0471dd
Signed-off-by: Benjamin Hanquin (beha) <beha@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Rémy Voet (ryv)