Wednesday, June 18, 2025
27 changes · 18.0
Enhancements to existing features
The Turkish Nilvera integration was updated to use the current access-checking method in Odoo 18. This keeps the module aligned with the latest platform standards and reduces the risk of future maintenance issues.
Original PR description
Starting from version 18.0, `check_access_rule()` is deprecated. This **PR** updates the code to use `check_access()` instead.
Resolved issues and error corrections
This fixes a small timing precision issue in manufacturing work orders that could cause automated checks to fail unpredictably. By standardizing timestamps to whole seconds, the system avoids tiny calculation differences that do not affect real operations but can disrupt validation.
Original PR description
The `_set_duration` inverse method of `mrp.workorder` is ignoring microsecond variations when computing the `date_start `of a workorder productivity record. This method uses the current time as the end date but does not remove microseconds from it. This causes a intermittent error when running the `test_labor_cost_balancing_with_cost_share`, because the computed duration (around 0.03 hours or 1.8 seconds) can vary slightly depending on the microseconds captured by `datetime.now()`. This fluctuation results in a 1- or 2-second difference, which breaks the test. To fix it, we simply set the microsseconds of the end date to zero. This bug was introduced in: https://github.com/odoo/odoo/pull/211853 Runbot failure example: https://runbot.odoo.com/odoo/runbot.build.error/226657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close produ
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [1]: 10ed12241365942914885dff953049303b9ed94f Enterprise: https://github.com/odoo/enterprise/pull/86905 opw-4800147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212885
Triple-clicking text in the HTML editor now selects the full paragraph even when it contains manual line breaks. This makes text editing more predictable and prevents users from accidentally selecting only part of a paragraph.
Original PR description
Problem: When a paragraph contains a `<br>` element, triple-clicking on any line does not select the entire paragraph — only the clicked line is selected. Solution: Ensure that on triple click, the selection expands to include the entire block, regardless of inline breaks like `<br>`. Steps to reproduce: - Open the Todo app. - Add a paragraph of text. - Use `Shift+Enter` to insert a line break (`<br>`). - Add text on the second line. - Triple-click on the second line. → Only the second line is selected, not the full paragraph. opw-4825816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents list items with line breaks from being split into multiple separate blocks when users toggle list formatting. It keeps edited content grouped correctly, reducing unexpected layout changes in the HTML editor.
Original PR description
**Current behavior before PR:** - When a list contains content separated by **Shift+Enter** toggling the list would break these lines and create a separate base container for each segment separated by `<br>`. **Desired behavior after PR is merged:** - Only a single base container is created when toggling a list that contains **Shift+Enter** contents. task:4854372
This fix ensures invoice or accounting lines without taxes are handled correctly when tax totals are summarized in the user interface. It prevents incorrect grouping behavior so displayed tax summaries remain accurate and consistent.
Original PR description
In 540e4243f4 we modified the `_aggregate_base_line_tax_details` method so that base lines without any taxes are no longer automatically grouped under the `None` / `null` grouping key and are instead also passed to the grouping function which evaluates a grouping key for them. As part of this improvement, all existing grouping functions needed to be adapted to explicitly return `None` or `null` for base lines with no tax. We forgot to modify the grouping function which computes the tax totals summary in JS. task-none
This update adds test coverage to ensure website page anchors are handled correctly when suggesting links in the editor. It helps prevent regressions in link creation and keeps website editing more reliable for users.
Original PR description
Before this commit: we have basic test for the url autocomplete in the linkpopover, but we miss the case for the page anchors After this commit: we added the page anchor test, also updated the icon path to the one inside website module Related PR: https://github.com/odoo/odoo/pull/187091 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users without administrator access can now open the Calendar app when Microsoft Calendar synchronization is enabled. This prevents an access error caused by reading the Microsoft Calendar token during synchronization, improving reliability for everyday calendar users.
Original PR description
Steps: - Open Calendar app without group_system access right Actual result: - Access error due to microsoft_calendar_token field Expected result - No error opw-4850523 Caused-by: https://github.com/odoo/odoo/pull/150186
This fixes a storefront issue where shoppers could not zoom images opened in the product image carousel. Product photos can now be inspected more closely as intended, improving the shopping experience when zoom is enabled.
Original PR description
## Version
18.0+
## Issue
Carousel images are not zoomable on product's website view
## Steps to reproduce
- Select any product and move to `Sales` tab:
- Add 1 image under `ECOMMERCE MEDIA` section.
- Click `Go to website` and open edit mode:
- Select the main image in the view;
- In the editor, change the `Image Zoom` value for `Pop-up on Click`;
- Save and close the editor.
- Click on the main image to display the carousel:
- Hover the current image and try to zoom in or out *(using the mouse wheel or equivalent action on trackpad)*
opw-4831912This fix prevents translated product names from appearing twice in sales order line descriptions when a newline was missing. It keeps sales documents clearer and avoids confusing product descriptions for users and customers.
Original PR description
This commit fixes an issue from [1] when the SOL description did not include a newline after the translated product name, which caused it to show unexpectedly. opw-4760300 --- 1. https://github.com/odoo/odoo/pull/209141 Related: - https://github.com/odoo/odoo/pull/214571 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
SEPA Direct Debit batch payments can now be validated even when the pre-notification email template is unavailable or intentionally disabled. This prevents validation failures for customers who do not want these emails sent, improving reliability of payment processing.
Original PR description
Current Behavior: When validating a SEPA Direct Debit batch payment, Odoo automatically attempts to send a pre-notification email using the email template account_sepa_direct_debit.email_template_sdd_pre_notification. If this template is missing (e.g. deleted or unlinked), the process fails with a ValueError: External ID not found, and the batch cannot be validated. Expected Behavior: If the template is missing, no pre-notification email should be sent, but the batch validation should still proceed without error. The process must not raise a traceback or prevent validation. task-4815699
This fix adjusts project and timesheet test coverage so checks for allocated hours run in the right module context. It helps prevent false test failures when the timesheet grid feature is not installed, improving reliability without changing day-to-day user behavior.
Original PR description
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking. runbot-115003
Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click "compare" on another product. Issue 1: Product animation goes to the top-left corner. Issue 2: After accepting the cookie bar, the compare button appears but overlaps with the popover. Reason: To cover bottom fixed elements when any modal is open, we added the `o_bottom_fixed_element_hidde
Original PR description
Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click…
Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click "compare" on another product. Issue 1: Product animation goes to the top-left corner. Issue 2: After accepting the cookie bar, the compare button appears but overlaps with the popover. Reason: To cover bottom fixed elements when any modal is open, we added the `o_bottom_fixed_element_hidden` class with the `d-none` property to hide those elements, making them visible once the modal closes. As a result, the compare button hides when scrolled, leading it to redirect to the top-left corner. Additionally, adding a product triggers the applyStyles function of popper.js to handle popover styles. When the cookie bar is accepted and the modal closes, this method doesn't trigger until scroll. This PR aims to resolve animation of product comparision when modal is open by remove the `o_bottom_fixed_element_hidden` class when added to compare products. Additionally, we add debounce leading and trailing params to the `_hideBottomFixedElements` to call function accordingly. task-3877807 Forward-Port-Of: odoo/odoo#182874
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b> Before archiving the product, the `Purchased` smart button correctly displays the total purchased quantity. However, after archiving the product template, this smart button displays `0.0`, even though purchases exist. Additionally, clicking the button opens a blank purchase order
Original PR description
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b>…
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b> Before archiving the product, the `Purchased` smart button correctly displays the total purchased quantity. However, after archiving the product template, this smart button displays `0.0`, even though purchases exist. Additionally, clicking the button opens a blank purchase order line view instead of showing related records if the product is archived. <b>Cause:-</b> Archiving a product template sets active=False on the template and its variants. The computed field `purchased_product_qty` relies on the variants to calculate the total. Because the variants are inactive post-archival, the compute method sees no records, resulting in a displayed value of 0.0. Similarly, the smart button action uses the active variants in its domain, so it fails to find any related purchase order lines. <b>Solution:</b> The context is now explicitly set with active_test=False when computing the purchased_product_qty and when generating the domain for the smart button action. This ensures that even inactive variants are included in the calculation and the view logic, preserving the correct purchased quantity and showing the relevant purchase lines after archival. opw-4781578 Forward-Port-Of: odoo/odoo#212901 Forward-Port-Of: odoo/odoo#209955
Scenario: - insert the last blog posts widget in a page - open editor and edit (eg. Filter Intensity) the cover of a post - save Result: the change is lost Cause: the content of the widget is dynamic, and we delete the content in cleanForSave (that call the destroy of the widget) before saving, so the change are not saved. Fix: make the dynamically added cover widget unselectable, the cover of the blog post can still be changed in other locations (blog post list, blog post page).
Original PR description
Scenario: - insert the last blog posts widget in a page - open editor and edit (eg. Filter Intensity) the cover of a post - save Result: the change is lost Cause: the content of the widget is dynamic, and we delete the content in cleanForSave (that call the destroy of the widget) before saving, so the change are not saved. Fix: make the dynamically added cover widget unselectable, the cover of the blog post can still be changed in other locations (blog post list, blog post page). opw-4633287 __PR NOTE:__ in verson before 18.0, the cover was not selectable probably from the .o_not_editable on `.s_dynamic_snippet_content` ancestor element. I've not found what changed (there was some change to dynamic snippet and widget blog post) that make it selectable now. Forward-Port-Of: odoo/odoo#210079
Description of the issue/feature this PR addresses: Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI processing for pickings that are not relevant for EDI (e.g., internal movements within the company). Current behavior before PR: The system does not explicitly exclude pickings of type 'internal' from EDI logic. As a result, internal transfers may trigger EDI processing even though they are not int
Original PR description
Description of the issue/feature this PR addresses: Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI…
Description of the issue/feature this PR addresses:
Currently, the l10n_ro_edi_stock_enable flag may be set for all stock pickings, including internal transfers. This leads to unnecessary EDI processing for pickings that are not relevant for EDI (e.g., internal movements within the company).
Current behavior before PR:
The system does not explicitly exclude pickings of type 'internal' from EDI logic. As a result, internal transfers may trigger EDI processing even though they are not intended for such flows.
Additionally, at line 508, the existing match-case logic processes only 'outgoing' and 'incoming' types:
```
match data['picking_type_id'].code:
case 'outgoing':
partner = data['picking_type_id'].warehouse_id.partner_id if location == 'start' else data['partner_id']
case 'incoming':
partner = data['picking_type_id'].warehouse_id.partner_id if location == 'end' else data['partner_id']
case _other:
errors.append(_("Invalid picking type %(type_code)s", type_code=_other))
continue
```
Since 'internal' is not handled explicitly, it is treated as an invalid type, resulting in misleading error messages and unnecessary processing.
Desired behavior after PR is merged:
The PR introduces a condition to exclude pickings with picking_type_code = 'internal' from EDI processing. This prevents the l10n_ro_edi_stock_enable flag from being set for irrelevant pickings and avoids the generation of errors for valid internal movements.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213457Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.  Steps to reproduce ----- - Go to Settings > Companies > Configure Document Layout - Set the Layout to DIN 5008 - Set Paper format to A4 (anything except DIN5008) - Download the PDF Preview -> The printed
Original PR description
Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.…
Issue ----- Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.  Steps to reproduce ----- - Go to Settings > Companies > Configure Document Layout - Set the Layout to DIN 5008 - Set Paper format to A4 (anything except DIN5008) - Download the PDF Preview -> The printed pdf has an empty vertical band to the right of the document Cause ----- 87b067a added a new `din_page_pdf` class that we apply when printing the pdf https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L37 This forces a specific width to the contents https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/static/src/scss/report_din5008.scss#L124-L127 This works with the DIN paper format because it applies adequate margins https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L5-L18 For regular formats, we are better off with the default dynamic behaviour. Visual comparison ----- Left is before the fix, right is after the fix.  ----- Ticket: opw-4660716 Forward-Port-Of: odoo/odoo#211715
The taxes used in the info popup of the product list should be the taxes of the company that owns the PoS. At the moment, it uses the all the taxes defined on the product regardless of the company. Steps to reproduce: ------------------- * Create a branch for your main company * Define a tax in the main company, and one in the branch * Create a product and assign the two taxes to it * Open the PoS in the branch * Open the product info popup > Observation: Both tax are shown on the popu
Original PR description
The taxes used in the info popup of the product list should be the taxes of the company that owns the PoS. At the moment, it uses the all the taxes defined on the product regardless of the company. Steps to reproduce: ------------------- * Create a branch for your main company * Define a tax in the main company, and one in the branch * Create a product and assign the two taxes to it * Open the PoS in the branch * Open the product info popup > Observation: Both tax are shown on the popup, even the one defined in the main company. Why the fix: ------------ As it is done in `_pos_data_process` we should take the taxes of the company that owns the PoS, and if no tax is found. We should use the taxe of the parent company if there is any. If no tax is found it means no tax should be used. opw-4647704 Forward-Port-Of: odoo/odoo#213797
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition
Original PR description
**Steps to reproduce:** - Install Accounting - Upload some particular PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "Arbitrary Uncaught Python Exception" Cause: When printing the original bill, we try to add a banner on the PDF. In this case, PyPDF2 fails to add a banner and raises an error from decimal library (i.e. "decimal.InvalidOperation") that is not catched. **Solution:** Bypass the addition of the banner in such case by handling the error. opw-4829787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214493
* STEP TO REPRODUCE: Have 2 company (1 is Default San Francisco the other is VN company),Start enviroment in VN company -> config an online payment method with Demo/Wire Transfer -> Start session and create pos order with no customer then Validate -> Customer scan QR code using mobile (not logged in) -> 403 forbidden error, read the log said: Sorry, Public user for VN company (id=10) doesn't have 'read' access to: User (res.users) * REASON: when request.env.ref('base.public_user') it will get
Original PR description
* STEP TO REPRODUCE: Have 2 company (1 is Default San Francisco the other is VN company),Start enviroment in VN company -> config an online payment method with Demo/Wire Transfer -> Start session and…
* STEP TO REPRODUCE: Have 2 company (1 is Default San Francisco the other is VN company),Start enviroment in VN company -> config an online payment method with
Demo/Wire
Transfer -> Start session and create pos order with no customer then Validate -> Customer scan QR code using mobile (not logged in) -> 403 forbidden error, read the log said: Sorry, Public user for VN company (id=10) doesn't have 'read' access to: User (res.users)
* REASON: when request.env.ref('base.public_user') it will get public user from San Francisco company while the request user is Public User of VN company, the record rule prevent that
* SOLUTION: Fix by using method _get_public_user() in res.company, this
commit also move _get_public_user() from website to base module so other
modules can use it
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#193881Previewing an invoice that has no invoice lines causes a crash . The error happens when trying t o compute early payment discount info and assumes at least one payment term line is present. When there aren't any, it fails with a `ValueError` due to a call to `ensure_one()` on an empty recordset. this commit simply skips the discount logic when there are no payment term lines. Steps to reproduce: Accountant -> invoices New invoice with no lines Click on the preview button. OPW-4657488
Original PR description
Previewing an invoice that has no invoice lines causes a crash . The error happens when trying t o compute early payment discount info and assumes at least one payment term line is present. When there aren't any, it fails with a `ValueError` due to a call to `ensure_one()` on an empty recordset. this commit simply skips the discount logic when there are no payment term lines. Steps to reproduce: Accountant -> invoices New invoice with no lines Click on the preview button. OPW-4657488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210550
No description available.
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be m
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#86905
The tour in `test_worksheet_quality_check` expects the "Select Work Centers" dialog to open automatically on load. This only happens if: - `localStorage` has no previous selection, and - the user has `group_mrp_routings` As seen [Here](https://github.com/odoo-dev/enterprise/blob/df3c6642cae9b40700b0b17e0335cec00ce23d3e/mrp_workorder/static/src/mrp_display/mrp_display.js#L124) in `MrpDisplay.onWillStart()`: `if (localStorage === null && this.group_mrp_routings) { this.to
Original PR description
The tour in `test_worksheet_quality_check` expects the "Select Work Centers" dialog to open automatically on load.
This only happens if:
- `localStorage` has no previous selection, and
- the user has `group_mrp_routings`
As seen [Here](https://github.com/odoo-dev/enterprise/blob/df3c6642cae9b40700b0b17e0335cec00ce23d3e/mrp_workorder/static/src/mrp_display/mrp_display.js#L124) in `MrpDisplay.onWillStart()`:
`if (localStorage === null && this.group_mrp_routings) {
this.toggleWorkcenterDialog(false);
}`
When running with `--without-demo=all`, the admin user does not have this group, so the dialog does not show and the test fails.
We fix this by explicitly assigning the group:
`self.env.ref("base.user_admin").groups_id += self.env.ref('mrp.group_mrp_routings')`
[runbot-161194](https://runbot.odoo.com/odoo/error/161194)
Forward-Port-Of: odoo/enterprise#87218Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6)
Original PR description
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account…
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6) Now, try to click on the Create Draft Entry **Error:** A traceback will occur. ``` ValueError: Expected singleton: res.company(1, 2) ``` **Cause:** When the user created multiple payslips with multiple companies containing the same batch and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, and try to change the state to Done using the action_payslip_done method. https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70 So the self will contain multiple payslip recordsets with different company in each payslip. This leads to the above traceback when accessing company_id from self https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61 **Solution:** In payslips, the company_id field should be in readonly state, since the value of the company_id will computed from the employee_id which is a required field. Also raised a validation Error for the previously created record to handle the traceback. Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763 opw-4797089 Forward-Port-Of: odoo/enterprise#86628
In this PR, we change the paid net rule code to NET to align with other localizations. Forward-Port-Of: odoo/enterprise#87727
Original PR description
In this PR, we change the paid net rule code to NET to align with other localizations. Forward-Port-Of: odoo/enterprise#87727