Daily updates from Odoo
Friday, March 15, 2024
62 changes · master
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