Tuesday, March 10, 2026
75 changes · saas-19.1
Resolved issues and error corrections
This update corrects a bug where the valuation of kit components was incorrectly calculated after vendor bills were processed. The system was failing to account for the proportional share of the kit's cost, leading to inflated component values. This fix ensures accurate valuation of kits, particularly when using vendor bills.
Original PR description
**Issue**: Billing a PO containing kit with several components can lead to incorrect valuation of its components **Steps to reproduce**: - Create a kit product (by creating a BOM with 2 components)…
**Issue**: Billing a PO containing kit with several components can lead to incorrect valuation of its components **Steps to reproduce**: - Create a kit product (by creating a BOM with 2 components) with AVCO valuation - Create a PO for 1 unit at unit price 10 - Confirm PO and validate the receipt - Go to the BOM of the kit product and check BOM overview -> The cost of the two components are 5, which is correct - Go to Accounting > Vendors > Bill - Create a new bill by indicating the PO in "Auto-Complete" field and validate - Go back to the BOM of the kit product and check BOM overview -> The cost of the two components are 10, which is correct This also occurs with FIFO valuation **Cause**: While computing the value of the move: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the Bill: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358 Which relies directly on the AML price of the kit: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170 This ignores the `cost_share` of each BOM component. As a result, each component receives the full kit value instead of its proportional share This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393 **Aditionnal note** The computation of the quantity is also incorrect: https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169 since it assumes the quantity of component of the kit is the same than the quantity of the kit itself, which is not true in the general case. opw-5924940 Forward-Port-Of: odoo/odoo#249264
This change resolves an issue preventing the l10n_mx_edi_pos module from correctly updating invoices when POS data is involved. The fix adds a necessary permission to access `pos.order` records, allowing the module to generate invoices accurately. This ensures proper integration with point-of-sale transactions in Mexico.
Original PR description
`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider…
`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:
- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model
We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:
```
File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
if invoice.pos_order_ids:
^^^^^^^^^^^^^^^^^^^^^
File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
return super().__get__(records, owner)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
return super().__get__(records, owner)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
recs._fetch_field(self)
File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
self.fetch(fnames)
File "/c19-1/odoo/orm/models.py", line 3055, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
field.read(fetched)
File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.
This operation is allowed for the following groups:
- Inventory/User
- Point of Sale/User
```
Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:
```
File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
return super()._create_update_invoice_document_from_invoice(invoice, document_values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
document = remaining_documents._create_update_document(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
result_document = self.create({
^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
return method(self, vals_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
records = self._create(data_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
field.create([
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
self.write_batch(record_values, True)
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
self.write_real(records_commands_list, create)
File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.
This operation is allowed for the following groups:
- Inventory/User
- Point of Sale/User
```
We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.
[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590
opw-6000974This update allows administrators to view and revoke user sessions, enhancing security and control over access to the Odoo system. The change improves administrative workflows by providing a dedicated view for managing user sessions, aligning with best practices for user access control.
Original PR description
An administrator must be able to revoke other users' sessions. The revocation action has been moved to the `res.session` model. Add the view that allows admins to view user sessions and revoke them. Task-5941823
This pull request reverts a recent change to the HR module. The previous update introduced an issue that was deemed to violate our stable release policy. This reversion ensures the HR functionality remains consistent and reliable for our users. We're prioritizing stability and adhering to our development standards.
Original PR description
Breaking stable policy 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 update resolves a crash that occurred when deleting an account move within the l10n_sa module. The issue stemmed from a check within the system's attachment handling process, which was incorrectly reacting to deleted moves. This fix ensures smooth account move deletion without causing errors.
Original PR description
Since https://github.com/odoo/odoo/pull/242777 the deletion of an account.move may crash. Indeed, the deletion of the move delete its corresponding attachments, and ir.attachment has an ondelete method that checks the attached move, namely _unlink_except_posted_pdf_invoices(). The method checks some condition on the corresponding moves, which have just been deleted, hence raising a MissingError. runbot_build_error-237850
This update resolves a bug that prevented users from deleting employee leave reports within the reporting module. The issue stemmed from a design where the report data wasn't stored in a traditional database table, leading to an error when attempting deletion. This fix ensures the report deletion functionality now works correctly.
Original PR description
When the user tries to perform delete operation on the ``hr.leave.employee.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_holidays`` module with demo data - Go to > Time Off > Reporting > by Employee > Switch to Graph View - Click on any record > Select any record > Actions > Delete Traceback: ```py UndefinedTable: relation "hr_leave_employee_report" does not exist ``` ``hr.leave.employee.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to delete a record of that model, It will lead to the above traceback. sentry-7202115608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where clicking the call dropdown in the Odoo system wouldn't open it. The fix involves styling adjustments to ensure the dropdown appears correctly, improving the user experience. It also corrects styling issues within the call action components.
Original PR description
task-5263009 Forward-Port-Of: odoo/odoo#251462
This update ensures that the 'Outstanding Account' field is automatically populated when setting up the 'Card' payment method in Point of Sale. Previously, the system didn't consistently assign this required field, leading to setup inconsistencies. This change improves the setup process and aligns automated configuration with manual settings.
Original PR description
Steps to reproduce: 1. Initialize a new database with 'point_of_sale' and 'accountant' modules. 2. Go to Configuration > Payment Methods and open the 'Card' payment method. 3. Observe that the 'Outstanding Account' field is empty, despite being required in the view for bank journals. The issue occurred because the '_create_journal_and_payment_methods' method created the default 'Card' payment method without specifying an 'outstanding_account_id'. While the ORM allows this (as the field is only required in the view), it creates an inconsistency between automated setup and manual configuration. Solution: Modify '_create_journal_and_payment_methods' to automatically assign the 'outstanding_account_id' during creation. It follows the pattern used in the payment method's onchange logic by fetching the default debit account from the chart template or falling back to the company's transfer account. opw-5914536 Forward-Port-Of: odoo/odoo#249439
This update resolves an issue where the eLearning course content section wouldn't display files from Google Shared Drives. The fix allows the system to properly access files in Shared Drives by adjusting the Google Drive API settings. This ensures users can seamlessly integrate content from Shared Drives into their courses.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Go to eLearning > Courses > select a course > Add Content 3. Paste a public link that belongs to a file located in a Google `Shared Drive` Issue: - The system shows a warning `Your file could not be found on Google Drive, please check the link and/or privacy settings` even if the link is accessible via a browser in incognito mode. Cause: - The Google Drive API restricts the search scope to the user's personal `My Drive` by default It filters out items located in Shared Drives unless the client explicitly signals Solution: - Add `params['supportsAllDrives'] = 'true'` to the API request opw-5424413 Forward-Port-Of: odoo/odoo#241037
This update enhances the visual appearance of the member list in Odoo, specifically addressing minor spacing and alignment issues. The changes improve the readability and overall aesthetic of the interface, ensuring a more polished user experience. This is a simple fix to improve the user interface.
Original PR description
- reduced spacing with the member name - better vertical alignment of name and star icon - some spacing with the "..." button when member name is long Before / After <img width="241" height="205" alt="Screenshot 2026-03-06 at 15 16 44" src="https://github.com/user-attachments/assets/448a8d5c-36a4-4018-89f3-cf89dabdac8a" /> <img width="237" height="195" alt="Screenshot 2026-03-06 at 15 15 47" src="https://github.com/user-attachments/assets/29968c76-51f8-498e-ac9a-98861d3360a2" /> Before / After <img width="241" height="206" alt="Screenshot 2026-03-06 at 15 16 56" src="https://github.com/user-attachments/assets/96a0ee34-ec87-418f-8ecd-0025dfe79387" /> <img width="244" height="197" alt="Screenshot 2026-03-06 at 15 16 10" src="https://github.com/user-attachments/assets/9a4dc28c-8ba3-4992-8230-0aa4f8af382c" />
This update removes a misleading button in the channel member panel for regular users. Previously, this button was visible even when users couldn't perform any actions, leading to an empty popover. Now, the button is hidden, providing a cleaner and more intuitive experience.
Original PR description
Partial backport of https://github.com/odoo/odoo/pull/246580 Before this commit, the button "..." on channel members was visible even for non-owner / admins. Normal members cannot make any action on members, so there's no point in showing this button: clicking on it shows an empty popover. This commit prevents the showing of this button when member has no actions. Before / After <img width="244" height="223" alt="Screenshot 2026-03-06 at 12 50 59" src="https://github.com/user-attachments/assets/2257e27a-33b3-4c33-94a7-0d81dff3e0a9" /> <img width="244" height="206" alt="Screenshot 2026-03-06 at 12 51 21" src="https://github.com/user-attachments/assets/6da655a3-30b4-430b-bdf6-7c2316674ebc" />
This update fixes an issue preventing the IoT box's Wi-Fi access point from connecting. The solution involved changing the Wi-Fi standard to 802.11a, which is compatible with modern Wi-Fi equipment. This ensures consistent connectivity for IoT box configurations.
Original PR description
Before this commit, the `hostapd` Wi-Fi access point that is started to allow configuring the Wi-Fi network on the IoT box could not be connected to when using the latest images. The exact cause is unknown, but the Odoo code has not changed so it seems to be due to an OS or driver update. After this commit, we set the Wi-Fi mode to 802.11a, which enables modern Wi-Fi standards on the AP, whereas before it defaulted to 802.11b which is the oldest Wi-Fi standard. This change makes the network visible and able to be connected to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where overtime calculations were incorrect for employees working night shifts that crossed midnight. The change ensures accurate overtime tracking by properly handling time zone differences and correctly deleting outdated overtime records, preventing duplicated hours. This improves the reliability of employee time tracking.
Original PR description
**Steps to reproduce:** 1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time): - Thursday: 20:00 to 24:00 - Friday: 00:00 to 04:00 2. Assign the above…
**Steps to reproduce:** 1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time): - Thursday: 20:00 to 24:00 - Friday: 00:00 to 04:00 2. Assign the above calendar to an employee. 3. Set the Employee’s Timezone to Asia/Kolkata (UTC+5:30). 4. Assign an active Overtime Ruleset to the employee. 5. When the attendance calendar is in Europe/Brussels TZ - Check-in: Jan 15, 15:30 CET - Check-out: Jan 15, 23:30 CET Expected Behavior: Worked Hours = 8.0, Overtime (Extra Hours) = 0.0 Actual Behavior (Bug): Worked Hours = 8.0, Overtime = 4.0 **Bug Cause:** 1. The _update_overtime function normalized the Ruleset version periods using time.min for both the start and end of the day. This forced the validity period of the rules to end exactly at 00:00:00 UTC on the final day. 2. The overtime recalculation logic failed to delete existing overtime records because the search domain was incorrectly computed. Specifically, using relativedelta(SU) and relativedelta(MO(-1)) without the weekday= keyword argument did not shift the dates to the week boundaries. This resulted in an empty or incorrect deletion range, leading to duplicated overtime hours as new records were layered on top of un-removed old ones. **Solution:** 1. Modified the version_periods_by_employee mapping to use time.max (23:59:59) for the end of the version period. This ensures that the ruleset remains active through the entire final calendar day in UTC, allowing shifts that cross the midnight boundary to be fully captured. 2. Corrected the date range logic by explicitly passing the weekday argument to relativedelta. This ensures the domain correctly targets the full week window - from the preceding Monday to the following Sunday, ensuring all relevant stale overtime lines are purged before recalculation. 3. Updated Manual Edit Handling: Refined the logic to detect days with manual overrides or "To Approve" statuses before unlinking. If an attendance change triggers a recalculation on such a day, the system now replaces the manual entry with the mathematically correct value but flags the new record with a to_approve status for manager review. 4. Adjusted the expected overtime in test_weekly_overtime to 18.0 to correctly reflect the cumulative calculation of daily overtime (2h/day) plus the weekly overtime threshold reached on Friday. Task: 5710273 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where discounts weren't correctly applied to split POS orders, leading to incorrect discount calculations. The fix ensures that discounts are accurately added to each split order line, improving the reliability of split payment processing for restaurant and loyalty programs. This resolves a bug that prevented accurate discount application during split order transactions.
Original PR description
**: discount, loyalty, restaurant Steps: --- - Create a POS order with at least 2 quantities. - Apply a global discount (e.g., 10%). - Split the order with 1 quantity. - Split again with the remaining 1 quantity. - After validating the final split payment, go back to Split again. Issue: --- - Clicking Split again shows a negative discount amount. - The split orders do not contain any discount line. Cause: --- - The discount line was added to the current order instead of the split order. - When all lines were split, the current order was reused instead of creating a new one. Fix: --- - Add the discount line to the correct split order. - Avoid creating a new order when all lines are already split. task-5942356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users without project access rights would encounter errors when modifying work orders linked to private projects. The fix ensures that workers can successfully update these work orders by granting necessary read permissions to project data, preventing access errors.
Original PR description
When working on a MO that is linked to a project in private, it will trigger a access error if the worker is does not have project access right Steps to reproduce: ------------------- * Install Project, MRP, Accouting * Create a private project * Create a MO and link it to this project * confirm this MO with a user that has no project access right Observation: ------------- When modifying the MO, we will pass through the write that has been overwritten: https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/project_mrp_workorder_account/models/mrp_production.py#L6-L10 we will call _get_analytic_distribution on project.project and since _get_analytic_distribution will [read fields from self](https://github.com/odoo/odoo/blob/436921c24a531eba6bf57ffe3f7c3b4978139d83/addons/analytic/models/analytic_line.py#L59-L64) we need project.project read rights. opw-4919576 Forward-Port-Of: odoo/enterprise#108148
This update ensures that refunds created through the Odoo backend system now accurately reflect the positive price changes made when refunds are created through the user interface. Previously, refunds in the backend showed negative prices, which was inconsistent with the UI. This fix improves data accuracy and consistency for all refund transactions.
Original PR description
Before this commit, when creating a refund from backend, the refunded lines had negative price, which is not the case when creating a refund from the UI. This commit makes sure that the refunded lines have positive price. opw-5459378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249548
This update corrects a display issue in the info side panel of demo livechat sessions. Previously, closed sessions were incorrectly shown as active, leading to inaccurate data. Now, demo sessions with feedback are properly marked as ended, ensuring the info panel accurately reflects the conversation outcome.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations…
**Description of the issue this PR addresses:** ---------------------------------------------- Some livechat demo sessions included feedback/ratings but were still displayed as active conversations in the info side panel. This created inconsistent demo data where closed conversations appeared with options meant for ongoing chats (e.g., status shown instead of outcome). **Current behavior before PR:** ---------------------------------------------- - Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set. - As a result, the info side panel treated them as ongoing conversations. - This caused mismatched UI information for demo data. **Desired behavior after PR is merged:** ---------------------------------------------- - Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt. - The info side panel correctly reflects closed conversations with coherent outcome information. Task-5412081 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250001
This update removes unnecessary customizations related to Swiss payroll calculations within the payrun process. The core logic has been corrected, eliminating redundant and potentially conflicting rules. This ensures consistent and accurate payroll processing for Swiss users.
Original PR description
Not necessary anymore, standard logic has been fixed Forward-Port-Of: odoo/enterprise#108121
This update resolves an issue where early payment discounts weren't correctly processed when generating invoices in the Factur-X format. The change adds the necessary handling for Early Payment Discounts (EPD) within this format, ensuring accurate invoice generation and compliance. This improves the accuracy of financial reporting.
Original PR description
Added the handling of early payment discount in the factur-x format. opw-5265981 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252098 Forward-Port-Of: odoo/odoo#244659
This update resolves an issue where extra drag-and-drop dropzones appeared when hidden popups were present in the website editor. By ensuring the popup's visibility state is consistently tracked, this fix prevents these unwanted dropzones and improves the overall user experience when working with popups.
Original PR description
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost…
## Description There was a desync issue with popup states between normal mode and edit mode. That caused: - Hidden popups contributed extra dropzones during drag-and-drop - Hidden popups lost `d-none` class after dropping unrelated snippets ## How to reproduce ### Bug 1: extra dropzones from hidden popup desync 1. Enter website edit mode. 2. Drop popup in the page 3. Drag another snippet as you were adding it to the page 4. An additional dropzone appears below the invisible popup snippet ### Bug 2: hidden popup loses `d-none` class 1. Enter edit mode. 2. Drop a popup. 3. Close it so `.s_popup` gets `d-none`. 4. Drop any other snippet on the page arbitrarily. 5. Popup loses `d-none` class. ## Expected behavior after fix - Popup hidden/shown state remains stable across editor refreshes and snippet drops. - Drag-and-drop no longer creates extra dropzones from hidden popups. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251517 Forward-Port-Of: odoo/odoo#250625
This update ensures that employees only receive timesheets for public holidays that are relevant to their company. Previously, timesheets were incorrectly generated for employees in companies without a linked public holiday, leading to inaccurate record-keeping. This change improves data accuracy and reporting.
Original PR description
**Steps to reproduce** - Have 2 companies A and B - Use a single working schedule (needs to have no company on it) for both companies and their employees - Create a public holiday with company A, while having company B in the selected companies - There's a timesheet for the public holiday created for employees of company B, even though the public holiday will not apply for them. **Change** Only generate the timesheets for employees belonging to the companies of the public holidays. opw-5498462 Forward-Port-Of: odoo/odoo#245743
This pull request reverses a recent change to the spreadsheet edition's styling, specifically related to borders. The change was reverted to restore the previous visual appearance. This ensures consistent and expected formatting within the spreadsheet functionality.
This update resolves an issue where temporarily disabled products weren't appearing correctly in the self-order POS configuration. The fix ensures that product snoozes are now accurately reflected in real-time, allowing cashiers to manage product availability effectively. This improves the user experience and operational accuracy of the self-order system.
Original PR description
The `pos_snooze_ids` was not included in the `load_pos_self_data_fields` so the field was not accessible in the config in self and it would not display the temporary disabled products. I added it now so that products will be disabled in real time based on updates from the cashier screen --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue preventing users from applying the 'My Department' filter in the Time Off module. The fix addresses a permissions error related to accessing employee data, ensuring the filter functions correctly for all users. This improves usability and prevents data access problems.
Original PR description
Steps to reproduce: 1- Install Time off app with demo data 2- Log in as Marc Demo 3- Go to Time Off > Overview 4- Enable My Department filter Issue: An access error is raised because of not having enough rights to access the field version_id on hr.employee. task-5948520
This update fixes a test failure related to live chat operator access permissions. The system now correctly assigns operators to channels, and the test has been updated to verify access without relying on outdated membership assumptions. This ensures consistent and reliable testing of the live chat functionality.
Original PR description
this PR is resolving [runbot error](https://runbot.odoo.com/odoo/runbot.build.error/241727) due to **/get_session** now creates the assigned operator as a channel member, so the previous non-member assertion became invalid and could fail depending on operator assignment. The test now uses a distinct livechat operator added after session creation to keep validating description edit access without relying on outdated membership assumptions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr