The purpose of this change is to be able to get the price of the
products from external APIs.
closesodoo/odoo#142402
X-original-commit: 420406d392dd3764f08ac698b67440a86abb2ca5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Enable multi steps route for manufacturing (in Inventory settings)
- Crete and confirm an MO with a kit and a non kit manufactured components
(eg: table kit and desk combination)
- Validate the created transfer
- Print the delivery slip
Bug:
the manufactured product is absent from the delivery slip
Fix:
apply the correct filter on the move lines
opw-3502881
closesodoo/odoo#142380
X-original-commit: 8c57a4f039549f4bb02a6794eda90de66c74ad28
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This commit contains a few small improvements to the Expense app.
- "View Report" button moved to the left if an attachment has been uploaded.
- Reports are auto saved when created from an expense.
- "Attach Receipt" button now sets the uploaded attachment as the main attachment.
- Expense lines in a report are no longer editable. When a line is clicked, the main attachment for that expense (if any) is shown in the attachment previewer.
task-3539382
closesodoo/odoo#138387
Related: odoo/enterprise#50136
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
5921343c2a removed values that didn't
include taxes but section subtotals were forgotten.
task-3562904
closesodoo/odoo#142303
X-original-commit: 3198c74409fa9778d493a0802dc57f7f7062c800
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Joren Van Onder (jov) <jov@odoo.com>
Steps to reproduce:
- In edit mode, drop the "Masonry" snippet.
=> There are spaces on the left and the right of the snippet. It should
not be the case as it is supposed to take the whole space, since its
container width is full (`container-fluid` class).
This happens because since commit [1], the rule setting the `--gutter-x`
CSS variable (which manages the row margins) to 30px when the container
is full width is now overridden by the general `.o_grid_mode` rule that
sets it to 0px, making the negative margins disappear.
Indeed, in commit [1], in order to disable the grid mode when used in a
mega menu that is in an extra menu (because the layout was broken), the
CSS selector managing the `.o_grid_mode` class has been modified. This
change caused the specificity of the rule to increase (x3), which made
it override the container rule.
This commit reverts this change and disables the grid mode in the extra
menu in a better way, by adding a proper rule for this specific case.
[1]: https://github.com/odoo/odoo/commit/709bffcb6de8883b679c0fc942f45cb293621c30
task-3593697
closesodoo/odoo#142189
X-original-commit: 8381af7d9898d7502c82a6b5622b0e91734267d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In commit [1], the media dialog has been improved in order to have a
better UX when using it. However, its code is quite complex and could be
simplified.
This commit modifies again the UX of the media dialog to only consider
the addition of the "scroll button" and leaves the "Load more" button
after the attachments without making it fixed. The scroll button still
disappears once the load more button appears in the modal.
This commit also addresses the remaining review comments that were not
resolved, as it was merged in a rush.
[1]: https://github.com/odoo/odoo/commit/d1c7e371491b06176c2f5a432dccdc87b7002296
task-3580707
closesodoo/odoo#141356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since 81fe11fabb, the field
`expense_sheet_id` was converted from a One2many to a Many2one,
making it a stored field.
Since then opening the form view of an expense report can be quite
slow (around +-1.6s) in a database with a lot of `account.move`, as
the whole table needs to be scanned to match the `id` of the
`expense_sheet_id`.
We add a partial not null index on the field (since not a lot of
`account.move` are linked to an expense) and it speeds up the read
to 60ms.
Reference:
task-3572440
closesodoo/odoo#142260
X-original-commit: edefee03110c63b152148b7599aed250dc9978df
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Current behavior:
When you sell a kit made of kit, the COGS are not registered correctly
in the invoice.
Steps to reproduce:
- Create Kit A with product A
- Create Kit B with product B
- Create Kit Final with kit A and kit B
- Make sure the Category of the products is in FIFO automated
- Open PoS, and sell Kit Final and invoice it.
- Go in the backend, and check the invoice lines of the order.
- The COGS of the products are not registered correctly.
Note:
This was happening because the price unit of the kit was not calculated
correctly. Because when the product was a kit made of kit, the bom was
not exploded to consider all the components of the kit.
opw-3548604
closesodoo/odoo#142246
X-original-commit: b8b3945ee0e4a82e18f85d8bbeb1a32654088308
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Description:
Portal routes `/my/tickets` or `/my/tasks` were reported slow to
load with many items.
Analysis:
The avatars that are loaded are of too large sizes (encoded in base64)
compared to their rendering size. `img.o_avatar` limits the
dimensions to `1.7145em` (roughly `27px` on desktop), so it's
useless to load `avatar_1024` for those image sources. This has a
significant impact when the user has a slow connection, the server
is hosted far away from the user, or the images used are of badly
compressed (so each images takes a quite a few MiB).
Fix:
Scan for all instances of the usage of `avatar_1024` on an `<img>`
with the class `o_avatar` and reduce it to `avatar_128`.
Reference:
opw-3470171
closesodoo/odoo#142103
Related: odoo/enterprise#50678
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In a recent fix (de77cef), the Kenyan EDI was adapted to exclude VAT
numbers for non-Kenyan partners. The field was also adapted to be
stripped before being serialised (due to a particular bug originating
from a space in front of the VAT).
Stripping this field results in a traceback when the field is empty,
since the type is not adapted from a bool to an empty string first.
This commit corrects this by using an empty string if the partner vat is
False. It also adapts the check to specifically use the country of the
commercial partner id instead of that of the partner.
task-id:None
closesodoo/odoo#142262
X-original-commit: b720833f5e52e14e379efcd51cfc559c57100a77
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Currently there is 2 behaviors:
- The records is pass to the _gather function, it will order base
on location complete name
- The records is not pass to _gather, it will be order by id.
Obviously we never want to order by id because it's not configurable
and hard to undersand since id are not editable
closesodoo/odoo#142237
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This traceback arises when the user removes 'Start Date' and change 'End Date',
while printing 'Sale Details'.
To reproduce this issue:
1) Install 'point_of_sale'
2) Open 'reporting/Sale Deatils'
3) Remove 'Start Date' and change the date of 'End Date'
Error:-
TypeError:'<' not supported between instances of 'datetime.datetime' and 'bool'
On the '_onchange_end_date' method, when the user removes 'start_date'
the value will be False. It leads to the above traceback
as '<' is used between 'start_date' and 'end_date'.
See:-
https://github.com/odoo/odoo/blob/5e3c4dd330184353a585b343741505cc223b1183/addons/point_of_sale/wizard/pos_details.py#L40-L43
By applying this commit will resolve the issue.
sentry-4521731693
closesodoo/odoo#142270
X-original-commit: ad5a7263461e734e294685fb1406bec97311c4d6
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>
For Confirmed MOs, the date that should be used is the `date_start`, not the `date_deadline`:
- Confirmed MOs have StockMoves with `move.date == mo.date_start`
- When computing the qty_to_order, the move.date will be used
- When finding existing MO to add quantity
If `mo.date_deadline != mo.date_start`
Then we can end up in a situation where a Confirm MO is too late to take its quantity into account, but not too late to add the qty_to_order to it.
Then everytime you run the scheduler, this MO will be too late, so new quantity must be ordered, and the quantity will be added on this MO which is too late.
## TO REPRODUCE ##
- Create product P_M
- Create BoM
- Create Reordering Rule:
trigger: auto | min: 10 | max: 20 | route: manufacture
- Create & Confirm SO for 10 unit of P_M
=> new confirmed MO for P_M should have been created
- Update MO scheduled date to 2 days in the future
- Run Scheduler
=> New quantity added, you can run the scheduler as many times as you want, new quantity will always be added
OPW-3524854
closesodoo/odoo#142256
X-original-commit: 531fa573a3bb40bd3b82c2a21db5e82d51a2800a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Steps to reproduce:
- Insert a list/pivot in a blank spreadsheet from a module (say Sales).
- Apply a global filter on it.
- Insert an odoo chart in the same sheet but from a different module (eg. CRM)
This works just fine when chart is inserted from the same model because it matches
the existing filter (from the pivot/list), and directly returns that field matching
without check the field matching from charts.
However in case of different model, the issue is that when there are no charts in the
sheet, the existing code of `getOdooChartIds` retrieves the incorrect chart ids
(`getChartIds` getter returns all chart ids, including the id of chart being inserted).
This leads to a traceback as the code tries to fetch fieldMatchings for a non-existent
chart within the sheet.
This commit resolves the issue by modifying the `getOdooChartIds` method to now utilize
`this.charts` instead of `getChartIds` getter, which correctly provides the ids of
charts already present in the sheet.
Task ID: 3573402
closesodoo/odoo#140700
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, when iterating over microsoft's recurrences occurrences, the'stop' attribute was being accessed instead of the 'end' attribute.
After this commit, this typo is fixed by changing the access from 'stop' attribute to the 'end' attribute.
Issue from: 3525764
closesodoo/odoo#142199
X-original-commit: 48f4cfc50d08f9333d6cb670b831beea8b7cdfbf
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Gabriel de Paula Felix (gdpf) <gdpf@odoo.com>
`Orderline.getDisplayData()` relies on the presence of the component's `env`.
However, since 7dd76be303b6769767ef0736ba738fc0063a4a28, an `Orderline` instance
can be created without `env`, which results to a traceback when rendering the
order widget. This commit makes sure the `env` is present in the Orderline
instance created from pos_sale module.
Closes runbot error: 27820
closesodoo/odoo#142167
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Scenario:
- add doc_count field in project.project view
- create new project
Issue: error and can't create new project
> File "addons/project/models/project.py",
> line 190, in _compute_attached_docs_count
> psycopg2.errors.SyntaxError: syntax error at or near ")"
> LINE 6: AND res_id IN ()
Fix: only do the query if there is non-NewID IDs
opw-3584925
closesodoo/odoo#142074
X-original-commit: 4d9a5cedef9459f0e86f16631170f2dc965d0a3b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Follow-up of [1]
PR above made several improvements to Messaging Menu, especially
in mobile.
By mistake, it removes the spacing between "All"|"Chats"|"Channels"
and "New Message" in desktop.
This commit re-adds this spacing with `div.flex-grow-1`.
[1]: https://github.com/odoo/odoo/pull/140405closesodoo/odoo#142186
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Since the commit afdcf9a5d5cd0d25b2ba61167d3ae6726a97d554, the mobile main flow tour
fail sometimes. This is due to the fact that the tour try to edit the record
before the new record is displayed.
The solution is to wait for the new record to be displayed before trying to edit it.
closesodoo/odoo#142124
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Following the Bookkeeping Act Request we needed to add a tag on each account of
the standard CoA. In this PR, we created a tag for each account and updated the
coa accordingly.
closesodoo/odoo#141976
Task: 3593628
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
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>
Bruno Zanotti