Daily updates from Odoo
Navigate
Branch
Friday, March 15, 2024
132 changes
19 changes
Enhancements to existing features
This update enhances the Odoo system by adding a log message to confirm when a data module has successfully been imported into the database. Previously, no log notification was provided upon completion, making it harder to track import successes. This improved logging provides greater visibility and confidence in the data import process.
Original PR description
Before this commit, there was no message in the logs when the import of a data module is finished. This commit adds a log info to state that the module is now in the db. Forward-Port-Of: odoo/odoo#157687
Resolved issues and error corrections
This update corrects a previous issue where users could set time off types directly on accrual plans within the system's list views. We've removed this option to simplify the accrual plan configuration process. This change ensures a cleaner and more straightforward experience for managing accrual plans.
Original PR description
In rework of accruals plan, we removed the possibility to set a time off type on the accrual plan directly. The field has been removed from the form view, but not from the list view. 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#157366
This update optimizes the process of reconciling accounts by adding a database index. This change speeds up the deletion of records during reconciliation, leading to faster and more efficient account reconciliation operations. The change was driven by a performance issue identified in a previous request.
Original PR description
## Description Add missing index on FKey `tax_cash_basis_rec_id` to speed up deletion of `account.partial.reconcile` records during reconciliation. It's `btree_not_null` as the relationship is sparse. ## Reference opw-3649801 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157415
This update fixes an issue where currency fields weren't correctly displayed within spreadsheets when linked to a list view. The problem stemmed from a previous change and has been resolved, ensuring accurate currency formatting and names are now consistently shown. This improves the reliability of financial data within spreadsheets.
Original PR description
Get to a list view where there's a monetary field AND the related currency field in the same list. Then insert the list in a spreadsheet. => Either the currency format is not fetched or the currency name, depending on the order in the list. bug introduced by 8777973e opw-3770057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157623
This update fixes a potential issue where reports could be generated in a random order. Previously, the system didn't guarantee a consistent order, which could lead to confusion for users. This change ensures reports are always generated in the same order, improving predictability and reliability.
Original PR description
Before this commit, ir.actions.report can be randomed orderer. @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157031
This update ensures that when processing online payments for POS orders, the system now prioritizes the customer associated with the order over the logged-in user or a general public user. This change improves the accuracy of payment tracking and reporting for POS transactions, particularly when customers are purchasing through the online portal.
Original PR description
Before this commit: POS online payments uses the logged-in user or the public user, even when a POS order customer might also be present. After this commit: We check the partner_id for POS orders and give it precedence over both the logged-in user and the public user. task-3805695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157562
This update resolves an issue where font styles differed depending on whether users selected Google fonts or served them locally. The fix adds a necessary parameter during font download, ensuring consistent font rendering across all website styles. This improves the user experience and visual consistency.
Original PR description
[This other commit] introduced a method to serve Google fonts from the local server. Then it has been back-ported to previous versions with [this commit]. Unfortunately, the font was not identical…
[This other commit] introduced a method to serve Google fonts from the local server. Then it has been back-ported to previous versions with [this commit]. Unfortunately, the font was not identical when the user chose to load the font from Google servers versus from the local server. This discrepancy was due to a missing parameter when downloading the font file to serve it from the local server. This commit fixes the issue by adding the missing parameter. Steps to reproduce the issue fixed by this commit: - Drop a text block onto a website page. - Make the text bold. - Go to the theme tab. - Change the font to https://fonts.google.com/specimen/Poppins => The text style changes depending on whether you checked the "Serve font from Google servers" option or not. [This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd [this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3 opw-3775683 Forward-Port-Of: odoo/odoo#157734
The website's search snippets were appearing invisible due to a color mismatch. This update introduces a new setting to ensure the snippets have a visible border and distinct background color, aligning with other search bars within Odoo apps. This improves the user experience when adding search snippets to webpages.
Original PR description
Since this commit [1], the two searchbar snippets are broken. The search bar input seems invisible because it shares the same color as the default snippet background and has no border. This style…
Since this commit [1], the two searchbar snippets are broken. The search bar input seems invisible because it shares the same color as the default snippet background and has no border. This style matches the search inputs used in apps (like the "/shop" search bar), which isn't affected by the "Input fields" settings in the "Theme" tab. To resolve this issue, this commit introduces a new option to choose between the "light" style (similar to "/shop" search bars) and the "default input style" for the 2 "Search" snippets. The "default input style" is automatically applied when the "Search" snippet (excluding saved snippets) is dropped to address the issue caused by the light-on-light color scheme. Steps to Reproduce the Issue: - While in Website edit mode, drag and drop a "Search" snippet onto the page. - Bug: The input appears invisible due to the lack of a border and a background color identical to the snippet's section color. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3662985 Forward-Port-Of: odoo/odoo#154435
This update fixes an issue where the 'My' filters weren't appearing at the top of the timesheet search view. The change reordered the filter placement to ensure users can quickly find timesheets related to themselves. This improves usability and efficiency for managing timesheets.
Original PR description
Steps to reproduce: - Install timesheets - click on all timesheets - open search view Issue: - in search view 'my' filters block should be at the top of the list Cause: - misplacing of the name month filter causes the issue. Solution: - if we replace that filter below the group then the issue will be solved. task-3772684 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#155714
This update resolves an issue where creating a new provider with a specified journal would lead to errors when changing the provider's company. The fix prevents the creation of unnecessary related accounts, streamlining the process and improving data consistency.
Original PR description
During the copy of provider if the journal is set, it create a new account.payment.method.line, and if you change the company of the new provider you have an error when you try to create a new journal. https://www.odoo.com/web#model=project.task&id=3778226 opw-3778226 Forward-Port-Of: odoo/odoo#157715 Forward-Port-Of: odoo/odoo#149423
This update resolves an issue where the reconciliation widget incorrectly selected a partner when multiple partners shared the same name. Previously, the last created partner was always used, even if the payment originated from a different partner. Now, the system avoids selecting a partner when names are identical, ensuring accurate reconciliation reporting.
Original PR description
In a single database, you could have two partners who are called John Doe. Before this commit, any statement line where the partner_name was set with 'John Doe' would return the last one being…
In a single database, you could have two partners who are called John Doe. Before this commit, any statement line where the partner_name was set with 'John Doe' would return the last one being created, due to the _order attribute on res.partner model, even if the statement line was generated from a payment of the other 'John Doe' (ie first one created). With this commit, we ensure that the wrong partner is not selected, in case we cannot differentiate one from the other. Description of the issue/feature this PR addresses: In case you have two partners with the same name in your DB, and you import a bank statement having a payment from the first created partner, the reconciliation widget will display a filter matching invoices of the last created partn. Current behavior before PR: Last partner created is selected for the filter. Desired behavior after PR is merged: No partner is selected for the filter if we have multiple ones sharing the same name. Enterprise test PR: odoo/enterprise#57846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157470 Forward-Port-Of: odoo/odoo#155986
This update allows users to register payments against multiple invoices using the payment wizard. Previously, the wizard was limited to single invoices and specific payment types. Now, users can select any bank journal, even when processing payments for multiple invoices, improving payment flexibility.
Original PR description
Create an invoice to partner A, confirm Create an invoice to partner B, confirm From Invoice list view, select just one invoice and hit register payment It will be possible to only select journals having inbound payment method Now select both invoices and hit register payment It will be possible to select any Bank journal, even if both invoice payment should be incoming opw-3757686 Forward-Port-Of: odoo/odoo#157665 Forward-Port-Of: odoo/odoo#156578
This update corrects a visual issue where new product templates initially displayed 'Odoo - False' in the tab title instead of the expected 'Odoo - New'. The fix ensures that new product records correctly show 'Odoo - New' until a product name is entered, improving the user experience.
Original PR description
**Current behavior:** When creating a new product template record, the tab title will be *Odoo - False* until a new name is saved rather than *Odoo - New*. **Expected behavior:** When creating a new record in a form view, the tab title will be *Odoo - New* until the `name` field is filled out and the record gets saved (at which point it will be *Odoo - <name>*). **Steps to reproduce:** 1. Install `sale_management` and go to the product list view 2. Create a new product, observe the misnamed tab title **Cause of the issue:** In `product.template`'s _compute_display_name() method, some of the default values can have a 'False' (str) value which will evaluate to True (bool), setting the name to 'False'. **Fix:** Set the display_name field to a False (bool) value if the current record does not have a name field set. opw-3793588 Forward-Port-Of: odoo/odoo#157258
This update resolves an issue where product image reordering caused unexpected swapping or jumping of images. Now, images are correctly inserted and maintained in their relative order, and the main product image always remains in the first position, providing a more stable and intuitive experience for users browsing product listings.
Original PR description
This change fixes the unexpected behavior of product image reordering: 1. Previously, when moving an image to the first or last postion, it was swapped with the first or last image. Now, it is inserted in the first or last postion, while keeping the relative ordering of the other images unchanged. 2. Previously, the main image could be in any position, but as soon as it was reordered, it would jump to the first position. Now, the main image is always in first position. task-3581895 Forward-Port-Of: odoo/odoo#150207
This update addresses several critical issues within the Odoo spreadsheet component, ensuring smoother operation and data integrity. Specifically, it resolves problems with chart resizing, sheet deletion, and renaming sheets in read-only mode. This improves the overall user experience and stability of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd0c9e005 [REL] 17.1.8 https://github.com/odoo/o-spreadsheet/commit/66c66a61d [FIX] figures: deleting a sheet will remove all figures https://github.com/odoo/o-spreadsheet/commit/3ceba1d93 [FIX] sheet_interactive: rename sheet in readonly mode https://github.com/odoo/o-spreadsheet/commit/c1bd3c971 [FIX] FiguresContainer: chart resizing broken
This update ensures that UTM tracking codes are correctly saved in cookies after a user accepts the website cookie bar. Previously, the cookie bar deactivated cookies, preventing UTM data from being captured. This fix resolves issues with tracking website traffic and accurately attributing sales through UTM links, especially when users navigate from marketing campaigns.
Original PR description
Current behavior: --- When the cookie bar is activated, the cookies are deactivated by default, unless you click on I agree. This prevents UTMs from being set in the cookies Steps to reproduce: ---…
Current behavior: --- When the cookie bar is activated, the cookies are deactivated by default, unless you click on I agree. This prevents UTMs from being set in the cookies Steps to reproduce: --- 1. Install website_sale and sale_management 2. Go to Settings/Website 3. Activate Cookies Bar 4. Go to Link Tracker 5. Create a new link 6. Set the url as .../shop and Medium as LinkedIn 7. Open a private tab 8. Go to the tracked URL 9. Click on I agree on the cookie bar 10. Buy a product 11. Go back to Sales 12. Find the last public user quotation 13. Go to other info 14. Medium is empty Cause of the issue: --- UTMs are read from the cookies. When you activate the cookie bar, the cookies are deactivated by default. So when you go to the tracked url, and it redirects you to the page, it doesn't put the info from the url in the cookies. Clicking on I agree doesn't resolve the issue because it doesn't reload the page. Fix: --- When closing the cookie bar, forcing the info in the URL to be stored in the cookies if the key is a UTM. opw-3681927 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157711 Forward-Port-Of: odoo/odoo#154924
This update improves the Spanish language support within Odoo by correcting and expanding translations. Specifically, the `l10n_es` module has been updated with new translations, ensuring that Odoo's Spanish-speaking users have accurate and comprehensive support. This enhances the overall user experience for our Spanish-speaking customers.
Original PR description
Enterprise: https://github.com/odoo/enterprise/pull/58700 Forward-Port-Of: odoo/odoo#157759
This update fixes a potential issue where discounts on subscription sales were being recalculated unnecessarily after the order was confirmed. This change ensures that discounts are calculated correctly and efficiently, improving the accuracy of subscription sales figures. The update includes a new test to verify this fix.
Original PR description
Add test to cover a problem fixed in `sale_subscription` opw-3740645 See also: https://github.com/odoo/enterprise/pull/58673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157699
Code cleanup and technical improvements
This update refactors the stock account module to make it easier to manage inventory ownership checks. Previously, changes to ownership required extensive modifications; now, it's simpler to add new features and customizations related to inventory valuation based on owner. This improves the system's adaptability and future development.
Original PR description
This PR adds a refactoring of the owner_id check within the stock_account module. The purpose of this refactoring is to prepare for a custom module that will value inventory based on specific ownership. This refactoring allows for extending to the functions as needed. @qrtl Forward-Port-Of: odoo/odoo#157614 Forward-Port-Of: odoo/odoo#155694
62 changes
New functionality added to Odoo
Spreadsheet users can now comment directly on cells, mention colleagues, and resolve discussions once complete. Notifications can bring users back to the relevant discussion, making collaboration around spreadsheet data clearer and faster.
French companies can now generate XML exports for required Intrastat declarations, including the EMEBI statistical survey and VAT recapitulative statement. This helps users prepare the correct French reporting files for intra-EU goods movements with the appropriate detail level based on the selected export type.
Original PR description
Add an intrastat xml export format for the French localization. French companies can submit two different documents: - “enquête mensuelle statistique relative aux échanges de biens intra-UE (EMEBI)”…
Add an intrastat xml export format for the French localization.
French companies can submit two different documents:
- “enquête mensuelle statistique relative aux échanges de biens intra-UE (EMEBI)” wich is a statistical survey to be filed for intra-EU arrivals and / or dispatches of goods,
- “Etat récapitulatif TVA”, which is a VAT recapitulative statement containing the client listing, to be filed for intra-EU dispatches only (intra-EU deliveries; transfers of own goods; call off stock movements; simplified triangulation).
When exporting, the user therefore has 3 choice of export, either only the EMEBI document, the Vat summary statement, or both. Depending on the export type and the chosen export flow for the EMEBI document, different regime are included in the XML items.
Regimes and detail level to export:
- EMEBI:
- Only Arrivals : 11 detailed
- Only Dispatches : 21 detailed
- Arrivals and Dispatches : 11 detailed + 21 detailed
- Vat summary statement: 21 short
- EMEBI + Vat summary statement:
- Only Arrivals (for EMEBI): 11 detailed + 21 short
- Only Dispatches (for EMEBI): 21 detailed
- Arrivals and Dispatches (for EMEBI): 11 detailed + 21 detailed
task-3507060Knowledge users can now add an Excalidraw room to an article with the new /draw command, making it easier to capture visual ideas directly alongside written content. The feature embeds a pre-created Excalidraw+ room and preserves the link when moving between articles.
Original PR description
This commit adds a new command to the editor of Knowledge, `/draw`. It creates an `<iframe>` inside the editor linked to a room ExcaliDraw that the user created in advance with its Excalidraw+ account. This enables the user to draw inside a canvas all of their ideas instead of having to write them inside the article. We are creating a new Behavior called `DrawBehavior`, this behavior uses the data-behavior-props of its anchor to store the URL of the room. This is necessary because iframes are sanitized by the editor, meaning that everytime we change article the iframe is removed from the body and the url would be lost everytime we change article. We unfortunately cannot embed public rooms as this is a limitation of ExcaliDraw themselves. In order to have public rooms, the usage of their React Library is necessary which is not compatible with the OWL Framework and would require a lot of adjustments for it to work. task-3060490
Enhancements to existing features
A new automated test checks that table appointments appear correctly in the restaurant point-of-sale view. This helps prevent future changes from breaking appointment visibility for restaurant staff.
Original PR description
This commit adds a test for the pos_restaurant_appointment. The test creates an appointment for a table and checks if the appointment is displayed underneath the table.
Helpdesk canned responses now have clearer access controls so users only see or manage responses appropriate to their role. This reduces accidental misuse while keeping support teams efficient when replying to customers through Helpdesk and live chat.
Original PR description
See https://github.com/odoo/odoo/pull/138486
The document sharing pop-up has been streamlined with clearer defaults, including an automatic name for new share links. This makes sharing documents faster and easier for users while reducing manual setup in related document workflows.
Original PR description
[IMP] documents : improve share modal UI This commit improves the UI of the share form dialog. It adds default name for the link and changes the type of action field from Selection to Boolean. taskid:3177098
Appointment scheduling now shows organizer conflict warnings in the standard appointment app, even when HR leave management is not installed. This helps users spot double-booked appointments earlier, including while creating new events, reducing scheduling mistakes.
Original PR description
When installing appointment_hr, users will get a warning in the small form of the gantt view if there is a conflict between another appointment and this appointment for the organizer. We move that code to appointment so that users may get the warning of conflicting events even when "hr leaves" are not a available. https://github.com/odoo/upgrade/pull/5800 task-3700412
This update standardizes how Odoo checks whether a user belongs to a group, removing older ambiguous behavior and making permission checks more predictable. It affects several business apps but is mainly an internal cleanup intended to reduce confusion and prepare for future simplification of debug-related behavior.
Original PR description
[IMP] base: Remove `user_has_groups` and env.user fallback in `has_group` The user_has_groups method calls `self.env.user.has_group`, with the difference being a split (and the negative group '!' used only for the views) of the provided string and management of `group_no_one` using `request.session.debug`. The use of `user_has_group` is quite confusing because it does not relate to the current record but to the environment. The `has_group` method is also confusing because if it is applied on an empty recordset then there is a fallback on `env.user` otherwise it uses the current record. The change makes it possible to unify the API and remove ambiguity and make method calls explicit, and make the groups independent of the session. Upcoming changes being the removal of group_no_one and decreasing the number of session.debug usages. see: https://github.com/odoo/odoo/pull/151597
Users can now publish social posts that contain images without requiring a written message. This makes image-led campaigns easier to create and keeps tracking information available by using the attachment name when no message is provided.
Original PR description
Purpose ======= Allow posting just images in a social post. Specification ============== This commit allows users to post images without a message. Technical ========= - It replaces the old constraint with `_check_message_or_image_not_empty`. - It alters the way UTM is prepared for social as previously we prepare UTM based on message but now it prepares UTM based on an attachment name if the message is not present. Task-3667674
Gantt views now offer a sparse display mode where each scheduled item appears on its own row, making timelines easier to read. Project task dependency views use this clearer layout, and dependency connectors can now be shown across more grouping levels.
Original PR description
This PR brings two improvements to the gantt view: - a new "sparse" display mode in which each gantt pill is put in its own row. - the possibility to display connectors for any number of groupbys. We also make the project tasks gantt views use the mode "sparse". Part of task `3601456`
Timesheets created on certain unvalidated field service tasks will no longer automatically reuse the task’s sales order line when no matching line is found for the employee. This avoids misleading billing or sales references and makes the timesheet information clearer for users.
Original PR description
Before this commit, when an employee timesheeted in an unvalidated FSM task which has a mapping for that employee and that no SOL was found in the SO according to that mapping, the SOL of the timesheet was set to the SOL of the FSM task by default. Which could lead to confusion for the user. Now, the SOL of the timesheet is set to False in such conditions. task-3510920
Public Knowledge pages now show only the relevant published article subtree instead of every published article, making navigation less cluttered and better scoped to the shared link. Publishing an article also publishes its children so public users can browse the intended section as a focused sub-site.
Original PR description
This commit improves the front-end part of Knowledge which was until now a bit confusing. The old version of the front-end displayed all of the published articles which resulted in the view being really cramped, and a public user could access unrelated articles to the one he was given the link for. When a user publishes an article we now automatically publish its children in order to create subtrees containing a part of the published articles. This way sub-sites are created for the public users, when they access an article via the specific `/knowledge/article/<article_id>`. Only published articles that are below a root, which is the highest published ancestor are thus visible on the front-end. The query counter of the 'test_article_home_page' was adapted as we changed the way the 'first accessible article' is retrieved to also take into account visible articles. task-3607868
This update makes several Odoo screens and flows easier to use, including cleaner marketing automation cards, clearer wording, better WhatsApp template guidance, and improved appointment calendar behavior. It also removes automatic CRM appointment tagging and refreshes placeholder examples so users see more practical guidance.
Original PR description
This PR includes several commits grouped by module / feature. The details are available in commit messages. The main changes are: - Clean the design of marketing automation activity card - Various rewordings - Remove constraints on the whatsapp template buttons - New alias builder placeholders - Remove appointment crm tag COM PR: https://github.com/odoo/odoo/pull/155399 UPG PR: https://github.com/odoo/upgrade/pull/5791 Task-3653289
This update standardizes how the activity and message panel is defined across many business forms. It reduces duplicated setup behind the scenes, making future maintenance easier while keeping the user experience unchanged.
Original PR description
Remove all fields from chatter arch and simply use `<div class="oe_chatter"/>` with optional `options` attribute follow up of odoo/enterprise#57020 [Related Odoo PR](https://github.com/odoo/odoo/pull/156463) [Related Upgrade PR](https://github.com/odoo/upgrade/pull/5780)
The close reasons form for subscriptions now uses clearer wording for portal visibility and includes added guidance. When a close reason is not selectable in the portal, related portal options are hidden, making the setup easier to understand and reducing configuration mistakes.
Original PR description
In this PR, the user interface for the close reasons form is enhanced. the field string visible_in_portal is modified to Selectable in Portal and additional guidance is provided for this field. A new condition is introduced, ensuring that if the field is set to false, the subsequent section becomes invisible otherwise, it remains visible. task-3776667
Referral sharing and social push notifications were updated to keep working with a changed link tracking service. This is a behind-the-scenes compatibility improvement that helps shared links continue to be created reliably.
Original PR description
also impacted: social_push_notifications `linkTracker.search_or_create` now expects a list of dictionaries. See COM PR Task-2788965
The appointment calendar now shows selected and unavailable scheduling areas with clearer colors, making availability setup easier to understand. Existing events no longer appear draggable or interactive while creating availability slots, reducing confusion for users.
Original PR description
### Adapt slot-creation mode colors This PR improves the selected and non-clickable areas in the calendar when the "Schedule availabilities" button is clicked. The background colors of the…
### Adapt slot-creation mode colors This PR improves the selected and non-clickable areas in the calendar when the "Schedule availabilities" button is clicked. The background colors of the `o_calendar_slot` used a green color applied in JS which didn't render well with the black text. This has been removed from the JS to apply the color in the SCSS instead. ### Disable events interaction in slot-creation mode Prior to this commit, when we were in slot-creation mode, we could always hover and drag events that already existed, but nothing happened. To fix this UX issue, we disable all interactions with these events. task-3630630 part of task-3575827 | Before | After | |--------|--------| |  | <img width="1787" alt="Capture d’écran 2024-03-12 à 11 19 17" src="https://github.com/odoo/enterprise/assets/80679690/924f2115-b182-4461-a5e4-53a5b43b3818"> | task-3630630 part of task-3575827
Resolved issues and error corrections
Recurring shifts now handle existing overlapping shifts more accurately when shift lengths differ. This reduces cases where employees are incorrectly treated as available or busy, helping planners create more reliable schedules while still falling back to open shifts when needed.
Original PR description
When generating recurrent shifts, we check whether the resource is busy or not and if they are, we generate the recurrent shift as an open shift. Currently, we check whether the resource is busy by…
When generating recurrent shifts, we check whether the resource is busy or not and if they are, we generate the recurrent shift as an open shift. Currently, we check whether the resource is busy by seeing whether there are any overlapping slots already for that resource and by checking that the allocating percentage for all overlapping slots wasn't above 100%. That is quite naive and only works when all the overlapping slots are of the same duration. This task should change the implementation in order for it to work with different duration slots. We do this by comparing the total planned hours between the overlapping slots to the total hours in the overlapping period. **Disclaimer:** This does not respect the working hours of the employee: Let Bob work from 9:00 to 17:00. If shift A is planned from 8:00 to 17:00 (8h) and recurrent shift B is planned from 16:00 to 17:00 (1h). In this scenario, the recurrent shift will be planned normally because the total hours in the overlapping period are 9 and the total hours being planned are also 9. We do not take the fact that Bob should work 8 hours :) task-3806681
A recent change in the HR app caused some Belgian payroll and salary configuration screens to display incorrectly. This fix restores the expected fields in those Belgian modules, helping users continue managing job-related payroll settings without disruption.
Original PR description
In response to the removal of certain fields from the hr module's job view on Task-3499251, inheritance in l10n_be_hr_payroll and l10n_be_hr_contract_salary views were disrupted. To address this issue, the affected fields have been set to invisible in the hr module and are now conditionally made visible within the dependent modules. Related PR causes issue: https://github.com/odoo/odoo/pull/141770
Images in the Social kanban view now load from the correct address after a recent URL routing change. This prevents broken image previews and keeps social content management visually consistent for users.
Original PR description
Bug === Since odoo/odoo@c63d14a0485a553b74a8457aee158384e9ae6d3f the base URL is /odoo and not /web, but the image route still use /web, so the URL must be absolute, otherwise the browser will try to fetch /odoo/web. Task-3805736
Barcode input fields are now larger in product addition, line editing, and inventory adjustment screens, making them easier to use. An unnecessary link on the location field was also removed to reduce confusion during warehouse operations.
Original PR description
With this commit =============== Enlarged barcode input fields in Add Product, Edit Line, and Inventory Adjustments sections, and removed the useless link to the location field. TaskId: 3516205
The Austrian financial reports now produce a balanced Balance Sheet by adding missing account classifications and separating current-year results from carried-forward profit or loss. This helps businesses produce reports that better match official Austrian reporting requirements and reduces the risk of incorrect statutory filings.
Original PR description
According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss in excess for the current year has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet found at https://www.bmf.gv.at/services/finanzonline/informationen-fuer-softwarehersteller/softwarehersteller-e-bilanz.html Community PR: https://github.com/odoo/odoo/pull/147108 taskid: 3060790
Intrastat report values are now taken from accounting entries in the company currency instead of recalculating from invoice line subtotals. This makes reported amounts more reliable, while still correctly valuing fully discounted goods using the appropriate exchange rate.
Original PR description
Amounts on the intrastat report should always be in the company currency. At present the intrastat report retrieves the value of the line subtotal (or the unit_price * quantity if the price_subtotal…
Amounts on the intrastat report should always be in the company currency. At present the intrastat report retrieves the value of the line subtotal (or the unit_price * quantity if the price_subtotal is equal to zero). The current behaviour is to retrieve the currency rate at the invoice date of the line, and calculate the value by converting to the company currency using this rate. Since the journal items are always in the company currency, it makes more sense and is more reliable to retrieve the balance of the line. This commit adapts the sql query that retrieves the data for the intrastat report. Instead of the "value" column of the report being retrieved using the "price_subtotal", we instead use the "abs(balance)", since the balance of the line is always in the company currency. In the case where the line has been fully discounted, is is still necessary to report the value of the goods being gifted. In this case, since there is no amount on journal items in the company currency, conversion still needs to occur. The existing method is to multiply the price_unit by the quantity (applying the conversion outside of this query). This commit adds a lateral join to the query so that conversion can be performed from within the query. The lateral join fetches the most recent conversion rate to the invoice date so that it can be applied to the price_unit * quantity. task-id: 3477631
This fixes a configuration screen issue in the French payroll module caused by an invalid visibility setting. It helps ensure payroll settings display correctly and reduces the chance of confusion or errors when administrators configure French payroll.
Portal and member users can now view published Knowledge articles that include embedded kanban content without hitting a generic error. The fix ensures published article stages are readable when needed, improving access for shared website knowledge pages.
Original PR description
**Current behavior before this PR**: -> Create 1 article that has an embedded kanban and 1 article inside a kanban(both articles are published). Now if the user opens this article from another user - member/portal, the user gets an error like 'Something went wrong'. **Reason:** -> Access to the Kanban stage was only for the user who had access to that article, there was no record rule defined that the stage was shown to the member/portal user if the article was published and the article was an item article. **Solution:** -> In previous versions there was a temporary fix that was added here(https://github.com/odoo/enterprise/commit/e9f63e0aa0bb51e2d686473227671ab392d56b9e) so removing that fix and adding the access rule which allows other users to read stages if the article is published. **Desired behavior after this PR:** -> Kanban will appear properly with read access to the portal/member if the article is published. **Task**-3486083
Code cleanup and technical improvements
The grid and Gantt views were updated to use a newer internal display mechanism. This prepares these views for upcoming work while keeping the visible user experience essentially unchanged.
Original PR description
The hook useVirtual has been replaced by a new hook useVirtualGrid. We adapt the GridRenderer and the GanttRenderer to that change. This is done in preparation of task `3601456`. Co-authored-by: Bruno Boi <boi@odoo.com> Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
This refactor aligns Enterprise inventory-related features with the updated stock movement rules from Odoo Community. It helps keep deliveries, rentals, field service stock, subscriptions, manufacturing planning, and barcode flows consistent with the new inventory logic.
Original PR description
Adaptions to the new push rules. More informations on the Community side. See odoo/odoo#156437 Task-3611243
Miscellaneous changes
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it. # Explanation: - When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign. # Steps To Reproduce: - Go to the helpdesk > Configuration > Teams. - For a team (E.g. Customer C
Original PR description
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket…
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it. # Explanation: - When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign. # Steps To Reproduce: - Go to the helpdesk > Configuration > Teams. - For a team (E.g. Customer Care ) tick Random for Assignment Method. Then, add two users to the team. - Create a ticket and Note the Assigned to user. - Create a another one with empty 'Assigned to' field. - Create another ticket and notice how the automation did not apply and the ticket was assigned to the same user. # Solution: - add a filter in the search domain of the last_assigned_user to make sure it returns the actual last assigned user. opw-3746215 Forward-Port-Of: odoo/enterprise#58415 Forward-Port-Of: odoo/enterprise#58084
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 &
Original PR description
This commit changes the danish csv report's header to match with the correct Danish documentation requirements. The Danis government's documentation for the annual report accounting file seems to have disprepancies between the PDF and the website. We got a feedback that the generated CSV did not follow the requirements given for regnskab basis at the following link: https://erhvervsstyrelsen.dk/vejledning-upload-af-regnskabsfil-i-regnskab-basis Based on the documentation chapter 3 & 4, the top row of the csv file (header) should consists of: KONTONUMMER_20230131, KONTONAVN_20230131, and VAERDI_20230131 task-id: None Forward-Port-Of: odoo/enterprise#58477
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741. ### Steps to reproduce * make sure you're on an instance running on Windows [^1] * install `account_accountant` * go to any reconciliation model that has Auto-Validate enabled * click on 'Run manually' You should be met with a traceback: `TypeError: '<' not supported between instan
Original PR description
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with…
### Summary Some configuration keys are not available when the system is running on Windows. Using them without fallbacks leads to errors. Issue introduced with 0d7d1a2994f14b80cd8f3644871f87a472821741. ### Steps to reproduce * make sure you're on an instance running on Windows [^1] * install `account_accountant` * go to any reconciliation model that has Auto-Validate enabled * click on 'Run manually' You should be met with a traceback: `TypeError: '<' not supported between instances of 'int' and 'NoneType'` ### Cause The system expects `tools.config['limit_time_real_cron']` to be a number. However, on Windows systems, `limit_time_real_cron` and a few other configuration keys are disabled, and always set to `None`. See https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L488-L497 opw-3752912 opw-3780549 [^1]: For testing on Linux, you can modify these two conditions to behave as if `os.name != 'posix'`: https://github.com/odoo/odoo/blob/6b5a839428b06e09d90631e9824a9b594ff8f4f5/odoo/tools/config.py#L494-L497 https://github.com/odoo/odoo/blob/7fc9a0bd0a1871b14c508cce73e0f103de9c1283/odoo/modules/registry.py#L50-L57 Forward-Port-Of: odoo/enterprise#58550 Forward-Port-Of: odoo/enterprise#57728
Before this commit, the origin doc number set when doing a credit note from the pos was the name of the reversed move instead of its l10n_latam_document_number which is now the case. Forward-Port-Of: odoo/enterprise#58480
Original PR description
Before this commit, the origin doc number set when doing a credit note from the pos was the name of the reversed move instead of its l10n_latam_document_number which is now the case. Forward-Port-Of: odoo/enterprise#58480
Steps to reproduce: - Install appointment - Go in calendar -> Online Appointments - Click on the link button - Remove the appointment type Issues: We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired. opw-3749154 Forward-Port-Of: odoo/enterprise#58630 Forward-Port-Of: odoo/enterprise#57240
Original PR description
Steps to reproduce: - Install appointment - Go in calendar -> Online Appointments - Click on the link button - Remove the appointment type Issues: We get a link to make an appointment in a chosen type. After checking with the product owner this behaviour is not desired. opw-3749154 Forward-Port-Of: odoo/enterprise#58630 Forward-Port-Of: odoo/enterprise#57240
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
Original PR description
In this fix we made the account reports in dark mode look similar to their light mode counterparts task: 3770541 Forward-Port-Of: odoo/enterprise#57773
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the v
Original PR description
The aim of this commit is handling properly the UK case when we unfold lines in the intrastat report. For some reasons, instead of using GB , we have to use XU for the product origin country code. The problem was that we used this country code to find children lines when the user unfold the Dispatch/Arrival line. As the country code XU doesn't exist, for all these lines, we don't get any children lines. Now, before we build the ID (that we'll use after to fetch children lines), we change the value for the right country code. no task id Forward-Port-Of: odoo/enterprise#58620 Forward-Port-Of: odoo/enterprise#58585
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` compon
Original PR description
To reproduce the issue: - Switch to the `Activity` view. - Click `+ Schedule Activity`. - The dialog box opens up with a list of documents. - Scroll down to spot the `DocumentsInspector` present at the bottom. Reason: - The dialog box renders the list view of the related model, depending on the module it is invoked in. - There is no condition present to evaluate when to display the `DocumentsInspector` and when not to. Fix: - Since the inspector is invoked inside the `Dialog` component, we check that condition. After this commit: - We no longer see the inspector inside the Dialog box. Task-3714496 Forward-Port-Of: odoo/enterprise#58484 Forward-Port-Of: odoo/enterprise#56056
Since the code is called in a safe_eval, instead of in the codebase in https://github.com/odoo/enterprise/pull/32970 We cannot use a variable in a lambda as it raises a NameError on the employee variable called in the filtered function. So to avoid the filtered function we loop on the leave and aggregate manually by employees. Forward-Port-Of: odoo/enterprise#58590
Original PR description
Since the code is called in a safe_eval, instead of in the codebase in https://github.com/odoo/enterprise/pull/32970 We cannot use a variable in a lambda as it raises a NameError on the employee variable called in the filtered function. So to avoid the filtered function we loop on the leave and aggregate manually by employees. Forward-Port-Of: odoo/enterprise#58590
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}` Forward-Port-Of: odoo/enterprise#58486
Original PR description
The criterium might be evaluated but be an int (e.g 0). In that case the computation is stuck in an eternal loop where the criterium is added to `to_treat`. This commit adds a fix for the criterium_val type check. This happens when using subformulas like `if_other_expr_{above,below}`
Forward-Port-Of: odoo/enterprise#58486…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
Original PR description
…en options Add the possibility to call the send & print with *only* a set of options. All other checkboxes are therefore set to False, instead of their default computed value. Forward-Port-Of: odoo/enterprise#58574
Since the downpayment product has been removed, we are no longer able to send a invoice CFDI containing some down payment lines. ticket_id: 3795193 Forward-Port-Of: odoo/enterprise#58537
Original PR description
Since the downpayment product has been removed, we are no longer able to send a invoice CFDI containing some down payment lines. ticket_id: 3795193 Forward-Port-Of: odoo/enterprise#58537
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Chang
Original PR description
This PR fixes 2 issues with multi-line fields: 1. when inserting long lines in multi-line text field and generating the final pdf, the multi-line did not respect its boundaries at all. This happened because font size wasn't applied properly on the frontend, so there was a difference between fontsize inside the textarea and the fontsize when writing lines on the document which caused the lines to overflow horizontally. 2. Text alignment is not applied when generating the final pdf. Changes: 1. remove the fixed textarea font-size property and allow it to be set dynamically based on the zoom factor 2. apply text alignment on the multiline field Task: 3696347 Forward-Port-Of: odoo/enterprise#58289 Forward-Port-Of: odoo/enterprise#58035
At the initial evaluation of a spreadsheet with pivots/lists, almost all cells are in error because they are loading. But throwing errors is slow. With this commit, instead of throwing loading errors for every single cell, the error is returned. This commit improves the first evaluation time of spreadsheet the "BE Timesheet" dashboard on odoo.com by ~20%, from ~1716ms to ~1365ms Task: 3736190 Forward-Port-Of: odoo/enterprise#58616
Original PR description
At the initial evaluation of a spreadsheet with pivots/lists, almost all cells are in error because they are loading. But throwing errors is slow. With this commit, instead of throwing loading errors for every single cell, the error is returned. This commit improves the first evaluation time of spreadsheet the "BE Timesheet" dashboard on odoo.com by ~20%, from ~1716ms to ~1365ms Task: 3736190 Forward-Port-Of: odoo/enterprise#58616
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
Original PR description
The aim of this commit is handling correctly the VAT number in the Partner VAT Listing. Before, to remove the BE in the vat, we removed the 2 first characters of the vat, it causes an issue when the VAT number doesn't start with BE. This fix is using the `_vat_to_bce` function (from the same module) which convert (if necessary) the VAT into the BCE number. no task id Forward-Port-Of: odoo/enterprise#58597 Forward-Port-Of: odoo/enterprise#58563
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
Original PR description
This PR fixes the name of a method in the list of async functions of the `timerHelpdeskService` service. Forward-Port-Of: odoo/enterprise#58583
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384
Original PR description
The goal is to be able to see cash basis values grouped by analytic. We use the amounts of the analytic lines, with a proportion corresponding to the cash basis amount divided by the real amount. task-3047794 Forward-Port-Of: odoo/enterprise#58408 Forward-Port-Of: odoo/enterprise#33384
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
Original PR description
-Before this commit: When a user lost access to an article which was a favorite, the sidebar was provided with the id of the article anyway, resulting in an error when trying to access its fields, preventing the sidebar from being displayed at all. -After this commit: Articles ids are not provided to the sidebar when they have a favorite related to the current user but that user currently can not access it. opw-3700698 Forward-Port-Of: odoo/enterprise#55590
In 2024, credit card withholding tax is only required for manual documents, we improve the suggestion method and fix the tests Forward-Port-Of: odoo/enterprise#58185
Original PR description
In 2024, credit card withholding tax is only required for manual documents, we improve the suggestion method and fix the tests Forward-Port-Of: odoo/enterprise#58185
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view
Original PR description
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that…
When a user attempts to restore an article with a parent in the trash, a validation error occurs. This is due to the article item getting detached from its parent, violating an SQL constraint that mandates every article item to have a parent. The existing error message lacks clarity regarding the issue and its resolution. This commit aims to enhance the error message for this specific scenario. Steps to reproduce the error: 1. Open Knowledge 2. Create an article 3. Insert an embedded view of article items with /kanban or /list 4. Create an article item (-> The "New" button from the embedded view) 5. Delete the parent article using the "more options" panel 6. Click on the "Open the Trash" button 7. From the list view, click on the article item you created at step 4 8. Click on the "Restore" button from the banner => The user receives a validation error indicating that the article item should have a parent. This error occurs because the parent article is in the trash, and the article item cannot be detached from its parent. TO BE: The user should receive an error message indicating that the article item cannot be restored and that the user needs to restore the parent article first in order to restore the article item. Forward-Port-Of: odoo/enterprise#55442
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forwar
Original PR description
This commit is the counterpart of odoo/odoo#156241 where we rework the logic of computing the visible buttons and those put in a dropdown, in the button box. There's an override in studio to bypass the invisible filter when we have toggled the "Show Invisible" option, so this override needed to be adapted. The fun part is that this was actually not working, because the viewEditorModel wasn't made reactive, so toggling the option didn't produce a re-rendering. Now it does. Task 3778382 Forward-Port-Of: odoo/enterprise#58565
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/enterprise#58459 Forward-Port-Of: odoo/enterprise#52726
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#5
Original PR description
__Current behavior before commit:__ The page crashes when a default search filter without group is set on the "Journal Items to reconcile" list __Description of the fix:__ Add optional chaining to check if groups is not `undefined` __Steps to reproduce the issue on runbot:__ 1. Go to Accounting > Accounting > Reconcile 2. Remove the *groupBy* search filter 3. Save current search and check "Default filter" 4. Refresh the page -> crash opw-3759244 Forward-Port-Of: odoo/enterprise#58137
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Payroll / Configuration / Switzerland / Work Locations; 2. create a new work address; 3. fill in fields & save. Issue ----- Error due to required field `bur_ree_number` being empty. Cause ----- Field is missing from the form. Solution -------- Add `bur_ree_number` to the form. opw-3783244 Forward-Port-Of: odoo/enterprise#58524
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#58439 Forward-Port-Of: odoo/enterprise#56188
Original PR description
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563 Forward-Port-Of: odoo/enterprise#58439 Forward-Port-Of: odoo/enterprise#56188
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selec
Original PR description
When the barcode application has many lines, it becomes slow and unresponsive, especially on mobile devices, which are widely used with the barcode app. Before this commit: Selecting a line in the barcode application triggers the rendering of the whole view. Each line rendered calls the getter `get selectedLine` multiple times, which is slow as it loops over all lines to find the currently selected line. After this commit: Do not call the getter to check whether the current line is selected or not. This reduces the complexity from O(n^2) to O(n). Benchmark: On a laptop and with 2000 lines, selecting the last line took 7.5s before, and 600ms with this commit. opw-3754849 Forward-Port-Of: odoo/enterprise#58182
Since fixed introduced in https://github.com/odoo/enterprise/pull/57590, the context is lost when we call 'update_existing_subscriptions'. As we put a dictionnary returned by '_upsell_context' in the 'with_context' to call write on the subscription, it replace the current context by the new one. As we just want to add values to the context and not replace it, we get the key/values as named arguments to update the current context and not replace it Forward-Port-Of: odoo/enterprise#58530
Original PR description
Since fixed introduced in https://github.com/odoo/enterprise/pull/57590, the context is lost when we call 'update_existing_subscriptions'. As we put a dictionnary returned by '_upsell_context' in the 'with_context' to call write on the subscription, it replace the current context by the new one. As we just want to add values to the context and not replace it, we get the key/values as named arguments to update the current context and not replace it Forward-Port-Of: odoo/enterprise#58530
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Original PR description
The new UPS REST module was not neutralized. This commit makes sure that the credentials of the shipping methods are replaced with dummy values, so that shipping labels are not created by mistake. opw-3799821 Forward-Port-Of: odoo/enterprise#58489
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in ca
Original PR description
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in case we are in debug mode. The display of the error allows to open the incriminating views in a dialog, and see some basic information on them, as well as, obviously, the error message and type. opw-3735973 [1]: 62c167f87176674cbabad976d93eeb717f73df7a Forward-Port-Of: odoo/enterprise#58491
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the database before going to the base level default of English. **Steps to reproduce:** 1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish 2. Deactivate the default English language pack 3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Tod
Original PR description
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the…
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the database before going to the base level default of English. **Steps to reproduce:** 1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish 2. Deactivate the default English language pack 3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Todos los recibos de nómina`, then select any report and click the Imprimir (Print) button 4. Observe some sections are in English **Cause of the issue:** When an employee's language is not set, English is used as a default. **Fix:** Look to use the environment's language if the Employee's is False. Ammended to fix other situations in hr_payroll where an employee language is accessed without using `env.lang` as a primary fallback. opw-3747839 Forward-Port-Of: odoo/enterprise#57780
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at
Original PR description
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at the bottom: `[44] < ([00] + [01] + [02] + [03] + [45] + [46] + [47] + [48] + [49]) * 200 if [88] > 99.999` opw-3767675 Note: confirmed by TSB on the ticket Forward-Port-Of: odoo/enterprise#58343
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
Original PR description
Create a tax group without country and property_tax_payable_account_id = False. Create a tax with this group. Create a new tax report, you are redirect to configure tax group. --> Issue this tax group is not show. X-original-commit: 860512b1eee26d0c65bf741173d870df6e76313a Forward-Port-Of: odoo/enterprise#58328
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
Original PR description
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed Forward-Port-Of: odoo/enterprise#57756
This PR fixes a method override not calling the method on super() Forward-Port-Of: odoo/enterprise#58494
Original PR description
This PR fixes a method override not calling the method on super() Forward-Port-Of: odoo/enterprise#58494
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on th
Original PR description
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on the original subscription. As a result, the information is duplicated. Solution: --------- Do not include upsells in the sales report. Note: ----- With the fix, the value is 200 and not 170, because it is not possible to take upsell discounts into account in the sales report (we have to use the subscriptions report). opw-3646388 Forward-Port-Of: odoo/enterprise#58369 Forward-Port-Of: odoo/enterprise#57568
19 changes
Enhancements to existing features
This update refreshes the Spanish language translations for the localization reports module. The changes ensure that Spanish-speaking users see accurate and up-to-date text throughout the reporting features, improving the user experience for businesses operating in Spain.
Original PR description
Community: https://github.com/odoo/odoo/pull/157759
The Mexican EDI Extended module has been updated to use Odoo's standard file handling tools instead of outdated system path methods. This change improves reliability when locating files, particularly in complex system setups with symbolic links, and ensures the module works consistently across different environments.
Original PR description
Replace outdated realpath usage with odoo tools.file_open. Allows file_open to locate file from addons path rather than looking up through realpath. This will resolve potential issues with realpath not finding the proper path of files in certain situations (like a symlink). Worth noting that file_open uses abspath instead of realpath anyway. Forward-Port-Of: odoo/enterprise#58659 Forward-Port-Of: odoo/enterprise#58305
Resolved issues and error corrections
A help message that appears when lxml fails to decode an emoji was providing incorrect installation instructions. The message suggested using the `--nobinary` switch, but the correct syntax is `--no-binary`. This fix ensures users receive accurate guidance if they encounter this error.
Original PR description
If lxml fails to decode an emoji, it indicates to reinstall lxml using `--nobinary` switch, which is incorrect. If you use the suggested command will get a "no such option". The correct switch is `--no-binary`
This fix resolves an error that occurred when registering by-products with lot or serial number tracking in the Shop Floor interface. The system was missing required location information in the context, causing the process to fail. By adding the necessary location details, users can now successfully generate or import lot/serial numbers for by-products without encountering errors.
Original PR description
### Steps to reproduce issue: 1. Create a Product with Lots/Serials tracking 2. Create a BoM with an operation and add Product as By-Product 3. Create a Manufacturing Order using the BoM, click on…
### Steps to reproduce issue:
1. Create a Product with Lots/Serials tracking
2. Create a BoM with an operation and add Product as By-Product
3. Create a Manufacturing Order using the BoM, click on Confirm then Plan
4. Go to Shop Floor, click on "Register [the By-Product]"
- Not the button with the units
6. Click on either "Import Lots" or "Generate Serials"
7. Enter a Lot/Serial number and click on "Generate"
8. Traceback error:
> loc_dest = self.env['stock.location'].browse(default_vals['location_dest_id'])
> KeyError: 'location_dest_id'
### Explanation:
When going through the Shop Floor, the context is missing a lot of elements that are normally passed in the manufacturing order form. https://github.com/odoo/odoo/blob/338173e231355d265ddc88bcef5e9b0a608e248e/addons/mrp/views/mrp_production_views.xml#L432-L437
### Suggested fix:
`default_dest_location_id` is the missing element causing the traceback but fixing it reveals that `default_location_id` is also missing, we then add it to the context as well.
Test is done in Enterprise while fix is in Community.
opw-3719439This update fixes critical issues when importing Mexican invoices (CFDI) with unknown customers. The system now correctly identifies whether customers are domestic or foreign, properly sets required fields like country and zip code, and prevents incorrect "CFDI to public" settings. This ensures invoices are processed accurately and comply with Mexican tax requirements.
Original PR description
<strike> ## [FIX] l10n_mx_edi: Set "CFDI to public" to true for foreign invoices The field "CFDI to public" is currently only set to true in the domestic to public case (special VAT / Rfc value…
<strike>
## [FIX] l10n_mx_edi: Set "CFDI to public" to true for foreign invoices
The field "CFDI to public" is currently only set to true in
the domestic to public case (special VAT / Rfc value XAXX010101000).
After this commit "CFDI to public" will also be set to true in the
XEXX010101000 case.
related: task-3731058
</strike>
A part of the original PR was reverted before this PR was merged.
That part was left out in this FW port.
Reverting PR: https://github.com/odoo/enterprise/pull/58697
## [FIX] l10n_mx_edi: import: fix partner creation and detection logic
There are currently the following problems when importing an invoice
with an unknown partner. A new partner is created in this case.
For invoices with an unknown domestic partner (no special VAT values):
- (1) There may be a VAT validation error.
- (2) The "CFDI to public" field (l10n_mx_edi_cfdi_to_public) on the
invoice will be set to True. It should be False.
For invoices with an unknown foreign partner (no special VAT values):
- (3) The partner is created w/o country or VAT value (since only
the special VAT / Rfc value XEXX010101000 is used).
Thus the detection logic applied to the partner to decide
whether we are in the domestic non-public, domestic public or
foreign case does not work correctly.
The issues are solved after this commit by the following changes
- (A) The country is set to Mexico for all created partners that are not
from a foreign invoice (XEXX010101000).
- (B) The detection logic to decide the case is updated.
Also see (C).
- (C) The "Foreign Customers" fiscal position is set for partners
created during the import of foreign invoices.
Note on (B) / (C):
We still want to assume that partners without a country are Mexican
partners. This is done since (many) Mexican users will not set an
explicit country for Mexican customers.
(One would e.g. not put the country for domestic letters either.)
This is why we use the "Foreign Customers" fiscal position (C).
### Details
(1)
Due to the missing country the wrong VAT validation is used.
The same error can be reproduced on a runbot when creating a new
customer without country and VAT DEA040805DZ4
(works after setting the country to Mexico).
(2) / (3)
Due to the missing country on the partner the invoice is wrongly
interpreted as a domestic invoice to public (XAXX010101000).
This leads to the wrong "CFDI to public" value.
### task
task-3731058
Forward-Port-Of: odoo/enterprise#57516This fix restores payroll configuration records that were accidentally removed in a previous update to the Luxembourg payroll module. The records are being added back to ensure existing systems continue to work properly, while preventing them from affecting payslip calculations going forward.
Original PR description
In https://github.com/odoo/enterprise/pull/58054 by mistake one record has been removed, and one xml id has been changed. Which is errorious for stable. To solve the issue, we add back records. We added back l10n_lu_employees_atn_transport, in case it is referenced, but we make sure that it won't be added in in the payslip computation.
This fix ensures that when new employees or internal users are created without a profile image, the system automatically generates an avatar based on their name. This improves the user experience by providing a consistent visual identity for all team members from the moment they're added to the system.
Original PR description
Ensure an avatar is generated based on the employee/user name if no image is provided at the record creation (for internal users only). TaskID: 3637523
This fix corrects how credit notes created from the point of sale system reference the original document. Previously, the system was using the internal move name, but now it correctly uses the official document number. This ensures credit notes properly reference the original transaction for compliance and record-keeping purposes.
Original PR description
Before this commit, the origin doc number set when doing a credit note from the pos was the name of the reversed move instead of its l10n_latam_document_number which is now the case. Forward-Port-Of: odoo/enterprise#58480
This fix resolves an issue where developers using VSCode were not receiving autocomplete suggestions for OWL (Odoo Web Library) imports in the enterprise codebase. The fix adds a configuration file that properly exposes the OWL module to the TypeScript language server, improving the developer experience and reducing coding errors.
Original PR description
On an IDE (VSCode) with a TypeScript Server. For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit [1]. Our main hypothesis is that, due to commit [1] who…
On an IDE (VSCode) with a TypeScript Server.
For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit [1].
Our main hypothesis is that, due to commit [1] who points to odoo/addons, import lines in those files are resolved first in the scope of the odoo directory.
Consider a file in enteprise:
```js
import { registry } from "@web/core";
import { Component } from "@odoo/owl"
```
From the TSServer point of view it needs to resolve `@web` first, which itself has to resolve `@odoo/owl` in its directory scope, that is, in the scope of odoo community. It then keeps it in cache for later and importantly shadows the one present in enterprise/node_modules. Only then the explicit `@odoo/owl` is resolved with the odoo community's owl module from the cache.
Since that owl module from the cache is not explicitly available in enterprise, there are no imports suggestions.
This commit defines a main.d.ts file that only exposes the community's `@odoo/owl` explicitly. This hypothesis is confirmed by some hints that we discover during debugging:
- delete odoo/nodule_modules in enterprise: @odoo/owl becomes a suggestion again.
- comment the path line of @web/* in enterprise/jsconfig.json, owl is suggested.
- replace the copy of node_modules in enterprise by a symlink to odoo/node_modules, owl is suggested. This last one should also be considered as a valid fix for the current issue, as node_modules in odoo and enterprise *are the same*.
After this commit, owl is proposed for imports in VSCode.
[1]: 62cbb20
Forward-Port-Of: odoo/enterprise#58601This update resolves a crash that occurred when users attempted to export the intrastat report to PDF. The issue was caused by the system trying to process empty values incorrectly. The fix ensures that empty fields are properly handled during the PDF generation process, allowing users to successfully print their intrastat reports.
Original PR description
When a user tries to print in PDF the intrastat report, he gets a traceback because the pdf template tries to call `len()` on the name and the name equals `None`. The aim of this commit is using the `_build_column_dict` method instead of formatting the column by ourselves. By doing this, the `None` value are set for an empty string. no task id
This fix resolves an access error that occurred when creating batch payments for subsidiary companies or branches. The security rules have been updated to properly recognize parent company relationships, allowing users to successfully create and save batch payments across company hierarchies without encountering permission errors.
Original PR description
When creating a batch payment with a sub company, we get an access error. Steps: - Create a company X and a branch Y - Select branch Y - Create and validate a payment P - Create a batch payment with payment P and save -> AccesError: ... "Due to multi company" With this commit, we adapt the domain in the security rule to take the parent company into account. opw-3716721 Forward-Port-Of: odoo/enterprise#58526
This update removes the year value from Hong Kong payroll time off type names. Previously, the year was hardcoded in the name, which meant it wouldn't automatically update when the calendar year changed. By removing the year from the name, the time off types will remain accurate and relevant without requiring manual updates.
Original PR description
Steps to reproduce: - Install l10n_hk_hr_payroll Current behaviour: - Time off type name contain year value Expected behaviour: - Time off type name should not contain year value Explanation: - Year changed will not update the time off type name, therefore better to not include the year value inside the name X-original-commit: 224aa76
This update brings Portuguese Balance Sheet and Profit & Loss reports into compliance with the official general regime regulations. The financial statements now correctly align with the Portuguese accounting standards (SNC 2016), ensuring that companies using Odoo in Portugal will generate accurate regulatory reports that match government requirements.
Original PR description
In Portugal, there are four regimes of regulations, which include a CoA and financial statements: general regime, small companies, micro-companies and non-profits. Regulations are published at https://www.cnc.min-financas.pt/snc2016.html As a result of the refactor in https://github.com/odoo/odoo/pull/87572, the CoA (almost) perfectly follows the general regime regulation. However, the financial reports are not up-to-date. This commit implements the Portuguese Balance Sheet and Profit and Loss for companies under the general regime, as defined at pp.42-45, 53-55 of https://www.occ.pt/fotos/editor2/manualapoiosaf-t_1.pdf. The correspondence between account 'Taxonomy Codes' and account codes was taken from https://www.occ.pt/fotos/editor2/taxonomiasplanocontas_fev2019.pdf. Community PR: https://github.com/odoo/odoo/pull/157131 taskid:3060790 Forward-Port-Of: odoo/enterprise#58387
This update fixes a bug where the system could incorrectly select the wrong partner when multiple partners share the same name. The fix improves the accuracy of partner identification in accounting operations, ensuring the correct business partner is selected during bank reconciliation and invoice processing.
Original PR description
…ther This commit only improve the test according to change done in odoo/odoo. Community PR: odoo/odoo#155986 Forward-Port-Of: odoo/enterprise#58547 Forward-Port-Of: odoo/enterprise#57846
This fix corrects an issue where the helpdesk automatic ticket assignment feature was not properly balancing workload across team members when unassigned tickets were present. Previously, when a ticket without an assignee was created, the system would incorrectly assign subsequent tickets to the same person instead of distributing them equally. This update ensures fair and balanced ticket distribution across all team members.
Original PR description
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket…
# Issue: - When a ticket is created, the automatic assignment rule "Each user is assigned an equal number of tickets" is not being applied correctly in the scenario where we have a unassigned ticket that preceeds it. # Explanation: - When searching for the last_assigned_user in determine_user_to_assign method we get none which misses the count and we end up with wrong user to assign. # Steps To Reproduce: - Go to the helpdesk > Configuration > Teams. - For a team (E.g. Customer Care ) tick Random for Assignment Method. Then, add two users to the team. - Create a ticket and Note the Assigned to user. - Create a another one with empty 'Assigned to' field. - Create another ticket and notice how the automation did not apply and the ticket was assigned to the same user. # Solution: - add a filter in the search domain of the last_assigned_user to make sure it returns the actual last assigned user. opw-3746215 Forward-Port-Of: odoo/enterprise#58415 Forward-Port-Of: odoo/enterprise#58084
This fix prevents discounts from being unexpectedly recalculated when confirming non-subscription sales orders. Previously, the system was unnecessarily updating subscription settings during order confirmation, which triggered automatic discount recalculations. This change ensures discounts remain stable unless there's a genuine reason to update them.
Original PR description
`discount` field on `sale.order.line` model is configured in sale_subscription to be recomputed when the order `subscription_state` is modified. Therefore, updates to that field should be avoided unless necessary. Nevertheless, in the override of `action_confirm`, the subscription state was always updated to False for non subscription orders, leading to an unexpected recomputation of discounts. opw-3740645 See also: https://github.com/odoo/odoo/pull/157699
This update fixes an issue where users were not prompted to close video previews in the Documents module. The fix adds a missing step to the guided tour that instructs users how to properly close preview windows, improving the user experience when working with document previews.
Original PR description
Before this commit: - We do not get the prompt to close the YOUTUBE video preview. After this commit: - We get the prompt to close the preview. Task-3748193 Forward-Port-Of: odoo/enterprise#58519 Forward-Port-Of: odoo/enterprise#56812
SODA files sent via email were not being recognized properly because the system was treating them as plain text instead of XML files. This fix updates the file detection logic to correctly identify SODA files regardless of how they are received, ensuring they are processed correctly in the accounting system.
Original PR description
Bug === When we send a SODA file by email, it is not detected as a SODA file. Technical ========= Since odoo/odoo@82142475f70517045f1fbbd700e202b8dd0a522b the XML files are imported as plain text. But the check for the SODA file check only the mimetype XML. Task-3792364 Forward-Port-Of: odoo/enterprise#58568
Managers can now see and validate time off allocations without manually entering a description. Previously, when employees requested time off through the dashboard, the allocation description wasn't automatically filled in, forcing managers to manually add it before approving. This fix ensures the description is properly computed and available for managers during the approval process.
Original PR description
Currently when a manager goes to validate an allocation, the name/description of the allocation is not displayed. This introduces the need for manager to name each allocation manually to be able to…
Currently when a manager goes to validate an allocation, the name/description of the allocation is not displayed. This introduces the need for manager to name each allocation manually to be able to validate them. Steps to reproduce: ------------------- * Open **Time off** app * On the dashboard, select **New allocation Request** * Save the allocation as it is * Select **Management** > **Allocations** > Observation : The description field of the new allocation is not filled. * Select the new allocation * Validate > Observation: Unable to validate, description field required. Why the fix: ------------ The description of an allocation corresponds to the field `name` in the model `hr_leave_allocation`. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L40-L45 In the compute method of this field, the name gets actualy computed in the context of `is_employee_allocation`. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/hr_holidays/models/hr_leave_allocation.py#L169-L177 We are in the context `is_employee_allocation` either by asking a new allocation from the dashboard, either by being on the `hr_leave_allocation_action_my` view. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/static/src/views/hooks.js#L62-L65 https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/views/hr_leave_allocation_views.xml#L456 On those two views, the description is computed AND readonly. Since the name is readonly, it means that the inverse of the compute method will not get called, thus never setting `private_name`. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L182-L186 When a manages goes to approve an allocation, he goes through **Management** > **Allocations**. The views used are either `hr_leave_allocation_view_tree` or `hr_leave_allocation_view_form_manager`. On those views, we are not in the context `is_employee_id`, the allocation name is no more readonly AND the name is required in order to validate the allocation. For a manager to be able to see anything in the description, the field `private_name` must be set. https://github.com/odoo/odoo/blob/2bcccbfb910609f6cf54d607d198aae4c5b28b86/addons/hr_holidays/models/hr_leave_allocation.py#L164-L178 This fix aims to create consistency in the creation of allocations. We can observe that the name is not in `vals` in the `web_save` function when creating an allocation through the dashboard or the tab **My Time** > **My allocations**. However, when creating an allocation through **Management** > **Allocations**, name can be found in `vals`. https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/models/models.py#L69-L69 `vals` corresponds to `changes` in this function: https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L1045-L1051 To have the name added to `changes`, we ultimately need the following condition to be false. https://github.com/odoo/odoo/blob/764088d6d5a5a18be451ec26b886691718bef835/addons/web/static/src/model/relational_model/record.js#L592-L599 In the manager flow, this is the case as `name` is not readonly. As a regular employee, the only possible way to have this false while keeping the `name` readonly, is to make it an active field. `name` in now in `vals` and thus in `vals_list` in the create method. This now allows to set `private_name` through the inverse function of name. opw-3722093