Daily updates from Odoo
Wednesday, March 5, 2025
50 changes · 18.0
New functionality added to Odoo
Point of Sale users can now set an additional unit of measure for products and enter sales quantities in that alternate unit. The system converts those quantities back to the product’s main unit at checkout, giving businesses more flexibility when selling items measured in different ways.
Original PR description
This commit introduces support for configuring and using a second unit of measure (UoM) for products in the same category. - Added a Second UoM field (pos_second_uom) in products, restricted to the same category as the primary UoM. - Users can configure a second UoM for better flexibility in POS. - In the POS module, users can input quantities using the second UoM, which automatically converts them to the primary UoM during checkout.
This update adds or adjusts an internal GitHub workflow configuration for the project. It helps automate repository processes and does not introduce changes that business users would see in Odoo.
Enhancements to existing features
Users entering the Website app from their database URL will no longer be forced onto the website domain, reducing disruptive redirects when accessing the backend. Link editing was also improved so Odoo can better suggest converting matching website or database-domain links into simpler internal links.
Original PR description
*: web_editor Before this commit, there was two cases where we forced the backend to reload using a website domain: 1. When trying to enter the website app, and reaching the default website's…
*: web_editor Before this commit, there was two cases where we forced the backend to reload using a website domain: 1. When trying to enter the website app, and reaching the default website's preview. Ensuring edition of that website is made while being on the right website domain. 2. When switching website using the website switcher (multi-websites case). This commit removes the redirection in the first case. It might lead to unexpected behavior in some specific/advanced cases, but it was decided it was worth the risk, to improve the QoL of users reaching their backend by explicitly typing their `<database>`.odoo.com URL. Even though this is not supposed the case anymore as soon as their website is properly configured. At the same time, this commit strengthens (hopefully) link edition. In the past, we suggested users to automatically strip the domain part of the URL they added in their website if it matches the current domain used while being in edit mode. Now we still do that and two more checks: - If the added URL is using `<dbname>`.odoo.com, suggest to strip the domain too. It might not be right, but it's a good guess. And the user can still opt-out. - If the added URL uses the website domain, suggest to strip the domain. Related to task-4069779
Point of Sale now allows product and customer loading limits to be configured through system settings. This gives businesses more control over POS performance and data volume, especially in large databases.
Original PR description
- Introduced `ir.config_parameter` settings for product and customer limits in POS. - Refactored partner loading to use configurable customer limit. task-id: 4610131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Deleting project tasks linked to many timesheet entries is now faster. This improves performance in databases with large timesheet histories and reduces delays during task cleanup.
Original PR description
Improve deletion performance for `project.task` with numerous `account.analytic.line` records by adding a missing index on the `parent_task_id` foreign key, which Postgres checks during the `DELETE` operation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and ot
Original PR description
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and other texts are updated to generalize - Companies without an accounting firm can access the Codabox configuration settings task - 4460499
Colombian electronic invoicing settings now include a Demo Mode that lets businesses test DIAN workflows without actually sending documents to the tax authority. This helps teams validate setup and training scenarios by simulating successful DIAN responses safely.
Original PR description
- Adding 'Demo Mode' option in the DIAN settings section - Adding demo mode bypasses to the relevant methods to imitate recieving a positive response from DIAN without sending anything task-4087930
Belgian companies can now connect to Codabox directly, even when they are not managed by an accounting firm. This broadens access to Codabox configuration and updates related wording so the feature no longer appears limited to fiduciaries.
Original PR description
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and other texts are updated to generalize - Companies without an accounting firm can access the Codabox configuration settings task - 4460499
Resolved issues and error corrections
This fix makes an automated online shop test wait slightly longer before checking results, reducing random failures in the testing system. It helps keep quality checks stable without changing customer-facing website behavior.
Original PR description
Versions -------- - 18.0+ Issue ----- The `website_sale_contact_us_button` tour fails randomly on Runbot. Cause ----- 50 ms check delay is inadequate. Solution -------- Set check delay to 500 ms. runbot-145471 runbot-145473
This fix ensures list views apply their configured properties when they are displayed. It helps prevent missing or incorrect behavior in customized list screens, improving consistency for users who rely on tailored views.
Original PR description
Before this fix, the list widget's extractProps function was never called due to an incorrect method reference in the web module. This caused issues when rendering dynamic props or customizing the list view behavior. After the fix: - The extractProps function is properly invoked. - The list widget can now retrieve props values as expected. Closes #200296 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
Portal chatter avatars now keep their intended shape even when the original image is not square. This prevents distorted profile pictures in customer-facing message threads, improving visual consistency and professionalism.
Original PR description
Before this commit, some messages in portal chatter may have avatar squished vertically or horizontally when the source image of avatar is not a square. This happens because avatar are cropped to fit cover with `.o_object_fit_cover`, in order to give the right visual when the avatar doesn't fit in a square. The classname was present but the SCSS file defining this rule was missing from the ` "portal.assets_chatter_style"` bundle, which this commit fixes. Before  After 
Duplicating a customer payment will no longer automatically keep it linked to the same invoice. This prevents confusing duplicate payments that appear connected to an invoice and cannot be adjusted, helping accounting users avoid payment allocation errors.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an unpaid invoice; 2. create a payment using the "Pay" button; 3. go the the payment; 4. duplicate payment. Issue ----- Duplicate payment is linked to the same invoice, with no way to change this. Cause ----- The `invoice_ids` field was added to `account.payment` in commit 01b87f1230bea. Before it, it relied on the reconciliation mechanism to link payments to invoices. Solution -------- Add `copy=false` to the field declaration, to prevent it from getting duplicated, and let other flows handle linking it to the desired invoice. opw-4555499
Portal users editing task descriptions can now see checklist checkboxes correctly, matching the backend editing experience. The update also removes an unwanted focus outline in the editor, making task editing look cleaner and more consistent.
Original PR description
**Problem**: When a portal user edits a task's description and adds a checklist, the checkboxes do not appear as they do in the Odoo backend (e.g., in the To-Do app). This occurs because the editor is rendered in an `iframe` with only `html_editor` loaded, while checklist styles are in `web_editor`. **Solution**: Add checklist styles to `html_editor`. **Steps to Reproduce**: 1. Share a project with **"Edit"** permission for a portal user. 2. Log in as the portal user. 3. Go to any task inside the project. 4. In the description, add a checklist using `/checklist` command. - **Issue**: No checkboxes appear. opw-4481993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the HTML editor where closing the link popup for an image without entering a URL could trigger an error. This improves editing reliability and prevents interruptions when users cancel or click away from link editing.
Original PR description
**Problem**: When an `img` is inside a link, `removeCurrentLinkIfEmpty` removes the `<a>` node if no `href` is provided. This resets `linkElement` to `null`. This happens if the user clicks outside the link popover (when is is open) without entering a URL, it results in a traceback due to an invalid reference. **Solution**: Ensure `linkEl.isConnected` before defining popover properties to avoid referencing a removed element. **Steps to Reproduce**: 1. Add an image. 2. Click on the image > toolbar > "Link". 3. When the link popover appears, click outside without typing a URL. 4. Observe a traceback. opw-4546324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures list widgets correctly read and apply their configured properties when screens are displayed. It helps customized list views behave as intended and reduces display or behavior issues for users.
Original PR description
Before this fix, the list widget's extractProps function was never called due to an incorrect method reference in the web module. This caused issues when rendering dynamic props or customizing the list view behavior. After the fix: - The extractProps function is properly invoked. - The list widget can now retrieve props values as expected. Description of the issue/feature this PR addresses: Current behavior before PR: widget extractProps do not execute correctly Desired behavior after PR is merged: widget extractProps execute correctly, and props are passed correctly --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where text in table cells could become invisible after applying a light background and switching to dark mode. The editor now keeps text readable by applying an appropriate default text color when a background color is set.
Original PR description
**Problem**: When applying a light background color to a table cell, switching to dark mode changes the text color to white, making it invisible. **Solution**: When setting a background color on a block element, also apply the default text color. This ensures text remains visible in both light and dark modes. **Steps to Reproduce**: 1. Add a table. 2. Change the background color of cells to white. 3. Switch to dark mode. 4. Observe that the text inside the cells is not visible. opw-4546663 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal users editing shared project tasks now see checklist checkboxes and editor styling correctly. This makes task descriptions behave consistently with the main Odoo backend editor and avoids confusion when using checklist features.
Original PR description
**Problem**: When a portal user tries to edit a task's description by adding a checklist, the checkboxes do not appear as they do in the Odoo backend (e.g., in the To-Do app). This occurs because the editor is rendered in an `iframe` without loading the required CSS classes. **Solution**: Load `web.assets_backend` to include all necessary CSS for the editor. **Steps to Reproduce**: 1. Share a project with **"Edit"** permission for a portal user. 2. Log in as the portal user. 3. Go to any task inside the project. 4. In the description, add a checklist using `/checklist` command. - **Issue**: No checkboxes appear. - **Issue**: Other styles, like the editable border, are missing. opw-4481993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a web interface issue where list view widgets were not applying their custom settings as intended. Users and implementers should see more reliable behavior when list views depend on dynamic configuration or custom display options.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Published Knowledge articles now include their main content directly in the page HTML instead of waiting for browser-side rendering. This helps search engines and other crawlers read public articles even when JavaScript is disabled, improving discoverability without changing the visible article experience.
Original PR description
Ensure that the HTML for Knowledge published articles is not delayed by OWL rendering promise. The content of the article should be available for web crawlers even with JavaScript disabled. The sidebar will still be loaded as a Component for convenience, and PublicWidget introduced through this commit will be converted to Interaction in future versions. task-4563216
Users can now make a copy of previous versions of quotation and quality control spreadsheet templates without hitting an error. This restores expected version-history behavior and prevents disruption when reusing or reviewing template revisions.
Original PR description
Prior to this commit, we get an error when we try to make a copy of a certain revision of a quotation/quality template spreadsheet. This is due to the method `_creation_msg` which was not implemented after inheriting the `spreadsheet.mixin` class. Steps to reproduce: - Go to Sales > Configuration > Quotation Templates (or Quality Control Templates) - Create a quotation template - Select the quotation calculator field and create a new quotation spreadsheet - In the quotation spreadsheet, select File > See version history - Select the three dots on any version and click "Make a copy" - Traceback occurs task-4568319
Payslip payments now fall back to the company currency when no payment currency is set. This prevents errors when reversing payroll-related journal entries, helping payroll and accounting teams complete corrections reliably.
Original PR description
Currently, an error was occurring when a user tried to reverse a journal entry by following these steps: - Install ``Accounting`` and ``Payroll`` module - Enabled payroll entries in Payroll >…
Currently, an error was occurring when a user tried to reverse a journal entry by following these steps: - Install ``Accounting`` and ``Payroll`` module - Enabled payroll entries in Payroll > Configuration > Settings. - Created a new employee and its corresponding contract in payroll > Create a bank account and enable ``Send Money`` in ``Private Information`` - In ``Contract`` change state from `New` to `Running` > Click on `Payslips` - Computed the payslip > generated draft journal entries > add lines in journal items and click `Pay` in payslip. - Go to ``Journal Entry`` and make a ``Reverse Entry``. ValueError: Expected singleton: res.currency() The issue occurs at [1] because, when a user makes a payment from a payslip after posting journal entries, the ``currency_id`` is not available. [1] - https://github.com/odoo/odoo/blob/0583db332efdc884975da1a074c91981d2865c9d/addons/account/wizard/account_payment_register.py#L972 This commit will fix the above issue by providing default company currency when currency is not available. sentry-6207053954
This fix prevents the point-of-sale scale service from showing an error when a weighing scale is not connected. It improves reliability for stores using POS IoT devices and backports the correction to the 18.0 version.
Original PR description
During the forward port of the scale certification PR (#75269), an issue was found where the scale service would throw an error when the scale wasn't connected. This doesn't cause any issues in 18.0 so wasn't caught in the original PR - this PR is backporting the fix to 18.0.
The ISO20022 payment file generation has been corrected so batch payment XML better matches bank requirements. This helps avoid rejected vendor payment files, including for banks expecting the newer ISO20022 structure.
Original PR description
Ensure that the ISO20022 payment method is enabled. Make a payment (ex, for a vendor bill) with the ISO20022 payment method. Make a Batch payment for the ISO20022 payment method. Add the payment, then validate the batch payment. Exact steps (or video) of correct behavior (on runbot): N/A Attachment: Technical guidelines for the customer's bank, NatWest. Other info : The generated XML file is poorly formatted in several ways. First, the element <BIC> should be <BICFI>. MKS found some documentation on a previous ticket (from ISO20022 website?) that mentions this change is required for pain.001.001.09. Second, the element <ReqdExctnDt> must have the <Dt> sub-elements within its contents. It appears that both of these changes were made for the SEPA payment module, but not for the ISO20022 module. opw-4557951
Appointment validation pages now show assigned resources and attendee lists correctly based on the appointment display settings. This prevents missing or misplaced information when confirming bookings, especially for automatically assigned time slots or calendar meetings without an appointment type.
Original PR description
Purpose ======= Fix the display of the resource on the validation page when in 'time_auto_assign'. Specification ============= If the apt type setting is: - 'time_auto_assign' and 'no_picture': resource(s) not displayed - 'time_auto_assign' and 'picture': if one resource -> displayed on the right with its picture if more than one resource -> displayed in the validation details related commit: odoo/enterprise@9fe0c7ab9f3276e9a79ba79831660ee0d7787582 Task-4395325
The accounting export for journal items now works correctly again after a recent update caused failures. This helps accounting teams reliably export the data they need for reporting and analysis.
Original PR description
This FW Port https://github.com/odoo/enterprise/pull/80368 introduced a bug at the export of amls: - `rpc` is not bind to `ExportDataDialog` anymore -> we import it instead - since 18.0 -> `get_fields` get a domain in its parameters opw-4622877
Miscellaneous changes
To reproduce: - on a record of a model that inherits mail.activity.mixin, create a new Activity of a 'meeting' type - open calendar - create 2 meetings on the calendar - only the second one is attached to the resource record's chatter Problem: When the calendar view is opened, the mail.activity record has already been created, and creating the calendar.event record writes to its calendar_event_id field with the id of the newly created calendar.event. Creating a second calendar.event reco
Original PR description
To reproduce: - on a record of a model that inherits mail.activity.mixin, create a new Activity of a 'meeting' type - open calendar - create 2 meetings on the calendar - only the second one is…
To reproduce: - on a record of a model that inherits mail.activity.mixin, create a new Activity of a 'meeting' type - open calendar - create 2 meetings on the calendar - only the second one is attached to the resource record's chatter Problem: When the calendar view is opened, the mail.activity record has already been created, and creating the calendar.event record writes to its calendar_event_id field with the id of the newly created calendar.event. Creating a second calendar.event record in the same view does not create a second mail.activity record, instead it overwrites the calendar_event_id field of the original mail.activity record, overwriting the original calendar.event. This also causes the first calendar.event record to no longer have any associated mail.activity record in its activity_ids field. Solution: In the calender.event create() method, modify the condition of whether a new mail.activity record should get created so that it makes a new mail.activity record if the linked mail.activity record already has a calender_event_id opw-4500292 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197761 Forward-Port-Of: odoo/odoo#196719
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.1 Forward-Port-Of: odoo/odoo#200352
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.1 Forward-Port-Of: odoo/odoo#200352
### Issue: MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split. ### Steps to reproduce: - Create 2 storable products tracked by SN: FP and COMP - Create a BOM for you final product FP: - 1 x COMP - 1 operation with an instruction of type "Register Consumed Materials
Original PR description
### Issue: MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component…
### Issue:
MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.
### Steps to reproduce:
- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
- 1 x COMP
- 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.
### Cause of the issue:
Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of the move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:
### Fix:
Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.
### Note:
We also tried 2 other fixes of the issue but aborted these other ideas:
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225
Enterprise: https://github.com/odoo/enterprise/pull/79591
opw-4558900
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#198599
Forward-Port-Of: odoo/odoo#198175Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line. Step to produce: - Install the ```hr_expense``` module. - Create an expense, add a category, and click on the `Split Expense` button. - Delete all expenses from the split expense line, and press the data-hotkey `ALT + Q` to click on the `Split Expense` button to split expenses. ```IndexError: tuple index out of range``` This occurs becau
Original PR description
Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line. Step to produce: - Install the ```hr_expense```…
Currently, an error occurs when users press the data-hotkey 'ALT + Q' to split expense and any expense is not available in the split expense line. Step to produce: - Install the ```hr_expense``` module. - Create an expense, add a category, and click on the `Split Expense` button. - Delete all expenses from the split expense line, and press the data-hotkey `ALT + Q` to click on the `Split Expense` button to split expenses. ```IndexError: tuple index out of range``` This occurs because the system attempts to access the first expense from the split expense line [1], but expenses are not available. Link [1]: https://github.com/odoo/odoo/blob/280b762e7cd1b3d9a578bbae60cbb9b137ee5ce5/addons/hr_expense/wizard/hr_expense_split_wizard.py#L36 To resolve this issue, Disable a 'Split Expense' button after simply adding a `disabled` attribute on it. Sentry-6015854429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198745 Forward-Port-Of: odoo/odoo#190323
**Steps to reproduce:** - Install Accounting - Create an included tax: * Amount: 20% * Included in Price: [enabled] * Affect Base of Subsequent Taxes: [disabled] - Create a retention tax: * Amount: -5% * Included in Price: [disabled] * Affect Base of Subsequent Taxes: [disabled] * Base Affected by Previous Taxes: [enabled] - Create an invoice: * Price: 120.0 * Taxes: [Both created taxes] **Issue:** The base amount used to compute the retention tax is including
Original PR description
**Steps to reproduce:** - Install Accounting - Create an included tax: * Amount: 20% * Included in Price: [enabled] * Affect Base of Subsequent Taxes: [disabled] - Create a retention tax: * Amount: -5% * Included in Price: [disabled] * Affect Base of Subsequent Taxes: [disabled] * Base Affected by Previous Taxes: [enabled] - Create an invoice: * Price: 120.0 * Taxes: [Both created taxes] **Issue:** The base amount used to compute the retention tax is including the amount of the included tax (i.e. 120.0), but it should not (i.e. 100.0) as the included tax doesn't affect the base of subsequent taxes. **Cause:** When "special_mode" is False, all excluded taxes following an included tax have their base affected by the included tax. opw-4451617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197512
Steps to reproduce: - Create a Vendor Bill with 10% ND tax - Post - In 'Edi Documents' tab download e-invoice Issue: `CuotaIVADeducible` element show the full tax amount, even if the tax has been set to non deductible opw-4582712 Forward-Port-Of: odoo/odoo#200157
Original PR description
Steps to reproduce: - Create a Vendor Bill with 10% ND tax - Post - In 'Edi Documents' tab download e-invoice Issue: `CuotaIVADeducible` element show the full tax amount, even if the tax has been set to non deductible opw-4582712 Forward-Port-Of: odoo/odoo#200157
This commit will revert the change done in this commit: https://github.com/odoo/odoo/commit/49217dc494d01326bb8a4221bbfa99d9c02aeec5 Because a majority of companies in Saudi Arabia instead provide services locally to Non-Resident Individual Customers, thereby necessitating the issuance of a Simplified Tax Invoice. With our recent change, those non-resident individual contacts are now being issued a Standard Export Tax Invoice, which is incorrect. task-4611062 --- I confirm I have si
Original PR description
This commit will revert the change done in this commit: https://github.com/odoo/odoo/commit/49217dc494d01326bb8a4221bbfa99d9c02aeec5 Because a majority of companies in Saudi Arabia instead provide services locally to Non-Resident Individual Customers, thereby necessitating the issuance of a Simplified Tax Invoice. With our recent change, those non-resident individual contacts are now being issued a Standard Export Tax Invoice, which is incorrect. task-4611062 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199825 Forward-Port-Of: odoo/odoo#199734
Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#198993
Original PR description
Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#198993
**Behavior before PR:** When removing format using removeFormat button, font-size style is not getting removed from formatted text. This happens because in `removeFormat` method `editor.document.execCommand('removeFormat')` fails to remove styles applied through classes. To remove these styles, font-size classes should be removed. **Behavior after PR is merged:** Now font-size related classes will be removed when removing format and font-size style will be removed from formatted text.
Original PR description
**Behavior before PR:**
When removing format using removeFormat button, font-size style is not getting removed from formatted text. This happens because in `removeFormat` method `editor.document.execCommand('removeFormat')` fails to remove styles applied through classes. To remove these styles, font-size classes should be removed.
**Behavior after PR is merged:**
Now font-size related classes will be removed when removing format and font-size style will be removed from formatted text.
task-4526026
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195979Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#200123 Forward-Port-Of: odoo/odoo#198994
Original PR description
Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/odoo#200123 Forward-Port-Of: odoo/odoo#198994
Issue: When archiving a contract the employee form view does not update the first contract. Cause: The first contract computation is not trigger when archiving a contract. expected behavior: When archiving a contract the first contract should be recomputed. Fix: Add the active field to the depends method of the contract. task-3745594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197146 Forward-Port-Of: odo
Original PR description
Issue: When archiving a contract the employee form view does not update the first contract. Cause: The first contract computation is not trigger when archiving a contract. expected behavior: When archiving a contract the first contract should be recomputed. Fix: Add the active field to the depends method of the contract. task-3745594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197146 Forward-Port-Of: odoo/odoo#158366
It is possible to add note / section lines with empty label (`name`). Currenlty we then print placeholder values: * section: `A section title` * note: `A note, whose content usually applies to the section or product above.` (They were added to be displayed in studio; see commit 2fbf17d235fb7c92914f0a3b6a3ce954c27f3032.) After this commit the placeholders will not be printed on PDFs anymore. (But they will still be shown in studio.) task: none Forward-Port-Of: odoo/odoo#200154
Original PR description
It is possible to add note / section lines with empty label (`name`). Currenlty we then print placeholder values: * section: `A section title` * note: `A note, whose content usually applies to the section or product above.` (They were added to be displayed in studio; see commit 2fbf17d235fb7c92914f0a3b6a3ce954c27f3032.) After this commit the placeholders will not be printed on PDFs anymore. (But they will still be shown in studio.) task: none Forward-Port-Of: odoo/odoo#200154
In commit 2f62d5c0d78371be70586c79cb2b5931e733b042 the issue was fixed for some cases. But the problem remains in some other cases. In the original fix a special context value was added to the reconciliation of some lines. It prevents the creation of cash basis related moves for that reconciliation. This commit adds the same context to all the other reconciliations in the same function as the original reconciliation. Reproduce on runbot for l10n_mx for bank payment method 1. Install l1
Original PR description
In commit 2f62d5c0d78371be70586c79cb2b5931e733b042 the issue was fixed for some cases. But the problem remains in some other cases. In the original fix a special context value was added to the…
In commit 2f62d5c0d78371be70586c79cb2b5931e733b042 the issue was fixed for some cases.
But the problem remains in some other cases.
In the original fix a special context value was added to the reconciliation of some lines. It prevents the creation of cash basis related moves for that reconciliation. This commit adds the same context to all the other reconciliations in the same function as the original reconciliation.
Reproduce on runbot for l10n_mx for bank payment method
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS
* Payment method: Bank on journal BNK1
* Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Bank payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
```
* 1 entry in the POS journal (order)
base: | - 100.0 $
tax: | - 16.0 $
receivable: | + 116.0 $
* 1 entry in the BNK1 journal (bank / payment)
bank: | + 116.0 $
receivable: | - 116.0 $
* 1 entry in the CBMX journal (caba)
base: | - 100.0 $
base: | + 100.0 $
tax: | - 16.0 $
tax: | + 16.0 $
* 1 entry in the EXCH journal (exchange difference)
for the cash basis rounding difference
tax: | - 16.0 $
tax: | + 16.0 $
```
opw-4355124
Forward-Port-Of: odoo/odoo#199194Following the fixes - https://github.com/odoo/odoo/commit/ce92dedea0fd3cdc73da6366c20b8052bb04f7e9 & https://github.com/odoo/odoo/commit/4dc901e77dc7e2873a94ea3a541450fc9fb2eb5e Investing more into the issues, we found out that E-waybill portal, doesn't allow generation of E-waybill as Inwards (Tax Invoice) type for Sales Return, Only Challan Type is accepted it means that the Sales Return, E-waybill should be generated by the E-waybill on Stock/Inventory. Not through the Invoice/Account App.
Original PR description
Following the fixes - https://github.com/odoo/odoo/commit/ce92dedea0fd3cdc73da6366c20b8052bb04f7e9 & https://github.com/odoo/odoo/commit/4dc901e77dc7e2873a94ea3a541450fc9fb2eb5e Investing more into the issues, we found out that E-waybill portal, doesn't allow generation of E-waybill as Inwards (Tax Invoice) type for Sales Return, Only Challan Type is accepted it means that the Sales Return, E-waybill should be generated by the E-waybill on Stock/Inventory. Not through the Invoice/Account App. This commit intends to do a soft block for generation of E-waybill through Sales Credit Note task-4441603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192090
Before this commit, if a user deletes a message before the recipient sees it and the recipient tries to click on "1 new message", they get a traceback. Steps to reproduce: 1. Have a long conversation between user A and user B 2. Scroll up with user B 3. Send message with user A 4. Delete said message 5. User B clicks on new message banner -> traceback This commit fixes the issue by only showing the unread banner if there is an unread message. task-4240887 Forward-Port-Of: odoo/odo
Original PR description
Before this commit, if a user deletes a message before the recipient sees it and the recipient tries to click on "1 new message", they get a traceback. Steps to reproduce: 1. Have a long conversation between user A and user B 2. Scroll up with user B 3. Send message with user A 4. Delete said message 5. User B clicks on new message banner -> traceback This commit fixes the issue by only showing the unread banner if there is an unread message. task-4240887 Forward-Port-Of: odoo/odoo#197599
The SAT added a new type of transport figure "Integrante de Coordinados". This should be available for the carta porte. task-4082068, previous pr for v15 67897 Forward-Port-Of: odoo/enterprise#77932 Forward-Port-Of: odoo/enterprise#73195
Original PR description
The SAT added a new type of transport figure "Integrante de Coordinados". This should be available for the carta porte. task-4082068, previous pr for v15 67897 Forward-Port-Of: odoo/enterprise#77932 Forward-Port-Of: odoo/enterprise#73195
Problem: When the user views the SLA tickets through the action, action_view_success_rate, they will only see successful SLA tickets after removing the 'SLA success' filter. Purpose: The user should be able to see all SLA tickets, successful and failed, after removing filters. Steps to Reproduce on Runbot: 1. Install Helpdesk 2. Navigate to Helpdesk and click on 'Success Rate' for Customer Care team 3. Remove filter 'SLA success' 4. Observe that failed SLA tickets doesn't display op
Original PR description
Problem: When the user views the SLA tickets through the action, action_view_success_rate, they will only see successful SLA tickets after removing the 'SLA success' filter. Purpose: The user should be able to see all SLA tickets, successful and failed, after removing filters. Steps to Reproduce on Runbot: 1. Install Helpdesk 2. Navigate to Helpdesk and click on 'Success Rate' for Customer Care team 3. Remove filter 'SLA success' 4. Observe that failed SLA tickets doesn't display opw-4601178 Forward-Port-Of: odoo/enterprise#80087
Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhanc
Original PR description
Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhancing portability for easy customization. task-3429403 Forward-Port-Of: odoo/enterprise#80524 Forward-Port-Of: odoo/enterprise#56158
In this commit [e366986](https://github.com/odoo/enterprise/commit/e36698683d984d8a1761809b85b591084ff37ed9), we used a rpc call in a function, but as the rpc is no more a service but a function, this is broken in this version. This commit fix the rpc call to use it as a function and not a service. no-task Forward-Port-Of: odoo/enterprise#80596
Original PR description
In this commit [e366986](https://github.com/odoo/enterprise/commit/e36698683d984d8a1761809b85b591084ff37ed9), we used a rpc call in a function, but as the rpc is no more a service but a function, this is broken in this version. This commit fix the rpc call to use it as a function and not a service. no-task Forward-Port-Of: odoo/enterprise#80596
### Issue: MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split. ### Steps to reproduce: - Create 2 storable products tracked by SN: FP and COMP - Create a BOM for you final product FP: - 1 x COMP - 1 operation with an instruction of type "Register Consumed Materials
Original PR description
### Issue: MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component…
### Issue:
MO with a tracked finished product are actually splited at validation. However, the qties of the MO are usually set by default to fulfill the maximal demand. As such, component registrations performed form the shopfloor might be completely override by the MO split.
### Steps to reproduce:
- Create 2 storable products tracked by SN: FP and COMP
- Create a BOM for you final product FP:
- 1 x COMP
- 1 operation with an instruction of type "Register Consumed Materials" for COMP
- Put 2 serial numbers in WH/Stock for COMP: SN01, SN02
- Create and confirm an MO for 2 units of FP using that BOM
> SN01 and SN02 should be reserved on the move raw
- Go to the shopfloor to the MO
- Click on Register component SN02 > Validate
- Click on the [+] button of the register Production
- Mark the MO as Done > Close Production
> You trigger a consumption warning dialog telling you that you registered more consumed quantity than expected (2 instead of 1) This dialog should not appear in the first place as you registered only 1 unit but suppose it is ok and continue
- Click on "Set quantities and validate"
- Go back to your MO in the back end
#### > It was closed using SN01 rather than the SN you registered.
### Cause of the issue:
Confirming the MO confirmed the move raw and a reservation was made for 2 units as the MO is not splitted yet. However, since the final product is tracked this MO will end up splitted. When you register consumption, the serial number of one of the move line related to the raw move will be updated and the line will be picked:
https://github.com/odoo/enterprise/blob/d4ff42fbcfa3dd297c6cb838b5b03955f12f02a4/mrp_workorder/models/quality.py#L519-L525 However, since at least one of the move line of hte move raw is picked the move its self will become picked:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L208-L212 This is problematic as picked picked move by pass the set_qty_producing so from now if you were to adapt the qty producing of the MO you would not affect the quantity of the raw move (which is currently at 2: one unpicked move line with SN01 and one picked with SN02): https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1218-L1228 Finally, when you click on the Close production, a `_split_productions` process will be started and adpat the demand of the move raw to 1: https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1831-L1832 Since the quantity set on the move exceeds this new demand the consumption warning. Note that at this point the backorders of the initial MO were already created and confirm without you dialog to be resolved so that the reservations of these splitted MO could not reserve the SN01 that is still used by your move. Finally, when you "Set quantities and validate" it will adpat the quantity and unreserve the picked move line as this decrease process does not prioritise to unlink unpicked move lines first:
### Fix:
Since registration process through shopfloor and barcode are expected to create picked move lines which will adpat the picked state of the move and since picking the move will automatically pick all the move line, a move line that is not picked in a picked move is a move line that is not expected to be kept. We therefore unlik these move_lines before adapting the demand of the move_raws in the split production.
### Note:
We also tried 2 other fixes of the issue but aborted these other ideas:
1) try to keep only picked move line at the Validation of the registration component process but this change of behavior was aborted since if instead of clicking on validate you click on "Continue consumption and then on the top right cross button", you would technically have registered only the first SN but you would fall in the situation as above and trigger the same issue.
2) Adapt the condition of that makes a move raw by pass the _set_qty_producing:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1219-L1221 Since the move is picked for the wrong reason we would instead use: `all(ml.pikced for ml in move.move_line_ids)`
However, this would also require to change the process decrease to unreserve picked move last here:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/stock/models/stock_move.py#L361-L365 Changing the loop to
`reversed(move.move_line_ids.sorted(lambda ml: (not ml.picked, ml.id))` And this would not solve the issue starting post 17.0 since we would still bypass the set_qty producing on the next lines:
https://github.com/odoo/odoo/blob/f9e362c45414001077738c2462e9e030f865ec36/addons/mrp/models/mrp_production.py#L1223-L1225
Community: https://github.com/odoo/odoo/pull/198175
opw-4558900
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#79851
Forward-Port-Of: odoo/enterprise#79591Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/enterprise#80654 Forward-Port-Of: odoo/enterprise#80034
Original PR description
Until 18.0 [1], test classes should not inherit from other test classes which themselves contain tests. When this happens, the tests of the parent class are run for every class that inherits from it. We fix occurrences of this for social marketing apps. A naive detection script is available on the pad of the related task. [1]: 6dc96811c24ec4c97b8fbd2489aef6d4f061ac03 task-3792478 Forward-Port-Of: odoo/enterprise#80654 Forward-Port-Of: odoo/enterprise#80034
Problem ---------- Amendments to PAYE computation from 27 Dec 2024 Objective ---------- Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024 Solution ---------- Adapt rules and parameters task-4457038 Forward-Port-Of: odoo/enterprise#80715 Forward-Port-Of: odoo/enterprise#79582
Original PR description
Problem ---------- Amendments to PAYE computation from 27 Dec 2024 Objective ---------- Correct the Kenya Payroll computation with the new rules from the 27 Dec 2024 Solution ---------- Adapt rules and parameters task-4457038 Forward-Port-Of: odoo/enterprise#80715 Forward-Port-Of: odoo/enterprise#79582
…versing Steps to reproduce: - In settings, set a default "Default invoice transaction code" and "Default refund transaction code" - Create an invoice with an invoice line and post it - Reverse it Issue: - The intrastat code will be the one from the invoice (and not the default refund one) Cause: When copying the lines we keep the one from the invoice Solution: Delete the default values when copying the data so the compute is triggered correctly which will set the correct value
Original PR description
…versing Steps to reproduce: - In settings, set a default "Default invoice transaction code" and "Default refund transaction code" - Create an invoice with an invoice line and post it - Reverse it Issue: - The intrastat code will be the one from the invoice (and not the default refund one) Cause: When copying the lines we keep the one from the invoice Solution: Delete the default values when copying the data so the compute is triggered correctly which will set the correct value opw-4417566 Forward-Port-Of: odoo/enterprise#79267
This PR adapts access rights so that Worldline folder 'ctep' can be deleted by 'delete_iot_handlers' Forward-Port-Of: odoo/enterprise#80283
Original PR description
This PR adapts access rights so that Worldline folder 'ctep' can be deleted by 'delete_iot_handlers' Forward-Port-Of: odoo/enterprise#80283
Recently, the Kenyan support team has been reporting a temporary increase in the number of timeouts when sending invoices to eTIMS, as well as associated issues (e.g. timed-out invoices turning out to be actually registered on eTIMS' side) which warrant further investigation. In order to reduce the number of timeouts and help diagnose (1) which API endpoints are timing out (which can tell us where we should implement retry mechanisms) and (2) whether the timed-out invoices are always or somet
Original PR description
Recently, the Kenyan support team has been reporting a temporary increase in the number of timeouts when sending invoices to eTIMS, as well as associated issues (e.g. timed-out invoices turning out to be actually registered on eTIMS' side) which warrant further investigation. In order to reduce the number of timeouts and help diagnose (1) which API endpoints are timing out (which can tell us where we should implement retry mechanisms) and (2) whether the timed-out invoices are always or sometimes registered on eTIMS' side, we: - Increase the timeout of eTIMS calls to 2 minutes; - Log every timeout in the server logs; and - Log every invoice timeout in the invoice chatter. task-4624257 Forward-Port-Of: odoo/enterprise#80672