Daily updates from Odoo
Friday, January 19, 2024
24 changes · 17.0
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.