When validating a confirmed picking, if in the meantime the user
added an SML with a kit, the done picking will have some not-done SM
for each kit component.
To reproduce the issue:
1. Inventory > Operation Types, edit Receipts:
- Show Detailed Operations: True
2. Create three products:
- P_kit
- P_compo
- P_other
3. Create a kit BoM
- Product: P_kit
- Components: P_compo
4. Create a planned receipt R
- Operations:
- 1 x P_other
5. Mark R as todo
6. Add two detailed operations:
- 1 x P_other
- 1 x P_kit
7. Validate R
Error: The SM for P_kit has been replaced with its component, which
is correct. However, the done quantity of the new SM is 0, it should
be 1
At some point, because the done quantity of SM_kit is gerater than
the demand, we create an extra move:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1529-L1534
So, the goal is to create a second SM_kit_02 with the expected
demand. Then, we merge this new SM_kit_02 with SM_kit:
https://github.com/odoo/odoo/blob/24f2e3f73498e5eb180a6793de6c25efd414aadb/addons/stock/models/stock_move.py#L1491-L1493https://github.com/odoo/odoo/blob/5f8da70b5b1f313e9b676846e55e84621f55e734/addons/mrp/models/stock_move.py#L239-L242
As shown above, we explode SM_kit_02 which gives SM_compo. However,
we don't explode SM_kit. Thefore, we will not be able to merge
SM_compo with SM_kit. In such situation, we should also explode
`merge_into`.
For the explode method to work with SM_kit, we need to change few
lines: as said at step 4, the receipt is not an immediate one.
However, we still have a case here where the SM has a quantity done
without any demand and only the done quantity matters (as we are
validating the receipt)
OPW-3015933
X-original-commit: 35a5b83b93fceac4073689edd74d680bed09a143
Part-of: odoo/odoo#112814
When manually setting a discount on the first line of a sale order having more than 3 displayed lines, the product_discount_field widget prompts the user if he would like to apply the same discount to all the lines.
This fails to apply when the localization uses a comma as decimal separator instead of a dot or uses a digit grouping symbol. This is because the widget calls the JS function Number() on the string that was entered by the user in the discount field, after it was formatted according to the localization.
Taking the number 1500 as an example, different cases are:
- Number("1500.0") gives 1500
- Number("1500,0") gives 'NaN'
- Number("1,500.0") gives 'NaN'
- Number("1.500,0") gives 'NaN'
This result is then used to apply the discount on the remaining lines of the sale orders. Using 'NaN' will result in a 0% discount.
The use of Number() can be avoided by using the property field 'value' of the product_discount_field widget.
opw-3127690
closesodoo/odoo#112734
Forward-port-of: odoo/odoo#112692
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
By adding an explicit order to the queries within `existing_accounting` the PostgreSQL query cost drops to `cost=0.84..1.78 rows=1 width=4` from `cost=13061.20..18895.19 rows=1 width=24` (on my local dev machine).
closesodoo/odoo#112842
X-original-commit: ab34d6b0273c6766757f0596ca5f62458a9d5ab5
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The date from would not be formatted on leaves spanning multiple days.
closesodoo/odoo#112830
X-original-commit: 7a392e9af999084d9dddf0f82affd6d539f5d907
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Werkzeug 1.0 colorised some outputs on POSIX IFF `click` was
installed.
Since 2.0 (pallets/werkzeug#2012) werkzeug unconditionally colorises
the log on POSIX. This is annoying when using output redirection (let
alone logging to a non-stream), as werkzeug will dump ANSI color codes
to the non-term stdout and thus the logfile.
Werkzeug provides no official knob to control this behaviour, but it
does have a secret flag which is normally used to check if colorama is
available on windows (so the ANSI codes are not output if colorama
won't be interpreting and stripping them on the way out). Since
`werkzeug.serving` is available in pretty much all versions, we can
just (un)set this flag if not logging to a tty, and versions 2+ should
pick it up and disable colorisation.
closesodoo/odoo#112829
X-original-commit: 7c9f883dc508a7a8a45bf7bf7e900da0be9b34be
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Since commit (1), the write/writeText were no longer correctly called,
because the browser native functions couldn't be called. Sometimes, it
raised the "Illegal invocation..." error, or could have an unexpected
behavior, preventing the value to be copied in the clipboard, which made
the button pointless.
No additional test was added, since it is difficult to test the clipboard
API programmatically, and the current test coverage is all that we can do,
without using the real clipboard object.
(1): 9cdcd1c1f7219030386d2c90205ea083eb835a13
closesodoo/odoo#112843
X-original-commit: 767922d43334a6cbccdb4be64f207813240fd314
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
repro steps:
1) in any kanban view that is not grouped, use the arrow key to focus the last card
2) use the up key to focus the previous card
3) use the TAB key to focus any element inside that card
4) use the down key to try to navigate to the last card -> traceback
The error comes from the fact that `focusNextCard` assumes that the
focus is exactly on the card element and not on any of its children.
closesodoo/odoo#112797
X-original-commit: 76434f4959cd0fade41ad02f790226f1a8046fea
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy CustomCheckbox and the backward
compatibility layer for the systray items. Both of them are no
longer used.
closesodoo/odoo#112718
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This commit fixes the wrong label that was displayed when options
are defined inside groups. Since displayValue was only looking for
a label on choices set using the choices props, the getter was only
returning the technical value for choices defined in groups.
A test has been modified to verify that the correct label is shown,
also on choices present inside of a group. This test previously
asserted that, but only on choices given by the choices props.
closesodoo/odoo#112766
X-original-commit: 176e61d5c25111a1e9339a0687bb526d1d430790
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112331
Related: odoo/upgrade#4320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The PR #105579 introduce the call of `setupCollaboration` in
`resetEditor` but did not remove the instructions in `resetEditor`
that will be called in `setupCollaboration`.
`this._getNewPtp` should be called by `setupCollaboration` as it is
called after an asynchronous call.
Additionally, `this._peerToPeerLoading` has to be awaited to prevent
concurrency issues.
closesodoo/odoo#112253
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With this commit, we add the shipping address
to the invoice report when it is different from
the invoicing address.
We do the same way as in l10n_din5008_sale/models/sale.py
and l10n_din5008_purchase/models/purchase.py,
by adding the computed field l10n_din5008_addresses
in account_move.
Steps:
- Insltall l10n_de and sale
- Set Customer addresses in settings
- Ensure that DIN5008 is set as document layout
- Create and confirm an invoice with delivery
address different than invoicing address
- Print or preview invoice
-> Shipping address does not appear on report
opw-3090418
closesodoo/odoo#112740
X-original-commit: 36731269ccd4ae8ca6d6078f7f9d6760381a5beb
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Bug
===
The unlink of the <mail.mail> in the CRON is problematic because we
accumulate a lot of records, and the CRON timeout.
In particular, when we sent a mailing, we receive the "opened" event
(blank image in the email), and so we need to update the mailing trace.
But, if we unlink the mail at the same time, it locked the mailing trace
table and we couldn't write the new value.
The reason for that is that before, the unlink took more queries, but
it was done one record at a time, so we could commit the change and
release the lock between each unlink.
Task-3179157
See odoo/odoo/pull/73271
closesodoo/odoo#112703
X-original-commit: 57ae1b9b8b61f5f4719a8a81e9d0d21fab58cfda
Related: odoo/enterprise#37069
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Steps to reproduce the bug:
- Get the website module.
- Go to Settings > Website > Shipping.
- Activate "On Site Payments & Picking" and save.
- Go to the same setting again and click on "Customize Pickup Sites".
- Pick the only delivery method that exists.
- Inside the delivery method, select a warehouse of the current company
and try to save.
Issue:
We won't be able to add a warehouse as the hidden field of the
`company_id` is not set.
Solution:
We modified the if statement inside `_check_warehouse_company` in order
to accept companies.
opw-3097424
closesodoo/odoo#112696
X-original-commit: dc8c24a5ace17382f54ad256b0ef585e24bca7ca
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The redirect function in the router exists only for the wait option.
This option is only used in one case (client action home). We have
therefore decided to remove the redirect function and to call
browser.location.assign(...) directly.
We will also remove the "wait" param for the "reload" and "home"
client actions. Because no call to "reload" needs it (1) and all calls to
"home" want it wait=True. So we will move the code that was executed
if wait=true to the "home" action client.
(1) In the POS, wait=true is used for a "reload" but this has no impact.
Wait=true was intended to wait for the server to restart before reloading
the page. In the case of the POS, there is no restart of the server, so
wait=True is useless.
closesodoo/odoo#112621
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the resize behaviour and the draggable behaviour were
completely separate, even though a lot of the logic for both behaviours
is common to both. This commit replaces both of these behaviours with a
hook: useMovable that lets the user drag an object around, but lets the
caller customize the behaviour on drag: when dragging a table or the
debug menu, we want to move the object around by setting its position in
its container, but when dragging a resize handle around, we want to
resize the table while keeping the handle position in the table the
same.
This commit also makes a bunch of popups non draggable as it doesn't
make sense for them to be draggable: you cannot interact with the
content behind the popup for as long as the popup is open (unlike the
debug menu), and serves no functional purpose, and may occasionally
confuse users.
closesodoo/odoo#112610
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Some changes were made to the default/demo/test data to be more
consistent:
- Duplicates of "Paid Time Off" time off types are consolidated into
one type (inluding year specific versions, ig "Paid Time Off 2019"
- Annual Time Off is renamed back to Paid Time Off (both for the
work entry type as the time off type) to be consistent everywhere.
- All mentions of years in work entry types and time off types have
been removed, as this is no longer relevant with the new allocation
rules.
- Time off types in the default data have been explicitely made
company agnostic, in order for them to be available to all companies
and not just the one company that was select when installing
hr_holidays. This was already the case for the be_payroll data, but
not for the standard hr_holidays ones.
- Various small cosmetic / functional fixes and simplifications
(eg deduplication of data)
- expense_other_input has been made country agnostic, in order for it
to be available in all countries.
task-2978513
closesodoo/odoo#112208
X-original-commit: dcc8bbf
Related: odoo/enterprise#36819
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.
After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.
Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.
task-2968292
closesodoo/odoo#112746
X-original-commit: c5a50362ef55ced373c53c7af069fd5534043ae2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
With this commit, when importing an account,
we post the opening move only when importing
opening balance field.
Steps to reproduce:
- import a coa template
-> an opening move has been created and posted
- import an account
-> Error: The entry MISC/XXXX/XX/XXXX (id XX) is already posted
Issue happened because we try to post the opening move
when entering in the account_account.load method.
With this commit wemodify and post the opening move only
if we try to import this field.
opw-3105083
closesodoo/odoo#112739
X-original-commit: 27ef0b93770c4e358a8cf4082afcfeb2da96f6c6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Current behaviour:
In the eCommerce, if you add a product that has a sale description
(properly translated) in a website that is set in another language
than the default for the company, the description of the product in
the shopping cart was the default for the company, not the one set
on the website.
Expected behaviour:
Product description language should follow the website's language,
in both the eCommerce, and in the shopping cart.
Steps to reproduce:
- Install eCommerce
- Add a second language of choice and add it to the website
- On a product add a sale's description in both languages
- Logout, go on the e-shop on your product, switch the website to
language 2
- Observe that the language of the description is indeed language 2
- Add it to cart, go in the cart.
- Observe that the language of the description is language 1, not 2.
Reason for the problem:
Since the cart is a `sales.order`, and each item in it is a
`sale.order.line`, we use the language of the partner for the
description. But by default the language of the public user is the
same as the company, not the one from the current context, which
would be the one from the website.
Fix:
We don't take the language of the partner, if that partner is the
`public user`.
Affected versions:
- saas-15.2
- 16.0
- saas-16.1
- master
opw-3142666
closesodoo/odoo#112738
X-original-commit: 2b0c52e08c35607c9ad75b491978231037a1340c
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
The employee should be subscribed to their own record in order to
receive communication send to them.
closesodoo/odoo#112736
Taskid: 2749585
X-original-commit: 43d99b06a792a39aa14b7afb8b48aa79c2da2737
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Very similar to the usecase in commit dafe732e6874fbdd15dfd213b5c5c0cde93e534e
Steps to reproduce:
- Install Accounting, Sales, Stock
- Create a product category PC:
- Costing method: FIFO
- Inventory Valuation: Automated
- Create a product P:
- Type: Storable
- Product Category: PC
- Create a Sales Order SO with 1 x P at cost 10
- Confirm delivery
- SO > Create Invoice > Post
- SO > Return the delivery
- Change product price from 10 to 6
- SO > Create Invoice (!!)
- The invoice will be marked as a credit note automatically
- Post the invoice
Issue:
The product is listed in the journal items, which is correct,
but its value is 6 while it should be 10.
If we create the invoice from the Sales Order instead of adding a
credit note, then the move lines will not be considered reversed,
since they do not have an associated invoice.
Solution:
Consider the move type when deciding if the move line is reversed or not.
opw-3077772
closesodoo/odoo#112673
X-original-commit: c1e8e4fbbe369615733298a1dfe18ead566eb310
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The user can use arrows up/down to change the value of an input in the
editor (inputs that handle numerical values). Unfortunately if this
input does not trigger a preview (data-no-preview="true"), the
modifications made by the user with arrow up/down are not saved. This
commit solves this problem by notifying that the value has changed at
the input blur (or on ENTER key press) if arrow up/down has been used.
Details:
Since we use text inputs in the editor, (even to manage numerical value)
the management of arrow up/down is done manually, so Javascript does not
consider the value of the input has changed and therefore does not
trigger the change event. Another solution would have been to say that
when we know that the input is going to manage a numeric value, we put
the type="number" on it but in this case, the change event is triggered
at each arrow up/down which breaks the fact that some inputs do not want
to have a preview.
Steps to reproduce the problem:
- Drop the Products block in a page
- Use arrow up/down to change the value of the Slider Speed input
- Save and Edit again
=> The change made with arrow up/down has not been saved.
task-2765868
closesodoo/odoo#112145
X-original-commit: 2e668f9c33e80ad9a78d5c0648d595a698936c81
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
The goal of this commit is to disable sample data mode when creating
a record using an on_create action in an empty kanban view.
How to reproduce:
- Go to an empty kanban view with an on_create and sample="1"
- Click on the create button
- Validate the creation
Before this commit:
The kanban view is still in sample data mode.
After this commit:
The kanban view deactivates the sample data mode.
closesodoo/odoo#112732
Taskid: 3176939
X-original-commit: b5909daaa16466321a0ad85aaf013155c0bcf5b2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The error:
> You need to add a line before posting.
was never raised anymore because a payment term line was always created
with a value of 0 if there were no invoice lines.
This commit checks that there are invoice lines before creating payment
term lines.
closesodoo/odoo#112745
X-original-commit: de328c2f7c6f06e3978ffcee462e2dcb2e12f564
Signed-off-by: William André (wan) <wan@odoo.com>
There is a check that prevent to set "internal" (meaning from the current company) partners on invoices/bills created via a journal alias.
When the "from" email is the email of the company, the check previously failed to recognize it as internal.
This could happen in this scenario :
If a customer/vendor sends a invoice/bill to the company email.
If then, someone forward this email to the journal alias. The "from" field is now the company email address.
closesodoo/odoo#112737
Task: 3145287
X-original-commit: b66f88870d78a22d0213aa70765f73f0de9e6252
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
We must force the access rights to the installation folder to "FullAccess"
because in some environments these rights have been restricted by customers.
And so the iot windows does not work properly
closesodoo/odoo#112735
X-original-commit: db3dff5150a638ed00d16109176853503326cd7f
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit if you would call phone_parse() but not pass along a
country code it would crash. This is reproducable by calling the phone_parse
function and not setting a country on the contact. In this case you would get
the following traceback:
AttributeError: 'bool' object has no attribute 'upper'.
This happens because the phonenumbers library tries to upper() the region but
if Odoo doesn't have a country set it passes along False. By doing a fallback
to 'None' the phonenumbers library will natively handle this and the user in
the UI does not get a traceback.
Task-2852953
closesodoo/odoo#112699
X-original-commit: 9b75d7ac1a912ff3d15c393a6a23018a18b3b9bb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Before this commit, opening a user profile in website does not show the
tabs like About, Questions, Answers, Activity, Votes.
After this commit, it will display all the tabs in user profile.
closesodoo/odoo#112695
X-original-commit: 44cd55b5df3a08ae24e86796c69ab361f4f53fe4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install stock, purchase
- Create a product with a long name without whitespace
- Create a purchase order with that product
- Go to portal and access the purchase order
Current behavior:
- Product description overflows when accessing the PO from the portal
Behavior after the PR:
- To fix the problem in the Portal we add table-responsive to the table
opw-3133407
closesodoo/odoo#112672
X-original-commit: 5abccc5efc6e333c8a889a1c24419dadc9c6e7f0
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a td has the `o_selected_td` class, it should be included in the
traversed/selected nodes, along with all its descendants. A syntax error
made it so that the descendants weren't in fact included.
closesodoo/odoo#112669
X-original-commit: 9f9279babbd98c343f51028fc719d7d9f1b2f887
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When selecting across table cells and changing block style, we applied
the block style to the traversed blocks which included the ones we want
to change but also their parent cell (`<td>`). This resulted in invalid
nested blocks like `<td><p><h1>...</h1></p></td>`.
task-3177014
X-original-commit: a6aff77af82066630f9d3b887beed288d2bdafaa
Part-of: odoo/odoo#112669
Steps to reproduce:
Add a record in the "Contacts & Addresses" tab of a contact.
Issue:
There are missing spaces in the information display.
Cause:
The kanban view compilation removes the spaces
(and line breaks) between the different tags.
Solution:
Add spaces on the template.
opw-3131806
closesodoo/odoo#112667
X-original-commit: 7bada7fc942cee0bcfd6447665640ee29a4b5752
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Before this commit, if the user mousedown a snippet, it would start a
timer of 1500 ms and a the end of the timer, it would show a tooltip to
help the user indicating him that he should drag & drop and not click.
The drag & drop code would (sort of) stop that timer if a drag was
detected, to not show the tooltip if the user is correctly drag &
dropping.
But it feels weird, as when you fail to realize you should drag & drop
but click instead, you only have the hint 1.5s later.
Some internal people would actually use triple click on snippet when
trying to show this tooltip, because it's probably not easy to figure
exactly what the trigger is.
The change is then made to show the tooltip directly on mouseup.
If the drag & drop code did not indicate that a drag happened, we can
safely assume it was a simple click and not a drag.
closesodoo/odoo#112666
X-original-commit: 00becd38ac5f43e2586b258d01c7af2825f75ddc
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, in the partner portal, all CRM stages were displayed for an
opportunity, even the non-relevant ones.
Now, only the stages that apply to this opportunity are displayed
Task-3133070
closesodoo/odoo#112665
X-original-commit: 9b385f034058d18608c9873a8a1e8fe44e220f1e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fixes the bug animation of the add to cart.
closesodoo/odoo#112663
Task: 2943578
X-original-commit: ef28650a94ac638676cb0ed5e14599416185faa8
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
The images of users in the livechat team were overlapping
with their ratings on the front-end page of the livechat channel.
Remove negative gutters to fix this.
task-3135733
closesodoo/odoo#112661
X-original-commit: 619a39e2f1fe50f5c76f2b54a578598e1540ef8d
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
Adrien Widart (awt)