Tuesday, June 11, 2024
28 changes · saas-17.2
Resolved issues and error corrections
Public visitors could trigger an error when selecting text or double-clicking in certain forum posts. This update checks that the toolbar option exists before changing it, preventing the page from breaking for forum users.
Original PR description
HOW TO REPRODUCE: ================= - website_helpdesk_forum addon shall be installed - Do not login (navigate as a public user) - Go to the Website > Forum > Help > any post - Double-click anywhere…
HOW TO REPRODUCE: ================= - website_helpdesk_forum addon shall be installed - Do not login (navigate as a public user) - Go to the Website > Forum > Help > any post - Double-click anywhere in the post body or select some text - You should get the following client error from `OdooEditor._updateToolbar: Cannot read properties of null (reading 'classList')` HOW TO FIX: =========== By ensuring the wysiwig toolbar unlink button is present in the page before adding classes to it. The bug seems to be in relation to the following PR odoo/odoo#147919, where the `OdooEditor._updateToolbar` method is slightly modified to ensure the toolbar unlink button is not visible initially, but forgets to check whether the element exists before hiding it. The bug can be spotted when `website_helpdesk_forum` is installed as it sets to 0 the level of karma required to answer a post while keeping the full edit rights (image and link) to 30 pts. As a consequence, the WYSIWYG is included in the post page even when requested by the public users, but the WYSIWYG toolbar does not include the unlink button. task-3932751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component to the latest version for Odoo 17.2 and fixes issues affecting charts, spreadsheet sizing, and paste behavior. Users should see more reliable spreadsheet interactions and fewer errors when working with charts or pasting content.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/14317eeae [REL] 17.2.10 Task: 0 https://github.com/odoo/o-spreadsheet/commit/2e5e95105 [FIX] chart: deepCopy support…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/14317eeae [REL] 17.2.10 Task: 0 https://github.com/odoo/o-spreadsheet/commit/2e5e95105 [FIX] chart: deepCopy support object without prototype Task: 3950324 https://github.com/odoo/o-spreadsheet/commit/146b0a0ae [FIX] spreadsheet: fix `useSpreadsheetRect` Task: 3965147 https://github.com/odoo/o-spreadsheet/commit/1217b1e83 [FIX] composer: Prevent default paste in composer Task: 3864000 https://github.com/odoo/o-spreadsheet/commit/f7df2fd33 [DOC] update integration minimal setup Task: 3918013 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes occasional failures in automated tests that verify Discuss channel subscriptions. The change makes the tests reliably detect when users join or leave channels, helping keep release validation stable without changing user-facing behavior.
Original PR description
Before this PR, some bus subscription tests were occasionally failing. These tests open Discuss and assert that bus subscriptions are correctly handled in different scenarios, such as joining/leaving a channel. To achieve this, they use the `waitForChannel` helper. Sometimes, the subscription is made before calling `waitForChannel`, which causes the test to fail. This PR replaces the `waitForChannel` method by adding a step when `bus_service.addChannel` is called. Since this setup can be done before opening Discuss, we ensure that the subscription is not missed. fixes runbot-61294,65319,61969
Miscellaneous changes
**Steps:** - Go to project > task > archive a task - Open portal view of project > go to the same project - Filter the search view by choosing 'Archived' - Click on the archived task **Issue:** - Session error when trying to open the archive task **Cause:** - By clicking on the archived task, page is refreshed and it tries to open the kanban view again and hence gives session expire error **Fix:** - Hiding the archived filter as suggested by the specs of the task because it seems
Original PR description
**Steps:** - Go to project > task > archive a task - Open portal view of project > go to the same project - Filter the search view by choosing 'Archived' - Click on the archived task **Issue:** - Session error when trying to open the archive task **Cause:** - By clicking on the archived task, page is refreshed and it tries to open the kanban view again and hence gives session expire error **Fix:** - Hiding the archived filter as suggested by the specs of the task because it seems to be irrelevant in project sharing - Passing the correct context so that it will take all the tasks in counting and not just the active tasks. **Affected version**: saas-16.3 - master **Task**-3690536 Forward-Port-Of: odoo/odoo#150866
Current behavior: --- When logged as a mass mailing user, in a mailing, using the editor, when applying a shape to an image, the image disappears. Steps to reproduce: --- 1. Make sure Marc Demo has the role User 2. Log in as Marc Demo 3. Create a new mailing 4. Select a template 5. Insert a picture 6. Select the picture 7. Change its shape to round 8. (preview works fine) 9. Save the mailing 10. Picture disappears Cause of the issue: --- When applying a shape to an image,
Original PR description
Current behavior: --- When logged as a mass mailing user, in a mailing, using the editor, when applying a shape to an image, the image disappears. Steps to reproduce: --- 1. Make sure Marc Demo has…
Current behavior: --- When logged as a mass mailing user, in a mailing, using the editor, when applying a shape to an image, the image disappears. Steps to reproduce: --- 1. Make sure Marc Demo has the role User 2. Log in as Marc Demo 3. Create a new mailing 4. Select a template 5. Insert a picture 6. Select the picture 7. Change its shape to round 8. (preview works fine) 9. Save the mailing 10. Picture disappears Cause of the issue: --- When applying a shape to an image, the resulting file is of mimetype 'image/svg+xml', when sending it to the server, the attachment is going to go through _check_contents https://github.com/odoo/odoo/blob/d752abb24d9b25bb6d10e411961447c8c8e28bba/odoo/addons/base/models/ir_attachment.py#L364 and if the mimetype is "xml_like", it will check for views write rights, without what the mimetype will be forced to text/plain. But in web_editor, when computing the image src https://github.com/odoo/odoo/blob/b6392e2c7dbc8e1ece326e28a9698801142714b7/addons/web_editor/models/ir_attachment.py#L34 if the mimetype is not a supported image type, src will be False. Fix: --- Override of _writeShape to use canvas to convert the image from svg to png. opw-3672798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164703 Forward-Port-Of: odoo/odoo#159497
PURPOSE Fix various issues related to automatic source creation and naming involving auto increment to avoid uniqueness constraint issues. Notably * avoid always incrementing (e.g. same name should not increment); * do not fail to start counters at 0 when possible; * improve write / batch bad support; * correctly check uniqueness in utm.source.mixin currently done on wrong model; * fill holes in counter sequence instead of continuing above higher found counter;
Original PR description
PURPOSE
Fix various issues related to automatic source creation and naming involving
auto increment to avoid uniqueness constraint issues.
Notably
* avoid always incrementing (e.g. same name should not increment);
* do not fail to start counters at 0 when possible;
* improve write / batch bad support;
* correctly check uniqueness in utm.source.mixin currently done on wrong
model;
* fill holes in counter sequence instead of continuing above higher found
counter;
See sub commits for more details.
LINKS
Task-3874538 (odoo/odoo#162229) Do not create endless copies
Task-3837272 (odoo/odoo#159699) Incorrect UTM source enumeration
Forward-Port-Of: odoo/odoo#168439
Forward-Port-Of: odoo/odoo#164287Current behavior before PR: - Cannot select projects with `company_id` = `False` when creating sale orders.  Desired behavior after PR is merged: - Allow to select projects with `company_id` = `False`.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
Current behavior before PR: - Cannot select projects with `company_id` = `False` when creating sale orders.  Desired behavior after PR is merged: - Allow to select projects with `company_id` = `False`.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167144
prior this PR, when a user selects an option from the HSN autocomplete widget using the keyboard, the selected value is not reflected in the input field. Technical Reason: The `onSelect()` method in the HSN autocomplete widget calls `this.props.record.update()`, followed by a call to `commitChanges()` in `input_field_hook.js` due to the `keydown` event. Consequently, the update method is called twice: first with the selected option value and then with the user's typed input value. This
Original PR description
prior this PR, when a user selects an option from the HSN autocomplete widget using the keyboard, the selected value is not reflected in the input field. Technical Reason: The `onSelect()` method in the HSN autocomplete widget calls `this.props.record.update()`, followed by a call to `commitChanges()` in `input_field_hook.js` due to the `keydown` event. Consequently, the update method is called twice: first with the selected option value and then with the user's typed input value. This sequence results in the input field displaying the typed value instead of the selected option. With this PR, selecting an option from the HSN autocomplete widget using the keyboard correctly updates the input field with the selected value. task-3961406 Forward-Port-Of: odoo/odoo#167501
With the update of ace to 1.32.3, the lib is formatting her cells by getting them with hardcoded position in a array (here: 0, 1 and 2). On our side we are adding our o_info as first element, so the lib returns a traceback because her elements are shifted. After this commit, our info node is added after the lib nodes to not shift the all bunch. runbot issue 55085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168
Original PR description
With the update of ace to 1.32.3, the lib is formatting her cells by getting them with hardcoded position in a array (here: 0, 1 and 2). On our side we are adding our o_info as first element, so the lib returns a traceback because her elements are shifted. After this commit, our info node is added after the lib nodes to not shift the all bunch. runbot issue 55085 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168264
**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field of the respective purchase order line. **Expected behavior:** These values will be synchronized. **Steps to reproduce:** 1. Make a purchase order with a following combination: A) `picking_type = receipt` `product cost_method != standard` B) `picking_type = dropship`
Original PR description
**Current behavior:** Depending on the created picking type and product costing method, unlocking a validated picking and changing the quantity field of a move will not update the qty_received field…
**Current behavior:**
Depending on the created picking type and product costing
method, unlocking a validated picking and changing the quantity
field of a move will not update the qty_received field of the
respective purchase order line.
**Expected behavior:**
These values will be synchronized.
**Steps to reproduce:**
1. Make a purchase order with a following combination:
A) `picking_type = receipt`
`product cost_method != standard`
B) `picking_type = dropship`
(product cost_method is arbitrary)
2. Confirm the order, validate the picking
3. Unlock the picking and change the quantity value of the stock
move
4. Observe that the purchase order's qty_received value does not
change
**Cause of the issue:**
In the case of the receipt picking type, when creating a stock
valuation layer for the related move with a 'standard' product
costing method we do not call `_get_price_unit()`. This method
will compute the qty_received value of a purchase order line.
After we unlock the picking and change the move quantity, this
field will not be recomputed (because it is stored). Thus, it is
not updated.
The dropship case is similar, except in the creation of a
dropship SVL, `_get_price_unit()` is called before checking the
product's cost method- so the bug always occurs.
**Fix:**
Make the purchase order line's qty_received field depend on it's
stock moves' quantities.
Reorder the conditional in the dropship SVL creation so it
matches that of the incoming SVL creation- this is for
improving consistency rather than a necessary modification for
the fix.
opw-3863510
Forward-Port-Of: odoo/odoo#166366Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations. The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed. Impacted branches: `17.0` and `master` Steps to reproduce: 1. Go to the
Original PR description
Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something…
Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations. The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed. Impacted branches: `17.0` and `master` Steps to reproduce: 1. Go to the Technical menu -> Fields and select a monetary type field 2. Try to update the Field Label or any field translation Current behavior: The editing is blocked by the required 'Currency field'. Expected behavior: Allow editing the form view or the related translations. 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#168504
Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian
Original PR description
Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests…
Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022` Before the present commit, the tests were surprisingly expecting the wrong result. An attempt was made [1] to fix the upstream issue but was never merged. In the meanwhile, Debian reverted the Babel issue 621 [2] in their package. It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib. So, this commit mitigate the issue by guessing the expected value even if the result is wrong. [0]: https://github.com/python-babel/babel/pull/621 [1]: https://github.com/python-babel/babel/pull/887 [2]: https://sources.debian.org/patches/python-babel/2.10.3-1/ For reference (from @Xavier-Do ) Pip version and Jammy ```python In [1]import babel.dates In [2]: import datetime In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE") Out[3]: 'dim. 52 2022' In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US") Out[4]: 'Sun 1 2022' ``` It looks like the week year used is actually not localized, adding a cornercase on Sunday Noble version ```python In [1]import babel.dates In [2]: import datetime In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE") Out[3]: 'dim. 52 2022' In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US") Out[4]: 'Sun 1 2023' ``` Forward-Port-Of: odoo/odoo#168132
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
Original PR description
We recently renamed `o-sidePanelButton` to `o-button` in the library but did not change it inside Odoo. 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#144139
-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step, the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done -Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/b
Original PR description
-PROPBLEM: one of the common onboarding step is setup company data where we will fill street, country or phone,... . Currently, when doing that step, the system always considers done eventhough we just open it and do nothing, unlike behavior in v16 where we will need to fill 'street' at least to be able to consider done -Solution is to do same like in 16.0, check if 'street' then we will consider the setup company data onboarding is finish https://github.com/odoo/odoo/blob/16.0/odoo/addons/base/models/res_company.py#L336-L338 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#167941
Problem: Combo product can have a price that is not the expected one Steps to reproduce: - Install "Point of Sale" app - Go to POS settings and go to the Tax settings - In the tab "Advanced Options", check "Included in Price" - Create a product of type "Combo", set the price to $7.00 - Add 3 combo choices with products prices as $7.00, $2.50 and $1.50 with no extra price - In the shop, sell this combo - The total price is $6.99 rather than $7.00 Cause: The condition supposed to fi
Original PR description
Problem: Combo product can have a price that is not the expected one Steps to reproduce: - Install "Point of Sale" app - Go to POS settings and go to the Tax settings - In the tab "Advanced Options", check "Included in Price" - Create a product of type "Combo", set the price to $7.00 - Add 3 combo choices with products prices as $7.00, $2.50 and $1.50 with no extra price - In the shop, sell this combo - The total price is $6.99 rather than $7.00 Cause: The condition supposed to fill the remaining price in the last orderline was always false opw-3897431 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167472
Currently administrators for the POS app don't see margins and costs when the setting is disabled. The setting should only affect simple POS users and admins should always see the margins and costs. Steps to reproduce: ------------------- * Connect as admin * Go to the current user settings and make sure he is a POS administrator * Go the **Point of Sale** App * Go to setting, make sure **Margins and Costs** is disabled * Open a shop session * Select the information icon on a product
Original PR description
Currently administrators for the POS app don't see margins and costs when the setting is disabled. The setting should only affect simple POS users and admins should always see the margins and costs. Steps to reproduce: ------------------- * Connect as admin * Go to the current user settings and make sure he is a POS administrator * Go the **Point of Sale** App * Go to setting, make sure **Margins and Costs** is disabled * Open a shop session * Select the information icon on a product > Margins and Costs are not shown Why the fix: ------------ Data loaded is different since using the new relational model https://github.com/odoo/odoo/commit/28b7d698be8255f933ba5314e44e7059746fc234 opw-3897694 Forward-Port-Of: odoo/odoo#166294
Issue: ------ The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account. For example: - monday morning: duration = 0.4 - monday afternoon: duration = 0.4 allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81 Note: It's strange to round up to the sixteenth of an 8-hou
Original PR description
Issue: ------ The use case in which certain employees, who work part-time over several days (and not part-time with full days with one or more days off), want to take leaves distributed via allocations given in days is unfortunately not taken into account. For example: - monday morning: duration = 0.4 - monday afternoon: duration = 0.4 allocation duration = round(0.8 * 16) / 16 = round(12.8) / 16 = 13 / 16 = 0.8125 ~= 0.81 Note: It's strange to round up to the sixteenth of an 8-hour day. It makes sense to have half-hour intervals, but it is does not work correctly with calendars that differ from the standard 8-hour calendar. opw-3957459 Forward-Port-Of: odoo/odoo#168517
Currently, when buying products with variants the attribute values are not reflected on the backend order. Steps to reproduce: ------------------- * Go to the **Point of Sale** app * Open a shop session * Make an order for the product `Desk Organizer` * Select any option from the product configuration popup * Pay and Validate the order * Go in the backend * Navigate to **Orders** * Select the last order > Observation: Selected options for the product are not reflected Why the fix
Original PR description
Currently, when buying products with variants the attribute values are not reflected on the backend order. Steps to reproduce: ------------------- * Go to the **Point of Sale** app * Open a shop…
Currently, when buying products with variants the attribute values are not reflected on the backend order. Steps to reproduce: ------------------- * Go to the **Point of Sale** app * Open a shop session * Make an order for the product `Desk Organizer` * Select any option from the product configuration popup * Pay and Validate the order * Go in the backend * Navigate to **Orders** * Select the last order > Observation: Selected options for the product are not reflected Why the fix: ------------ The function `set_full_product_name()` was changed with https://github.com/odoo/odoo/commit/672c853ab7d77ac1cebd2f4d16bd98fc454b2d55 It basically changed the behavior to set the `full_product_name` to `display_name` where it was previously computed with the attribute values. The fix is based on the fix made for the `pos_retaurant` module. https://github.com/odoo/odoo/commit/3b6455eb979078354e3b1009a354ca7010e5fec9 This will re-introduce a feature removed from the first commit mentioned which is to show the attribute values in full name of the product. This has already been re-introduced in later versions https://github.com/odoo/odoo/blob/8e00b5337a2ee30e667b0b2e6ff26b7df9fef2e3/addons/point_of_sale/static/src/app/store/models.js#L315-L320 This is in sass-17.2 opw-3950366 Forward-Port-Of: odoo/odoo#168697 Forward-Port-Of: odoo/odoo#168121
Steps: - Create a quotation template with 2+ products and optional products. - Create a new quotation using the template. - Add an optional product from the template. Issue: - Optional product is not added at the end of the quotation. Cause: - Optional product sequence defaults to 10 instead of continuing the sequence. Fix: - Adjust the sequence of added optional products in add_order_button to be the max sequence + 1. opw-3932966 I confirm I have signed the CLA and read the P
Original PR description
Steps: - Create a quotation template with 2+ products and optional products. - Create a new quotation using the template. - Add an optional product from the template. Issue: - Optional product is not added at the end of the quotation. Cause: - Optional product sequence defaults to 10 instead of continuing the sequence. Fix: - Adjust the sequence of added optional products in add_order_button to be the max sequence + 1. opw-3932966 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168311
Steps: - Install Ecom. - Buy a product without login and set different address for billing and shipping. Issue: - SO email sent to both billing and shipping emails it should only be sent to billing (main address). Cause: - In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails. Fix: - Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal
Original PR description
Steps: - Install Ecom. - Buy a product without login and set different address for billing and shipping. Issue: - SO email sent to both billing and shipping emails it should only be sent to billing (main address). Cause: - In Ecom address controller it set both shipping and billing partner record to follower of SO and because of that SO sent to both emails. Fix: - Only set main address partner to follower of SO so it'll only send email to Customer's main email like it do for normal Sales flow. opw-3714686 Forward-Port-Of: odoo/odoo#168259
## Description As an internal user one has access to many timesheets as if from the backend. If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of reco
Original PR description
## Description As an internal user one has access to many timesheets as if from the backend. If the group by option of the portal view `/my/timesheets` is set to `None`, on a large database with millions of timesheets, the computation for the aggregate of the `unit_amount` is really slow, and it faces an internal limitation of the ORM when the `mapped` hitting fields out of cache. The code path used to fetch the missing records `expands_ids` has a bad space complexity and with millions of records, this leads to an Memory Error (OOM). ## Benchmark On a database with over 4+M of timesheets matching the domain: | | Before | After | |--------|-----------|-------| | Timing | N/A (OOM) | 0.7s | ## Reference task-3977971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168549
### Issue: When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal. The same thing happens with Vendor Bills when the firm setting is activated. ### Steps to reproduce: - In Set
Original PR description
### Issue: When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more…
### Issue: When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal. The same thing happens with Vendor Bills when the firm setting is activated. ### Steps to reproduce: - In Settings > Accounting > 'Accounting Firms Mode' select "Customer Invoices and Vendor Bills" - In Accounting > Customers > Invoices create a new Invoice - Choose a name, for example 'INV234' and a journal - Save the record - Change the journal - When saving a popup indicates it is impossible to change the journal when a sequence number is assigned ### Cause: When not in firm mode the invoice can't be filled (displays as Draft) and will be generated from the previous invoice name (In fact the user can only modify the name of the first invoice created in the journal, not the next ones). With the firm mode activated, the user can always modify the name of the draft invoice, giving it a sequence number. Then when changing the journal, it is blocked because the user is not supposed to change the journal of an invoice with a sequence number greater than 1. The check: https://github.com/odoo/odoo/blame/16.0/addons/account/models/account_move.py#L2303 ### Solution: Modify the condition of the UserError so that it is not triggered when the 'Firm Mode' is active. opw-3925402 Forward-Port-Of: odoo/odoo#168319
As the selection badge is not checking if a badge is selected to set the value, when clicking to a badge that is selected yet, is updating the value to itself, so the value does not change.  By checking if the badge is trying to assign the same value, we can set the badge to false.  cc @Te
Original PR description
As the selection badge is not checking if a badge is selected to set the value, when clicking to a badge that is selected yet, is updating the value to itself, so the value does not change.  By checking if the badge is trying to assign the same value, we can set the badge to false.  cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167191 Forward-Port-Of: odoo/odoo#140544
Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode. This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode. task-3754159 Part of task-3575827 | Before | After | |--------|--------| |  |  |  | |  |  | |  |  | |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154856
The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language. opw-3976888 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#168567 Forward-Port-Of: odoo/odoo#168482
Original PR description
The field is translatable, but the default value wasn't being translated so new projects' tasks labels were always defaulting to English regardless of language. opw-3976888 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#168567 Forward-Port-Of: odoo/odoo#168482
When the user performs a mass produce, the generated serial numbers will only be created if they do not already exist in the database Forward-Port-Of: odoo/odoo#168141
Original PR description
When the user performs a mass produce, the generated serial numbers will only be created if they do not already exist in the database Forward-Port-Of: odoo/odoo#168141
Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry. This fix adds the missing inverse command. OWP: 3966053 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168744
Original PR description
Before this fix, undoing a command MOVE_GLOBAL_FILTER broke the history because the inverse command was missing from the inverse registry. This fix adds the missing inverse command. OWP: 3966053 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168744
Steps to reproduce: - Install eCommerce and `l10n_be` (to get a second company) - Enable online payment in the settings - Go to the payment provider and duplicate it for belgium company - Publish the payment provider - Make an invoice for a customer - Send or generate the link - Open the link in incognito - Pay the invoice Issues: When we create the `temp_move` we don't provide the `company_id` as such we will go in the compute which will fail. https://github.com/odoo/odoo/blob/f1
Original PR description
Steps to reproduce: - Install eCommerce and `l10n_be` (to get a second company) - Enable online payment in the settings - Go to the payment provider and duplicate it for belgium company - Publish the…
Steps to reproduce: - Install eCommerce and `l10n_be` (to get a second company) - Enable online payment in the settings - Go to the payment provider and duplicate it for belgium company - Publish the payment provider - Make an invoice for a customer - Send or generate the link - Open the link in incognito - Pay the invoice Issues: When we create the `temp_move` we don't provide the `company_id` as such we will go in the compute which will fail. https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_journal.py#L363 https://github.com/odoo/odoo/blob/17d85347f92d813704d3f8faef366166bbbaa730/addons/account/models/account_move.py#L693 In this line we call the `_accessible_branches` method on the belgium company as expected, in this method we use `self.env.companies` (default company) and we do an intersection with the current company (belgium). This results in an empty recordset for the company. Later in the stock we face this instruction which ends up in an empty recordset error as we have an ensure one at the beggining of `_get_violated_lock_dates`. https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_move.py#L4394 https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/company.py#L370 Website solve it by copying the `public_user` and affecting it to the desired company. https://github.com/odoo/odoo/blob/9079b7038754ca4fe547086d3fe8947a4bb6ddce/addons/website/models/res_company.py#L43-L57 A potential approach to solve this problem could be to allow `public_user` to access all of the companies (possibly problematic w.r.t. security). The solution chosen for this PR is a local solution as it makes more sense for stable. opw-3859791 Forward-Port-Of: odoo/odoo#162058