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>
Steps to reproduce:
- Install ecommerce and the website_sale_delivery_mondialrelay module
- Publish the mondialrelay shipping method
- Go to the website shop
- Start a cart with an object that can be delivered (e.g. a table)
- Process to checkout
- Select mondial relay shipping method and a relay depot
- Don't click on Pay Now but go back to your cart and make it empty
- Add a non deliverable item to the cart (e.g. a warranty)
- Process to checkout and try to pay
Current behavior:
There is an error message related to mondial relay
Expected behavior:
There is no error message
Explanation:
The sale order keeps the partner_shipping_id even if it does not
contain any delivarable item. The mondial relay error message can
be sent for any order without checking that the order is supposed
is supposed to be delivered. To solve the issue we just add a
condition so that only orders with delivery can receive this message.
opw-2869883
closesodoo/odoo#93132
X-original-commit: 4cba0200f8915079e96284f215cbb97831e2d7d5
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Use of `addOrderline` presses the numpad, after clicking the product,
even if the quantity of the product being added is only 1. Because of
this, there might be a rogue press which calls `_updateSelectedOrderline`
at the wrong timing. This can be proven by looking at the screenshot where
the quantity of `Small Shelf` is 11, not 1. In this particular failing tour,
the sequence of steps properly aligned resulting to this runbot issue. To
make sure runbot isn't failing randomly, we replace `addOrderline` with
manual `click product` and `orderline check`.
Runbot: 3883, 3884, 3886
X-original-commit: 40aef1c4161f21801c1bbae823d9b5c46a035478
Part-of: odoo/odoo#93124
When using multiwarehouse, you can have moves that will be valuated on location A
and then moved to location B. In that case, the forecasted report of Location B
will have discrepancy because the move from A to B will not be valuated (internal move)
and the initial valuated stock valuation layer will still be linked to location A.
I change the way we retrieve the quantity using stock quants linked instead of
the svl.quantity linked to the selected location.
opw-2715253
closesodoo/odoo#93032
X-original-commit: a8a130e5b10aab3cb9eeedbf627b9a195cf7a253
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Reason: this fix is a patch for previous PR: https://github.com/odoo/odoo/pull/91009
As it should only depends on amount_delivery instead of fixed_price
Fix: clean the redundant condition and modify the delivery price
rendering in the else part
closesodoo/odoo#92965
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Crrently, 'parent task' stat button is visible even if the
'sub-tasks' feature is disabled.
So in this commit fixes the issue by adding the subtask group
on button.
task-2834743
closesodoo/odoo#93115
X-original-commit: cd7db331ae36ef2ecbb1b6795522cf469608c855
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
An error is thrown when trying to close a POS session in the Pakistan
localization
Steps to reproduce:
1. Install POS and Pakistan localization
2. Switch to PK Company
3. Go to Point of Sale > Configuration > Payment Methods and create a
new payment method with journal 'Cash'
4. Go to Configuration > Point of Sale and create a new point of sale
with sales journal 'Customer Invoices'
5. Open a POS session in the new POS and sell any item
6. Try to close the session, an error occurs telling you to close the
session in the back-end
7. Try to close the session, an error occurs and the message is
displayed
Solution:
Add a default POS account in the Pakistan module
Problem:
The function `_get_receivable_account` didn't find any account so it was
not possible to create the account move lines related to the POS session
opw-2857669
closesodoo/odoo#93113
X-original-commit: 77e62b56ce57edf621e4c7ed42d6b53a98fc044f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, both the theme install* and upgrade flow would end
up calling the theme's `_post_copy()`.
The `_post_copy()` is in charge of enabling or disabling some website
options as ripple effect, language in footer, changing header template
etc.
From there, the user could later fine-tune its website and change those
options, altering what the theme chose during the install.
We don't want a later theme update to reapply the theme pre-selected
options and erase/revert the changes the user made after the theme
install.
This commit is then removing the call to `_post_copy()` on theme update.
Note that the `_post_copy()` is encapsulating the theme python code
which is supposed to only do some visual stuff like enabling a view or a
theme option.
Also, note that calling `_post_copy()` in a theme update will not only
re-enable/disable some views but that will create a de-sync between the
activated view and the scss value.
Indeed, for instance, enabling the hamburger menu view is not enough, it
should also be coming with a scss value change.
The mismatch between the template and the scss will lead to some visual
glitches / ugly result.
Calling `_post_copy()` when applying the theme for the first time
through the UI (the only way possible) will not create that de-sync
issue as that flow is resetting the scss value:
`_reset_default_config()` will be called through `_theme_remove()`.
* `theme install` does not refer to the module install
but the moment the theme is applied on a website, which is not the
same as themes modules behaves in their own manner. When a theme is
installed on the DB, it does nothing except creating fake records in
"standalone" tables, which will then be converted to real records and
applied on the selected website.
opw-2824045
closesodoo/odoo#93109
X-original-commit: 14387f36438b731753e2e7169f54865b123cdcfa
Related: odoo/design-themes#571
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
As we have more and more standalone tests related to the website app, it
has been decided with the runbot team to introduce a unique tag to
easily identify those tests.
The goal is to make the runbot build config easier to manage, without
the need to add the new tag name in the command.
Instead, this build will be fired by finding and testing all the
`website_standalone` tests.
The other tags are kept to easily identify what are the test related to.
Command without this (which need to be edited for each new tag):
```
--standalone cow_views,cow_views_inherit,theme_views,theme_upgrade
```
Now:
```
--standalone website_standalone
```
X-original-commit: a28c181b7f934bed06adccd2678d6c6db47422fe
Part-of: odoo/odoo#93109
Before this commit:
After the user checked the checkbox in the mail thread, a dialog create res.partner will be shown, the content of this dialog is not translated.
After this commit:
The content of dialog will be translated
closesodoo/odoo#93104
X-original-commit: 759275b913b599bedb2380ec3200671488bfc298
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Observed Behaviour
When assigning someone to a task (in project), the employee
will receive a link be email. If he opens this link in a
browser where he isn't already logged, he will be redirected
to the logging page and, after have successfully logged in,
he will be redirected to the Odoo mail module
Expected Behaviour
After a successful loggin, the user should be redirected to
the task view
Reproducibility
This issue can be reproduced with the following steps:
1. Connect as Mitchell Admin
2. Go to the project module
3. Create a new task and assign it to Marc Demo
4. Go to Mark Demo's email and open the related mail
5. Open the link in the mail in an incognito window
6. Log in as Marc Demo
Fix Description
The issue is coming from the fact that, when no user is
logged in and if the url isn't public, we redirect the
url to the connection page without ensuring we have the
correct redirection after the loggin. This is fixed by
editing the url to web/login?redirect= + target url
Related Issues/PR
opw-2802439
closesodoo/odoo#93091
X-original-commit: 0b9d49f33713fc2d5a76f25523f2d4bb5ddb3b44
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
1. Delete the mail.template "Event: Registration Badge".
2. Go to any event.registration record.
3. Click on Send by Mail button.
closesodoo/odoo#93090
X-original-commit: 373a838d2df05b8be9a89a933b291492ba6052f0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Improvements to the chatter in Knowledge after the first merge.
Fix the issue where the chatter would not render properly if a tracked file was
modified (this sends a message in the chatter and it was not properly
reloaded).
Prevent the full reload of the view in cases where only the chatter needs to be
reloaded. In Knowledge, if the param `keepChanges` is set to `true`, only the
chatter will be updated.
Update the style of the chatter button to add more contrast when the chatter is
toggled on. Added a minimal size for the width of the chatter in side mode so
that thread messages don't become too small.
Add `_mail_post_access = 'read'` to the model in order to allow
someone with read access to post chatter messages. This is useful when a private
article is shared with read only access rights.
Add an explicit message along with a tracked field change in case the change is
caused by a user which does not have 'write' access on the modified article.
Task-2858428
closesodoo/odoo#93088
Forward-port-of: odoo/odoo#91969
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Consider the following case:
- Article A
- Article B
- Article C
- User X has write access on B, but read access on C.
-> User X moves B so that it is now a sibling of A.
-> Since C is a child of B, it also underwent a change, which is caused by X.
To clarify this situation and the fact that X does not have write access on C, the
automatic field tracking message is made more explicit in this case (Changes of
C are a side effect of the changes of B).
Task-2858428
X-original-commit: e6af7c8c6a2eb37038742ce93018a8eb8cfbf6d6
Part-of: odoo/odoo#93088
If a private article is shared with someone which is granted 'read' access, that
someone could not post messages in the chatter.
This commit adds _mail_post_access = 'read' to the model in order to allow
someone with read access to post chatter messages.
Before this change, mail_post_autofollow was always activated with "send
message" in the chatter, and it could cause errors in the following case:
- A user has read access on a record whose model has _mail_post_access = 'read'
enabled. This means that he can post messages even if he can not edit the
record.
- If the user sends a message while mentioning someone, if mail_post_autofollow
is enabled, the server will try to subscribe the recipient to the thread even
though the sender only has read access to the record, which results in an
error.
After this change, the chatter will enable mail_post_autofollow only if the user
has write access on the thread.
Task-2858428
X-original-commit: 0c628d63b2d1b64c88c0e72513fad417070569d9
Part-of: odoo/odoo#93088
Sébastien Theys