When you are shipping later from POS and have a multi-step
configuration, you get an error saying that you cannot unreserve more
than what is reserved. It comes form a bad filtered list of move.
Now as we are correctly filtering the move on their product_id it
correctly works.
OPW-2854159
closesodoo/odoo#93336
X-original-commit: 93e0509d0ba7302ecdf5d0f6dbc2dbe90e98229d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Use case:
---------
Create a task with public user
At the end of the transaction sometimes the flush
is done with an env where su is False.
This cause the public user enable to read data needed
for the recomputation of is_closed field which is related_sudo=False
Why is this random ?
--------------------
The flush in transaction select the first env in the set of
env with a user. Since the order in the set is not deterministic
Sometimes an env with su=True is choosen and everything is fine
but sometimes it's not and we get an access error
It happened in 3 acts
this commit f98470e6cf add
related_sudo=False for perf improvement pre v13.0
this commit 42c430a539 introduce
a new related field is_closed that copy paste the related_sudo=False
this commit cf8bb933ac3a9fd6344ca79617a2f7317fbc20af stored the field
and stored computed field should always be compute_sudo=True
Solution
--------
Remove all the related_sudo=False, they don't make sense since v13.0
closesodoo/odoo#93349
X-original-commit: e0fe5c5a1c6932f02ca0822c5c26618c91fd50b3
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Activate units of measure
Create taxes:
- [TAXE] not included in price (i.e. 15%)
- [TAXI] included in price (i.e 15%)
Have a fiscal position mapping [TAXE] to [TAXI]
Have a product [PROD]:
- Price 10$
- Tax [TAXE]
- Unit: g
- Purchase Unit: kg
In point of sale settings:
- Add the fiscal position as default
- Display tax included prices
Start a pos session, add [PROD] to order, confirm and print receipt
The price on order screen and receipt will be wrong, it will take into
account the price excluded tax on top of the correct price
(final price 11.50, should be 10.30)
opw-2688375
closesodoo/odoo#93321
X-original-commit: ff61382c3865a159bb92f873bf82b8ab48426730
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit removes the layout menu, the layout is now automatically
adjusted based on the focused tile and uses a collapsable sidebar.
Layout variables are now located on the callView model instead of
messaging, which means that the presence of video tiles may depend on
multiple views with each their own layouts. It is therefore no longer
possible to rely on the previously global layout state to know if a
stream is viewed and should be downloaded.
closesodoo/odoo#82692
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When creating a custom datetime field (with date option type) with Studio and
that you edit the field manually then validates with the ENTER keyboard, the
date is changed (one day is removed - mm/dd-1/yy).
Since [1].
Step to reproduce the issue:
1. Put yourself in Europe timezone (e.g. BE)
2. Add a datetime field via studio (e.g. on the product form)
3. Put a date widget (no datetime)
4. Enter a date manually mm/dd/yy
5. Hit ENTER without clicking outside the box
You will see that the final date will be mm/dd-1/yy.
Solution: The path applied when clicking outside the box and cliking ENTER is
not the same. In the ENTER path, we check if the type of the field is a
`datetime`, if so, we remove the offset TZ to match 00:00:00 instead of
02:00:00 (if you were in GMT+2 zone). The issue is that we do this offset
if the customm field (via Studio) is a `datetime`. This check is incorrect: we
can have a `datetime` field but a date widget, in that case, if we are not on
GMT time we offset by some hours and we end up the day before (as we offset by
2 hours starting from midnight which results in 22PM the day before and when
rendered as a simple date we "loose" one day).
[1]: https://github.com/odoo/odoo/commit/08a423577f732b65ad5035e8f4662386a8631c5f
opw-2830843
closesodoo/odoo#93293
X-original-commit: 37a58832bc966f28fb2c1d627dfe28cef4fb5de7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Since the addition of the CallParticipantVideoView model, it makes more
sense to have this view(DOM) related function in it.
closesodoo/odoo#93260
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
===================
unit price calculation give error ZeroDivisionError: float division by zero for more details https://pad.odoo.com/p/r.c871c2581c415b13b0455a192ad0619d
After this commit:
==================
No error and set unit price,total amount before discount and discount amount if 100% discount or zero quantity is there
closesodoo/odoo#93027
X-original-commit: 60047761e592e9621650d65ac6ac1911f853141a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Translate the product name "Down payment"
when it is created "on the fly" from wizard.
X-original-commit: 17f460587a207d708f1b9d9a0c6d080e64f9eac8
Part-of: odoo/odoo#93249
In the case of a multi-step delivery, a warning would be thrown telling
goods have already been delivered when only one step (like packing) was
done, which is wrong.
In the case of a MTO MO flow, just validating the 'pick components'
picking for the MO would trigger this warning as well.
Task-2797359
closesodoo/odoo#93233
X-original-commit: 167e94cba756a3fa88ed9928be7a1be3f85464a6
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When creating a backorder for a manufacturing order, date_deadline for
its raw_moves are lost in the process, as the field is set to copy
False. But the split of a manufacturing order is not a usual copy paste.
In this specific case, we need to keep the date_deadline as well, or
resulting moves wouldn't be able to be merged with moves in
pre/post-production pickings from the original manufacturing order.
Task-2797359
X-original-commit: b50db19fa0da58dc0734c8cd494795743eaf0984
Part-of: odoo/odoo#93233
- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:
Product | Location | Lot/SN | Real Quantity
-------------------------------------------------------------
Product X | WH/Stock | LOT 01 | 20
Product X | WH/Stock | | 10
- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
* Source Location: WH/Stock
* Destination Location: WH/Stock/Shelf1
* Operation Type: Internal Transfers
* Operations:
[Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."
It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.
opw-2419444
Close#64497closesodoo/odoo#66029closesodoo/odoo#93141
X-original-commit: 83d55d8ed8b8b5a5232e3cdfc09abf5285f18ed7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
However, by further investigation, we saw that both need to
be current liabilities. (see discussion on issue/pr)
(92515, 91455, 84039)
closesodoo/odoo#93129
X-original-commit: d432ce9e5fd546cdf3759e5563c3a17d5381fefc
Signed-off-by: Josse Colpaert <jco@odoo.com>
Since https://github.com/odoo/odoo/pull/86682, when a user opens
the replenishment view, the Days to Purchase are not taken into
consideration when calculating the forecast of a product.
This was due to the fact that the Days to Purchase are now taken from the
orderpoint and not from the company settings. This is fixed by taking
the company setting if no value from the orderpoint is sent to the
method.
closesodoo/odoo#93252
Task-id: 2871408
X-original-commit: ac1df1949e4523aff65543f1381300fc7de3b4e4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: npi-odoo <npi@odoo.com>
Since 362f6b6d5b, the control panel of an
action can be rendered only the first time the dom is mounted. Any
further remount won't rerenders do anything. The bom report needs to add
some buttons and a searchView. Previously, those widgets was mounted in
the set_html _after_ the first mount of the controlPanel. This report is
an extend of the stock traceability which also adds some buttons. In
this case the buttons are rendered correctly because they are added
_before_ the first controlPanel mount.
This commit makes the extra widgets to be rendered in the control panel
generated in a new specific method overridable in the bom report file
closesodoo/odoo#93245
X-original-commit: 39306370a3a7c5767a29bba216ffe61ab8c69544
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Define the decimal accuracy for the "Product Price" to 5
- Create a product with "cost = 0.00875"
- On-hand product = 10'000
- Change the cost to "0.00975"
Issue:
In Inventory valuation, for the product you will have two layers valued at:
- 87.5
- 12.5
Instead of:
- 87.5
- 10
Cause:
We round with currency precision
Solution:
Use the "Product Price" decimal precision as it is the case when we define a "standard_price"
https://github.com/odoo/odoo/blob/4c7ef5673b8fc28bf7fe2bc36fe2450987f15a28/addons/product/models/product.py#L110-L112
opw-2724975
closesodoo/odoo#93257
X-original-commit: deb26bb1182682a5071287ae313064801d080607
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Since Chrome 94, some element's sizing computation returns a slightly
different value (in the order of a fraction of a pixel). Sadly, due to
rounding, this difference has an impact on exact sizing assertion.
In this case, assertion regarding the scrolling of an element inside its
scrollable container when it should be aligned to the bottom of the
container while being fully visible breaks due to those rounding change
(cf. the element is +/- 1px too low).
This commit fixes it by adjusting the `scrollTo()` implementation to
round the height of the element that should be visible in its scrollable
element to the upper pixel. This allows the element to remain fully
visible, with eventually a 1px margin in some cases (taken as an
reasonnable margin of error).
closesodoo/odoo#93235
Note: similar issue was also addressed in commit odoo/enterprise@6e973df114
X-original-commit: fdd03848e806b42ee0ee778bfd09d2f583b34f16
Related: odoo/enterprise#28215
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When generating an SO, the down payment section is translated into the language
of the current user instead of the language of the partner.
Step to reproduce the issue:
1) Install the Sales module
2) Install another language (e.g.: French) and change the language of a partner
to this language.
3) Create a quotation for the partner which you just changed its language (and
confirm it)
4) Create an invoice (down payment) of 50% for example (confirm the invoice)
5) Create another invoice to complete the payment (confirm it too)
6) Go the latest invoice and print it
You should see that the "Down Payments" section is kept in English instead of
the other language (e.g. French).
Solution: The issue is simply that the translation of the concerned term is
translated using the lang of the user instead of the lang of the partner. To
fix this, we must update the current context to change the lang to the partner
language (defaulting to the user language if the partner has no lang).
The side effect is that in the frontend, the user will see this section in the
language of the partner instead of his own (which may looks as a bug).
Unfortunately, it is an inherent functionnality of reports, we cannot do it
otherwise (we have the same issue with the label of the Down Payment).
opw-2865865
closesodoo/odoo#93210
X-original-commit: 2859f2709f92f8947c1f81f52a580ad3510316eb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Step to reproduce:
- Open 'Sales'
- Open a SO
- Click on the product link in the OrderLine tree
Current Behaviour:
- Breadcrumbs are cleared
Since https://github.com/odoo/odoo/commit/cefd6ade293e6cfa8ec405f55c6d4d7194f36e7e the onClick is only triggered in form view
Behaviour after PR:
- Breadcrumbs are not cleared
Link are now trigger via another click action '_onLinkClick' and quickEdit does not trigger on URL click
Test provided by Anh Thao (pta)
opw-2748041
closesodoo/odoo#85203
X-original-commit: 8ba45fde9f248e5a2b76ff3e934d9784d5d57ff0
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. Setting up a database with location in Germany and choose German as
the system language
2. Go to Settings->General Settings->Configure document layout, choose
DIN5008
3. The word “Invoice” is not translated
Fix: translate the title in python file, added term in pot
opw-2795031
closesodoo/odoo#93196
X-original-commit: 18c5bf4581d1e13ec169dc26f79499dac73eaed0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
This commit also add a wizard on the applicant kanban view to
search applicants in the reserve based on their skills, degree,
tags and availability and move them on the recruitment pipe.
closesodoo/odoo#93126
Taskid: 2877672
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Changes in rules of session storage for visitors (04e97266) prevented the list
of viewed slides to be updated for public viewers, ending in possibly unlimited
counts. Fixed by touching the sessions, with a small performance improvement
"en passant".
See Odoo#86015
Task-2878900
closesodoo/odoo#93181
X-original-commit: 5b375d6c5e1f4a29add3976af7fd71600c7b4cda
Signed-off-by: Julien Castiaux <juc@odoo.com>
Searching for the product field of account move lines is something expected to be used frequently.
closesodoo/odoo#86910
Signed-off-by: William André (wan) <wan@odoo.com>
The aim of this commit is to make `get_lines_in_hierarchy` yielding the lines
in the same order even if 2 sequences are the same.
The additionnal diff correct the iteration to get it in the same order in copy
than in `get_lines_in_hierarchy`.
closesodoo/odoo#93156
Task: None
Pr-community: https://github.com/odoo/odoo/pull/93061
X-original-commit: decc29d59baee1398a4497097055a2332e2305d7
Signed-off-by: William André (wan) <wan@odoo.com>
In 7dd5437a65 the usage of imagelib was changed to match the one of
general fetchmail so the flag sent to IMAP server was (\Seen) and not
\Seen which is often accepted but not always.
From recent reports, it seems that the method `uid` and `store` may have
some difference (base on using message-id rather than UID) so this
commit is reverting 7dd5437a65 and using the parenthesis around the flag
explicitely.
opw-2853609
closesodoo/odoo#93158
X-original-commit: 550f9e77625a7917bffd693f18aafe10a04276c9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Even though the release process changed a bit, it seems that only the
MINOR version number should be incremented in the master branch until
the next major release.
This avoid confusion when writing upgrade scripts, it should work in any
case and it leaves more room from process improvement.
closesodoo/odoo#93123
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/76415
This commit mistakenly duplicated 2 tests, with exact same name
and exact same content that is being asserted.
This commit removes one of the duplicate.
closesodoo/odoo#93137
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Have Tax A and Tax B both configured with tax exigibility based on
payment
Have a Tax G set as group of taxes with A and B as childs
Make an invoice with Tax G on a line
Register a payment
The CABA entry will be generated without base line
This occur because the system checks for the base line tax exigility,
but the exibigility of a group of taxes is fixed to 'on_invoice' so we
need to check the value on the childs
opw-2858656
closesodoo/odoo#93131
X-original-commit: 766802c345aaae0d9d01ec17685e9742f27526e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Alexandre Kühn