Wednesday, January 31, 2024
47 changes · 17.0
New functionality added to Odoo
A new web_studio_export module has been added to Odoo Enterprise that enables users to export module data with industry-specific information. This feature allows businesses to extract and manage customized data exports based on specific criteria, improving data portability and business intelligence capabilities within the Web Studio customization environment.
Original PR description
task id: 3446301
This update makes Belgian payroll localization modules available for translation on Transifex by exporting source terms and configuring translation resources. It also brings forward existing translations from Odoo 16, ensuring the payroll system can be used in multiple languages across Belgium and other regions.
Original PR description
This pull request: 1. re-exports the source terms of Belgian payroll localization modules 2. adds the corresponding resources to the .tx/config so that's it available for translation on Transifex 3. forward-ports translations from Odoo 16
A new spreadsheet report feature has been added for GST Return 1 (GSTR1) filings in India. This allows users to generate and review a spreadsheet version of their GST return data before submitting it to the government portal, providing an additional verification step and better data visibility.
Original PR description
Added new module l10n_in_reports_gstr_documents_spreadsheet it allows us to generate a spreadsheet report for gstr1 before sending the json to the portal task-3293298 Forward-Port-Of: odoo/enterprise#55356 Forward-Port-Of: odoo/enterprise#40589
Enhancements to existing features
This change appears to adjust how Odoo exports master data when using Studio customizations. It may help businesses move or reuse configured data more reliably, though the pull request details are limited.
Original PR description
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
Resolved issues and error corrections
Fixed an error that could block approved expense reports from being posted when the expense was linked to both project and department analytics and set to be re-invoiced to a customer. This helps ensure accounting entries are created successfully for these expense scenarios.
Original PR description
**Current behavior:** Trying to post journal entries for an expense report sheet containing an expense that has: A) an associated analytic distribution with both a Project and Department, and B) a…
This update enhances the automatic SODA file import process used in Belgian accounting. The changes improve document dating by using the generation date from imported files, add accounting period information to transaction references for better tracking, and simplify the account matching interface by displaying combined account codes and names instead of separate fields.
Original PR description
Problem --------- With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved. Objective --------- Adapt the…
Problem --------- With the integration of Codabox in l10n_be_codabox, we need to managed the automatic import of SODA. This is currently done but can be improved. Objective --------- Adapt the following point: 1. Put the date from <GenDate> by default in the date of document 2. Add the period linked to the document in the ref of the document. This info is store in the field <AccountPeriod> 3. In the matching form between SODA account and Account in the company: Merge the account and the name from SODA (to be consistante with the column in which the user should add account) Solution --------- 1. Simply add the date data from the XML in the dictionary that will be passed to the wizard creating the account move and make sure the wizard gives that value in the move create method. 2. Concatenate the formatted <AccountPeriod> text to the ref. 3. Add a compute method to computes the display_name for the current model as it is done in account_account. Use the display name in the wizard view in readonly instead of the SODA account codes and names. task-3615994
This update enhances the invoice sending and printing functionality with improved user notifications. Users will now receive real-time updates when invoices are being processed, including notifications when the batch processing is complete or if any issues occur. The system also now supports multiple languages for downloaded invoice files, and the underlying code has been reorganized for better maintainability.
Original PR description
1. [TECHNICAL] Move send & print files into wizard folder when it's not the case 2. [TECHNICAL] More testing: test cron + cron in multicompany setup 3. Make 'invoices.zip' translatable 4. Use the bus to notify when cron is done (and maybe when it's started ? ) task-id: 3568549
This update adds database indexes to the Point of Sale system to speed up order and payment processing. These optimizations improve the performance of order creation operations, particularly benefiting businesses with large transaction volumes by reducing query execution time.
Original PR description
Add two missing indexes on pos.order and one on pos.payment. These speed up queries executed when calling create_from_ui from the pos interface. #### speedup Customer database with 560 000 pos.orders. Example of queries benefiting from the indexes  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150452 Forward-Port-Of: odoo/odoo#148842
This update enhances the stock management system by allowing customization of which warehouse locations are used when calculating reorder points. This improvement makes the system more flexible and responsive, enabling businesses to optimize their inventory management processes and reduce unnecessary calculations in large warehouse operations.
Original PR description
Description of the issue/feature this PR addresses: This commit allow to inherit the method _get_orderpoint_locations to filter in which location compute orderpoints imrpoving performance and usability --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150256
**Current behavior:**
Trying to post journal entries for an expense report sheet
containing an expense that has:
A) an associated analytic distribution with
both a Project and Department, and
B) a customer to be re-invoiced (requires the expense
to be for a product which permits this operation),
attempting to post the journal entries for the approved expense
sheet will raise a ValueError.
---
**Expected behavior:**
The entries get posted to their respective accounting journals.
---
Steps to reproduce:
0. Install the Project, Accounting, Sales, Expense apps
and enable analytic accounting in the db settings
1. Create a new expense with:
A) an analytic distribution which has
both available fields filled out, and
B) a category that permits a customer to be re-invoiced
(then enter a customer)
2. Create the report, submit it to the manager, approve it,
then attempt to post the journal entries
3. This should cause the traceback, if the process was blocked
try again after deleting any tax rules in the expense
---
Cause of the issue:
The analytic_distribution field in the hr.expense module is
stored as a dictionary. During the process of recording the
journal entries, the keys are converted from a string to
integers. However, when multiple keys are in the dict, the
conversion is set up improperly and fails.
---
Fix:
Modify the conversion sequence so that multiple dict keys are
accounted for.
---
opw-3663082Fixed an issue where subscription products with multiple duration variants were not displaying the correct time period (daily, monthly, yearly, etc.) when customers switched between variants on the website. The fix ensures that when a customer selects a different variant, the pricing period updates correctly to match that variant's settings.
Original PR description
Issue: ====== When having a product with duration variant and they have different temporal units, it will only display the temporal unit of the first selected variant in ecommerce product page. Steps to reproduce the issue: ============================== - Create a recurring product , add duration variant - Add pricing for each variant using different periods - Go to the product page in website and change the current variant , the temporal unit doesn't change. Origin of the issue: ==================== It seems that the current code isn't reachable , and the function isn't updated. While debugging , this override of the function is never called but the website_sale_stock one is called. Solution: ========= I copied the same format of code done in website_sale_stock/static/src/js/variant_mixin.js and it solved the issue. opw-3618345
A recent update to the action service caused Studio to crash because it was calling a closeAll function that didn't exist in Studio's dialog service override. This fix adds the missing closeAll function to prevent the crash and ensure Studio works properly with the updated action service.
Original PR description
With PR odoo/odoo#149543, we call dialog.closeAll when the action service executes an action. As a consequence, there was a crash in studio because that function doesn't exist on the override of the dialog service inside Studio. This commit fixes the issue.
This fix resolves an issue where kitchen printers were unable to print orders when both a preparation display and printer were enabled in the Point of Sale system. Previously, when an order was validated and paid, it would appear on the preparation display but fail to print. This fix ensures that orders are properly sent to both the preparation display and the printer simultaneously.
Original PR description
Current behavior: When both preparation display and printer are enabled, the printer was not able to print changes from an order. Steps to reproduce: - Create a preparation display that show all the orders - Create a pos printer that print all the pos categories - Setup the PoS to use both the preparation display and the printer - Create an order with some products - Validate the order, and pay for it - At this point the order should be printed and displayed on the preparation display. But the printer will not print the order. opw-3606888
This fix corrects how Peruvian electronic invoices handle currency for SPOT (exchange rate) amounts. Previously, the system was using the invoice's currency for SPOT amounts, but Peruvian regulations require SPOT amounts to always be in Peruvian Soles (PEN) regardless of the invoice's currency. This ensures compliance with local tax authority requirements.
Original PR description
With the refactor of the Peruvian electronic invoicing [1], we missed a valid use case where the currency of the SPOT amount must always be PEN and not the same as the currency of the related invoice. [1] 12b9effea5a763483d86477e27c7bc8261bcb4f0
This update corrects the net wage value displayed in payslip PDF reports. The fix ensures that employees and managers see the accurate net wage amount when generating or viewing payslip documents, improving the reliability of payroll reporting.
Original PR description
Fix net wage pdf value.
This update fixes a problem where restaurant table orders would fail to load in the Point of Sale system for German businesses. The issue was caused by a recent code reorganization that didn't properly include a required field. This fix ensures table orders load correctly again.
Original PR description
This commit resolves an issue where loading table orders would fail due to a refactor (commit: https://github.com/odoo/odoo/commit/01b3a2e4c24fe24bb7b8bb74fc6d2e2edaa96e87). The "l10n_de_fiskaly_time_start" field was correctly added in the 'export_for_ui' method. opw-3706454
This update resolves an access rights problem in the HR salary configurator template that was preventing some users from accessing the tool properly. The fix ensures that employees and managers can now use the salary configuration feature without permission errors, improving the usability of the compensation planning process.
Original PR description
…late
This fix resolves an issue where feedback request deadlines were not being properly updated when sending 360-degree feedback surveys in the appraisal process. Previously, even when a future deadline was set, surveys would incorrectly appear as expired. The fix ensures deadline information is correctly transmitted to survey responses, allowing managers to properly schedule feedback collection periods.
Original PR description
### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails…
### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails list (debug) and open the feedback request mail 5. The survey is expired, which is expected 6. Repeat 3. and use the same settings except for the deadline, set it in the future 7. Repeat 4. 8. The survey is expired, which should not be the case - You can also observe the issue by opening `survey.user.input.view.tree.inherit.appraisal` (debug) instead of emails list. No survey to click on but the deadline is visible. ### Explanation: Deadline is not transmitted to answers in [action_send](https://github.com/odoo/enterprise/blob/df62564226d0ac9b4a3c7c489e5b2ff486dc7b2f/hr_appraisal_survey/wizard/appraisal_ask_feedback.py#L127-L130), which makes it not updating, despite being created with a deadline. ### Suggested Fix: The fix from 17.0 (commit: aecbb5c3e9b708e117510fb4ffd60baed3b6930c) is working in multiple version ranging from 15.0 to 16.4, applying it from 15.0. A test is also added to ensure workflow is not compromised again. opw-3665560 Forward-Port-Of: odoo/enterprise#55326 Forward-Port-Of: odoo/enterprise#54234
This fix allows users to edit the journal field for fixed assets, which was previously locked as read-only. The journal field is now editable, giving users more flexibility in managing asset accounting records and correcting journal assignments when needed.
Original PR description
Follow up to 8c4445fc63dc01ea0cf359066e3cd21fbac23a7b. The field that was changed in that commit is computed, which is means it's readonly by default. opw-3635484
This fix restores the inclusion of bank identification codes (BIC) in payroll payment files to prevent rejections by payment platforms like Isabel. Previously, a workaround was added to skip BIC codes to avoid issues with some banks, but this caused payment files with non-European bank accounts to be rejected. The fix now properly includes BIC information when available, while skipping only when genuinely missing.
Original PR description
This reverts the commit: https://github.com/odoo/enterprise/commit/b67b9e432f2de936ab6c2c68e23cb8f0b2aca76d Purpose ======= The payroll payment file is rejected on Isabel platfrom due to a bank account that was outside of the European Union, because the BIC wasn't mentioned. The commit was originally made to avoid posting 'NOTPROVIDED' as BIC, which was rejected by some banks. Now, we skip if there is not BIC on the bank https://github.com/odoo/enterprise/blob/17.0/account_sepa/models/account_journal.py#L336 It wasn't like that in the original version of that function; only got fixed recently: https://github.com/odoo/enterprise/commit/3c06ce695b80dec0c336ac2133594d9eaa07e3ba So, we can remove the context key in 16.4+. TaskID: 3710072 Forward-Port-Of: odoo/enterprise#55440
This update fixes an issue where dialog windows remained open after clicking action buttons (like stat buttons) within forms displayed in dialogs. Now, when an action is executed from within a dialog, all open dialogs automatically close, providing a cleaner and more intuitive user experience. Additionally, SCSS compilation errors are now displayed as notifications instead of dialogs, with improved error messaging.
Original PR description
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#149230
Fixed a bug where clicking the "view" button on an unsaved subtask in the list view would incorrectly redirect to create a new unrelated task instead of preventing the action. The system now prevents navigation when the record hasn't been saved yet, ensuring subtasks are properly linked to their parent task and project.
Original PR description
To reproduce ============ - On a project, on a task - create a subtask give it a name and from the list view click on the "view" button - you get redirected to form view to create a new task that is not related to the parent task or the project Problem ======= When you click on the "view" button, the task is not saved yet, so the subtask doesn't exist yet to be viewed in Form view Solution ======== We prevent the redirection to the form view if the record is not saved yet same logic as : https://github.com/odoo/odoo/commit/9b136383c2599301413e6770cc0ff204273b589d opw-3681471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the proper appearance of color picker buttons in the backend editor. A previous change had removed styling that affected both the backend and frontend color pickers, causing them to look broken. The fix uses CSS styling variables to ensure both versions display correctly without affecting the frontend experience.
Original PR description
This PR fixes an issue related to the colorpicker component, presents in both back-end and front-end. They use the same XML template but they have two different selectors within our SCSS files.…
This PR fixes an issue related to the colorpicker component, presents in both back-end and front-end. They use the same XML template but they have two different selectors within our SCSS files. task-3693078 ------------------ Some months ago, commit[1] removed some `@extend` rules related to button design within the `web_editor`, and replaced them with a `.btn` BS class. This affected both colorpicker since they share a common template, and causes layout issues on the "front-end web editor", which was not the expected output. The issue was fixed directly with commit[2], but by removing the `.btn` class from the template, it removed the whole styling on the back-end color picker, making it use the user agent button styling. == After == Since the colorpicker already has some CSS variables to handle its design depending on the context, we make use of the CSS variables to customize the design of the component when it is inside the backend, and make it look as it was before it lost its `.btn` class. | 17.0 | 17.0-fix-colorpicker-button-issue-chgo | | ------------- | ------------- | |  |  | Commit[1]: ee38c69503a0fd9175751f054d88bf760ec660b8 Commit[2]: 711fc86368eb5283cb0962620f0557d381904fde
Users with many product categories in Point of Sale couldn't scroll to see all items because the scrollbar was hidden. This fix restores the scrollbar on desktop devices while keeping it hidden on mobile, allowing users to access all categories when needed.
Original PR description
Current behaviour: --- When there is too many product categories, you cannot see the last items, because the scrollbar is hidden. This was made to hide the scrollbar on mobile. Steps to reproduce: --- 1. Go to Point of Sale 2. Configuration > PoS Product Categories 3. Duplicate one category 12 times 4. Uncheck Restrict Categories 5. Dashboard > New Session 6. The list of categories is too long 7. Cannot see the last items Cause of the issue: --- Introduced by https://github.com/odoo/odoo/commit/60f41b1f831248c58f554dbe40114ef0d4ce42c0#diff-f23069b3927b8544dd51433e277cf8b650b10a67e5b8648155e427aaa31c19a3R838 Fix: --- Make the scrollbar disappear on mobile, and appear otherwise. opw-3653429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148180
This update reverts an earlier change to how accounting tax tests were structured. The previous approach created issues with tax restrictions and test data setup that prevented other important migration fixes from working properly. This correction restores the proper test methodology to ensure all accounting features work as intended.
Original PR description
Revert of commit https://github.com/odoo/odoo/commit/da251b757d3bec9b663d7b5ad4d43929f2575a4f Problem --------- In said commit, tests were failing due to 1. the new restrictions on tax (related PR https://github.com/odoo/odoo/pull/130403) 3. default creation of repartition lines. However, updating the way chart_template._get_chart_template_data is patched in those tests was not the way to go. Because of that, some fixes due to migration error to 17.0 failed - PR https://github.com/odoo/odoo/pull/149733. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where backorder processing was incorrectly splitting origin moves for all stock moves, when it should only do so for subcontracting operations. The change ensures that backorders are handled properly without affecting standard inventory operations.
Original PR description
This commit corrects commit https://github.com/odoo/odoo/commit/7a78839ca6cf45ddec7adb59051da132e0ebceb4 that split the move_orig_ids for new stock moves created in backorder. The issue is this should only happens in case of subcontracting, not for every backorders --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150943 Forward-Port-Of: odoo/odoo#150843
This fix resolves an issue where modal dialog text became invisible when websites used dark background colors. The system now automatically adjusts text colors in modals to ensure they remain readable regardless of the website's background theme. This improves the user experience when customers interact with product modals during checkout.
Original PR description
**[FIX] web, web_editor: fix text color of modals if dark body background** Before this commit, if the text color of the body was light (e.g., due to a dark body background), the text in certain…
**[FIX] web, web_editor: fix text color of modals if dark body background**
Before this commit, if the text color of the body was light (e.g., due
to a dark body background), the text in certain modals (for example, in
the "Alternative products" modal displayed when adding a product to a
cart on a product page) was also light, making it not visible on the
white modal background.
Steps to reproduce the bug:
- Install the e-commerce on your website.
- In Settings, enable the "Optional Products" option.
- Go to the "Customizable Desk" product page.
- Click on "Edit" to go in edit mode.
- Click on the "Theme" tab.
- Click on the 4th color of the theme colors and choose "black".
- Save the page to leave edit mode.
- Click on the "Add to cart" button.
- Bug: The text in the the modal is not visible because both text and
background are white and the input elements have their background the
same color as the body.
After this commit, we now verify that there is sufficient contrast
between the text color of the body and the background color of the
modals. If this condition is not met, we apply an alternative color
("$yiq-text-dark" or "$yiq-text-light") to the text of the modal to
ensure visibility.
opw-3570774
Forward-Port-Of: odoo/odoo#150869
Forward-Port-Of: odoo/odoo#147347This fix resolves inconsistent synchronization behavior that occurred when deleting orders from the restaurant ticket screen. The system now properly waits for synchronization to complete when sending orders for preparation, ensuring reliable and predictable behavior across all operations.
Original PR description
A fix introduced in https://github.com/odoo/odoo/pull/146836/commits/5fd63c81b092d07c4c92381a0391dad52d9b76aa resulted to unpredictable server-syncing behavior when deleting an order from the ticket screen. The value of sync notification message can be different between the runs of the `pos_restaurant_sync` tour test. To make the behaviour predictable, we make sure to await the syncing when sending order for preparation. Runbot Error: 56341 Forward-Port-Of: odoo/odoo#151325
This fix corrects an issue where public holidays were incorrectly showing a duration of 1 day instead of 0 days on the Time Off dashboard. The problem occurred because the system wasn't properly accounting for public holidays when calculating time off durations. The fix ensures public holidays are now correctly recognized and excluded from duration calculations.
Original PR description
Steps to reproduce:
-------------------
On the Time Off dashboard, click on a public holiday.
Issue:
------
The duration is 1 Day instead of zero day.
Cause:
------
To ignore the current holiday, the domain for finding holidays adds the condition:
```py
('holiday_id', '!=', self.id)
```
Unfortunately, if we have a `NewId`, in postgresql, `NULL != NULL` condition always returns NULL.
As a result, public holidays (which do not have a `holiday_id`) will not be taken into account.
Note:
This does not happen when you save because the id exists.
Solution:
---------
Accept `holiday_id` equal to `False` in the domain.
opw-3635949This update adds necessary safety configurations to the Xendit payment module to prevent test databases from accidentally interacting with live payment systems. This ensures that when support teams create copies of production databases for investigation, they won't inadvertently process real payments or affect customers.
Original PR description
This commit adds the missing neutralisation necessary for the `payment_xendit` module introduced in [1] The purpose of the standard neutralisation framework is to allow us to create database copies that will not interract with external systems in ways that could impact the production database (or if it is not possible to prevent the interractions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] odoo#141661
This fix resolves an error that occurred when creating timesheets for employees in companies outside the current user's allowed access list. The system now properly recognizes employees from all relevant companies during timesheet creation, preventing false "inactive employee" errors that could interrupt automated processes like scheduled tasks.
Original PR description
Before this commit, when the company of the employees updated is not in the allowed_company_ids of the current user (could happen in the execution of a cron), an error is triggered saying we are not allowed to create a timesheet for an employee inactive. The reason is because the employee is not fetched in the check made in the timesheet creation because of the company of that employee is not in the companies contained in the environment. This commit makes sure the companies in the environment are the ones set on the employees created/updated, to be sure those employees are fetched in the check made in timesheet creation. Forward-Port-Of: odoo/odoo#151596 Forward-Port-Of: odoo/odoo#151386
This fix resolves an issue where calendar alarm notifications were not being created for subsequent occurrences of recurring events. When a recurring event had an alarm set (like 5 minutes before), the system would fail to schedule reminders for the next occurrences in the series. The fix ensures that each event in a recurring series gets its alarm properly scheduled by correctly identifying which event is being notified and excluding it from the query for the next alarm.
Original PR description
After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens…
After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens when the cron is run after the first trigger of the recurrence. Imagine we have an alarm of 5 minutes before the event, the call for_setup_alarm from _send_reminder will try to get the next event in the recurrency to notify. However, the SQL query uses `WHERE start > now` and if the cron trigger runs before the event is started (most cases) this query will return the event that we're notifying. This commit fixes this by passing the events that are being notified in the context of the `_setup_alarm` call, so that we can exclude them from the query. How to reproduce? Install calendar - Create a recurring event with daily recurrence repeating for 3 days. Invite Demo, set an email alarm for 5 min before the event and create the event - A cron trigger will be created for 5 min before the event - Change your computer's time so that it is 5min before the event - The cron trigger will be called and it should create a new cron trigger for the other day, however no cron trigger is created Issue: SQL query in _setup_alarms in calendar.recurrence is getting the first event with start > now, however it returns the event that was already notified Solution: Pass in the context which events are already being notified so that they are excluded from the query task-3663455 Forward-Port-Of: odoo/odoo#147914
This fix improves how Odoo handles invoice sending and printing when external services fail after the PDF has already been generated. Previously, if a service like UBL failed after PDF creation, the system would not link the PDF to the invoice and would fall back to creating a Proforma instead. Now, the system will properly link the generated PDF to the invoice, providing users with a better experience and avoiding unnecessary Proforma document creation.
Original PR description
Currently, if the Send & Print fails in a web-service that happens *after* the PDF generation (such as UBL) we don't link the PDF and fallback on Proforma if possible. After this task, if we are in this situation we will link the invoice and not generate the proforma. Behavior is left unchanged for web-services that fail *before* PDF generation. task-id: 3690897 Forward-Port-Of: odoo/odoo#150636
This fix resolves a crash that occurred when users tried to create a meeting room in the Community section of an online event. The issue happened because a required variable was missing from the code that generates the room creation form. The fix restores the proper handling of this variable so users can now successfully create meeting rooms without errors.
Original PR description
To reproduce: - Log-in as admin - Switch to debug mode - Go to Events / Configuration / Event Templates - Create a new template: * Name: Online Conference - Check 'Website menu', 'Community' and…
To reproduce:
- Log-in as admin
- Switch to debug mode
- Go to Events / Configuration / Event Templates
- Create a new template:
* Name: Online Conference
- Check 'Website menu', 'Community' and 'Allow Room Creation' option,
- Save it
- Go to Events / Events
- Create a new event:
* Name: New Online Conference
* Template: Online Conference
- Save it and click on 'Go to Website' smartbutton
- Then click on 'Community' submenu
- In the right panel, click on "Create a Room"
It crashes with:
```
TypeError: ctx.widget is undefined
template@.../web/assets/1/debug/web.assets_frontend_lazy.js line 13622 > Function:26:29 (/web/static/lib/owl/owl.js:5532)
render@.../web/assets/1/debug/web.assets_frontend_lazy.js:66320:28 (/web/static/src/core/utils/render.js:56)
renderToElement@.../web/assets/1/debug/web.assets_frontend_lazy.js:66272:22 (/web/static/src/core/utils/render.js:8)
_onClickCreate@.../web/assets/1/debug/web.assets_frontend_lazy.js:132115:35 (/website_event_meet/static/src/js/website_event_create_meeting_room_button.js:25)
```
This revert odoo/odoo@065a2f451a88 change for `website_event_meet`, as in that case the `csrf_token` value is provided directly as context value to `renderToElement` (see `websiteEventCreateMeetingRoom` publicwidget `_onClickCreate` handler)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an error that occurred when printing the sales details report in Point of Sale after closing a session. The issue was with how the total paid amount was being displayed in the report. Users can now successfully print sales reports without encountering error popups.
Original PR description
Current behavior: When we print the sales details report, we get an error popup Steps to reproduce: - Setup an ePos printer - Open PoS - Make an order with some products and finalize it - Click on the close session button, and print the sales details report Total paid is set here in currency: https://github.com/odoo/odoo/blob/f8f4e899b51a73b48882b2b6e33441f0e8eed477/addons/pos_daily_sales_reports/models/pos_daily_sales_reports.py#L204 opw-3702011 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical error that was preventing analytic line data from being properly populated in the system. The issue occurred when the system tried to combine different data types incorrectly. By adjusting how the data combination works, analytic reporting and tracking now functions as intended.
Original PR description
The `sum` function needs to be given a compatible for the `start` argument. Instead of using that function for a simple sum of two elements (not `int`), lets just sum them explicitly instead. Traceback: ``` TypeError: unsupported operand type(s) for +: 'int' and 'account.analytic.plan' ```
This update fixes a display issue in the course learning interface where the progress bar and completion tag were not showing properly when course names were long. Instead of hiding content, the solution now limits course names to a single line using text truncation, ensuring all interface elements display correctly and remain accessible to learners.
Original PR description
Purpose ======= This reverts commit https://github.com/odoo-dev/odoo/commit/27a1ccc829d290c8589a535f10b31caaacd6400f which fixed the container height when course name was too long. It added a 'visibility: hidden' style which caused an issue on the course left bar where the progress bar and completed tag are located next to each other. Instead of adjusting the size of the container we prefer to limit the size of the course name to fit a single line. To do that we use the text-truncate class. Task-3607404 Forward-Port-Of: odoo/odoo#150162 Forward-Port-Of: odoo/odoo#143136
This fix resolves an error that occurred when trying to view a module's details in the system after the module had been uninstalled or removed. Previously, users would encounter a system error when attempting to access the form view and view the module's icon. Now the system gracefully displays the default module icon instead, providing a better user experience.
Original PR description
Before this patch, if you once had one module available and, later, remove it, you'd be getting an exception when browsing its form view and trying to get its icon image: <details> ``` RPC_ERROR Odoo…
Before this patch, if you once had one module available and, later, remove it, you'd be getting an exception when browsing its form view and trying to get its icon image:
<details>
```
RPC_ERROR
Odoo Server Error
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 886, in get
return field_cache[record._ids[0]]
KeyError: 1508
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1057, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 889, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'ir.module.module(1508,).icon_image'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_http.py", line 237, in _dispatch
result = request.dispatch()
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 687, in dispatch
result = self._call_function(**self.params)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 359, in _call_function
return checked_call(self.db, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/service/model.py", line 94, in wrapper
return f(dbname, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 348, in checked_call
result = self.endpoint(*a, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 916, in __call__
return self.method(*args, **kw)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 535, in response_wrap
response = f(*args, **kw)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1342, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/main.py", line 1334, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 464, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 451, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3227, in read
return self._read_format(fnames=fields, load=load)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3247, in _read_format
vals[name] = convert(record[name], record, use_name_get)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5893, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1106, in __get__
self.compute_value(recs)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 2139, in compute_value
super().compute_value(records_no_bin_size)
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1265, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 4255, in _compute_field_value
getattr(self, field.compute)()
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_module.py", line 254, in _get_icon_image
with tools.file_open(path, 'rb') as image_file:
File "/opt/odoo/custom/src/odoo/odoo/tools/misc.py", line 198, in file_open
path = file_path(name, filter_ext=filter_ext)
File "/opt/odoo/custom/src/odoo/odoo/tools/misc.py", line 179, in file_path
raise FileNotFoundError("File not found: " + file_path)
Exception
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 643, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 301, in _handle_exception
raise exception.with_traceback(None) from new_cause
FileNotFoundError: File not found: /base/static/description/icon.png
```
</details>
Now it gets the base module icon image, just like it should.
@moduon MT-1524 OPW-3082012
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#149386
Forward-Port-Of: odoo/odoo#105532This fix restores the "vat_required" option for the "Domestique - France" fiscal position, which was incorrectly removed in a previous update. This ensures that French domestic transactions are properly configured to require VAT information as intended.
Original PR description
Issue: This PR (https://github.com/odoo/odoo/pull/145412) wrongly removes "vat_required" option from "Domestique - France" fiscal postion. Solution: Set "vat_required" option back. opw-3617761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151629 Forward-Port-Of: odoo/odoo#151518
This update ensures that when partner names are changed, website URLs automatically redirect to the correct address. Previously, outdated partner URLs could remain indexed by search engines even after renaming. Now the system validates and redirects to the accurate URL, improving search engine optimization and user experience.
Original PR description
'+ website_crm_partner_assign that overrides website_partner Implement partner slug validation for accurate URL redirection Prior to this commit, partner slugs weren't verified, leading to Google indexing outdated partner URLs even after renaming. With this change, when the virtual slug (fake slug sinc no read access on res.partner) differs from the actual one, redirection to the correct URL is enforced. Forward-Port-Of: odoo/odoo#151678 Forward-Port-Of: odoo/odoo#151524
This fix resolves an issue where call-to-action (CTA) buttons were losing their proper styling when edited in the web editor. The editor was incorrectly removing button classes, causing CTA buttons to appear broken. This update ensures buttons maintain their correct appearance and functionality after being edited.
Original PR description
When a button is updated, its `btn` classes are stripped by the editor. However, in so doing the regex replaces `btn_cta` by `_cta`. This commit fixes it. Related to opw-3644220 Forward-Port-Of: odoo/odoo#151436 Forward-Port-Of: odoo/odoo#149086
This fix resolves an error that occurred when accessing the Manufacturing Forecast from a product template's forecasted view. The system was incorrectly trying to find product variants using the template's ID instead of the variant's ID, causing a "Missing record" error. Users can now successfully view manufacturing forecasts from product templates without encountering this issue.
Original PR description
Have a product template with bom Ensure the product variant has not the same id of the template (Add and remove a template variant) In the product page > Hit "forecasted" smart button > "Manufacturing Forecast" Error will raise: Missing record Record does not exist or has been deleted. This occurs because when opening the Manufacturing Forecast from the template product we are searching the variant using the id of the template product opw-3636661 Forward-Port-Of: odoo/odoo#149736
This fix ensures that when a product's cost rounding precision is changed (for example, from 2 to 3 decimal places), the updated precision is properly reflected in expense records. Previously, expense products and amounts would not display the correct number of decimal places after a rounding change, which could cause confusion in financial reporting and expense tracking.
Original PR description
Fixes an error where a product cost rounding change (e.g. from default 2 to 3) would not be shown on the expense product and expense unit_amount Task link: https://www.odoo.com/web#model=project.task&id=3679204 task-3679204 Forward-Port-Of: odoo/odoo#151726 Forward-Port-Of: odoo/odoo#149032
Sales users without purchase permissions were seeing an incorrect warning about linked purchase orders even when none existed. This fix ensures the warning only appears to users who have access to purchase information, preventing confusing alerts for sales-only staff.
Original PR description
To reproduce on runbot: - edit the access rights of internal user 'lauriepoiret' and grant she the group "Sales / User: own document only" (and ensure she does not have the group "Purchase / User") -…
To reproduce on runbot: - edit the access rights of internal user 'lauriepoiret' and grant she the group "Sales / User: own document only" (and ensure she does not have the group "Purchase / User") - as 'lauriepoiret', create a sale order for a product without 'service subcontracting' (ex. Bacon Burger) and confirm it - click on "Cancel" button In the wizard and warning is shown: ``` There are active purchase orders linked to this sale order that are not cancelled automatically! ``` As the user is not a member of `Purchase / User`, he has no right to read the `display_purchase_orders_alert` field which prevent the invisible attrs to be correctly evaluated, showing the warning in all cases even when there is no purchase order linked This commit restrict the PO warning to the same `Purchase / User` group to ensure that warning information is coherent --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149785
Fixed an issue where event registration confirmation emails were missing the message body in the chatter, showing only the subject and attachments. The email body is now properly displayed when event attendees receive ticket confirmation notifications, ensuring users can see the complete email content in their message history.
Original PR description
### Steps - Go to any event with tickets and using the ticket confirmation template, sending 'after new confirmation'. - Confirm a new attendee. - An email is sent but the chatter only shows the attachment and the subject, with no body. ### Issue Chatter should show full content of the email. ### Reason Above 16.2+ the 'body' is not implicitely set when genrating the template in ``mail_template.send_mail()``. As discussed with RETH, when requesting the 'body_html' for a template, setting the 'body' solves the problem. opw-3562438 Forward-Port-Of: odoo/odoo#142840
This fix resolves an issue where text would disappear when users pasted unformatted content (Ctrl+Shift+V) containing line breaks into certain content areas. The system now properly handles line breaks in these restricted areas by using the appropriate insertion method, ensuring pasted content is preserved instead of being lost.
Original PR description
Current behavior before PR: When pasting using CTRL+SHIFT+V, if the textFragment includes linebreak(\n), each textFragment is divided, and each seperated fragment is inserted using `insert` command, followed by `oEnter` command. However, when `oEnter` is UNBREAKABLE, the inserted text is ROLLBACKED. Desired behavior after PR is merged: We now check whether the anchorNode's closestBlock is UNBREAKABLE. If so use `oShiftEnter` command; otherwise, use `oEnter` command which avoids ROLLBACK. task-3563785 Forward-Port-Of: odoo/odoo#140876
Fixed a bug in the Calendar application where users would encounter an error when creating an all-day event after deleting the end date. The system now properly sets the required end time fields when users switch to all-day mode and set both start and stop dates, allowing events to be created successfully.
Original PR description
In calendar if you delete the end_date, switch to all_day event and set both start_date and stop_date and try to create the event, it will raise an error because `end` is not set. This is due to 'end' being a required field and the end_date not setting the end value. This commit adds an onchange to properly set the start and stop values from the start_date and stop_date. task-3682608 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#149364
This fix resolves a bug in the command palette where typed characters would occasionally disappear during searches. The issue occurred when using the @ namespace with delayed search processing and async command providers. The fix ensures that the search text is properly preserved and displayed as users type, improving the reliability of the command palette search feature.
Original PR description
Before this commit, in the command palette, during a search, it is possible that the value entered is modified. The problem only occurs if the namespace has a debounceDelay bigger than 0 and at least…
Before this commit, in the command palette, during a search, it is possible that the value entered is modified. The problem only occurs if the namespace has a debounceDelay bigger than 0 and at least one of its command providers is async. How to reproduce: ================= - Go to the command palette with the @ namespace. - Type a few characters - Re-enter a few characters If you repeat this operation several times, some characters may disappear. Why: ==== The value of the input is modified at each "input" event, but the searchValue in the state is only modified when the debounce trigger "search". Since the command palette template is contained in a slot, each state change causes a complete rendering of the command palette. When the search is executed, the commands are added to the state after each provider has generated them, so a rendering takes place and it is the value contained in state.searchValue that is used for the input and not the value contained in it before the rendering. Solution: ========= No longer modify state.searchValue during the search, but at each input event. 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#151772