Wednesday, June 18, 2025
34 changes · saas-18.1
Resolved issues and error corrections
Moving a job application to the empty or unassigned stage no longer creates an extra stage named "None" after refresh. This keeps recruitment boards cleaner and avoids confusion from duplicate placeholder stages.
Original PR description
In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false). ## Description of the issue/feature this PR addresses: In…
In this PR, we fixed the creation of a new None stage each time when we move an application to the existing None stage (stage_id = false).
## Description of the issue/feature this PR addresses:
In the Kanban view of the application dashboard, when a user moves an application to the "None" stage (which corresponds to stage_id = False) and refreshes the page, a new stage labeled "None" is incorrectly created.
The issue arose from the way we were updating the many2one field for stage_id. Specifically, we were setting the value as:
`{ id: false, display_name: "None" }`
This object was interpreted by the model layer as an instruction to create a new related record (i.e., a new stage) with the name "None", which is unintended.
## Fix:
We adjusted the logic so that if the targetGroup.value is falsy (i.e., null, undefined, or false), we now explicitly pass false instead of constructing an object. This correctly unsets the many2one field without triggering record creation.
This ensures:
- If a valid stage is selected, we pass the appropriate { id, display_name } object.
- If "None" is selected, we pass false to unset the stage_id, avoiding the creation of a phantom stage.
Current behavior before PR:
Desired behavior after PR is merged:
Task: 4873853
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes live chat and discussion channel creation use a single consistent timestamp, preventing chats from being incorrectly treated as pinned when systems are slow. It also tidies related partner handling so the process is more dependable behind the scenes.
Original PR description
runbot-112917 runbot-112998 `unpin_dt` was using `now()` inside the function and `last_interest_dt` was using `now()` (-1 sec) from its default value. When there was more than one sec between the two calls due to slow CPU or slow query, the channel would be considered pinned even though it was supposted to not be. This commit ensures the same `now()` is used in both cases. The opportunity is taken to clean the method a bit: - ensure the provided ids are existing partners - internally, use recordset of partners rather than ids - use `self_member_id` rather than extra manual search
This fixes an automated Shop Floor workflow test by removing an unnecessary pause step. The change helps keep manufacturing work order checks reliable without changing day-to-day user functionality.
Original PR description
remove pause from step in tour_shopfloor refer to this commit : https://github.com/odoo/enterprise/commit/73c8690df52dd42fdf34f3a7fea6e2c06ff987e6
Miscellaneous changes
Step to reproduce; - install documents - upload a parasolid file, it has extension `x_t` - download it Observation: if a file is uploaded with file named as `file.x_t`, it will be downloaded as `file.x_t.txt` Issue: currently, the `get_extension` method only allow alphanumeric values for extension, which do not consider extension having '_' https://github.com/odoo/odoo/blob/15fd3f62769b137cb9a0625f47b333424b851a27/odoo/tools/mimetypes.py#L212-L218 when such file is downloaded,
Original PR description
Step to reproduce; - install documents - upload a parasolid file, it has extension `x_t` - download it Observation: if a file is uploaded with file named as `file.x_t`, it will be downloaded as `file.x_t.txt` Issue: currently, the `get_extension` method only allow alphanumeric values for extension, which do not consider extension having '_' https://github.com/odoo/odoo/blob/15fd3f62769b137cb9a0625f47b333424b851a27/odoo/tools/mimetypes.py#L212-L218 when such file is downloaded, `_get_stream_from` appends extra extension to the filename, depending upon its mimetype. https://github.com/odoo/odoo/blob/15fd3f62769b137cb9a0625f47b333424b851a27/odoo/addons/base/models/ir_binary.py#L148-L150 Fix: instead of `isalnum()`, use a regex that allows alphanumeric and underscore in extension. opw-4801263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212197
This PR updates the share dialog message shown when a slide is shared via email. Since emails are queued and sent later in batches, the previous message could be misleading and prompt users to send multiple emails unnecessarily. Task-4797324 Forward-Port-Of: odoo/odoo#211390
Original PR description
This PR updates the share dialog message shown when a slide is shared via email. Since emails are queued and sent later in batches, the previous message could be misleading and prompt users to send multiple emails unnecessarily. Task-4797324 Forward-Port-Of: odoo/odoo#211390
Description of the issue/feature this PR addresses: Posting an account move will unconditionally overwrite any value in the `checked` field to the value of the `journal_id.autocheck_on_post` field. I.e. whatever the user has selected in the `checked` will be overwritten. This PR will change the functionality to work as the original comment for the feature states. Current behavior before PR: The `checked` field on an account move is always updated to the value of the `journal_id.autocheck_
Original PR description
Description of the issue/feature this PR addresses: Posting an account move will unconditionally overwrite any value in the `checked` field to the value of the `journal_id.autocheck_on_post` field. I.e. whatever the user has selected in the `checked` will be overwritten. This PR will change the functionality to work as the original comment for the feature states. Current behavior before PR: The `checked` field on an account move is always updated to the value of the `journal_id.autocheck_on_post` field, when posting an account move. Desired behavior after PR is merged: The checked field on an account move is updated to the value of the journal_id.autocheck_on_post, when posting a move, only when the journal_id.autocheck_on_post is `True`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213370
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Enterprise PR: https://github.com/odoo/enterprise/pull/87223 task-4242065 F
Original PR description
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Enterprise PR: https://github.com/odoo/enterprise/pull/87223 task-4242065 Forward-Port-Of: odoo/odoo#213405
Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This happens because it opens the composer to reply to the message. Replying to a message should normally use the composer of thread and rely on `props.messageToReplyTo` from the `useMessageToReplyTo` hook, but portal chatter instead makes a composer linked to the message. The problem is that
Original PR description
Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This…
Before this commit, clicking on "Comment" button in portal chatter to reply to a message leads to the following crash: ``` TypeError: Cannot read properties of null (reading 'effectiveSelf') ``` This happens because it opens the composer to reply to the message. Replying to a message should normally use the composer of thread and rely on `props.messageToReplyTo` from the `useMessageToReplyTo` hook, but portal chatter instead makes a composer linked to the message. The problem is that a message linked to a composer is actually meant to say the composer is for editing the message, and when editing the message the composer shows no avatar as this is shown by the `Message` component. Portal chatter reply to comment should display avatar of self user, but the problem is that the component `Composer` isn't directly linked to `thread`, therefore the LOC `thread.effectiveSelf` crashes in template. This commit fixes the issue by using the `message` linked to composer when no immediate thread is found in order to display the `effectiveSelf` avatar. A composer is necessarily linked to either a thread or composer, thus this ensures the `effectiveSelf` is defined. Forward-Port-Of: odoo/odoo#213268
When refunding a PoS order with mulitple lines containing a product with a category that use FIFO/AVCO valuation method, there was a traceback Steps to reproduce: ------------------- * Create a category CAT that use FIFO/AVCO valuation method * Create a product P1 with category CAT * Create a product P2 with category CAT * Create a PoS order with P1 and P2 * Validate the order using the shiplater and invoice option * Refund the order using the shiplater and invoice option > Observatio
Original PR description
When refunding a PoS order with mulitple lines containing a product with a category that use FIFO/AVCO valuation method, there was a traceback Steps to reproduce: ------------------- * Create a category CAT that use FIFO/AVCO valuation method * Create a product P1 with category CAT * Create a product P2 with category CAT * Create a PoS order with P1 and P2 * Validate the order using the shiplater and invoice option * Refund the order using the shiplater and invoice option > Observation: You get a traceback opw-4848667 Forward-Port-Of: odoo/odoo#213209
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#213457* 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#193881The 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: 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
Issue ----- When returning different products than the ones sold on the SO, the returned products have their sequence set to 10 so they all appear between the first and second sold products. Steps to reproduce ----- - Install both Sale & Stock apps - Create & confirm a sale for 2 different products - Confirm the delivery - Create & validate a return for a third product - Open the SO -> The returned product sol is second in sequence Cause ----- The return SOL are created with n
Original PR description
Issue ----- When returning different products than the ones sold on the SO, the returned products have their sequence set to 10 so they all appear between the first and second sold products. Steps to reproduce ----- - Install both Sale & Stock apps - Create & confirm a sale for 2 different products - Confirm the delivery - Create & validate a return for a third product - Open the SO -> The returned product sol is second in sequence Cause ----- The return SOL are created with no specified sequence value, so they all have the default (10). See [review](https://github.com/odoo/odoo/pull/209091#pullrequestreview-2828126823) for details. ----- Ticket: opw-4564504 Forward-Port-Of: odoo/odoo#209091
Companies (typically branches) whose VAT or Codice Fiscale differs from their parent (root) company are now allowed to create their own EDI proxy user. This ensures that only independent legal entities are assigned individual proxy users, while subsidiaries sharing the same VAT/CF use the root company's proxy configuration. no-task Forward-Port-Of: odoo/odoo#212701
Original PR description
Companies (typically branches) whose VAT or Codice Fiscale differs from their parent (root) company are now allowed to create their own EDI proxy user. This ensures that only independent legal entities are assigned individual proxy users, while subsidiaries sharing the same VAT/CF use the root company's proxy configuration. no-task Forward-Port-Of: odoo/odoo#212701
When calculating line discounts, extra decimal places are being used when computing the total in intermediate steps. This discrepancy is interpreted as a small discount, that shouldn't be there. We should instead use the current currency's precision. Example: ``` qty: 1.65 unit_price: 29.9 total: 1.65 * 29.9 = 49.335, rounded to 49.34 discount = 0.005 * 100 / 49.335 = 0.010 ``` Steps: - Create an invoice with a product - Set quantity to 1.65, price to 29.9 - Confirm & get the invo
Original PR description
When calculating line discounts, extra decimal places are being used when computing the total in intermediate steps. This discrepancy is interpreted as a small discount, that shouldn't be there. We should instead use the current currency's precision. Example: ``` qty: 1.65 unit_price: 29.9 total: 1.65 * 29.9 = 49.335, rounded to 49.34 discount = 0.005 * 100 / 49.335 = 0.010 ``` Steps: - Create an invoice with a product - Set quantity to 1.65, price to 29.9 - Confirm & get the invoice PDF - Upload the PDF in accounting app - Check the "discount" value Slight improvement to odoo/odoo#206107 opw-4776391 Forward-Port-Of: odoo/odoo#213594 Forward-Port-Of: odoo/odoo#211032
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 Forward-Port-Of: odoo/odoo#214569
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 Forward-Port-Of: odoo/odoo#214569
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error. The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemp
Original PR description
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via…
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error. The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemps to decode it. The `b64decode` function silently discard non-b64 characters and only complain if the final thing lacks the b64 `=` padding (to make the length a multiple of 4). So when it downloaded something, it downloaded crap. Makes the code actually raise an error should the binary field not contains b64 data. Fixing the problem by using the data as-is (with no b64 decoding) is not desirable. We use `Binary(attachment=False)` when we need to store sensitive documents, often cryptographic keys, and exporting them is often not desirable. 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#214412 Forward-Port-Of: odoo/odoo#213997
**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#214577 Forward-Port-Of: odoo/odoo#214493
Prevent invoice send method from being overwritten to "Peppol" when it is already manually set to another value like "Email". Steps to reproduce: 1. Install the Peppol module. 2. Create a contact with "Email" as invoice send method and a valid Peppol endpoint. 3. Create an invoice for that contact. 4. Click "Print and Send". 5. The method wrongly switches to "Peppol" instead of staying "Email". A similar overwrite also occurs when clicking "Verify" next to the Peppol endpoint verifica
Original PR description
Prevent invoice send method from being overwritten to "Peppol" when it is already manually set to another value like "Email". Steps to reproduce: 1. Install the Peppol module. 2. Create a contact with "Email" as invoice send method and a valid Peppol endpoint. 3. Create an invoice for that contact. 4. Click "Print and Send". 5. The method wrongly switches to "Peppol" instead of staying "Email". A similar overwrite also occurs when clicking "Verify" next to the Peppol endpoint verification on the contact form, but in that case the user sees it immediately, making it less confusing. This fix prevents overwriting the send method if it is already manually set. opw-4826186 Forward-Port-Of: odoo/odoo#214723
Forward-Port-Of: odoo/odoo#206918
Original PR description
Forward-Port-Of: odoo/odoo#206918
Forward-Port-Of: odoo/enterprise#83860
Original PR description
Forward-Port-Of: odoo/enterprise#83860
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550 Forward-Port-Of: odoo/enterprise#86870
Original PR description
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550 Forward-Port-Of: odoo/enterprise#86870
### Steps to reproduce: - Install PoS mexican localization - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ### Cause: This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error. https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/model
Original PR description
### Steps to reproduce: - Install PoS mexican localization - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ### Cause: This is happening because when refunding an order we are checking if every line has positive price but since discount lines will have negative value it trigger the validation error. https://github.com/odoo/enterprise/blob/78bcd2e0b9296ad124ea1c3157a884fa6e62999a/l10n_mx_edi_pos/models/pos_order.py#L286 ### Fix: We check if the order lines are positive but after filtering the discount lines out opw-4528737 Forward-Port-Of: odoo/enterprise#87773 Forward-Port-Of: odoo/enterprise#84331
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#87218At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward
Original PR description
At the moment, the tax aggregators always give a base line with no tax the `None` grouping key. Sometimes, we want base lines with no tax to be grouped as if they had a particular tax, such as an exempt one. This commit extends the aggregator behaviour so that for base lines with no tax, the grouping function is called with an empty tax_data dict, and the returned grouping key is used to group the base line. Community PR: https://github.com/odoo/odoo/pull/213405 task-4242065 Forward-Port-Of: odoo/enterprise#87223
Adds a test to the fix done in the commit [814b1b2](https://github.com/odoo/enterprise/commit/814b1b21f60189715c82c96397c36da706736490) opw-4836094 Forward-Port-Of: odoo/enterprise#87166
Original PR description
Adds a test to the fix done in the commit [814b1b2](https://github.com/odoo/enterprise/commit/814b1b21f60189715c82c96397c36da706736490) opw-4836094 Forward-Port-Of: odoo/enterprise#87166
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87165
Original PR description
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87165
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
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading
Original PR description
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3.…
**Steps to reproduce:** 1. Install hr_payroll. 2. Create a salary rule (with a structure where country_id is null) and set `View on Payroll Reporting?` is checked for a custom field (x_l10n_xx_%). 3. Add the custom field to the payroll report's pivot view using Studio. **Issue:** - The pivot view fails to open, resulting in a traceback. ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillStart: "Cannot read properties of undefined (reading 'string')" ``` **Cause:** - Custom field that not start with `l10n_<country_code>` or `x_l10n_<country_code>` are removed, causing undefined fields in the pivot view. https://github.com/odoo/enterprise/blob/ccb5ed4779db4bdf6944f43eb2e4a7aa978b9272/hr_payroll/static/src/js/hr_payroll_report_pivot_model.js#L13-L15 **Solution:** - Allow to add custom fields created from salary rules without a country code to be used as custom measures in the pivot view. opw-4688376 Forward-Port-Of: odoo/enterprise#84881
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87468
Original PR description
Before this PR: - IRN number was also copied when a record was duplicated or while creating a debit/credit note for purchase document. - This caused the same IRN to appear on multiple records. After this PR: - Now, when a record is duplicated or a debit/credit note is created, the IRN number will be empty to prevent duplication. Task Id: 4854568 Forward-Port-Of: odoo/enterprise#87468
before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Task Id: 4836667 Forward-Port-Of: odoo/enterprise#86779
Original PR description
before this PR: split horizontally is ticked by default on Balance Sheet. after this PR: split horizontally is unticked by default. Task Id: 4836667 Forward-Port-Of: odoo/enterprise#86779
Currently an error occurs when the user tries to remove the currency on any monetary field through web studio. Steps to replicate: - Open any list view with web_studio. - Drag and drop a monetary field and remove the currency field and save. Error: `TypeError: Argument must be bytes or unicode, got 'NoneType'` This error occurs because the `attrs` dictionary contains `{'name': None}`, and `etree.Element()` doesn't accept attributes with None values, causing it to raise a `TypeError`.
Original PR description
Currently an error occurs when the user tries to remove the currency on any monetary field through web studio.
Steps to replicate:
- Open any list view with web_studio.
- Drag and drop a monetary field and remove the currency field and save.
Error:
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
This error occurs because the `attrs` dictionary contains `{'name': None}`, and `etree.Element()` doesn't accept attributes with None values, causing it to raise a `TypeError`.
This commit fixes the issue by making the field required so that user cant remove the value from currency field and hence preventing error at line [1].
[1]-https://github.com/odoo/enterprise/blob/a41cca06bc1e25614390f9207c937566557350a0/web_studio/controllers/main.py#L928
sentry-4244801243
Forward-Port-Of: odoo/enterprise#85565Steps: - Create an employee with marital status is married - Keep the spouse name empty - Try to export ird reports with a confirmed payslip Current behavior: - Error raised Expected behavior: - Should be able to export the report even spouse name is empty Forward-Port-Of: odoo/enterprise#86270
Original PR description
Steps: - Create an employee with marital status is married - Keep the spouse name empty - Try to export ird reports with a confirmed payslip Current behavior: - Error raised Expected behavior: - Should be able to export the report even spouse name is empty Forward-Port-Of: odoo/enterprise#86270