Daily updates from Odoo
Navigate
Branch
Friday, January 19, 2024
45 changes
16 changes
Enhancements to existing features
Financial reports can now show tailored warnings more easily, helping users spot issues without extra technical customization. Luxembourg tax XML exports now present validation issues as warnings instead of blocking errors, so users can export while still being informed about items to review.
Original PR description
### [IMP] account_reports: allow adding custom warnings This commit adds a hook `_get_custom_warnings` to add custom warnings in custom report handlers easier without needing to extend the custom_line_postprocessor. Warnings might still be added when generating dynamic lines for performance reasons. ### [IMP] l10n_lu_reports: switch validation errors into warnings Currently, we do a validation when an XML is being exported. If there are several checks that fail one after another, the users have to try to export, face the error, fix, try to export again several times. This commit changes these into warnings. We allow exporting XML despite these warnings, so that users are not blocked that way. task-3556111
Australian payroll accounting now adds the required PAYG withholding tax tags to payslip accounting entries so payroll amounts can feed into government tax reports. Employers can also switch relevant reporting from W2 to W3 on employee contracts without duplicating payroll structures, making compliance setup easier.
Original PR description
The Australian government allows companies to report their payroll activities through a kind of tax report. To fill the tax report lines representing these activities, we need to update the modules in order to add tax tags when creating entries from the payslips. We thought that payroll generated entries could happen more than in one localisation, so we applied the principle to hr_payroll_account. Following this idea, we now have tags that can be set directly on the hr salary rules or hr payslip lines. These tags will be applied on the corresponding lines when creating the journal entry from the payslip. For the Australian payroll, we need to be able to change the W2 tag to W3 by a boolean on the contract, as the default data for salary structures will represent all the use cases possible (we don't want users to duplicate structures just to change the tag). task-2719708
Confirmed appraisals now allow skill lines to be edited directly in the list instead of opening a separate form. This makes updating employee skills during appraisal reviews faster and more convenient for users.
Original PR description
Before this commit: When you want to edit skill on a confirmed appraisal, a form view was displayed to do it. With this commit, you can directly edit the line without form view. task: 3612532
Spreadsheet edition templates were updated to match the newer way Odoo applies template inheritance in the browser. This keeps spreadsheet chart menu behavior compatible with the platform change and avoids future template loading issues.
Original PR description
The PR https://github.com/odoo/odoo/pull/145602 brings several changes in the way inheritance of static templates is applied. One of which is that for a template which inherits from a template with t-name=template_name, the value of t-inherit should be exactly template_name. This means we no longer accept implicit references to modules names (in any ways). Here we adapt the code of spreadsheet_edition to that particular change.
Accounting teams can now turn off automatic account and tax predictions on vendor bill lines from settings. This gives businesses more control when automated suggestions are not desired or do not fit their workflow.
Original PR description
Adds two new fields in the settings to disable predicting accounts and taxes on vendor bill lines. task-3512211
Code cleanup and technical improvements
This update reorganizes how several Odoo apps load messaging-related information by combining multiple server requests into one. It should make startup behavior more consistent and easier to maintain, with little direct change for everyday users.
Original PR description
\* = account_accountant, documents, voip, web_studio,
website_helpdesk_livechat
In particular, init_messaging and failures are now done in a single RPC.
Time control tests have to be adapted to take into account the extra delay that is introduced before fetching data.
Discuss action is made to render even if messaging is not initialized in order to resolve the action promise, to know when to advance time.
The new async step helper is used to guarantee proper order between RPC.
Part of task-3605717
https://github.com/odoo/odoo/pull/149860Point of Sale display modules now use a shared update mechanism to make live notifications more consistent and easier to distinguish. This reduces duplicate infrastructure and fixes an issue affecting real-time communication between POS screens.
Original PR description
pos*: pos_order_tracking_display,pos_preparation_display,pos_restaurant_appointment
- create the `pos.bus.mixin` class;
- it insures that modules that inherit this class have an
`access_token`; ( similar to `portal.mixin` )
- implements the `_notify` method that uses the `access_token`
and the notification name concatenated as a channel;
--> as such, listeners can differentiate between senders.
- adapt `pos.config`, `pos.session`, `pos.preparation.display` to
inherit from `pos.bus.mixin`;
- replace all bus usage in the frontend with `bus.subscribe`;
( the PosBus service has been removed )
- this has the benefit of solving the bug from task: 3557587
Task 3508655
https://github.com/odoo/odoo/pull/136621Miscellaneous changes
Activate 'Budget Management' In Accounting>Configuration>Management>Budgetary Positions Create a new Budgetary Position Add some accounts Save Remove an account Save ValidationError: The budget must have at least one account This occurs because there was a change in the write commands sent Up to saas-16.4 we used to receive `{'account_ids': [[Command.set, False, ids]]}` We now have something like `{'account_ids': [[Command.unlink, id]]}` and the old way of checking the updated `a
Original PR description
Activate 'Budget Management'
In Accounting>Configuration>Management>Budgetary Positions
Create a new Budgetary Position
Add some accounts
Save
Remove an account
Save
ValidationError: The budget must have at least one account
This occurs because there was a change in the write commands sent Up to saas-16.4 we used to receive
`{'account_ids': [[Command.set, False, ids]]}`
We now have something like
`{'account_ids': [[Command.unlink, id]]}`
and the old way of checking the updated `account_ids` no longer works
opw-3633650
Forward-Port-Of: odoo/enterprise#54323Before this commit, the report Finished Product PDF (mrp.label_production_view_pdf) was editable. Though this report really doesn't play well in the report editor as the xml contains a lot of code and the model on this report is wrong, meaning that "docs" does not refer to the actual data that report contain eventually. After this commit, this report cannot be edited via studio as it is too specific. opw-3650049 Forward-Port-Of: odoo/enterprise#54487
Original PR description
Before this commit, the report Finished Product PDF (mrp.label_production_view_pdf) was editable. Though this report really doesn't play well in the report editor as the xml contains a lot of code and the model on this report is wrong, meaning that "docs" does not refer to the actual data that report contain eventually. After this commit, this report cannot be edited via studio as it is too specific. opw-3650049 Forward-Port-Of: odoo/enterprise#54487
This commit aims at adding the status indicator buttons that are present in most other Odoo Form views to Knowledge. These indicators enables the user to know when changes has been taken into account and can be saved inside the DB, either using the buttons or using other methods. This also enables the user to discard any changes he'd done to the article quickly. task-3609594 COM PR: odoo/odoo#145928 Forward-Port-Of: odoo/enterprise#54396 Forward-Port-Of: odoo/enterprise#51579
Original PR description
This commit aims at adding the status indicator buttons that are present in most other Odoo Form views to Knowledge. These indicators enables the user to know when changes has been taken into account and can be saved inside the DB, either using the buttons or using other methods. This also enables the user to discard any changes he'd done to the article quickly. task-3609594 COM PR: odoo/odoo#145928 Forward-Port-Of: odoo/enterprise#54396 Forward-Port-Of: odoo/enterprise#51579
Steps to reproduce: - Install the planning app and Studio. - Go to the planning app and trigger studio to edit. - Change the `Day Precision` to `Quarter Hour`. - Close and now click on `Week` and change the view to `Day`. The issue is that since the gantt is generated based on the screen size of the user in order to fit the whole gant in that width, when we divide the cell in 4 or even 2, the totals are going to overlap in smaller screens since there's no space for that division to disp
Original PR description
Steps to reproduce: - Install the planning app and Studio. - Go to the planning app and trigger studio to edit. - Change the `Day Precision` to `Quarter Hour`. - Close and now click on `Week` and…
Steps to reproduce: - Install the planning app and Studio. - Go to the planning app and trigger studio to edit. - Change the `Day Precision` to `Quarter Hour`. - Close and now click on `Week` and change the view to `Day`. The issue is that since the gantt is generated based on the screen size of the user in order to fit the whole gant in that width, when we divide the cell in 4 or even 2, the totals are going to overlap in smaller screens since there's no space for that division to display the totals horizontally. But in the other hand If we display the totals vertically and make them have a responsive fontsize, it will be visible for pretty much every screen size. Before:  After:  Note: It will also change for when we don't need to divide the cells, but I'm not sure of an easier solution to this. opw-3538039 Forward-Port-Of: odoo/enterprise#50763
Turns out we don't want to pollute Runbot instances with these demo data Forward-Port-Of: odoo/enterprise#54615 Forward-Port-Of: odoo/enterprise#54555
Original PR description
Turns out we don't want to pollute Runbot instances with these demo data Forward-Port-Of: odoo/enterprise#54615 Forward-Port-Of: odoo/enterprise#54555
This commit moves the embedded actions `Open` and `Rename` to the cog menu of the embedded views so that it doesn't interfer with either the top of the article or, in later versions, with comments. task-3635780 This commit is a FW of c3e83668bf9953aea361fb6e3e461bb65c83316c Forward-Port-Of: odoo/enterprise#54598
Original PR description
This commit moves the embedded actions `Open` and `Rename` to the cog menu of the embedded views so that it doesn't interfer with either the top of the article or, in later versions, with comments. task-3635780 This commit is a FW of c3e83668bf9953aea361fb6e3e461bb65c83316c Forward-Port-Of: odoo/enterprise#54598
- Create an invoice with account 151000 - Create an asset with this account as Depreciation Account - Sell this asset with the invoice => You have a weird error talking about remaining value In case of disposal with same accounts, the computation of depreciation_value is wrong. We should instead take the right line to compute it. Forward-Port-Of: odoo/enterprise#54430
Original PR description
- Create an invoice with account 151000 - Create an asset with this account as Depreciation Account - Sell this asset with the invoice => You have a weird error talking about remaining value In case of disposal with same accounts, the computation of depreciation_value is wrong. We should instead take the right line to compute it. Forward-Port-Of: odoo/enterprise#54430
**Before this PR:** The "Delete" button was visible in all instances of the document form view, including documents, projects, etc even while creating a new record. This was not logical since the "Delete" button is only useful when editing a workspace, not while creating a new record. **Technical:** We have added an `attrs` having invisible with the condition `('id', '=', 'False')` to the delete button, so It won't be visible if the record is not created. **After this PR:** The Delete
Original PR description
**Before this PR:**
The "Delete" button was visible in all instances of the document form view, including documents, projects, etc even while creating a new record. This was not logical since the "Delete" button is only useful when editing a workspace, not while creating a new record.
**Technical:**
We have added an `attrs` having invisible with the condition `('id', '=', 'False')` to the delete button, so It won't be visible if the record is not created.
**After this PR:**
The Delete button will only be visible in the Documents app when editing a workspace.
**Task**-3607426
Forward-Port-Of: odoo/enterprise#54071
Forward-Port-Of: odoo/enterprise#51636### Before this PR: User was allowed to do the following operations: - User was able to change month/quarter/year once the GSTR was filed/received - User was able to delete GSTR Period after sending/receiving data ### After this PR: - We restrict the user from doing the above operations as it could be problematic task-3672403 Forward-Port-Of: odoo/enterprise#54103
Original PR description
### Before this PR: User was allowed to do the following operations: - User was able to change month/quarter/year once the GSTR was filed/received - User was able to delete GSTR Period after sending/receiving data ### After this PR: - We restrict the user from doing the above operations as it could be problematic task-3672403 Forward-Port-Of: odoo/enterprise#54103
29 changes
New functionality added to Odoo
This update implements the new mandatory requirements for Mexico's Carta Porte 3.0 delivery guide standard. The changes add required fields to comply with the latest version and extend delivery guide functionality to include receipt documents, ensuring your Mexican operations remain compliant with current regulations.
Original PR description
This commit adds the new mandatory fields according to Version 3.0 of the delivery guide. It also extends the functionality of the delivery guide to Receipts. task-3608164 Forward-Port-Of: odoo/enterprise#52580
This change adds a new automated workflow to generate and publish SLSA3 build provenance, which helps ensure the integrity and authenticity of Odoo releases. This security enhancement provides customers with verifiable proof that builds haven't been tampered with and come from trusted sources.
Original PR description
integrate 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
Enhancements to existing features
This update makes marketing automation server actions easier to use by replacing complex Python code with a more user-friendly interface. The underlying system has also been improved to be more reliable and maintainable, with new tests added to ensure everything works correctly.
Original PR description
This commit converts server actions from python to more user friendly interface. The commit also improves `_create_records_with_xml_ids`, by removing try/except block and doing same thing using ORM. Commit also adds test, that tests the functionality of `_create_records_with_xml_ids` function. task-3597555
The salary configurator for Belgian HR contracts now displays detailed bike information similar to car details. Employees can now see bike specifications including monthly rental cost, electric assistance availability, color, frame type, and frame size when reviewing bike benefits in their salary packages.
Original PR description
Like we have it for cars, we add the following description to bikes in the salary configurator : Monthly cost : [contract value] (Rent) Electric Assistance : Yes/No Color Bike Frame Type Frame Size task-3640749
This update adds comprehensive tests for the formatLang() function in Odoo's tools module. By establishing a solid test foundation, the development team can safely improve and refactor this function in future versions without accidentally breaking existing functionality that users depend on.
Original PR description
Tests the method formatLang() to be able to do safe(r) refactoring in future versions. --- 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 issue preventing users from importing asset data with journal information from CSV or XLSX files. The journal_id field is now available for selection during imports, while maintaining the existing read-only behavior in the user interface for non-draft assets. This resolves a regression from version 16 where such imports were previously supported.
Original PR description
### Steps to reproduce * attempt to import an asset (CSV or XLSX file) with a value for a `journal_id` related field. That value will not be automatically matched with an Odoo Field. If you try to set it by manually, that field won't appear in the list of available fields. ### Cause In 16, even though a field was read-only, we would still allow it to be imported [depending on the 'states' field](https://github.com/odoo/odoo/blob/78bb35ae0f33777af003db310a59d807182008d5/addons/base_import/models/base_import.py#L288-L294) attribute. But since that attribute has been removed, a read-only field cannot be set trough import. ### Fix This commit makes the assets' `journal_id` field not read-only. The usual behavior (read-only if not in draft) remains unchanged because the views were already adapted accordingly. opw-3635484
This fix resolves an issue where users received an error message when removing accounts from a Budgetary Position, even when keeping at least one account. The system's validation logic was not properly handling the updated way accounts are removed, causing false error alerts. This update ensures the validation works correctly with the current account management process.
Original PR description
Activate 'Budget Management'
In Accounting>Configuration>Management>Budgetary Positions
Create a new Budgetary Position
Add some accounts
Save
Remove an account
Save
ValidationError: The budget must have at least one account
This occurs because there was a change in the write commands sent Up to saas-16.4 we used to receive
`{'account_ids': [[Command.set, False, ids]]}`
We now have something like
`{'account_ids': [[Command.unlink, id]]}`
and the old way of checking the updated `account_ids` no longer works
opw-3633650This fix resolves a system error that occurs when users generate follow-up reports for customers with invoices that have empty Due Date fields. The system now properly handles missing due dates instead of crashing, allowing follow-up reports to be generated and sent successfully.
Original PR description
The traceback will occur when the user is going to take follow up and the Due Date column is empty for any one of the move lines To reproduce this issue: 1. Install ``account_accountant``(with demo…
The traceback will occur when the user is going to take follow up and the Due Date column is empty for any one of the move lines
To reproduce this issue:
1. Install ``account_accountant``(with demo data)
2. Create a new Invoice
3. Add ``Customer`` as ``Deco Addict`` and ``Invoice Date`` before today's date and make ``Payment Term`` as ``Immediate Payment``
4. Now add a product from ``Add a line`` in ``Invoice line`` and ``Confirm`` it
5. Now Customers -> follow-up reports
6. Click on ``Deco Addict`` in list view and there click on ``Follow up`` button and ``Send and Print`` (make sure that the ``Due Date`` column is empty for any one of the move lines ")
Error:-
```TypeError: unsupported operand type(s) for -: 'datetime.date' and 'bool'
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(1298,)", line 1, in <module>
File "home/odoo/src/enterprise/17.0/account_followup/models/res_partner.py", line 616, in _cron_execute_followup
self.with_context(allowed_company_ids=company.ids)._cron_execute_followup_company()
File "home/odoo/src/enterprise/17.0/account_followup/models/res_partner.py", line 605, in _cron_execute_followup_company
partner._execute_followup_partner()
File "home/odoo/src/enterprise/17.0/account_followup/models/res_partner.py", line 524, in _execute_followup_partner
self._update_next_followup_action_date(followup_line)
File "home/odoo/src/enterprise/17.0/account_followup/models/res_partner.py", line 312, in _update_next_followup_action_date
eligible_levels = previous_levels.filtered(lambda level: (today - aml.date_maturity).days >= level.delay)
File "odoo/models.py", line 6089, in filtered
return self.browse([rec.id for rec in self if func(rec)])
File "odoo/models.py", line 6089, in <listcomp>
return self.browse([rec.id for rec in self if func(rec)])
File "home/odoo/src/enterprise/17.0/account_followup/models/res_partner.py", line 312, in <lambda>
eligible_levels = previous_levels.filtered(lambda level: (today - aml.date_maturity).days >= level.delay)
ValueError: <class 'TypeError'>: "unsupported operand type(s) for -: 'datetime.date' and 'bool'" while evaluating
'model._cron_execute_followup()'
File "odoo/addons/base/models/ir_cron.py", line 377, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 932, in run
res = runner(run_self, eval_context=eval_context)
File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
res = super(ServerAction, self)._run_action_code_multi(eval_context)
File "odoo/addons/base/models/ir_actions.py", line 764, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
This commit will check the datatype of the variable, if the datatype doesn't match then it will execute the next line.
https://github.com/odoo/enterprise/blob/15ec5105e9a20f7581a6c7b2b77db527606ffbf3/account_followup/models/res_partner.py#L312
sentry-4710882784This fix resolves an issue where clicking on a chat item from the messaging menu wouldn't open the chat window after reloading the page from the home menu. The problem occurred because the system was incorrectly detecting whether the Discuss app was actively open. By improving how the system checks if the Discuss app is in use, users can now reliably open chat conversations from the messaging menu regardless of their navigation history.
Original PR description
Before this commit, opening chat window from messaging menu might not work. Step to reproduce: - open Discuss app - Go to home menu - Reload the page - Click on Messaging Menu - Click on chat item to…
Before this commit, opening chat window from messaging menu might not work. Step to reproduce: - open Discuss app - Go to home menu - Reload the page - Click on Messaging Menu - Click on chat item to open chat => Chat window is not open This happens because when in the home menu from Discuss app in background page reload, the URL contains the Discuss app menu_id, but the action is "menu" rather the action id. This difference is crucial to distinct discuss app being actively open or it's in the background from home menu. The latter should NOT consider Discuss app being open. This is not a problem when opening/closing Discuss app, because the mounting/unmounting of the Discuss app component is good enough to detect that. However, with page reload, the way to detect Discuss app being open from URL was only relying on `menu_id` instead of `action` value. This commit fixes the issue by checking `active_id` of discuss app rather than `menu_id`, as `active_id` is 100% reliable whereas `menu_id` is not. The problem with home menu is one example among many other cases (e.g. page reload in channel settings form view). https://github.com/odoo/odoo/pull/149969
This fix resolves an issue where an unlinked "To Do" task stage was appearing in the project configuration even though it wasn't assigned to any project. The problem was caused by a case-sensitivity mismatch in the cleanup process. After this update, orphaned task stages will be properly removed automatically.
Original PR description
Steps to reproduce: -------------------------- 1) Install documents_project_sale module. 2) Open project 3) Go to configuration > task stages. 4) There is a 'To Do' stage that isn't linked to any project. Issue: -------- before this commit, the 'To Do' stage that stage that isn't linked to any project. which is showing abnormally. Cause: --------- The created stage will be removed automatically but the problem is it searches for 'To do' not 'To Do' that's why it was not removed. Fix: ----- after this commit, when we go to the task stages it will search for the 'To Do' stage if there is no project linked to the 'To Do' stage then it will be removed automatically the 'To Do' stage. task-3550638 Forward-Port-Of: odoo/enterprise#49641
This update fixes how onboarding tours display formatted text. Previously, HTML formatting tags were shown as plain text to users. Now the formatting effects (like bold, italics, etc.) are properly displayed, making the onboarding experience clearer and more professional across accounting, field service, and planning modules.
Original PR description
*= industry_fsm_sale, planning Current behavior before PR: - HTML tags are displayed in the onboarding tour. Desired behavior after PR is merged: - Display the tag effects instead of showing it in the onboarding tour. After the https://github.com/odoo/odoo/pull/107618 web_tour was converted into Owl, 'markup' was required to show the html tag effect instead of htm tags. Task-3457112 Forward-Port-Of: odoo/enterprise#54449 Forward-Port-Of: odoo/enterprise#53893
This fix resolves an issue where payroll users without expense module access couldn't calculate payslips. The payroll group permission was missing from an expense sheet field, preventing authorized payroll staff from completing their work. Adding the proper group permission restores functionality for these users.
Original PR description
Issue: ------ A user who has access rights for payroll but not for expenses will not be able to calculate the payslip. Cause: ------ An additional security check [^1] has been added to the `_flush_search` method to check which fields have groups. Unfortunately, payroll groups are not mentioned in the `groups` attribute of the `refund_in_payslip` field. Solution: --------- Add the group in the `groups` attribute. opw-3691235 [^1]: https://github.com/odoo/odoo/blob/4b096631ad23298c12bbd12593e9358c3e9f404a/odoo/models.py#L5330-L5332
This fix resolves an error that occurred when regular employees tried to save changes to their time off requests. The system was incorrectly trying to access restricted employee data during the save process. By using a different data field that has proper access permissions, employees can now successfully update their time off without encountering errors.
Original PR description
**Description of the issue this PR addresses:** When a normal user writes to a previously created hr.leave an access error is raised because of reading `employee_ids`. This happens because the field is restricted to the group `hr_holidays.group_hr_holidays_user` and it's used in `_check_date`. To prevent this `all_employee_ids` should be used because of the `compute_sudo` set. **Current behavior before PR:** Access error on save **Desired behavior after PR is merged:** No access error on save --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148638
This fix resolves a display issue in percent pie charts where values were sometimes shown with excessive decimal places due to rounding precision problems. The values are now cleanly displayed rounded to 2 decimal places, or as whole numbers when appropriate, improving the visual clarity of reports and dashboards.
Original PR description
Fix the rounding of the percentpie field value as it was sometimes displaying a very long number due to python rounding precision. The value is now displayed rounded to 2 decimals using half to even rounding and keeps being displayed as an integer if there's only zeros as decimals. Task-3648755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where employees using the Odoo mobile app on iOS devices could not check in or check out using the attendance button. The problem was caused by the app trying to access location services in a way that isn't supported on iOS. The fix ensures the app properly detects whether location services are available before attempting to use them, allowing iOS users to successfully record their attendance.
Original PR description
To reproduce ============ - With hr_attendance installed on ios application - click on small button (green/red) to checkin/checkout - nothing happens Problem ======= the method `signInOut` is failling because `navigator.geolocation` is not defined on iOS Solution ======== check if `navigator.geolocation` is defined before using it opw-3649654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves compatibility with newer versions of Ticketbai (Spain's tax authority EDI system) by supporting up to 8 decimal places in financial calculations, whereas the previous version only supported fewer decimals. This ensures accurate invoice transmission to Spanish tax authorities without rounding errors.
Original PR description
…e 8 decimals Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes two related issues with the web interface's searchbar menu. The searchbar menu was appearing in the wrong position after opening the advanced search dialog, and the system was making unnecessary repeated position updates. These fixes ensure the menu displays correctly and the system performs more efficiently.
Original PR description
## [FIX] web: fix searchbar menu position Before this commit, the searchbar menu was misplaced after opening the advanced search dialog. After this commit, the searchbar menu is always at the correct position. task-id: 3673493 ## [FIX] web: batch position updates Before this commit, a component that uses the `usePosition` hook could trigger multiple position update in the same tick and the update would be call as much as it was called. In this commit, the hook batches the calls to the update to call it once. task-id: 3673493 Forward-Port-Of: odoo/odoo#148814
This update fixes a technical issue that prevented the "Down payment invoice" text from being properly translated into different languages. The fix reorganizes how the translation system processes this text, ensuring it can be exported and translated correctly for international users.
Original PR description
Nested gettexts aren't exported. This commit solves the problem by moving the inner gettext outside of the arguments of the first gettext.
Fixed an issue where clicking "Jump to Present" in the messaging app wasn't reliably scrolling to the most recent messages. The problem occurred because message loading wasn't immediate, causing scroll adjustments to interfere with the jump action. This fix ensures the scroll-to-present feature works consistently every time users click it.
Original PR description
Before this commit, when looking at old messages of a message, clicking on "Jump to presence" was frequently not scrolling to most recent message. This happens because loading messages is not immediate, and thread UI has some heuristics to adjust scrolls that were working against scrolling to presence when the RPC to load messages around presence is not immediate. This commit fixes the issue by handling the actual scroll to presence in the same workflow as all other scroll adjustments. Also the logic for adjusting scrolls requires immediate scrolling, hence this commit has to remove smooth scrolling to comply with current scroll adjustment techniques.
This fix corrects an issue where the total account count was being calculated incorrectly when using analytic plans with subplans. Previously, when accounts were distributed across multiple subplans, the count displayed on subplans was inaccurate. This update ensures that account counts are properly computed and displayed across all plan levels.
Original PR description
When having an analytic plan with subplans, with analytic accounts on each, the all accounts count is not well computed on the subplans. opw-3677889
This fix resolves an issue where footer elements from nested form views were incorrectly appearing in the parent dialog's footer. Now, each nested form view properly keeps its footer elements separate from the parent view, ensuring cleaner and more correct dialog layouts when adding records through one2many fields.
Original PR description
Have a nested (2 levels) form view with a footer. On the main view, add a record in the one2many in form view (dialog). Before this commit, the footer of the nested one2many form (within the dialog) was put inside the footer of the dialog, which is wrong, as the footer originates from a subview, hence has nothing to do with its parent. After this commit, each subview's part that should be rendered elsewhere than in the main formRenderer doesn't pollute the main view. opw-3681966 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#149933 Forward-Port-Of: odoo/odoo#149896
This fix resolves an access restriction that prevented non-admin users from submitting invoices to ZATCA (Saudi Arabia's tax authority) or printing invoices with QR codes. The change allows all users to perform these critical invoice operations regardless of their administrative privileges, improving workflow efficiency for accounting teams.
Original PR description
Currently, when a user that is not part of the 'base.group_system' group, they are unable to submit invoices to ZATCA and print B2B invoices since the QR code requires the use of the…
Currently, when a user that is not part of the 'base.group_system' group, they are unable to submit invoices to ZATCA and print B2B invoices since the QR code requires the use of the l10n_sa_production_csid_json fields. To fix this, we mark the l10n_sa_qr_code_str as compute_sudo=True and use sudo when we try to sign XML before submission to ZATCA Description of the issue/feature this PR addresses: If a user that is not part of the base.group_system group and tries to either submit an invoice to ZATCA or print a submitted invoice with QR code, an exception will show up since one of the fields required, l10n_sa_production_csid_json, is restricted to the base.group_system group. Current behavior before PR: Access error shows up when a user that is not part of the base.group_system group tries to submit/print an invoice. Desired behavior after PR is merged: Users should be able to submit invoices to ZATCA or print submitted Invoices irrespective of their belonging to the base.group_system group. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149342 Forward-Port-Of: odoo/odoo#147893
This fix restores the "Last Post" feature that was accidentally removed from the forums front page in a previous version. When forum administrators toggle the Last Post button in the forums editor, the latest post information will now display correctly, helping users quickly see recent forum activity.
Original PR description
### Steps to reproduce: 1. Create multiple forums. 2. Click on edit in Forums front page. 3. Toggle Last Post button. 4. Last Post doesn't appear. ### Explanation: Last Post was removed from the `forum_all_all_entries` template in *v16.4*. ### Fix: Recreate Last Post, mixing the behaviour and look of *v16.3* (clickable title, truncated text) and the look of *v16.4* (badge with dark background). The `<object>` tag wraps the inner `<a>` tag to avoid nested links issues. opw-3558730 Forward-Port-Of: odoo/odoo#146121
This fix resolves an issue where clicking on a chat item from the messaging menu wouldn't open the chat window after reloading the page from the home menu. The problem occurred because the system was incorrectly detecting whether the Discuss app was active. The fix improves the reliability of this detection, ensuring users can consistently access their chats from the messaging menu regardless of navigation history.
Original PR description
Before this commit, opening chat window from messaging menu might not work. Step to reproduce: - open Discuss app - Go to home menu - Reload the page - Click on Messaging Menu - Click on chat item to…
Before this commit, opening chat window from messaging menu might not work. Step to reproduce: - open Discuss app - Go to home menu - Reload the page - Click on Messaging Menu - Click on chat item to open chat => Chat window is not open This happens because when in the home menu from Discuss app in background page reload, the URL contains the Discuss app menu_id, but the action is "menu" rather the action id. This difference is crucial to distinct discuss app being actively open or it's in the background from home menu. The latter should NOT consider Discuss app being open. This is not a problem when opening/closing Discuss app, because the mounting/unmounting of the Discuss app component is good enough to detect that. However, with page reload, the way to detect Discuss app being open from URL was only relying on `menu_id` instead of `action` value. This commit fixes the issue by checking `active_id` of discuss app rather than `menu_id`, as `active_id` is 100% reliable whereas `menu_id` is not. The problem with home menu is one example among many other cases (e.g. page reload in channel settings form view). https://github.com/odoo/enterprise/pull/54638
This update adds a dismiss button to the Progressive Web App (PWA) installation notification, allowing users to close it without installing. The fix also improves how the notification behaves in private browsing mode and when the app is already installed, preventing confusing situations where the install button wouldn't work.
Original PR description
*: mail This commit fixes the behavior of the notification to install the PWA. The initial spec was not completely achieved, since the 'Dismiss' button, using the fa-close icon was not present. See…
*: mail This commit fixes the behavior of the notification to install the PWA. The initial spec was not completely achieved, since the 'Dismiss' button, using the fa-close icon was not present. See task-3275275. Now, the button is present, and it can hide the notification and the user don't need to interact with the installation prompt to dismiss it. The fix also fixes the behavior of the notification when being used in an incognito tab. The installPrompt service assumed the PWA could be installed, since window.BeforeInstallPromptEvent is defined. But in an incognito scenario, the event was never actually triggered, since the feature is disabled by the browser. This could finally create a UX issue if the app had been installed, and the localStorage cleaned. The notification would appear, but wouldn't do anything when clicking on the Install button since the event is no longer triggered by the browser. Now, we rely on the trigger of the event exclusively, except on Safari, where we rely on the installationState and the standalone display-mode. Now, the service only set its state when the event has effectivelly been triggered and the native prompt can be called. Since the UI relies on the state from the service, the notification is no longer shown. Tests have been adapted, to dispatch a custom event, allowing the service to be initialized as if it was in a situation where the PWA can be installed effectively. A new test have been added to verify the interaction with the close icon.
This update fixes how HTML content is displayed in the onboarding tours for mass mailing and website modules. Previously, HTML tags were shown as plain text to users. Now, the formatted content displays correctly, making the tours more user-friendly and easier to follow.
Original PR description
Current behavior before PR: - HTML tags are displayed in the onboarding tour. Desired behavior after PR is merged: - Display the HTML tag effects instead of showing it in the onboarding tour. After the https://github.com/odoo/odoo/pull/107618 web_tour was converted into Owl, 'markup' was required to show the html tag effect instead of htm tags. Related Enterprise PR-https://github.com/odoo/enterprise/pull/53893 Task-3457112 Forward-Port-Of: odoo/odoo#149647 Forward-Port-Of: odoo/odoo#148604
This update fixes a bug where email message body fields weren't being properly formatted as HTML when the html option was enabled during message insertion. Previously, if a message was inserted without the html option and then re-inserted with it enabled, the formatting wouldn't be applied. This fix ensures HTML formatting is correctly applied every time, improving the consistency of how email content is displayed.
Original PR description
Since [1], the `insert` method accepts the `html` option to automatically cast record fields marked as `html` to markup. Before this PR, this option was ignored after the first insertion if the field value remains the same. Steps to reproduce this issue: - Insert a message without passing the `html` option: the body field is an instance of string. - Insert the same message setting the `html` option to true: the body field of the message is still an instance of string while it should be an instance of markup. This PR fixes this issue. [1]: https://github.com/odoo/odoo/pull/139501
This fix resolves an issue where Stripe payment configuration would fail when using non-ASCII custom domain names (like test-môu.com). The system now properly encodes domain names so they work correctly with Stripe's API, allowing businesses with international domain names to set up and use Stripe payments without errors.
Original PR description
Steps to reproduce: - Configure a non-ASCII custom domain (Punycode encoded) on a database (e.g. `test-môu.com` <> `xn--test-mu-y0a.com`). - Setup test API keys on a Stripe account ("Publishable" &…
Steps to reproduce:
- Configure a non-ASCII custom domain (Punycode encoded) on a database
(e.g. `test-môu.com` <> `xn--test-mu-y0a.com`).
- Setup test API keys on a Stripe account ("Publishable" & "Secret").
- Install and activate the Stripe payment acquirer (in "Test Mode").
- Go to the Stripe Odoo config (Invoicing > Payment Acquirers > Stripe).
- Configure Stripe API keys and click on the button to "GENERATE YOUR
WEBHOOK" > traceback:
`Invalid URL: Non-ASCII characters in URLs must be percent-encoded in order for the URL to be valid`.
The same error occurs in every interaction with the Stripe API.
The `get_base_url()` refactoring (exactly [1]) introduced a way to get
the most suited URL for a record in the following order:
`record.website_id` > `record.company_id.website_id` > The ICP:
`web.base.url`.
For payment acquirers, and to handle multi-website scenarios, the code
uses the base URL: `httprequest.url_root` which explains why the error
occurs even when the domain name is configured in punycode.
The goal of this commit is to fix this behavior by correctly encoding
the returned base URL.
[1]: https://github.com/odoo/odoo/commit/92175d3341b576676a550c60db7c759f71cb17ea
opw-3619608
Forward-Port-Of: odoo/odoo#149801
Forward-Port-Of: odoo/odoo#147388This fix reduces notification noise in channels by only alerting users about messages that are explicitly marked as important (through mentions or replies), rather than notifying on every new message. Chat conversations and direct messages continue to notify on all messages as intended. This helps users stay focused on relevant communications while keeping channels as a broadcast medium.
Original PR description
Before this commit, any new message in a channel of type "channel" was automatically opening a chat window and showing new message counter in tab title when out-of-focus. This behaviour is only intended for important messages. In chat (group chat, DM chat, livechat), all new messages are considered as important so this is good. However, for channels, these are intended for communication with many users, and we only want to notify on messages that are explicitly flagged as "needaction". As a reminder, message are needaction through `@mention` or reply-to for example. This commit fixes the issue by limiting notifying out-of-focus of new messages in channel "channel" to only needaction. Also the auto-opening of chat window as a consequence from this new message is also limited to needaction messages.