Tuesday, February 18, 2020
32 changes · master
New functionality added to Odoo
This update adds automated checks for TaxCloud tax rate handling in sales and invoicing flows. It helps ensure existing tax rates are reused, new rates are created when needed, and tax updates happen correctly during order confirmation, invoice posting, and payment registration.
Original PR description
-In this commit, Test cases for
-Retrive tax rate from taxcloud.
-Taxrate returned by taxcloud which already
exist in DB then that is taken from db instead of creating
a new one.
-If no record for taxrate returned by taxcloud in DB then
new TAX will be created successfully.
-Taxrate returned by Taxcloud that is correctly assign on
invoice line.
-Full Payment Registration Flow.
-Invoice posting triggers a Tax Update.
-SO confirmation triggers a Tax Update.
Task-2121109Enhancements to existing features
Adds basic automated checks for the TaxCloud integration in accounting and sales workflows. This helps ensure tax calculations connected to TaxCloud continue working as expected and makes future changes safer.
Resolved issues and error corrections
This fixes a display issue that prevented users from selecting fields when setting conditional visibility on one-to-many fields in Studio. Users can now access the field selector as expected, making form customization smoother and less frustrating.
Original PR description
previously when we click on the conditional visibility of one2many field, we were unable to access the field selector due to overlay issue in this commit we have changed the z-index value to fix the above issue. Task 2187354
Miscellaneous changes
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45531
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45531
Use date_stop instead, and remove the instruction to remove the computed field. Forward-Port-Of: odoo/odoo#45664
Original PR description
Use date_stop instead, and remove the instruction to remove the computed field. Forward-Port-Of: odoo/odoo#45664
- When browsing the blogs, in some cases the code need to fix the URL to properly slugify the tags. When so, the code crashes since it is trying to maniapulate a `werkzeug.wrappers.Response` as if it was a `dict`. To avoid this, we directly return the `werkzeug.wrappers.Response` instead of trying to modify it. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45649
Original PR description
- When browsing the blogs, in some cases the code need
to fix the URL to properly slugify the tags.
When so, the code crashes since it is trying to maniapulate
a `werkzeug.wrappers.Response` as if it was a `dict`.
To avoid this, we directly return the `werkzeug.wrappers.Response`
instead of trying to modify it.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#45649Commit c883ed108759dfff7f0373da535c557a09c0f30d let the possibility to add additional stock moves in a confirmed production. The issue is those move don't get the production group and their procure method is set (and never changed) to make_to_stock. This commit call adjust_procure_method before confirming additional moves. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA
Original PR description
Commit c883ed108759dfff7f0373da535c557a09c0f30d let the possibility to add additional stock moves in a confirmed production. The issue is those move don't get the production group and their procure method is set (and never changed) to make_to_stock. This commit call adjust_procure_method before confirming additional moves. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45475
Purpose ======= Fix kanban state default value and display in community. Fix question answers not correctly parsed from frontend. Fix sale availability ACLs issue when having tickets. Do not group the event tracks by location. See sub commits for more details. Task 2188857 PR #44545 Forward-Port-Of: odoo/odoo#44545
Original PR description
Purpose ======= Fix kanban state default value and display in community. Fix question answers not correctly parsed from frontend. Fix sale availability ACLs issue when having tickets. Do not group the event tracks by location. See sub commits for more details. Task 2188857 PR #44545 Forward-Port-Of: odoo/odoo#44545
Fix error introduced in https://github.com/odoo/odoo/pull/44813 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45279 Forward-Port-Of: odoo/odoo#44875
Original PR description
Fix error introduced in https://github.com/odoo/odoo/pull/44813 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45279 Forward-Port-Of: odoo/odoo#44875
Sitemap uses `generate()` results, which were using `_rec_name` as slugified URL. Routing map has endurl using slugified `display_name` which is checked against during `dispatch()`, that will redirect 301 to that url. For instance: - `/shop/product/acoustic-bloc-screens-23` is listed in sitemap while this URL is not the correct endpoint. Reaching this URL will 301 redirect you to `/shop/product/furn-6666-acoustic-bloc-screens-23`. - `http://localhost:8069/event/design-fair-
Original PR description
Sitemap uses `generate()` results, which were using `_rec_name` as slugified
URL.
Routing map has endurl using slugified `display_name` which is checked against
during `dispatch()`, that will redirect 301 to that url.
For instance:
- `/shop/product/acoustic-bloc-screens-23` is listed in sitemap while this
URL is not the correct endpoint. Reaching this URL will 301 redirect you to
`/shop/product/furn-6666-acoustic-bloc-screens-23`.
- `http://localhost:8069/event/design-fair-los-angeles-1` in sitemap which
redirect to `/event/design-fair-los-angeles-2020-02-14-2020-02-18-1`.
Sitemap should contains endurl, not 301 URL.
task-2119086
Forward-Port-Of: odoo/odoo#45295**One field defined twice** Impacted versions: - 12.0 Current behavior: - warehouse_count is defined twice Expected behavior: - warehourse_count is defined once Forward-Port-Of: odoo/odoo#45450
Original PR description
**One field defined twice** Impacted versions: - 12.0 Current behavior: - warehouse_count is defined twice Expected behavior: - warehourse_count is defined once Forward-Port-Of: odoo/odoo#45450
Issue: as salesman you want to send and print the invoice of your customer but you don't have the access to write on the invoice and thus you don't have access to create a mail.message and set the flag invoice_sent to True Allow to post message on an invoice when you have read access If you have the right to send the invoice, you should be able to modify the flag invoice_sent Allow to write on invoice_sent when you use the wizard to send the invoice to the customer -- I confi
Original PR description
Issue: as salesman you want to send and print the invoice of your customer but you don't have the access to write on the invoice and thus you don't have access to create a mail.message and set the flag invoice_sent to True Allow to post message on an invoice when you have read access If you have the right to send the invoice, you should be able to modify the flag invoice_sent Allow to write on invoice_sent when you use the wizard to send the invoice to the customer -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45544
The problem occurs when the pos session has currency that is different from the company's currency. Additionally, product that is tracked in accounting is also sold in this session. This situation results to anglo saxon move lines that are incorrectly converted. The current implementation considers the value from the stock valuation layer to be in the session's currency. However, that is not the real case because values in the valuation layer are always in the company currency. This
Original PR description
The problem occurs when the pos session has currency that is different from the company's currency. Additionally, product that is tracked in accounting is also sold in this session. This situation results to anglo saxon move lines that are incorrectly converted. The current implementation considers the value from the stock valuation layer to be in the session's currency. However, that is not the real case because values in the valuation layer are always in the company currency. This commit fixes the behavior of pos in generating anglo saxon lines in the pos session's accounting entry. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41392
- Create 2 applications with the following emails: 'test@test.com' 'test@test.com ' The 'Applications' stat button doesn't match the 2 applications. Since `_compute_application_count` uses a `read_group` for performance reason, we choose to strip the value at create and write for the sake of simplicity. opw-2189965 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed t
Original PR description
- Create 2 applications with the following emails: 'test@test.com' 'test@test.com ' The 'Applications' stat button doesn't match the 2 applications. Since `_compute_application_count` uses a `read_group` for performance reason, we choose to strip the value at create and write for the sake of simplicity. opw-2189965 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45582 Forward-Port-Of: odoo/odoo#45370
### Issue - Create new db with language en_CA - Install Sales & Purchase - Enable fr_CA - Create a product & Save - Edit the name & Save - Create a quotation or RFQ - Do not select partner - Select your product The description is still the old name ### Cause We try to browse a product with an empty partner language ### Solution Use odoo.tools.misc.get_lang() in order to fallback to a language is the partner's one is empty closes #44357 OPW-2196602
Original PR description
### Issue - Create new db with language en_CA - Install Sales & Purchase - Enable fr_CA - Create a product & Save - Edit the name & Save - Create a quotation or RFQ - Do not select partner - Select your product The description is still the old name ### Cause We try to browse a product with an empty partner language ### Solution Use odoo.tools.misc.get_lang() in order to fallback to a language is the partner's one is empty closes #44357 OPW-2196602 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45591
Let's say we have a chain of move wh1 - intercomp transit -> intercomp transit - wh2 The second move will be reserved according to what the first move brought since they are chained. This behavior resulted in rev[0] which tries to work around the ir.rule limiting the access of stock.move and stock.move.line records in multi-company environment. This patch wasn't perfect since, if the first move brought a lot, the second move will reserve this lot and it will result in another access
Original PR description
Let's say we have a chain of move wh1 - intercomp transit -> intercomp transit - wh2 The second move will be reserved according to what the first move brought since they are chained. This behavior…
Let's say we have a chain of move wh1 - intercomp transit -> intercomp transit - wh2 The second move will be reserved according to what the first move brought since they are chained. This behavior resulted in rev[0] which tries to work around the ir.rule limiting the access of stock.move and stock.move.line records in multi-company environment. This patch wasn't perfect since, if the first move brought a lot, the second move will reserve this lot and it will result in another access error since the lot will still have the company of the first move. We fix this by implementing the following logic: receiving from another company should behave the same as receiving from the supplier, no reservation is applied. We fix this by marking the inter company transit as `_should_bypass_reservation` and we break the move chain if the pull/push rule create an intercompany chain. [0] 6ff34073153767d449804669f31e26c04de0a670 Task: 2160847 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44947
Before this commit the sentence was a bit weird as a date is not on the future but in the future. This commit resolves this. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44982
Original PR description
Before this commit the sentence was a bit weird as a date is not on the future but in the future. This commit resolves this. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44982
- Install MRP and Purchase - Configure the rule 'Stock → YourCompany: Production (MTO)' with: Supply Method: Take From Stock, if unavailable, Trigger Another Rule - Create a product AB with route 'Manufacture' - Create products A & B with routes 'Buy' and 'Replenish on Order (MTO)', set a supplier - Create a BOM for AB with: Product A: 2.0 Units Product B: 3.0 Units - Create a MO for 1.0 Unit of AB, 'Mark as Todo' No RFQ is created for A & B while there is no stock available
Original PR description
- Install MRP and Purchase - Configure the rule 'Stock → YourCompany: Production (MTO)' with: Supply Method: Take From Stock, if unavailable, Trigger Another Rule - Create a product AB with route 'Manufacture' - Create products A & B with routes 'Buy' and 'Replenish on Order (MTO)', set a supplier - Create a BOM for AB with: Product A: 2.0 Units Product B: 3.0 Units - Create a MO for 1.0 Unit of AB, 'Mark as Todo' No RFQ is created for A & B while there is no stock available and a supplier is set. This is because the 'MTSO' logic is located in `_run_pull`, which is never called in this use case since no procurement is created. We need to apply the same logic in `_adjust_procure_method`, which is called at MO confirmation. opw-2189694 opw-2194739 Forward-Port-Of: odoo/odoo#45567 Forward-Port-Of: odoo/odoo#45412
Before this commit, when receiving a needaction message while messaging was not ready (i.e. `/mail/init_messaging` not resolved), the web client crashed with the following error message: ``` TypeError: Cannot read property 'incrementMailboxCounter' of undefined ``` This happens due to reception of needaction message incrementing counter of mailbox Inbox, but this mailbox is only added after messaging is ready. This commit fixes the issue by directly adding inbox mailbox on starting
Original PR description
Before this commit, when receiving a needaction message while messaging was not ready (i.e. `/mail/init_messaging` not resolved), the web client crashed with the following error message: ``` TypeError: Cannot read property 'incrementMailboxCounter' of undefined ``` This happens due to reception of needaction message incrementing counter of mailbox Inbox, but this mailbox is only added after messaging is ready. This commit fixes the issue by directly adding inbox mailbox on starting the mail service. Forward-Port-Of: odoo/odoo#45439 Forward-Port-Of: odoo/odoo#44413
Create an invoice, validate it, sending the data to the SDI. Now reset to draft the invoice and re-validate it. Action will be blocked because "You can't regenerate an E-Invoice when the first one is sent and there are no errors". This add the possibility to modify the invoice without re-sending it as long as the first one is still in a sent-with-no-answer state opw-2196956 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odo
Original PR description
Create an invoice, validate it, sending the data to the SDI. Now reset to draft the invoice and re-validate it. Action will be blocked because "You can't regenerate an E-Invoice when the first one is sent and there are no errors". This add the possibility to modify the invoice without re-sending it as long as the first one is still in a sent-with-no-answer state opw-2196956 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45514
Steps to reproduce: - install sales - go into debug mode - dev tools > start tour > sale_tour Previous behavior: tour would fail to see that the product has been selected and time out Current behavior: the tour finishes properly opw-2187218 Forward-Port-Of: odoo/odoo#44964
Original PR description
Steps to reproduce: - install sales - go into debug mode - dev tools > start tour > sale_tour Previous behavior: tour would fail to see that the product has been selected and time out Current behavior: the tour finishes properly opw-2187218 Forward-Port-Of: odoo/odoo#44964
Create a new mass mailing, add a video via youtube embed link, save. Send email. Embedding a video can't work because it embeds an iframe, which is not supported by most email clients for security reasons. Extending the noVideo flag also to mass_mailing opw-2179665 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44544
Original PR description
Create a new mass mailing, add a video via youtube embed link, save. Send email. Embedding a video can't work because it embeds an iframe, which is not supported by most email clients for security reasons. Extending the noVideo flag also to mass_mailing opw-2179665 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44544
Steps to reproduce: - install accounting - go to accounting > accounting > reconciliation (you need at least one unpaid invoice and one unreconciled payment for the proper screen to show) - manual operations > click the cog icon > create model - create a model with a long name and duplicate it 5-10 times - go back to the reconciliation tool > manual operations Previous behavior: the model buttons leak out of the right of the screen Current behavior: An horizontal scrollbar appea
Original PR description
Steps to reproduce: - install accounting - go to accounting > accounting > reconciliation (you need at least one unpaid invoice and one unreconciled payment for the proper screen to show) - manual operations > click the cog icon > create model - create a model with a long name and duplicate it 5-10 times - go back to the reconciliation tool > manual operations Previous behavior: the model buttons leak out of the right of the screen Current behavior: An horizontal scrollbar appears if necessary opw-2185355 Forward-Port-Of: odoo/odoo#45208 Forward-Port-Of: odoo/odoo#45195
During a forward port, a regression was introduced that broke the multi-company invoicing flow in Sales. Create a SO in company 1, use the web client with company 2 as the main one. The invoice should be in company 1. This commit fixes that by providing the journal_id in the invoice values (the company of the account move comes from the journal). While making this fix (and adding a test for it), I stumbled upon another multi-company issue when fetching the accounts of the product w
Original PR description
During a forward port, a regression was introduced that broke the multi-company invoicing flow in Sales. Create a SO in company 1, use the web client with company 2 as the main one. The invoice should be in company 1. This commit fixes that by providing the journal_id in the invoice values (the company of the account move comes from the journal). While making this fix (and adding a test for it), I stumbled upon another multi-company issue when fetching the accounts of the product where the property field was not accessed with the correct company. I fixed it as well. Forward-Port-Of: odoo/odoo#45459 Forward-Port-Of: odoo/odoo#42408
Description of the issue/feature this PR addresses: OAuth Current behavior before PR: Before this Commit, there will be Crash on `ResConfigSetting` if a record with XML id `'auth_oauth.provider_google'` is not present as it is trying to get/set values on that record. Desired behavior after PR is merged: Now, we check for the Record and get/set values if Record is present. Cc: @KangOl -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
Description of the issue/feature this PR addresses: OAuth Current behavior before PR: Before this Commit, there will be Crash on `ResConfigSetting` if a record with XML id `'auth_oauth.provider_google'` is not present as it is trying to get/set values on that record. Desired behavior after PR is merged: Now, we check for the Record and get/set values if Record is present. Cc: @KangOl -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#43967