Daily updates from Odoo
Navigate
Branch
Monday, January 6, 2025
81 changes
3 changes
Miscellaneous changes
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite rep
Original PR description
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite report. task-4317649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188476
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix th
Original PR description
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix the alignment issue. task-4294780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186532
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size:
Original PR description
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center…
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size: - for 100 pixels: 100 / (32 * mm) => 1.012… - for 256 pixels: 256 / (32 * mm) => 2.822… - for 400 pixels: 400 / (32 * mm) => 4.409… But in the code, the zoom is just hardcoded to mm (~2.83) which corresponds to a barcode size of mm * 32 * mm => 257.127 pixels which is kind of good enough for 256 pixels, but wrong for most other size. In base code we only use 256 x 256 pixels so this is not much of an issue unless someone want to use it for something else. Fix: With this commit, we apply the Drawing zoom (on which we have the QrCodeWidget) to the ch_cross image. Note: Without the fix, the added test only fail on the third assertion for each loop iteration, the farer we are from 257x257 pixels the bigger the error is, for example for 256x256: Result: (38.45140, 38.45140, 52.25725984251969, 52.25725984251969) Expected: (38.28288, 38.28288, 52.02823111111111, 52.02823111111111) opw-4307177 PR NOTE: this could be merged in an higher version, and we could also just not fix this since as far as I can tell, we only need to support 256x256 and with and without the fix there is just one pixel of difference in this case.  Forward-Port-Of: odoo/odoo#192091
13 changes
Miscellaneous changes
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default C
Original PR description
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines. …
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default Company;  - Log in as that new user; - Try create a new product through a Customer Invoice or a Vendor Bill. **Cause:** The `Accountant` role itself has no right on products. **Fix:** Reset a previously removed (february 2023 (saas-16.2) odoo/odoo@512574861691f425ec6a17f20fe4b586bb88a299) access right on `product_template` for group `group_account_manager`.  **Note:** This PR replaces https://github.com/odoo/enterprise/pull/75453 after discussion with reviewer. opw-4293151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190360
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size:
Original PR description
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center…
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size: - for 100 pixels: 100 / (32 * mm) => 1.012… - for 256 pixels: 256 / (32 * mm) => 2.822… - for 400 pixels: 400 / (32 * mm) => 4.409… But in the code, the zoom is just hardcoded to mm (~2.83) which corresponds to a barcode size of mm * 32 * mm => 257.127 pixels which is kind of good enough for 256 pixels, but wrong for most other size. In base code we only use 256 x 256 pixels so this is not much of an issue unless someone want to use it for something else. Fix: With this commit, we apply the Drawing zoom (on which we have the QrCodeWidget) to the ch_cross image. Note: Without the fix, the added test only fail on the third assertion for each loop iteration, the farer we are from 257x257 pixels the bigger the error is, for example for 256x256: Result: (38.45140, 38.45140, 52.25725984251969, 52.25725984251969) Expected: (38.28288, 38.28288, 52.02823111111111, 52.02823111111111) opw-4307177 PR NOTE: this could be merged in an higher version, and we could also just not fix this since as far as I can tell, we only need to support 256x256 and with and without the fix there is just one pixel of difference in this case.  Forward-Port-Of: odoo/odoo#192091
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite rep
Original PR description
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite report. task-4317649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188476
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Original PR description
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob
Original PR description
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L384-L388 This leads to the above traceback when accessing the product template id from an empty dict from the below line. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L395 sentry-6173505059 Forward-Port-Of: odoo/odoo#191761
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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
Original PR description
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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#191295
Since [1], when an extra menu is displayed due to the top menu exceeding its maximum width, the active class is no longer applied correctly. This issue was introduced during the conversion from jQuery to vanilla JavaScript. Steps to reproduce: - Enter the Website in edit mode. - Navigate to Site > Menu Editor. - Add several menu items until the menu exceeds its maximum width. - Ensure that one of the items in the extra menu redirects to "Contact Us". - Click on the "Contact Us" menu it
Original PR description
Since [1], when an extra menu is displayed due to the top menu exceeding its maximum width, the active class is no longer applied correctly. This issue was introduced during the conversion from jQuery to vanilla JavaScript. Steps to reproduce: - Enter the Website in edit mode. - Navigate to Site > Menu Editor. - Add several menu items until the menu exceeds its maximum width. - Ensure that one of the items in the extra menu redirects to "Contact Us". - Click on the "Contact Us" menu item. - Open the dropdown menu (via the "+" icon) and observe that the "Contact Us" entry is not highlighted. This commit resolves the problem. [1]: https://github.com/odoo/odoo/commit/0de634965a0dec4470b30154f3722a1e83b0e866 task-4428845 opw-4383641 Forward-Port-Of: odoo/odoo#192164 Forward-Port-Of: odoo/odoo#191548
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
Original PR description
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I co
Original PR description
to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192376 Forward-Port-Of: odoo/odoo#191552
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-O
Original PR description
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191137
Description of the issue/feature this PR addresses: - A recent change in the contact's list view introduces a small bug, due to which, now a blank column for display name appears. commit ensure correct attribute value for list view. - [commit](https://github.com/odoo/odoo/commit/76aa55dbfcce535d645270448b096ed8cfede104) that introduces issue. Current behavior before PR: - a blank column is visible  that introduces issue. Current behavior before PR: - a blank column is visible  Desired behavior after PR is merged: - `display_name` field is hidden properly.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191887
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191205
Original PR description
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191205
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_tem
Original PR description
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the…
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_template.py#L186-L188 In the `RecordSet`'s context, `bin_size=True`, so accessing `image_<size>` returns a size instead of a binary. `_compute_can_image_1024_be_zoomed` calls `tools.is_image_size_above` with this binary size, while the method expects the full base64 encoded image. Ultimately, this causes `base64.b64decode` to crash with the above error. **FIX** Update the `RecordSet`'s context to `bin_size=False`. Accessing `image_<size>` from the `RecordSet` will then return the full binary instead of the size. **NOTES** In versions <17.0, read and write were done in separate network calls causing the recompute to happen during the flush of the write, which doesn't have `bin_size=True` in the context. Because the field is stored, the read will not cause a recompute and thus avoids any error. In >=17.0, because the read occurs before the flush, and the write has invalidated the field, the recompute will occur with the context of the read (`bin_size=True`), causing the issue. opw-4413647 Forward-Port-Of: odoo/odoo#192047
12 changes
Enhancements to existing features
Combo products are now shown with a clearer parent-child layout on preparation displays, making it easier for staff to see which items belong together. Related combo lines also stay synchronized when order changes are handled, reducing confusion and helping kitchen or preparation teams process orders consistently.
Original PR description
- Indent child combo product in prepatration display - Implemented synchronization between combo lines and parent orderlines for consistent handling of the `skip_change` state across all related lines. - Added a parent-child connection for orderlines in preparation display so that we can check the combo parent only to send the combo-lines to the next change and vice versa. Task ID: 4180121 Related: https://github.com/odoo/odoo/pull/180847
The Helpdesk Tickets Analysis report now lets users click report data to open the matching support tickets directly. This makes it faster for teams to move from high-level reporting to the underlying tickets they need to review or act on.
Original PR description
related: https://github.com/odoo/odoo/pull/187262 task-4334996
Code cleanup and technical improvements
The Point of Sale system’s internal data handling has been reorganized to make the code easier to maintain and extend. This should not change day-to-day behavior for users, but it helps future updates across related Point of Sale features be delivered more reliably.
Original PR description
In this PR, we refactor the related_models module. There is now `Models` class that contains all the models. Also, a `CRUD` class is introduced to represent each model. We can get the model records from the `CRUD` methods. This refactoring is introduced so that the `Models` and the `CRUD` methods don't need to accept the instances as first param. `this` becomes usable in the `Models` and `CRUD` methods. Related: https://github.com/odoo/odoo/pull/189500
Miscellaneous changes
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#75767 Forward-Port-Of: odoo/enterprise#73742
Original PR description
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#75767 Forward-Port-Of: odoo/enterprise#73742
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss" - Create a menu item in the action of the report - Open the report - Press the filter "Unfold All" - Press the "PDF" button -> Results: the pdf has no line unfolded while they should (the web UI works as expected) Reason of the issue
Original PR description
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated,…
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss" - Create a menu item in the action of the report - Open the report - Press the filter "Unfold All" - Press the "PDF" button -> Results: the pdf has no line unfolded while they should (the web UI works as expected) Reason of the issue: In the dispatch_report_action() function, the get_options() was wrong and unnecessary. This function is first called on the first section, then called on the composite report with its own options. This led to use the options of the composite report which does not have the filter_unfold_all field set to True. This also handles the case where a composite report has reports A and B, A having the filter_unfold_all while B doesn't have it. The expected result when printing it is that only report A has unfolded lines. task-4317649 Forward-Port-Of: odoo/enterprise#74826
- When the type of identification of vendor is 'RUC' the code should be 01 because is purchase - The "tipoComprobante" tag has to be '41' instead '01' according the schema of DIMM (government's software to validate ATS report) Forward-Port-Of: odoo/enterprise#73194
Original PR description
- When the type of identification of vendor is 'RUC' the code should be 01 because is purchase - The "tipoComprobante" tag has to be '41' instead '01' according the schema of DIMM (government's software to validate ATS report) Forward-Port-Of: odoo/enterprise#73194
Currently, An error occurs when reloading the DIAN configuration in an account journal to obtain the security token of a certificate, if no certificate is available. Step to produce: - Install the `l10n_co_dian` module. - Navigate to Settings and click on Certificates under the Certificates and Keys section. - And delete a 'Demo DIAN Certificate'. - Open any Journals and click on a 'Reload DIAN configuration'. `IndexError: tuple index out of range` The error occurs because the sys
Original PR description
Currently, An error occurs when reloading the DIAN configuration in an account journal to obtain the security token of a certificate, if no certificate is available. Step to produce: - Install the `l10n_co_dian` module. - Navigate to Settings and click on Certificates under the Certificates and Keys section. - And delete a 'Demo DIAN Certificate'. - Open any Journals and click on a 'Reload DIAN configuration'. `IndexError: tuple index out of range` The error occurs because the system attempts to access the certificate's token from a company at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/a354a19060338084df35a14ed7f21defc3c05c11/l10n_co_dian/xml_utils.py#L123 To resolve this issue, Raise a validation error if a certificate is not found when the system attempts to retrieve its security token. Sentry-6165073693 Forward-Port-Of: odoo/enterprise#76316 Forward-Port-Of: odoo/enterprise#76052
Forward-Port-Of: odoo/enterprise#76430
Original PR description
Forward-Port-Of: odoo/enterprise#76430
Issue: ==================== - A traceback occurred when attempting to print the session report from the reporting menu. - The issue was caused by unused code related to pro forma orders left over from the refactoring in version 17.0. Fix: ==================== - Removed the unused code related to pro forma orders. - Ensured the session report can be printed without errors. Task-4438550 Forward-Port-Of: odoo/enterprise#76428 Forward-Port-Of: odoo/enterprise#76285
Original PR description
Issue: ==================== - A traceback occurred when attempting to print the session report from the reporting menu. - The issue was caused by unused code related to pro forma orders left over from the refactoring in version 17.0. Fix: ==================== - Removed the unused code related to pro forma orders. - Ensured the session report can be printed without errors. Task-4438550 Forward-Port-Of: odoo/enterprise#76428 Forward-Port-Of: odoo/enterprise#76285
Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong. Forward-Port-Of: odoo/enterprise#76425
Original PR description
Fix a small issue with the test where the batch is created before the freeze time, causing the batch date & name to be wrong. Forward-Port-Of: odoo/enterprise#76425
Fix division by 0 and some UI Forward-Port-Of: odoo/enterprise#75916
Original PR description
Fix division by 0 and some UI Forward-Port-Of: odoo/enterprise#75916
Before this commit: ====================== - HTTP errors were not handled for UrbanPiper requests. - Calling `response.json()` raise a traceback After this commit: ====================== - Enhanced error handling using `raise_for_status()` to notify users of any errors. - Added a check for `fiscal_position` during configuration. task-4447233 Forward-Port-Of: odoo/enterprise#76436
Original PR description
Before this commit: ====================== - HTTP errors were not handled for UrbanPiper requests. - Calling `response.json()` raise a traceback After this commit: ====================== - Enhanced error handling using `raise_for_status()` to notify users of any errors. - Added a check for `fiscal_position` during configuration. task-4447233 Forward-Port-Of: odoo/enterprise#76436
52 changes
Enhancements to existing features
Appointment sharing options and category names have been renamed to be easier to understand, such as “Propose Slots,” “Specific Slots,” and “Shared Calendar.” A new Share button on appointment cards lets users open the link-sharing dialog directly, reducing extra steps when sending appointment links.
Original PR description
Purpose ======= Rename Share Availabilities's Dropdown Menus as following: - Select Dates → Propose Slots - Any Time → Share Calendar Rename Appointment Categories Values as following: - Custom → Specific Slots - Recurring → Regular - Any Time → Shared Calendar Add a 'Share' button on Appointment Type Kanban View, that opens a Custom Link modal to share a appointment link -> Remove 'More Options' button in 'Share Availabilities' form view, as it will covered via a generic button. Task-4221267
Resolved issues and error corrections
Payroll payment reports no longer reject employees with valid Oman IBAN bank accounts. This prevents an incorrect validation error and lets payroll teams generate payment reports for Oman employees normally.
Original PR description
Steps to reproduce: - Create an employe with an oman bank account number - Create a payslip for this employe - Create a payment report Issue: when trying to create a payment report in the payroll app for an employee with an oman bank account number, when creating the payment report an error :"Invalid IBAN for the following employees: .." will raise. Fix: This issue can be fixed by adding the 'om' in the variable _map_iban_template. This ensure that the mapping will be done correctly and the error will not be raised anymore. opw-4312502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue that prevented users from adding product videos through the website sales media manager. Product teams can now attach video URLs without overlapping error messages, improving product page media management.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a product template. 2. Press the "Add Media" button in the "Sale" tab of the product form. 3. Try to add a video by pasting the URL. 4. Pressing "Add" displays multiple error messages, one on top of each other. Issue ----- Impossible to add a video as extra media for a product. Cause ----- The `video_url` field is not loaded by the Kanban view, which is used by the `X2ManyMediaViewer` to display the `product.image`. Therefore, updating the `video_url` caused a series of “ field not found” bugs. Solution -------- Add the `video_url` to the Kanban view of the `product.image` model. opw-4391126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a typo in the state name for Somalia, changing it from “Somalia” to “Somali.” It improves the accuracy of country/state reference data shown to users in Odoo.
Original PR description
Typo in state name (Somalia -> Somali). https://en.wikipedia.org/wiki/Somali_Region task-4453644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The multiple time-off request wizard now only shows time-off types that do not require an allocation, matching behavior from earlier versions. This prevents users from selecting time-off categories that are not valid for bulk requests, reducing mistakes and confusion.
Original PR description
In previous versions, when dealing with multiple time-off requests, only time-off types that do not require allocations were listed for selection. This behavior has been restored by restricting the `holiday_status_id` field to show only non-allocation time-off types in the multi-request wizard. opw-4370090 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manual payment validation now avoids trying to repost accounting entries that are already posted or cancelled. This prevents an unnecessary error and lets users complete the payment validation flow as expected.
Original PR description
Steps to reproduce: 1. Install account 2. Configure the bank journal so it has an account linked to manual payments 3. Go to Customers -> Payments and create a new payment with a fake user and amount…
Steps to reproduce: 1. Install account 2. Configure the bank journal so it has an account linked to manual payments 3. Go to Customers -> Payments and create a new payment with a fake user and amount 4. Confirm the payment. Then Validate the payment. 5. An error shows up: "The entry must be in draft." --- Description of the issue this commit addresses: When trying to validate a payment (marking it as paid), the move linked to the payment is posted but if the move was already posted or cancelled, an error is raised. This is not a desired behavior. --- Desired behavior after this commit is merged: When following the same process, the move is only posted if it is not posted or cancelled yet to make sure it should pass through the posting method. --- Note on the fix: Cancelled is taken into account for safety purposes but since the payment is manual, no move at that point in the code should ever have state == 'cancel'. --- opw-4445889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where inherited views without XML content could fail validation even though that content is optional. It helps prevent unnecessary errors when saving or processing valid view configurations.
Original PR description
Since the arch is not mandatory and the `_combine` method would [assume it is a data node](https://github.com/odoo/odoo/pull/182766), the `_check_xml` for child views should allow an empty arch in the same way. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures project task tour tests wait until description changes are fully saved before moving on. It helps prevent false test failures caused by automated steps running too quickly, improving confidence in project-related quality checks.
Original PR description
When you chain several uses of changeDescriptionContentAndSave() in a tour, you don't necessarily wait for the editor to be actually saved before continuing. So, it always works for the first use but not for the following ones if the tour engine goes too "fast". So this fix add a step in which we make sure that the form is actually saved before continuing. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change temporarily skips an unreliable automated test related to opening the chatter attachment popout across multiple records. It helps keep validation results stable while the underlying race condition is investigated, with no direct change for end users.
Original PR description
Skip because test has race conditions, until we have time to properly fix it. runbot-109795
This change fixes unnecessary reloading of already cached views when users open similar actions, such as scheduling activities from different contacts. It reduces repeated server requests, making the interface feel faster and lowering avoidable system load.
Original PR description
**Steps to reproduce (a bit technical):** 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a…
**Steps to reproduce (a bit technical):** 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a new activity". 4. Notice a call to `get_views` in the Network tab. 5. Click on a different contact activities, and "Schedule a new activity". 6. Notice a new call to `get_views` in the Network tab. **Expected:** The view is already cached, so the webclient should not attempt to load it. **Explanation:** This is likely a regression since f983703d, when the embedded actions were introduced. Now, the `embeddedParentResId` is part of the views cache key, and so we get much fewer cache hits. For most views, there isn't really an `embeddedActionId` set, and yet the `embeddedParentResId` was always set. The later is only used in combination with `embeddedActionId`, so it causes a lot of avoidable cache misses. The solution is to simply set the `embeddedParentResId` only if there's an `embeddedActionId`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Portal users will no longer see a trash icon on message attachments when they do not have permission to delete them. This prevents confusion by only showing actions that the current user can actually perform.
Original PR description
Portal users don't have access to delete attachments created by others. In this case, the trash icon shouldn't be displayed. This PR removes this icon from the attachment of a message when the message is not editable by the current user.
This fixes an issue where a point-of-sale session could not be closed after processing a negative combined payment, such as a refund or negative-quantity sale. The payment account handling now happens at the right point in the process, preventing closure errors while keeping accounting entries correct.
Original PR description
It is impossible to close a session when there is a combined payment amount with a negative value. Steps to reproduce: - Create a new bank payment method and assign as payment method of a pos.config. - Open a session. - Sell with negative amount (e.g. negative quantity) and pay using the new payment method. - [ISSUE] Try to close the session and you will get an error. When a payment amount is negative, we invert the destination and outstanding accounts. Prior to creation of the `account.payment` record, it's possible that an outstanding account is missing. This value can be missing but will be automatically assigned during the creation of the `account.payment` record. So instead of inverting the accounts before creating the `account.payment` record, we now invert them after the creation. OPW: 4317320
This fix makes the Project app's guided tour wait for the newly created subtask before selecting it. It prevents the tour from clicking the wrong item and closing the menu unexpectedly, improving reliability for testing and onboarding flows.
Original PR description
In this commit, we fix the project tour. In the kanban view, we click on the first subtask_list_row but it is not yet (still) the newer subtask. We can therefore click on the first element even though it is not yet created. The DOM re-renders ... and the dropdown menu disappears. By specifying (:contains()) that we want to click on the newer subtask, we wait for it to be created, for it to be rendered and then we click on 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
Point of Sale now prevents the same tracked serial number from being selected in multiple active orders. This helps avoid inventory mistakes and fulfillment issues before orders are finalized.
Original PR description
Steps: - Open the POS. - Add a product with serial number tracking to the order line. - Create a new order. - Add the same product to the new order Issue: - it is possible to select the same serial number that was previously used in another order. Fix: - Hide serial numbers that are being used in active orders Task - 3944652
This fix makes Ctrl+click work properly on links that have styling applied in the HTML editor. Users can now open the intended link even when clicking on styled text or elements inside it, improving editing convenience and reducing confusion.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: Ctrl+clicking on a styled link is ineffective since the target is the styled element. Desired behavior after PR is merged: Ensure the target is the closest anchor tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The tooltip on the cog menu icon has been removed because it could appear over the drop-down menu. This makes the menu easier to use, especially on smaller screens where space is limited.
Original PR description
Before this commit, the tootip was above the drop-down menu. This was particularly annoying for small screens. Task-ID: 4377708 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
Dutch companies can now update the VAT rounding profit and loss accounts in accounting settings. This fixes fields that were incorrectly locked, allowing businesses to align VAT rounding postings with their preferred accounting setup.
Original PR description
Steps to reproduce:
1. Install accounting app
2. Install l10n_nl
3. Select the nl company
4. From settings, under "Default Accounts", the "Dutch VAT Rounding {Profit|Loss} Account" are readonly.
Fix:
Adding `readonly=False` to the `l10n_nl_rounding_difference_loss_account_id` and `l10n_nl_rounding_difference_profit_account_id` fields.
opw-4380635This fixes an unstable automated test in Web Studio by ensuring the test waits for dropdown results before selecting an item. The change helps prevent false test failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
Before this commit, one tour searched in a dropdown and clicked on an item representing a field of a model, without waiting for the dropdown to update. Because tours' behavior change rapidly in an effort to strengthen them, this undeterminism was not detected before. runbot-error-111417 runbot-error-111192
Fixed an error that prevented users from opening the Depreciation Schedule after the journal filter was deactivated. This helps accounting users access asset depreciation reporting reliably, even when optional filters are turned off.
Original PR description
Steps to reproduce: - Activate debug mode - Go to Accounting/Configuration/Accounting Reports/Depreciation Schedule - Deactivate the journals filter - open the depreciation schedule -> Traceback because it can't iterate on None Type object opw-4364589
The Sign completion dialog now displays better on mobile and desktop and presents clearer wording to encourage continued use of the Sign app. The close action has been simplified and can guide signed-out users to the Sign app, reducing confusion after completing a document.
Original PR description
The dialog content and button is off on mobile and the dialog should promote better the sign app. This commit fixes the design to improve the promotion and better render the content on both mobile and desktop. - No more sign up button -> close button redirect to /app/sign if user is not connected - Close button is always secondary - Reviewed wording and design task-4434783 
This update ensures that country-specific Point of Sale setups always load the customer or company records they need when a sales session starts. This prevents receipt and fiscal-printer errors caused by partner records being skipped due to loading limits, especially for Chile, Ecuador, and Italy localizations.
Original PR description
For some localizations, some partners are required at all times for the POS to work properly. Since we restrict the number of loaded partners, we need to explicitly add those required partners to the set of partners loaded at the opening of the pos session. Previous fixes implemented this logic in pos_onfig. However it seems like it would make more sense to handle this from res.partner directly. This PR also proposes a fix of the same type for l10n_it_pos, where the partner associated to the current company must be loaded for propoer fiscal data display on the fiscal printer receipts.
Portal users could encounter an access error when moving between shared document folders, preventing them from reaching project-related documents. The fix ensures shared document links are generated reliably, so authorized portal users can browse the folders they have been given access to.
Original PR description
How to reproduce: - install all project related module (I couldn't find the exact module but it should at least involve the website_document which adds the website_id in the model document) - create a portal user and share the project folder and Marketing folder - connect with the portal user, click on the Marketing folder and then on the project folder You get an access error related to the access of a company record. We solve that issue by getting the base URL in sudo in the compute method of access_url of document. This should not be a problem as we get the access_token of the document in the same line which implies that the user has access to the document for which we want to compute the full URL. Task-4244767
This update fixes automated test data for Mexico electronic invoicing where some dates were still tied to 2024. It helps keep year-sensitive validation checks running reliably without changing customer-facing functionality.
Original PR description
Some 2024 years were encoded in test files.
Features or functions removed from Odoo
This removes old WhatsApp sample-data generation scripts that are no longer used after an internal tooling change. The change keeps the WhatsApp module cleaner and avoids maintaining obsolete internal files, with no expected impact on day-to-day users.
Original PR description
Following 044da127dc977f124c3d0d105dbe3712113f14fb, the populate tool was refactored and doesn't use specific scripts by modules anymore. It seems the populate scripts for the whatsapp module cd7dfa8828cb6b2fb4aa5c35564210e7f4f876da were introduced around the same time the refactoring of the populate itself.
Code cleanup and technical improvements
This change centralizes how country-specific POS setups ensure essential customer records are available when a session opens. It helps avoid POS disruptions caused by partner loading limits while keeping the behavior easier to maintain across affected localizations.
Original PR description
For some localizations, some partners are required at all times for the POS to work properly. Since we restrict the number of loaded partners, we need to explicitly add those required partners to the set of partners loaded at the opening of the pos session. Previous fixes implemented this logic in pos_onfig. However it seems like it would make more sense to handle this from res.partner directly. This PR proposes such a change, where the required partners are being loaded from a newly dedicated function.
Miscellaneous changes
**Current behavior before PR:** Messages posted by visitors in demo data incorrectly displayed the author name as `Odoobot` instead of `Visitor`. This happened because the messages created for visitors in the demo data do not have the `author_id` field explicitly set to `False`, leading the `_message_compute_author()` method to compute the author incorrectly. **Desired behavior after PR is merged:** Messages posted by visitors in demo data correctly display the author name as Visitor
Original PR description
**Current behavior before PR:** Messages posted by visitors in demo data incorrectly displayed the author name as `Odoobot` instead of `Visitor`. This happened because the messages created for visitors in the demo data do not have the `author_id` field explicitly set to `False`, leading the `_message_compute_author()` method to compute the author incorrectly. **Desired behavior after PR is merged:** Messages posted by visitors in demo data correctly display the author name as Visitor. Task-[4420677](https://www.odoo.com/odoo/project/1519/tasks/4420677) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192003
Cancelled order should be ignored by default in the POS order report. Steps to reproduce: ------------------- * Open PoS create an order and go back to the backedn * Open the PoS again and close the PoS, it will cancel the order > Observation: Open PoS order report, it will include the cancelled order, that can be missleading. Why the fix: ------------ We add a new default filter that apply a domain to exclude the cancelled order from the report. opw-4257734 Forward-Port-Of: odo
Original PR description
Cancelled order should be ignored by default in the POS order report. Steps to reproduce: ------------------- * Open PoS create an order and go back to the backedn * Open the PoS again and close the PoS, it will cancel the order > Observation: Open PoS order report, it will include the cancelled order, that can be missleading. Why the fix: ------------ We add a new default filter that apply a domain to exclude the cancelled order from the report. opw-4257734 Forward-Port-Of: odoo/odoo#192377
Changes to the synchronization system to ensure full synchronization every time a PoS writes to a record. This synchronization will not unlink local records in other PoS. Forward-Port-Of: odoo/odoo#191904
Original PR description
Changes to the synchronization system to ensure full synchronization every time a PoS writes to a record. This synchronization will not unlink local records in other PoS. Forward-Port-Of: odoo/odoo#191904
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191503 Forward-Port-Of: odoo/odoo#191205
Original PR description
Refund order in spain require a refund reason. Steps to reproduce: ------------------- * Install l10n_es_pos_tbai module * Open PoS * Make an order and try to refund it > Observation: You get an error message saying that you need to add a refund reason opw-4282586 Forward-Port-Of: odoo/odoo#191503 Forward-Port-Of: odoo/odoo#191205
Draft pos order where considered as paid when counting the invoiced qty of a sale linked to a pos order. Steps to reproduce: ------------------- * Create a sale order with any product * Open PoS and settle the order but do not validate it * Click on "Backend" button so that the order is synchronized * Go back on the sale > Observation: The invoiced quantity is 1 Why the fix: ------------ We should not consider draft pos orders when counting the invoiced qty as they are not yet vali
Original PR description
Draft pos order where considered as paid when counting the invoiced qty of a sale linked to a pos order. Steps to reproduce: ------------------- * Create a sale order with any product * Open PoS and settle the order but do not validate it * Click on "Backend" button so that the order is synchronized * Go back on the sale > Observation: The invoiced quantity is 1 Why the fix: ------------ We should not consider draft pos orders when counting the invoiced qty as they are not yet validated. opw-4201267 Forward-Port-Of: odoo/odoo#192160
Steps to reproduce: - wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42) - reload the spreadsheet - before the pivot is loaded (throttle the network in the dev tools): right click the cell - click on "See records" menu item => boom Task: 3847477 X-original-commit: odoo/enterprise@31401c75baa4252917fe5d808be0abd5fc23a906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172826 Forwa
Original PR description
Steps to reproduce:
- wrap a pivot function inside a IFERROR e.g. =IFERROR(PIVOT("1", "probability"), 42)
- reload the spreadsheet
- before the pivot is loaded (throttle the network in the dev tools): right click the cell
- click on "See records" menu item => boom
Task: 3847477
X-original-commit: odoo/enterprise@31401c75baa4252917fe5d808be0abd5fc23a906
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#172826
Forward-Port-Of: odoo/odoo#162568Apply sudo to avoid an access error when importing records (e.g. partners). Example use case: - Uninstall `base_install_request` - A user without the Administrator > Settings permission - Go to Contacts and click on Import records - When uploading the file the access error occurs @Tecnativa TT51841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188634
Original PR description
Apply sudo to avoid an access error when importing records (e.g. partners). Example use case: - Uninstall `base_install_request` - A user without the Administrator > Settings permission - Go to Contacts and click on Import records - When uploading the file the access error occurs @Tecnativa TT51841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188634
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the default_team_id is not passed as a parameter to the context when the partner is selected, which works correctly in sales orders but fails in invoices. Current behavior before PR: When modifying the partner_id in an invoice, the sales team is not recomputed, leading to incorrect or missing
Original PR description
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the…
Versions 16.0+ Description of the issue/feature this PR addresses: The issue occurs when selecting a partner in an invoice, the sales team is not correctly computed. The problem arises because the default_team_id is not passed as a parameter to the context when the partner is selected, which works correctly in sales orders but fails in invoices. Current behavior before PR: When modifying the partner_id in an invoice, the sales team is not recomputed, leading to incorrect or missing sales team assignment. Desired behavior after PR is merged: After this PR is merged, modifying the partner_id on an invoice will correctly recompute the sales team by passing the default_team_id in the context, ensuring consistent behavior between invoices and sales orders. I will now provide a short video demonstrating the error. This issue is replicable if none of the sales teams have any members assigned. https://drive.google.com/file/d/15mUpXvdlVpGZXW976PK7EVYH6X4sm2CJ/view?usp=sharing PR of v16 https://github.com/odoo/odoo/pull/180961 Forward-Port-Of: odoo/odoo#192242 Forward-Port-Of: odoo/odoo#181244
Versions -------- - saas-17.4+ Steps ----- 1. Have a published product "A" with 16+ variants; 2. have a published product "B" with alternative product "A"; 3. add more alternative products whose names are greater than "A"; 4. open product "B" in eCommerce. >[!Important] > Products with a reference value (e.g. "[FURN_2100]") get sorted before "A", so be sure to exclude those to reproduce the issue. Issue ----- Only product "A" gets displayed. Cause ----- The dynamic filter
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Have a published product "A" with 16+ variants; 2. have a published product "B" with alternative product "A"; 3. add more alternative products whose…
Versions -------- - saas-17.4+ Steps ----- 1. Have a published product "A" with 16+ variants; 2. have a published product "B" with alternative product "A"; 3. add more alternative products whose names are greater than "A"; 4. open product "B" in eCommerce. >[!Important] > Products with a reference value (e.g. "[FURN_2100]") get sorted before "A", so be sure to exclude those to reproduce the issue. Issue ----- Only product "A" gets displayed. Cause ----- The dynamic filter for alternative products applies the default limit of 16 to the variant count. This was not an issue in earlier versions, as alternative products displayed variants instead of templates. Solution -------- In the `_prepare_values` method, set the `hide_variants` context value even if `self.filter_id` is falsy, making it accessible for dynamic filters as well. In the `_get_products_*` methods, check this context value. If present, limit each product template to a single variant before calling `search`. opw-4318624 Forward-Port-Of: odoo/odoo#189040
to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I co
Original PR description
to reproduce: ============= - create a leave for an employee of 3 days - create a public holiday that happens to be in the middle of the employee leave - check work entries for the employee on that period -> only work entries of the public holiday are created Problem: ======== - when the public holiday was created, the leave was not split to take into account the public holiday Solution: ========= - split the leave to take into account the public holiday opw-4353988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192376 Forward-Port-Of: odoo/odoo#191552
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
Original PR description
This commit uses the `inset-inline-start` CSS property instead of `left` to account for RTL languages. (No linked task) Forward-Port-Of: odoo/odoo#191342
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Original PR description
Before this commit, "search more" would not find any matches if searching partners by VAT numbers. After this commit, it becomes possible to search and "load more" partners by VAT number. opw-4379852 Forward-Port-Of: odoo/odoo#190621 Forward-Port-Of: odoo/odoo#189703
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob
Original PR description
Currently, a traceback is occurring when the user tries to delete archived product variants. To reproduce this issue: 1) Install sale and enable product variants from configuration 2) Create a product from the variant and archive it 3) Now try to delete the above archived product. Error:- ``` KeyError: 2 ``` When the user archives a product and tries to delete the archived product, we get the `product_ids_by_template_id` as an empty dict. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L384-L388 This leads to the above traceback when accessing the product template id from an empty dict from the below line. https://github.com/odoo/odoo/blob/f118a44c5b15163556e3388c5a7daa72119f58f8/addons/product/models/product_product.py#L395 sentry-6173505059 Forward-Port-Of: odoo/odoo#191761
Since [1], when an extra menu is displayed due to the top menu exceeding its maximum width, the active class is no longer applied correctly. This issue was introduced during the conversion from jQuery to vanilla JavaScript. Steps to reproduce: - Enter the Website in edit mode. - Navigate to Site > Menu Editor. - Add several menu items until the menu exceeds its maximum width. - Ensure that one of the items in the extra menu redirects to "Contact Us". - Click on the "Contact Us" menu it
Original PR description
Since [1], when an extra menu is displayed due to the top menu exceeding its maximum width, the active class is no longer applied correctly. This issue was introduced during the conversion from jQuery to vanilla JavaScript. Steps to reproduce: - Enter the Website in edit mode. - Navigate to Site > Menu Editor. - Add several menu items until the menu exceeds its maximum width. - Ensure that one of the items in the extra menu redirects to "Contact Us". - Click on the "Contact Us" menu item. - Open the dropdown menu (via the "+" icon) and observe that the "Contact Us" entry is not highlighted. This commit resolves the problem. [1]: https://github.com/odoo/odoo/commit/0de634965a0dec4470b30154f3722a1e83b0e866 task-4428845 opw-4383641 Forward-Port-Of: odoo/odoo#192164 Forward-Port-Of: odoo/odoo#191548
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite rep
Original PR description
Steps to reproduce: initial state: The accounting report "General Ledger" has the filter "unfold all" option activated and this filter can be selected on the report. - Create a new accounting report - Select "Composite Report" - Add the General Ledger as a section - Save -> When navigating to the General Ledger, it no longer has the "unfold all" option selected. Solution provided: If the report is accessible, should not change its fields when being added to a composite report. task-4317649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188476
Fixes an issue due to the phone number being formatted before the verification that it is actually set. The formatting will now support receiving no phone number, and it won't cause an issue as its existence is checked right after. Also avoid running the account_edi_proxy_client neutralize on malaysian users, as it simply set the type to test. The malaysian edi supports having both a test and production user set on the same db (only one is being use at any given time of course), so that neut
Original PR description
Fixes an issue due to the phone number being formatted before the verification that it is actually set. The formatting will now support receiving no phone number, and it won't cause an issue as its existence is checked right after. Also avoid running the account_edi_proxy_client neutralize on malaysian users, as it simply set the type to test. The malaysian edi supports having both a test and production user set on the same db (only one is being use at any given time of course), so that neutralize could result in having two test users, which is not allowed by the constrains. opw-4352823 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190685
Steps to reproduce: - insert a list of timesheets in a spreadsheet - reload the spreadsheet - right click on a list cell - click on "See record" => it's not the correct form view Task: 4444541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192356 Forward-Port-Of: odoo/odoo#192222
Original PR description
Steps to reproduce: - insert a list of timesheets in a spreadsheet - reload the spreadsheet - right click on a list cell - click on "See record" => it's not the correct form view Task: 4444541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192356 Forward-Port-Of: odoo/odoo#192222
When an order is canceled, the order is removed from the store and the session. This commit ensures that the order is removed from the store Forward-Port-Of: odoo/odoo#191232
Original PR description
When an order is canceled, the order is removed from the store and the session. This commit ensures that the order is removed from the store Forward-Port-Of: odoo/odoo#191232
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size:
Original PR description
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center…
Scenario: - install l10n_ch - go to /report/barcode/?barcode_type=QR&value=&width=150&height=150&mask=ch_cross => the ch_cross mask (swiss cross that should be in the center) is not in the center Issue: Reportlab QrCodeWidget has a fixed size to 32mm (with mm that is 72(ppi) / 25.4(1mm to inch) so ~2.83 pixels) and to get the widget to the full size, a zoom is applied on the Drawing content (so on the QrCodeWidget). Here are the zoom that are applied for several Drawing size: - for 100 pixels: 100 / (32 * mm) => 1.012… - for 256 pixels: 256 / (32 * mm) => 2.822… - for 400 pixels: 400 / (32 * mm) => 4.409… But in the code, the zoom is just hardcoded to mm (~2.83) which corresponds to a barcode size of mm * 32 * mm => 257.127 pixels which is kind of good enough for 256 pixels, but wrong for most other size. In base code we only use 256 x 256 pixels so this is not much of an issue unless someone want to use it for something else. Fix: With this commit, we apply the Drawing zoom (on which we have the QrCodeWidget) to the ch_cross image. Note: Without the fix, the added test only fail on the third assertion for each loop iteration, the farer we are from 257x257 pixels the bigger the error is, for example for 256x256: Result: (38.45140, 38.45140, 52.25725984251969, 52.25725984251969) Expected: (38.28288, 38.28288, 52.02823111111111, 52.02823111111111) opw-4307177 PR NOTE: this could be merged in an higher version, and we could also just not fix this since as far as I can tell, we only need to support 256x256 and with and without the fix there is just one pixel of difference in this case.  Forward-Port-Of: odoo/odoo#192091
This reverts commit ff3702651a30fd7a6ee3007988df953dda911e41 After which customer credit notes share the sequence with supplier credit notes. Steps to reproduce: - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm - Document name will be 'N/C 000001' - Now create an invoice with document type '(33) Factura Electrónica'
Original PR description
This reverts commit ff3702651a30fd7a6ee3007988df953dda911e41 After which customer credit notes share the sequence with supplier credit notes. Steps to reproduce: - Open Vendor Bills journal and enable 'Use Documents?' - Create a Bill with document type '(46) Factura de Compra Electrónica' - Create the credit note - In the Wizard: select 'Full Refund', Document Type 61, Confirm - Document name will be 'N/C 000001' - Now create an invoice with document type '(33) Factura Electrónica' - Add a credit note for the invoice Issue: Credit note name will be 'N/C 000002' but sequences should be unique for move type opw-4268371 Forward-Port-Of: odoo/odoo#192285
Changes to the synchronization system to ensure full synchronization every time a PoS writes to a record. This synchronization will not unlink local records in other PoS. Forward-Port-Of: odoo/enterprise#76253
Original PR description
Changes to the synchronization system to ensure full synchronization every time a PoS writes to a record. This synchronization will not unlink local records in other PoS. Forward-Port-Of: odoo/enterprise#76253
Base users do not have access to the model `spreadsheet.revision` which is directly affected in a collaborative context. The usual flow consists to give access to the revisions once we check the access rights on the related spreadsheet. The code that handled the restoration of previous versions did not follow this flow and base users would face access errors. Task-4397512 Forward-Port-Of: odoo/enterprise#75474
Original PR description
Base users do not have access to the model `spreadsheet.revision` which is directly affected in a collaborative context. The usual flow consists to give access to the revisions once we check the access rights on the related spreadsheet. The code that handled the restoration of previous versions did not follow this flow and base users would face access errors. Task-4397512 Forward-Port-Of: odoo/enterprise#75474
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++] Forward-Port-Of: odoo/enterprise#76000 Forward-Port-Of: odoo/enterprise#75962
Original PR description
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++] Forward-Port-Of: odoo/enterprise#76000 Forward-Port-Of: odoo/enterprise#75962
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#75767 Forward-Port-Of: odoo/enterprise#73742
Original PR description
The "remaining" value of a budget should be the difference between the amount spent and the amount forecast, not the other way around. Task-4331872 Forward-Port-Of: odoo/enterprise#75767 Forward-Port-Of: odoo/enterprise#73742
Forward-Port-Of: odoo/enterprise#76430
Original PR description
Forward-Port-Of: odoo/enterprise#76430
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss" - Create a menu item in the action of the report - Open the report - Press the filter "Unfold All" - Press the "PDF" button -> Results: the pdf has no line unfolded while they should (the web UI works as expected) Reason of the issue
Original PR description
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated,…
Steps to reproduce - Activate developer mode - Go to Accounting -> Configuration -> Accounting Reports - Create a composite report with 2 existing reports that have the "filter_unfold_all" activated, i.e. "Balance Sheet" and "Profit and Loss" - Create a menu item in the action of the report - Open the report - Press the filter "Unfold All" - Press the "PDF" button -> Results: the pdf has no line unfolded while they should (the web UI works as expected) Reason of the issue: In the dispatch_report_action() function, the get_options() was wrong and unnecessary. This function is first called on the first section, then called on the composite report with its own options. This led to use the options of the composite report which does not have the filter_unfold_all field set to True. This also handles the case where a composite report has reports A and B, A having the filter_unfold_all while B doesn't have it. The expected result when printing it is that only report A has unfolded lines. task-4317649 Forward-Port-Of: odoo/enterprise#74826
Add missing english labels for the `l10n_mx_nationality` and `l10n_mx_type_of_operation`fields.  task-no Forward-Port-Of: odoo/enterprise#76055 Forward-Port-Of: odoo/enterprise#76038
Original PR description
Add missing english labels for the `l10n_mx_nationality` and `l10n_mx_type_of_operation`fields.  task-no Forward-Port-Of: odoo/enterprise#76055 Forward-Port-Of: odoo/enterprise#76038
1 change
Resolved issues and error corrections
This update fixes an issue where multiple company payroll settings only displayed the main company's localization block. Now, when multiple companies are selected, the correct localization block for each company is shown within the payroll settings, ensuring accurate reporting and configuration across all businesses. This improves the usability of the payroll system for international operations.
Original PR description
* is l10n_{au,be,ch,hk,lu,ma,us}_hr_payroll
- When miltiple companies it shows `X Localization` block only in payroll settings Where X is the cuntry of the current chosien company
Task: 4409568