Friday, February 7, 2020
47 changes · master
Enhancements to existing features
This update makes it easier for website editors to manage online courses directly from the frontend, including editing course images and prices. It also improves forum navigation, adds a shortcut to enable surveys from the upload flow, and fixes hard-to-read tab and modal text colors.
Original PR description
\* = website_sale_slides, website_slides_forum - The image of a course is now editable when editor is active. - Added a button in the upload/"add content" modal to install the "website_slides_survey"…
\* = website_sale_slides, website_slides_forum - The image of a course is now editable when editor is active. - Added a button in the upload/"add content" modal to install the "website_slides_survey" module. The button is displayed only if the module is not install. - Fix the color of the active tab, the foreground color was almost white on a white background because $headings-color was set to null. The scss function "color-yiq" is used to get the most contrasted color of the given parameter. - When "website_sale_slides" module is installed, the price and the button to buy the course are now displayed if we are web editor and enrolled. We can now edit the price in the editor. - When on a question in the forum we can now click on the "Forum" tab to go back to the "home" of this specific forum. task-2026846 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
This update enhances the Romanian localization with more complete accounting setup data, including fiscal positions, tax groups, reconciliation models, tax tags, and additional tax handling. Romanian companies should get more accurate default accounting configuration and reporting compatibility when using Odoo.
Original PR description
Task : https://www.odoo.com/web#id=48668&view_type=form&model=project.task&action=333&active_id=131&menu_id=4720 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
The event registration confirmation page has been redesigned to make next steps clearer for attendees. Calendar links are made more visible, helping participants remember the event and reducing no-shows.
Original PR description
Closed in favor of #44843 ----- Improve confirmation page design. Reduce no-shows making "add to calendar" links more visible. TASK #2189545 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This change prevents an error that could appear when users clicked the Edit button in website slides. It helps keep the website editing experience stable so users can continue updating slide content without interruption.
Original PR description
- When we click on Edit button in website slides, we get a traceback: Uncaught TypeError: node.className.indexOf is not a function task-2026846 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
Miscellaneous changes
### Description of the issue/feature this PR addresses: Formerly the vendor bills, customer invoices and regular journal items were evaluated by the _check_unique_sequence_number method, but this was wrong and also was overwritten Odoo original constraint error message. Now the _check_unique_sequence_number evaluate the account.moves that are not vendor bills that se documents because this kind of bills uniqueness depend on the vendor: we can have same name of vendor bill from different pa
Original PR description
### Description of the issue/feature this PR addresses: Formerly the vendor bills, customer invoices and regular journal items were evaluated by the _check_unique_sequence_number method, but this was wrong and also was overwritten Odoo original constraint error message. Now the _check_unique_sequence_number evaluate the account.moves that are not vendor bills that se documents because this kind of bills uniqueness depend on the vendor: we can have same name of vendor bill from different partners. This is evaluate in the already existing _check_unique_vendor_number method -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44813
### Issue - Install Website - Go on your website - Add text block with image - Change ONLY the image's alt and/or the image's title text - Save dialog - Save page Not saved ### Cause The element doesn't become dirty after changes in alt dialog. ### Solution Trigger content_changed to make the element become dirty. **OPW-2189909** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44853
Original PR description
### Issue - Install Website - Go on your website - Add text block with image - Change ONLY the image's alt and/or the image's title text - Save dialog - Save page Not saved ### Cause The element doesn't become dirty after changes in alt dialog. ### Solution Trigger content_changed to make the element become dirty. **OPW-2189909** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44853
Description of the issue/feature this PR addresses: - Call method with expected singleton Recordset Current behavior before PR: - When the write method of account.move.line is called with a multiple Recordset if this line (https://github.com/odoo/odoo/blob/fb14e51278078e18e391400e85abe8162548e733/addons/account/models/account_move.py#L3322) is reached an 'Expected Singleton' error is thrown Desired behavior after PR is merged: - Non expected singleton error Cc @Tecnativa TT19675
Original PR description
Description of the issue/feature this PR addresses: - Call method with expected singleton Recordset Current behavior before PR: - When the write method of account.move.line is called with a multiple Recordset if this line (https://github.com/odoo/odoo/blob/fb14e51278078e18e391400e85abe8162548e733/addons/account/models/account_move.py#L3322) is reached an 'Expected Singleton' error is thrown Desired behavior after PR is merged: - Non expected singleton error Cc @Tecnativa TT19675 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44239
Make sure `is_website` is an existing field of the model at creation. opw-2192139 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#44841
Original PR description
Make sure `is_website` is an existing field of the model at creation. opw-2192139 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#44841
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44838
Original PR description
-- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44838
Explanation about flushing in action_switch_invoice_into_refund_credit_note: Because the 'type' is set before 'amount_total', 'amount_total' is recomputed with the wrong type and then make the condition badly evaluated. For some reason, the field wasn't badly recomputed before: 020e2a5 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44708
Original PR description
Explanation about flushing in action_switch_invoice_into_refund_credit_note: Because the 'type' is set before 'amount_total', 'amount_total' is recomputed with the wrong type and then make the condition badly evaluated. For some reason, the field wasn't badly recomputed before: 020e2a5 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44708
- install e-commerce; - In the website settings, orders followup, set a salesperson; - By something as a public user; - Pay the order. Before this commit: - 2 emails where create to assign the salesperson to the SO, but these emails didn't have a from and the salesperson didn't receive the emails. - 1 email was also create to assign the salesperson to the contact, this mail is not necessary. Now, only the emails that assign the salesperson to the SO are sent, with a co
Original PR description
- install e-commerce;
- In the website settings, orders followup, set a salesperson;
- By something as a public user;
- Pay the order.
Before this commit:
- 2 emails where create to assign the salesperson to the SO, but these
emails didn't have a from and the salesperson didn't receive the
emails.
- 1 email was also create to assign the salesperson to the contact, this
mail is not necessary.
Now, only the emails that assign the salesperson to the SO are sent,
with a correct from address.
opw-2189683
Forward-Port-Of: odoo/odoo#44826
Forward-Port-Of: odoo/odoo#44717Before this commit, no recompulation were performed at the end of the tracking procedure. When the tracking was used to create/update records, some values were not properly set. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44827
Original PR description
Before this commit, no recompulation were performed at the end of the tracking procedure. When the tracking was used to create/update records, some values were not properly set. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44827
Some technical explanations: The method became async because the `setTarget` call which was in there became `async` since it performed an UI update. As this method being async is a problem with some snippets, it is best to keep it synchronous for now. For this, the UI update in `setTarget` is removed and becomes the responsibility of the caller. Nothing relied on it except one code, which is solved by calling `onFocus` before the UI update which occurs on focus, as it is already the cas
Original PR description
Some technical explanations: The method became async because the `setTarget` call which was in there became `async` since it performed an UI update. As this method being async is a problem with some snippets, it is best to keep it synchronous for now. For this, the UI update in `setTarget` is removed and becomes the responsibility of the caller. Nothing relied on it except one code, which is solved by calling `onFocus` before the UI update which occurs on focus, as it is already the case in master. Forward-Port-Of: odoo/odoo#44801 Forward-Port-Of: odoo/odoo#44772
Normally, the number of column option adjusts the width of each column after changing their number so that they always fit in one row. In previous versions, the sequence of the code was correct thanks to jQuery's deferreds executing their then callbacks synchronously if the promise was already resolved. However, native Promise objects always put their then callbacks in the microtask queue, and this was resulting in the column width classes being recalculated before their number had actual
Original PR description
Normally, the number of column option adjusts the width of each column after changing their number so that they always fit in one row. In previous versions, the sequence of the code was correct thanks to jQuery's deferreds executing their then callbacks synchronously if the promise was already resolved. However, native Promise objects always put their then callbacks in the microtask queue, and this was resulting in the column width classes being recalculated before their number had actually changed. This commit fixes that by calculating the width of the columns based on how many columns there will be after addition/removal. It also introduces a new field on the option that is used to update the UI so that it displays the correct number. Forward-Port-Of: odoo/odoo#44791 Forward-Port-Of: odoo/odoo#43975
- Activate 'Round Globally' - Create a 21 % tax included in price - Create a product costing 21.5 - Add the product in a pos order, make the payment The `price_subtotal` is saved as `17.768595`, while it should be `17.77`. When these amounts are added in [1] (coming from [2]), it can lead to an inconsistency in the final computation, preventing the closing because of an unbalanced journal entry. Actually, the total and the subtotal must always be rounded following the currency pr
Original PR description
- Activate 'Round Globally' - Create a 21 % tax included in price - Create a product costing 21.5 - Add the product in a pos order, make the payment The `price_subtotal` is saved as `17.768595`,…
- Activate 'Round Globally' - Create a 21 % tax included in price - Create a product costing 21.5 - Add the product in a pos order, make the payment The `price_subtotal` is saved as `17.768595`, while it should be `17.77`. When these amounts are added in [1] (coming from [2]), it can lead to an inconsistency in the final computation, preventing the closing because of an unbalanced journal entry. Actually, the total and the subtotal must always be rounded following the currency precision, as done in [3] and [4]. It was probably not causing an issue before 13.0 since the creation of the journal entry from the POS was different. [1] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/point_of_sale/models/pos_session.py#L381 [2] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/point_of_sale/models/pos_session.py#L557 [3] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/account/models/account.py#L1654 [4] https://github.com/odoo/odoo/blob/b22935caa3df824bc56a0828da9bee921bca5a5b/addons/account/models/account.py#L1740 opw-2181486 Forward-Port-Of: odoo/odoo#44692
We only want journal entries with an actual sequence to be used as reference, otherwise we can't deduce the reset periodicity of the journal. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44721
Original PR description
We only want journal entries with an actual sequence to be used as reference, otherwise we can't deduce the reset periodicity of the journal. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44721
On product categories, the `total_route_ids` field is shown without label. This is confusing for end users since the same route seems to appear twice. opw-2173783 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#44720
Original PR description
On product categories, the `total_route_ids` field is shown without label. This is confusing for end users since the same route seems to appear twice. opw-2173783 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#44720
Before this commit, when printing in safari a receipt that contains products with long names, parts of the name were overlapped. This occurs because, in safari, the library that transforms the html into text mismanages the spaces. This is a well known problem, see : niklasvh/html2canvas#1654 Now, the name is printed correctly in safari, same behaviour than the others browsers. opw-2169656 Forward-Port-Of: odoo/odoo#44658
Original PR description
Before this commit, when printing in safari a receipt that contains products with long names, parts of the name were overlapped. This occurs because, in safari, the library that transforms the html into text mismanages the spaces. This is a well known problem, see : niklasvh/html2canvas#1654 Now, the name is printed correctly in safari, same behaviour than the others browsers. opw-2169656 Forward-Port-Of: odoo/odoo#44658
in anglo saxon accounting - receipt products through an rfq - when creating the vendor bill of the rfq, add a landed costs product - post the vendor bill then create the landed cost, validate the landed cost - the aml of the LC is not reconciled with the aml of the vendor bill for the lc product We fix this by setting the product_id of the lc product on the aml generated by the lc and calling reconcile with only aml of the same products. Forward-Port-Of: odoo/odoo#44729 Forward-P
Original PR description
in anglo saxon accounting - receipt products through an rfq - when creating the vendor bill of the rfq, add a landed costs product - post the vendor bill then create the landed cost, validate the landed cost - the aml of the LC is not reconciled with the aml of the vendor bill for the lc product We fix this by setting the product_id of the lc product on the aml generated by the lc and calling reconcile with only aml of the same products. Forward-Port-Of: odoo/odoo#44729 Forward-Port-Of: odoo/odoo#44367
- Create a default value for 'Source Location' or 'Scrap Location' - Create a Scrap Order the default value is not taken into account since it is overridden by `_onchange_company_id`. We avoid changing the location in case the company matches. opw-2189578 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-
Original PR description
- Create a default value for 'Source Location' or 'Scrap Location' - Create a Scrap Order the default value is not taken into account since it is overridden by `_onchange_company_id`. We avoid changing the location in case the company matches. opw-2189578 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#44753
- Create the following tax: Tax Computation: Percentage of Price Tax Included Amount: 100 % Included in price - Create an invoice, add a product with this tax - Save A ZeroDivision error is raised. opw-2186998 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#44724
Original PR description
- Create the following tax: Tax Computation: Percentage of Price Tax Included Amount: 100 % Included in price - Create an invoice, add a product with this tax - Save A ZeroDivision error is raised. opw-2186998 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#44724
1) Go to purchasing, and in the search area type "8888" 2) Click on the little arrow next to "Search Product for: 8888" 3) Select "[FURN_8888] Office Lamp" 4) Choose Purchase Order PO00009 which has FURN_8888 on the second line: 5) Choose Action > Duplicate The 1st line end up with the searched product, not the original product. This happens because the search add the context key 'default_product_id'. By chance the product.product model has a 'product_id' field which may happen to be n
Original PR description
1) Go to purchasing, and in the search area type "8888" 2) Click on the little arrow next to "Search Product for: 8888" 3) Select "[FURN_8888] Office Lamp" 4) Choose Purchase Order PO00009 which has FURN_8888 on the second line: 5) Choose Action > Duplicate The 1st line end up with the searched product, not the original product. This happens because the search add the context key 'default_product_id'. By chance the product.product model has a 'product_id' field which may happen to be not filled. This cause the model api to look for a default value in the context and the first line of the order get overridden. Removing the specific key from the env solve the issue opw-2188429 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44598
Forward-Port-Of: odoo/odoo#44668
Original PR description
Forward-Port-Of: odoo/odoo#44668
Before, the buttons to save, cancel or update and the icons weren't displayed correctly. Now, all elements are displayed correctly on mobile or on computer. task-2153990 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#42846
Original PR description
Before, the buttons to save, cancel or update and the icons weren't displayed correctly. Now, all elements are displayed correctly on mobile or on computer. task-2153990 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#42846
Highlight the 'Validate Inventory' button only if there is at least one inventory line. opw-2187225 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#44628
Original PR description
Highlight the 'Validate Inventory' button only if there is at least one inventory line. opw-2187225 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#44628
Have a company with Croatian address but no street2 set. Create and invoice, print it. On the report the street2 will appear blank (Empty line). Correcting the formatting of the address fix the issue opw-2182621 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44706
Original PR description
Have a company with Croatian address but no street2 set. Create and invoice, print it. On the report the street2 will appear blank (Empty line). Correcting the formatting of the address fix the issue opw-2182621 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44706
Nothing prevents to delete a bank statement linked to an open pos session, which leads to a KeyError when validating and posting entries at closure. Description of the issue/feature this PR addresses: opw-2185483 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#44229
Original PR description
Nothing prevents to delete a bank statement linked to an open pos session, which leads to a KeyError when validating and posting entries at closure. Description of the issue/feature this PR addresses: opw-2185483 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#44229
Steps to reproduce the bug: - Create a journal entry - Create a line L1 with an account A and a partner P - Create a second line L2 with an account A and a partner P - Create a third line by clicking on 'Add line' Bug: The account A and partner P was not suggested as in saas-12.3 opw:2188921,2152827 Forward-Port-Of: odoo/odoo#44656
Original PR description
Steps to reproduce the bug: - Create a journal entry - Create a line L1 with an account A and a partner P - Create a second line L2 with an account A and a partner P - Create a third line by clicking on 'Add line' Bug: The account A and partner P was not suggested as in saas-12.3 opw:2188921,2152827 Forward-Port-Of: odoo/odoo#44656
Since synchronization of tables was added in POS restaurant, requests are frequently made to the server to display the number of open orders on each table. The implementation of the counting caused O(num_tables) queries, and those queries were slow on large databases because there was no index for the `table_id` column. This patch fixes both problems, and the counting now uses 3 fast queries regardless of the number of tables. On a sample database with 2k tables and 50k POS orders, call
Original PR description
Since synchronization of tables was added in POS restaurant, requests are frequently made to the server to display the number of open orders on each table. The implementation of the counting caused O(num_tables) queries, and those queries were slow on large databases because there was no index for the `table_id` column. This patch fixes both problems, and the counting now uses 3 fast queries regardless of the number of tables. On a sample database with 2k tables and 50k POS orders, calls to `get_tables_order_count` went down from 1 s and 100+ SQL queries to 10 ms and 4 queries. About 2 orders of magnitude faster, with server load drastically reduced as well. Forward-Port-Of: odoo/odoo#44660
Steps to reproduce the bug: - Let's consider a partner P without property_payment_term_id - Create a SO for P, confirm it and create an invoice I - In debug mode, on the SO click on the smart button 'invoice' - On I, click on the 'Set Default' in the debug menu - Set a payment term PT as default value (ir.default) for all users - From this view, create a new invoice Bug: The default payment term PT was not set on the new invoice opw:2184367 Forward-Port-Of: odoo/odoo#44648
Original PR description
Steps to reproduce the bug: - Let's consider a partner P without property_payment_term_id - Create a SO for P, confirm it and create an invoice I - In debug mode, on the SO click on the smart button 'invoice' - On I, click on the 'Set Default' in the debug menu - Set a payment term PT as default value (ir.default) for all users - From this view, create a new invoice Bug: The default payment term PT was not set on the new invoice opw:2184367 Forward-Port-Of: odoo/odoo#44648
Steps to reproduce: - install sales - activate units of measures and variants - set imperial units under general settings (pounds for weight and ft³ for volume) - create at least 2 variants on a product and access them via the smart button from product.template Previous behavior: the volume remains in m³, it is hardcoded in the template Current behavior: the volume is printed just like the weight (generic uom notation) opw-2186965 Forward-Port-Of: odoo/odoo#44649
Original PR description
Steps to reproduce: - install sales - activate units of measures and variants - set imperial units under general settings (pounds for weight and ft³ for volume) - create at least 2 variants on a product and access them via the smart button from product.template Previous behavior: the volume remains in m³, it is hardcoded in the template Current behavior: the volume is printed just like the weight (generic uom notation) opw-2186965 Forward-Port-Of: odoo/odoo#44649
Don't ignore correction layers when computing the anglo saxon price unit. We use the `stock_valuation_layer_id` field on the layer to point the correction layer to the corrected layer. When computing the average price of the delivered things, ignore correction entry but take them into account when choosing a corrected entry. opw-2179900 Forward-Port-Of: odoo/odoo#44498
Original PR description
Don't ignore correction layers when computing the anglo saxon price unit. We use the `stock_valuation_layer_id` field on the layer to point the correction layer to the corrected layer. When computing the average price of the delivered things, ignore correction entry but take them into account when choosing a corrected entry. opw-2179900 Forward-Port-Of: odoo/odoo#44498
Before, we had abs() in the report, but we saw it was wrong: https://github.com/odoo/enterprise/commit/5e7d91d5ea5356fa3c38b6676b68403a713da5be#commitcomment-33050133 Somehow they remained in saas-12.3 and with this we remove them as well. Thanks to Martijn Kluijtmans opw-2186942 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.c
Original PR description
Before, we had abs() in the report, but we saw it was wrong: https://github.com/odoo/enterprise/commit/5e7d91d5ea5356fa3c38b6676b68403a713da5be#commitcomment-33050133 Somehow they remained in saas-12.3 and with this we remove them as well. Thanks to Martijn Kluijtmans opw-2186942 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#44657 Forward-Port-Of: odoo/odoo#44566
Description of the issue/feature this PR addresses: Task ID: https://www.odoo.com/web?#id=2061760&action=327&model=project.task&view_type=form&menu_id=4720 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#44597 Forward-Port-Of: odoo/odoo#36845
Original PR description
Description of the issue/feature this PR addresses: Task ID: https://www.odoo.com/web?#id=2061760&action=327&model=project.task&view_type=form&menu_id=4720 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#44597 Forward-Port-Of: odoo/odoo#36845
### Issue - Install Field Services - Go to All Tasks - Remove filters - Group by stage - Try to create a column - Refresh the page The column disappeared ### Cause The column is created, so the JS add it to the page but it has no project_id and the view context has no default project id so it can't retrieve it. ### Solution I didn't find a way to retrieve the columns since the only solution I found is to add a project id to the column (can't know which pro
Original PR description
### Issue - Install Field Services - Go to All Tasks - Remove filters - Group by stage - Try to create a column - Refresh the page The column disappeared ### Cause The column is created, so the JS add it to the page but it has no project_id and the view context has no default project id so it can't retrieve it. ### Solution I didn't find a way to retrieve the columns since the only solution I found is to add a project id to the column (can't know which project I am in) and a default project id to the view (I can have several projects, all tasks should show the tasks of all projects) **OPW-2187656** Forward-Port-Of: odoo/enterprise#8257
### Issue - Install Studio & Purchase - Create a new report - Insert Subtotal & total block Traceback ### Cause The currency is falsy. In the currency round method we do self.ensure_one but id = False so we have a traceback ### Solution Use the company currency instead of an empty currency in Subtotal & Total block **OPW-2183380** Forward-Port-Of: odoo/enterprise#8259
Original PR description
### Issue - Install Studio & Purchase - Create a new report - Insert Subtotal & total block Traceback ### Cause The currency is falsy. In the currency round method we do self.ensure_one but id = False so we have a traceback ### Solution Use the company currency instead of an empty currency in Subtotal & Total block **OPW-2183380** Forward-Port-Of: odoo/enterprise#8259
Currently, if 'helpdesk_account' is already installed, one won't be able to install 'l10n_latam_invoice_document' module or 'l10n_co_edi_ubl_2_1'. This is because 'move_ids' field is overridden to have 'suitable_move_ids' field in it's domain from python side for 'account.move.reversal' model in 'helpdesk_account' module. This makes it require to define 'suitable_move_ids' field for every view inherited from 'view_account_move_reversal'(where 'move_ids' field is defined). And since 'l
Original PR description
Currently, if 'helpdesk_account' is already installed, one won't be able to install 'l10n_latam_invoice_document' module or 'l10n_co_edi_ubl_2_1'. This is because 'move_ids' field is overridden to…
Currently, if 'helpdesk_account' is already installed, one won't be
able to install 'l10n_latam_invoice_document' module or 'l10n_co_edi_ubl_2_1'.
This is because 'move_ids' field is overridden to have 'suitable_move_ids'
field in it's domain from python side for 'account.move.reversal' model in
'helpdesk_account' module. This makes it require to define 'suitable_move_ids'
field for every view inherited from 'view_account_move_reversal'(where 'move_ids'
field is defined).
And since 'l10n_latam_invoice_document' or 'l10n_co_edi_ubl_2_1' is not dependent
on 'helpdesk_account', we can't just put 'suitable_move_ids' in views inherited
in such modules.
So, this domain better be applied on the XML view in 'helpdesk_account' module instead
of applying it on python side.
Task: 2181730
**Update:** Other alternative solution would be to inherit parent view, that is, `account.view_account_move_reversal` and put `suitable_move_ids` with `invisible="1"` in `helpdesk_account` module itself, like,
```
<record id="view_account_move_reversal" model="ir.ui.view">
<field name="name">account.move.reversal.inherit.helpdesk.account</field>
<field name="model">account.move.reversal</field>
<field name="inherit_id" ref="account.view_account_move_reversal"/>
<field name="arch" type="xml">
<xpath expr="//field[@name='move_type']" position="after">
<field name="suitable_move_ids" invisible="1"/>
</xpath>
</field>
</record>
```
Drawback with this solution would be, it would throw same error when someone defines new view for `account.move.reversal` model having `move_ids` field in it.
Forward-Port-Of: odoo/enterprise#8199Before this commit account_financial_report_be_profitandloss0 was having "Bilan" as source term, while in the latest version, it is "Compte de résultats" This avoid having two menus with the translation "Balans" Forward-Port-Of: odoo/enterprise#8206
Original PR description
Before this commit account_financial_report_be_profitandloss0 was having "Bilan" as source term, while in the latest version, it is "Compte de résultats" This avoid having two menus with the translation "Balans" Forward-Port-Of: odoo/enterprise#8206
In 3b1d94cbe5a all reference of a package would be tried to be cancelled, so the cancelling would would be with multiple reference we would have error on first cancel: REF2: No shipment found within the allowed void period REF3: No shipment found within the allowed void period then on second cancel: REF1: The Shipment has already been voided REF2: No shipment found within the allowed void period REF3: No shipment found within the allowed void period and because we send an error, it was not c
Original PR description
In 3b1d94cbe5a all reference of a package would be tried to be cancelled, so the cancelling would would be with multiple reference we would have error on first cancel: REF2: No shipment found within the allowed void period REF3: No shipment found within the allowed void period then on second cancel: REF1: The Shipment has already been voided REF2: No shipment found within the allowed void period REF3: No shipment found within the allowed void period and because we send an error, it was not clear that the first request worked. With this changeset, we go back to previous behavior and only cancel the first reference which is what UPS API is expecting. opw-2180729 Forward-Port-Of: odoo/enterprise#8205
- Create a product tracked by unique S/N, set a barcode - Create some stock - Create an inventory adjustment, set all quantities to zero - Open the barcode view - Scan the product barcode - Scan the lot An error prevents from registering the product: ''The scanned serial number is already used.' We should check the quantity to know if a line is used of not, as done in a40f51ed1f59bdd69f4a1c4b47679d26f70a618e opw-2189812 Forward-Port-Of: odoo/enterprise#8187
Original PR description
- Create a product tracked by unique S/N, set a barcode - Create some stock - Create an inventory adjustment, set all quantities to zero - Open the barcode view - Scan the product barcode - Scan the lot An error prevents from registering the product: ''The scanned serial number is already used.' We should check the quantity to know if a line is used of not, as done in a40f51ed1f59bdd69f4a1c4b47679d26f70a618e opw-2189812 Forward-Port-Of: odoo/enterprise#8187
Without the `payment_method_id` field of the linked account.payment record being set to the SDD payment method, it was impractical (or impossible, really) for users to export payments generated that way in an xml file to send to their bank. By using this payment method, we ensure that the available payments will be listed in the accounting dashboard and will be exported easily. Forward-Port-Of: odoo/enterprise#8196
Original PR description
Without the `payment_method_id` field of the linked account.payment record being set to the SDD payment method, it was impractical (or impossible, really) for users to export payments generated that way in an xml file to send to their bank. By using this payment method, we ensure that the available payments will be listed in the accounting dashboard and will be exported easily. Forward-Port-Of: odoo/enterprise#8196
One call to rmspaces function contains an extra argument while one call to parsefloat function is missing one. opw-2187711 Forward-Port-Of: odoo/enterprise#8198
Original PR description
One call to rmspaces function contains an extra argument while one call to parsefloat function is missing one. opw-2187711 Forward-Port-Of: odoo/enterprise#8198
Steps to reproduce: - install ups_delivery - configure ups to use Collect on Delivery and select Cashier's check or MoneyOrder as an option - go to sales order and create a quotation, set ups as shipping carrier - confirm > delivery > validate Previous behavior: you get a traceback error "No type 'CODAmountType' in namespace" Current behavior: the order validates correctly Forward-Port-Of: odoo/enterprise#8132
Original PR description
Steps to reproduce: - install ups_delivery - configure ups to use Collect on Delivery and select Cashier's check or MoneyOrder as an option - go to sales order and create a quotation, set ups as shipping carrier - confirm > delivery > validate Previous behavior: you get a traceback error "No type 'CODAmountType' in namespace" Current behavior: the order validates correctly Forward-Port-Of: odoo/enterprise#8132
OCR wasn't meant to be available for customer invoices at the time. Only vendor bills are currently properly handled on the server side. Forward-Port-Of: odoo/enterprise#8106 Forward-Port-Of: odoo/enterprise#8044
Original PR description
OCR wasn't meant to be available for customer invoices at the time. Only vendor bills are currently properly handled on the server side. Forward-Port-Of: odoo/enterprise#8106 Forward-Port-Of: odoo/enterprise#8044
- Create an inventory with 'Counted Quantities' set as 'Default to stock on hand' - Start the inventory - Open the barcode app (from the 'Barcode' stat button) The 'Validate' button is disabled, while it should be enabled since it is allowed to validate an empty inventory. The inventory use case is a specific use case where the validation should always be available. opw-2187225 Forward-Port-Of: odoo/enterprise#8165
Original PR description
- Create an inventory with 'Counted Quantities' set as 'Default to stock on hand' - Start the inventory - Open the barcode app (from the 'Barcode' stat button) The 'Validate' button is disabled, while it should be enabled since it is allowed to validate an empty inventory. The inventory use case is a specific use case where the validation should always be available. opw-2187225 Forward-Port-Of: odoo/enterprise#8165
Tried to fix with #8004 but it's not working in some obscure cases. ### Issue - Install Projects - Enable Forecast and Timesheets - Planning > Reports > Planning analysis - Group by Project > Employee Traceback ### Cause In 5262914, we override the read_group method to make open shifts always visible on Gantt view. It create a fake record with all fields to False but when you use group by it removes the fields from the fields variable and it put it in groupby v
Original PR description
Tried to fix with #8004 but it's not working in some obscure cases. ### Issue - Install Projects - Enable Forecast and Timesheets - Planning > Reports > Planning analysis - Group by Project > Employee Traceback ### Cause In 5262914, we override the read_group method to make open shifts always visible on Gantt view. It create a fake record with all fields to False but when you use group by it removes the fields from the fields variable and it put it in groupby variables. So when you are in Gantt view it works fine but when you group by in report analysis (pivot view) it crashes because it doesn't have a record with all fields. ### Solution Apply the custom group by only on gantt view **OPW-2179747** Forward-Port-Of: odoo/enterprise#8180
- Create a subscription product, do not set an income account - On its product category, set a specific income account - Create a subscription with the product - Create an invoice The account of the category is not selected. This is because `_get_computed_account` of `account.move` is not called explicitly. It is usually called by `_onchange_product_id`, but calling explicitly the latter would rewrite many other fields. Therefore, we explicitly set the account. opw-2172440 Forw
Original PR description
- Create a subscription product, do not set an income account - On its product category, set a specific income account - Create a subscription with the product - Create an invoice The account of the category is not selected. This is because `_get_computed_account` of `account.move` is not called explicitly. It is usually called by `_onchange_product_id`, but calling explicitly the latter would rewrite many other fields. Therefore, we explicitly set the account. opw-2172440 Forward-Port-Of: odoo/enterprise#7755