Daily updates from Odoo
Monday, February 2, 2026
30 changes · saas-18.3
Enhancements to existing features
This update adjusts the National Social Security Fund (NSSF) contribution limits to align with the latest regulations as of 2026. Specifically, the lower and upper earnings limits have been revised to reflect the fourth year of implementation of the NSSF Act 2013, impacting maximum combined contributions.
Original PR description
This commit updates the NSSF Lower and Upper Earnings Limits in accordance with the 4th year of implementation of the NSSF Act 2013. - Set Lower Earnings Limit (Tier 1) to 9,000. - Set Upper Earnings Limit (Tier 2) to 108,000. - Resulting max combined contribution is now 6,480. Task: 5485002 Forward-Port-Of: odoo/enterprise#105019
Resolved issues and error corrections
This update fixes an issue where the UrbanPiper store identifier field was visually overflowing its container. The changes include wrapping the field and button in a container with a flexible width, ensuring a cleaner and more professional appearance for users.
Original PR description
Before this commit: --- - The UrbanPiper store identifier field could overflow its container. After this commit: --- - Wrap the store identifier field and action button in a container. - Apply `overflow-hidden` and flexible width to the store identifier field. task-5472992 Forward-Port-Of: odoo/enterprise#103464
This update fixes a bug related to how the system handles responses from Zatca when obtaining CCSID or PCSID information. Previously, invalid responses went unnoticed, leading to user tracebacks. Now, the system checks for CSR field length and displays a helpful message to the user, ensuring smoother Zatca onboarding.
Original PR description
Previously, it was assumed that if no 'error' or 'errors' key was present that means we've received a valid response for obtaining CCSID or PCSID. But sometimes the error is not sent with those keys, and the binarySecurityToken is missing, therefore a traceback is shown to the user because the invalid requests passes through the validation unnoticed. This kind of response is the result of a new change introduced by zatca requiring csr fields to be at most 64 characters long. This commit improves the error handling mechanism of CSID responses, to show the user an informative message, and handles the length check for csr fields on the client side before sending to zatca. task-5347269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246343 Forward-Port-Of: odoo/odoo#244507
This update resolves an error that occurred when employees had multiple commission plans linked to the same payslip input. The fix ensures accurate currency conversion for each commission, preventing a system failure and guaranteeing correct pay calculations for employees with complex commission structures. The issue was identified and corrected through a code change.
Original PR description
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the…
Currently, an error occurs while generating a payslip for an employee who is linked to more than one commission plan using the same payslip input. **Steps to Reproduce:** 1. Install the `hr_payroll_sale_commission` module. 2. Create a user and link to an employee. Set a contract for the employee. 3. Create two commission plans for the same user: - Use the same Payslip Input in both plans. - Set the Target Frequency to "Monthly" for both. 4. Generate a payslip for the employee. Ref: [Video](https://drive.google.com/file/d/1HhtUL2xznS_Aoi9ePL0OJLdGaXU8ZFZR/view?usp=sharing) **Error:** `ValueError - Expected singleton: sale.commission.report(30026010100009, 40026010100009)` **Cause:** When multiple commission records belong to the same payslip input, it tries to convert the commission amount using `coms.commission`, where coms has multiple recordsets. This leads to a singleton error during currency conversion. **Fix:** This commit ensures the currency conversion is applied per commission and prevents the singleton error. sentry-7187854690 Forward-Port-Of: odoo/enterprise#104464
This update resolves an issue that previously prevented users from duplicating journal entries containing outdated accounts. Now, users can successfully duplicate entries with deprecated accounts, correct the accounts in the draft, and post the entry. The system only flags the issue during the posting stage if the user doesn't address the deprecated account.
Original PR description
Before this commit, duplicating a journal entry that contained a deprecated account raised a validation error immediately. This blocked the duplication process entirely, preventing users from using historical entries as templates. This commit changes the validation to be done in write function and post. Now, users can duplicate an entry with a deprecated account, correct the account in the draft, and post successfully. Validation only blocks the user if they attempt to post the entry without fixing the deprecated account. or if the user inserted a deprecating account while editing the move. task-5417810 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#243782 Forward-Port-Of: odoo/odoo#240230
This update resolves an issue where users couldn't see all available Starshipit delivery services. The fix ensures Odoo sends complete sales order details (address, weight) to Starshipit, allowing users to select the correct and full list of services during setup. This improves the user experience and accuracy of delivery options.
Original PR description
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this…
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup. Expected behaviour: Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume). Steps to reproduce: 1. Create new delivery method 2. Configure Starshipit API credentials. 3. Attempt to select a service. 4. Observe that not all service is shown from the available options. Cause of the issue: Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods. Fix: Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them. Forward-Port-Of: odoo/enterprise#103316
This update fixes an issue where the rental report was displaying incorrect dates. The fix ensures that each row in the report accurately reflects the start and return dates of a rental order, providing more reliable reporting data. This improves the accuracy of rental revenue tracking.
Original PR description
The rental report is a daily report with x rows by rental order, with x the days between the start and return dates. With generate_series inside the select, the query was creating x rows with the same id, resulting in the date field not being correctly displayed (one unique date, the start date). This fix corrects the generation of the report to display the real date on each row. opw-5266525 Forward-Port-Of: odoo/enterprise#104764
This update resolves an issue preventing service products from correctly applying their default packaging type in the Keňa (Kenya) localization. The previous XML ID was invalid, and this change ensures service products now utilize the appropriate packaging type as defined for Keňa EDI transactions.
Original PR description
Update the xmlid for the default packaging type for service products, the previous one `l10n_ke_edi_oscu.packaging_type_ou` seems to have never existed. opw-5220129 Forward-Port-Of: odoo/enterprise#105905
This update resolves an issue where documents actions would sometimes fail when multiple languages were enabled. The fix ensures that actions are only displayed and used for languages currently selected by the user, improving stability and preventing errors.
Original PR description
Filter Embedded Actions Based on Active Languages ### Impacted versions: 18.0 and later ### Steps to reproduce: - Install at least 2 languages - Install documents and accounting or other app to have actions on select - Uninstall one language - You will get an error when trying to activate again actions on select (also appears on network interface) ### Current behavior: When a language is deactivated, its corresponding translations may still appear in server actions, leading to errors when trying to add them to the context. This issue is now resolved by filtering actions to only include those linked to active languages. Task: [5420820](https://www.odoo.com/odoo/project/49/tasks/5420820) Forward-Port-Of: odoo/enterprise#102938
This update fixes an issue where EPD discounts weren't being accurately reflected for certain partner types. The change ensures that each partner with EPD discounts receives the correct discount loss line when reconciling payments and transactions. This improves the accuracy of financial reporting.
Original PR description
Steps: - create two invoices with a different partner (epd + no tax on the lines) - register for each a payment (payment method with no outstanding account) - select the two payments and create a batch - create a transaction with an amount equal to two payments (discounted amount) - reconcile it with the batch payment Issue There is only one epd discount loss line for one partner Cause: in https://github.com/odoo/odoo/blob/ecb4de3fea463d6524bb2aab8d2388c679dc2ed7/addons/account/models/account_move.py#L4638 The two lines share a common grouping dict key with the same `account_id`. `setdefault` returns the value if the key is existing. opw-5057109 Forward-Port-Of: odoo/odoo#226287
This update includes a new test case within the account_accountant_batch_payment module to ensure the reliability of batch payment processing. The test was created to address a potential issue identified in a related Community PR, improving the overall stability and quality of the Enterprise version. This ensures accurate and consistent payment handling.
Original PR description
Add test for PR opw-5057109 Forward-Port-Of: odoo/enterprise#94304
A recent test failure related to the restaurant appointment tour was resolved. The fix ensures the test environment uses a consistent, simulated time, preventing inconsistencies and making the test reliable. This improves the quality and predictability of our automated testing process.
Original PR description
The `RestaurantAppointmentTour` was failing inconsistently because the browser used the real system clock during the initial Point of Sale load, while the test data was created for a specific mock date (Jan 28). Because the PoS logic filters appointments based on the current time, the test data was being misinterpreted or "normalized" by the application before the tour had a chance to freeze the clock. Moving `Chrome.freezeDateTime` to the absolute first step of the tour ensures the simulated time is applied as early as possible, making the test deterministic. runbot-232601
This update ensures that when an upsell is confirmed on a subscription, all remaining alternative upsells are automatically cancelled. Previously, confirming one upsell would leave others in a pending state. This improves the subscription management process and prevents unnecessary order activity.
Original PR description
Currently, when creating multiple upsells for a specific subscription, confirming one of them leaves the others in the sent state instead of cancelling them. This fix ensures that all other upsells for the same subscription are cancelled once one upsell is confirmed. task-5270139 Forward-Port-Of: odoo/enterprise#105694 Forward-Port-Of: odoo/enterprise#100058
This update corrects a discrepancy in how event registration data is captured in the POS system. Previously, attendee information wasn't consistently populated, but now the system prioritizes the first valid answer to identification questions (like name and email) when 'once per order' is enabled, ensuring accurate attendee records. This improves data reliability for event management.
Original PR description
When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with…
When pos_event was added, a difference in behavior with the existing registration flow in website_event was missed. When answering an 'identification question' (name, email, phone, company_type) with the 'once per order' enabled, the values should be used and propagated directly on the created event.registration records, with precedence over other answers given to individual questions (not once per order) STEPS ===== 1. Create a new event with name, email questions, once per order ticked. 2. Go to POS (reload data if needed) 3. Register and answer both questions 4. Continue the pos flow until both registrations are created 5. Go to backend > your event > registrations 6. You can see that even if the answers are propagated in the o2m field registration_answer_ids, which is expected, the attendee's name and attendee's email fields are empty. They should contain the values of step 3. FIX === Align the website_event flow and precedence of OPO questions over individual answers in pos_event. Now, the first non-null answer of an OPO question will be used for each of the question_type values listed above, if any, over answers to individual questions. Also align the fact that after OPO answers, precedence should be given to the first non-null answer to a given question type for identification questions, and not the last as it is currently. Task-4919080 Forward-Port-Of: odoo/odoo#231502
This update resolves a technical issue preventing tax calculations from processing correctly when product item codes exceeded 50 characters. The system now automatically truncates item codes to 50 characters before sending them to the AvaTax API, ensuring accurate tax calculations and preventing errors. This improves the reliability of our integration with AvaTax.
Original PR description
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50…
Link to Avalara (Avatax) documentation: https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/ Expected Behaviour: The itemCode sent to the AvaTax API should be 50 characters or fewer to comply with Avalara's field length constraints. Actual Behaviour before the Fix: When an itemCode exceeded 50 characters, the system attempted to send the request as-is. This resulted in the AvaTax API returning an error, causing the transaction or tax calculation to fail. Behaviour with the Fix: The system now ensures that the itemCode adheres to the 50-character limit before the API call is made, by trancating the code to the first 50 characters if it exceeds 50 characters. This prevents API rejection and ensures successful tax processing for items with long identifiers. Steps to reproduce: 1. Create or select a product/item with a reference (or barcode if using UPC) longer than 50 characters. 2. Trigger an action that calculates tax via the AvaTax integration (e.g., creating an invoice or updating a line item). 3. Observe the API response. - Before fix: API returns a validation error regarding the itemCode length. - After fix: Request is successful as the itemCode is properly handled/validated. opw-5406451 Forward-Port-Of: odoo/enterprise#105017
This update resolves a test failure related to outdated date ranges in the EC accounting module. The fix ensures the test environment uses the correct, 'frozen' date selection, preventing errors. While a long-running server scenario is theoretical, this change improves test reliability.
Original PR description
The selection field of the dividend_fiscal_year has a restricted range based on dates, which has implication for the frozen dates in the test. That is why the test will fail today: 2021 is not anymore in the selection. But, suppose however that you have a server running for 3 years, it could be problematic as well. (quite theoretical however) So we can simply make the selection field selection in the wizard a lambda method and that way also in the test, it will take the 'frozen selection'. build error 237681 https://runbot.odoo.com/odoo/runbot.build.error/237681
This update resolves a crash that occurred when users selected taxes within Journal Entry items in the mobile view. The fix replaces a problematic widget with a standard one, ensuring tax changes are saved correctly and preventing the web client from freezing. This improves stability for mobile users.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Journal Entry** in mobile view. * Add a **Journal Item**, opening it in a form dialog. * Select a tax in the **Taxes Applied**…
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Journal Entry** in mobile view. * Add a **Journal Item**, opening it in a form dialog. * Select a tax in the **Taxes Applied** field. * Click on the **Save and close** button. **Observed behavior:** * The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`. **Cause:** * The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected. * When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`. **Fix:** * Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form. * Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it. **Note:** * The crash happens when `autosave_many2many_tags` calls `model.root.save()` on a **new** `account.move` from within a dialog. * In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936) in-memory and does not trigger form reloads or component destruction. * As a result, the crash cannot be reproduced in tests. opw-5497342 Forward-Port-Of: odoo/odoo#246638 Forward-Port-Of: odoo/odoo#246084
The Point of Sale system now handles initialization errors more gracefully. When data inconsistencies cause the loading screen to freeze, users are presented with an option to clear local data and refresh, particularly beneficial for mobile users. This prevents frustrating wait times and improves the overall user experience.
Original PR description
Inconsistent data in the localDB or local storage can cause the POS to fail before it can get initialized. When this happens the page just stays showing the loading screen forever. Now when an error happens while initializing the POS the loader will disappear and the app will give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242532
This update fixes a validation error preventing users from scheduling paid time off with a 2-week calendar. The issue stemmed from a display element within the calendar causing incorrect date calculations. The fix removes these display elements to ensure accurate PTO scheduling functionality.
Original PR description
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select…
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off. - Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025. - While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone. - From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025. - From the employee's profile > Time Off, try to take a Monday off. Issue: - The user gets a Validation error stating that the "start date" is later than the "end date". Fix: - In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off. - Add a check to remove lines from calendar that are just there for display purposes. opw-5387347 Forward-Port-Of: odoo/odoo#246094
This update addresses discrepancies in invoice totals, particularly for Peppol transactions, caused by rounding of product prices. The system now displays 'Product Price' with a minimum precision, ensuring totals align more closely with original documents. This improves data accuracy and compliance.
Original PR description
Imported invoices can show different totals than what the original document show. This especially an issue for Peppol. Because `price_unit` is rounded, by computing the total of a line with `quantity * price_unit`, it may not be possible to obtain the same total as the one from the original document. To face this issue, the float fields related to "Product Price" don't have a decimal precision set anymore. To keep the UI clean, the precision set on "Product Price" is now interpreted as a "minimal precision". So if it set to 3, we'll see at least 3 digits. If there's more, all the digits are shown. As so: `4.0` -> `'4.000'` `4.23` -> `'4.230'` `4.235` -> `'4.235'` `4.2358` -> `'4.23458'` task-4895014 Forward-Port-Of: odoo/odoo#245660 Forward-Port-Of: odoo/odoo#243987
This update adjusts the way product prices are stored within Odoo Enterprise, ensuring greater accuracy and consistency. The change addresses a technical issue identified in previous development, improving data reliability. This update primarily impacts the core accounting functionality.
Original PR description
Fix tests, related to https://github.com/odoo/odoo/pull/243987 task-4895014 Forward-Port-Of: odoo/enterprise#105448 Forward-Port-Of: odoo/enterprise#104728
This update resolves a warning in Odoo caused by updating the Chart of Accounts in the wrong type of script. By moving the update to an ‘end-’ script, which runs after all modules are loaded, the issue is now fixed. This ensures smoother operation and prevents potential errors during Odoo’s startup process.
Original PR description
We faced a warning because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 Regarding the changes in this PR related to Registry: https://github.com/odoo/odoo/pull/186467 see: https://github.com/odoo/odoo/pull/222186 upg-3828301 **Reference Image** <img width="1769" height="39" alt="2026-01-28_18-44" src="https://github.com/user-attachments/assets/8aa5f213-b150-403b-b2a1-0bc9ed4a4ccc" /> 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#246541
This update resolves issues with the kitchen printer labels and the 'Send To Kitchen' button in self-order mode. Previously, the KOT prints included unnecessary text and the button remained visible after orders were already sent to the kitchen. Now, the KOT labels are accurate, and the button disappears correctly, streamlining the self-order workflow.
Original PR description
Configuration: ------------------------- - Restaurant Mode - Self-Order Mode: “QR + Ordering” - Service At: Table (Online Payment)…
Configuration:
-------------------------
- Restaurant Mode
- Self-Order Mode: “QR + Ordering”
- Service At: Table (Online Payment)
--------------------------------------------------------------------------------
Issue 1: Extra Order word print in KOT
---------------------
Steps to Reproduce:
1. Make an order using Self Order (QR).
2. Configure and enable the Kitchen Printer.
3. Check the KOT print it shows “Order Self-Order T2”.
Cause:
- The QWeb template always prefixed “Order” regardless of order type.
Fix:
- Added a condition to skip the “Order” label for self-order references:
--------------------------------------------------------------------------------
Issue 2: “Send To Kitchen” Button Visible even order in kitchen
---------------
Steps to Reproduce:
1. Open the Restaurant
2. Place a order from mobile menu and select a table.
3. In the Restaurant UI:
- Open that table. The "Send To Kitchen" button is still visible even
though the order was already sent to the kitchen and printed.
Cause:
- In self-order mode the order is not automatically synced after being sent to
the kitchen and print.
- As a result, the system still treats it as unsent, leaving the Order button
visible.
Fix:
- Synced the order state after sending it to the kitchen.
----------------------------------------------------
Task-5106704This update resolves an issue where lengthy reconciled names on bank statements were being displayed as a long list of commas due to a formatting error. The fix moves a key component, improving the clarity and readability of statement line information for users. This ensures a cleaner and more user-friendly experience.
Original PR description
When we have a lot of reconciled names, it can happens that you just have a long list of comma. It's because the text truncate was misplaced. This commit will fix this by moving the text truncate no task id
This update resolves a bug that prevented the system from correctly creating vendor partners when processing vendor bills in Uruguay. The issue stemmed from incorrect state detection when the 'Departamento' tag was missing from the XML data. This ensures accurate vendor partner creation and integration with Uruguay's tax system.
Original PR description
If the xml file has a tag "Departamento" without a value, the vendor partner creation fails because the state is searched with an empty string and detects a state that is not correct because the xml has no state value. Task Adhoc side: 109004 Forward-Port-Of: odoo/enterprise#105801
This update fixes an issue where a work center wouldn't be blocked after a work order was deleted, due to a lingering timer. Now, deleting a work order correctly stops the associated timer and prevents the work center from being blocked, ensuring accurate resource management.
Original PR description
Steps to reproduce: - Start the timer on the work order - Delete the work order - Try to block the work center Current behavior: - The work center is not blocked because the latest mrp.workcenter.productivity is still active Expected behavior: - The work center is blocked - mrp.workcenter.productivity is stopped opw-5475227 Forward-Port-Of: odoo/odoo#245815
This update fixes a translation issue in the Swiss payroll module (l10n_ch_hr_payroll) where warnings on payslips didn't display translated field names. The fix ensures that all warning messages are correctly translated into French (CH), improving the user experience for French-speaking Swiss employees. This resolves a minor usability concern.
Original PR description
The warnings that appear on a payslip when the employee's form misses information are not fully translated Steps to reproduce: 1. Install module l10n_ch_hr_payroll 2. Switch to "My Swiss Company" and change language to French (CH) 3. Open app "Paie" and create a new employee (only add a name) 4. Click on "Contrats" in the stat button and create a new contract for the employee (only add a name), save it and set it as "En cours" in the status bar 5. Go to "Fiches de paie" > "Toutes les fiches de paie" and create a new payslip 6. Add the newly created employee to the payslip 7. The warnings in the form displaying the missing fields from the employee form do not translate the name of the missing fields Solution: Use `get_description` to get the translated name of the missing fields opw-5403634 Forward-Port-Of: odoo/enterprise#104499
This update ensures accurate payslip transmission for Swiss users by adding a necessary security layer (sudo) when accessing payroll data. Previously, users could potentially modify their own payroll information, leading to errors. This fix prevents unauthorized access and resolves a technical issue impacting payroll processing.
Original PR description
From a previous PR (103147), the payslip update logic was moved to the write function which gets called when a field is changed. In doing so, a sudo call is necessary to avoid problems with users modifying their own record (and not having access rights to read slip_ids). This also applies to tests and solves the following runbot error: Runbot Error: 237743 Forward-Port-Of: odoo/enterprise#105287
This update resolves a problem where demo data creation in the l10n_be_hr_payroll_fleet module failed due to a missing dependency. The fix changes the module's reliance to hr_fleet, ensuring all necessary components are installed, and preventing the traceback error. This ensures demo data can be created correctly.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410
This update resolves an issue preventing website designers with 'Editor and Designer' access from optimizing the SEO of eCommerce categories. The fix grants necessary write permissions to category records, allowing designers to implement SEO best practices directly within the website. This improves the functionality for designers and ensures consistent SEO across the platform.
Original PR description
### Issue: Due to this issue, website designer cannot optimize seo on category. #### Steps to reproduce: 1- Create a `eCommerce Category`. 2- In demo user, set Sale access to `All Documents` and Website access to `Editor and Designer`. 3- Login with demo user and navigate to website. 4- In shop page, open category. 5- From site tab, click on `Optimize SEO`. You get access error. Expected: You should be able to optimize seo with `Editor and Designer` access. ### Cause: The user needs write access on record in order to optimize seo: https://github.com/odoo/odoo/blob/ec5da99ca3f52420e7d973c3cf07167bd4104ffa/addons/website/controllers/main.py#L831-L834 opw-5443854 Forward-Port-Of: odoo/odoo#246624 Forward-Port-Of: odoo/odoo#244724