Friday, October 6, 2023
17 changes · master
Resolved issues and error corrections
This fixes a crash that occurred when users selected "Get View" from the debug menu. The debug tool now handles the updated view format correctly, helping administrators and support teams inspect views without interruption.
Original PR description
Since commit [1], there was a crash when the user clicked on the "Get View" item in the debug menu (in any views). This was because the arch now received by the views in props is an XmlDocument, whereas before it was a string. [1] odoo/odoo@cc3a3a328db913da76573404967e1190f40bcc98 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 fixes a problem that prevented users from uploading attachments when posting information, such as in the Expenses app. The change restores support for sending multiple uploaded files correctly, reducing disruption in workflows that rely on attachments.
Original PR description
In a recent commit odoo/enterprise/pull/47775 the post function was modified so that it directly adds the values in params to the FormData object. Before, a check was done to see if the value was an array and handle it accordingly. This change resulted in not being able to upload attachments in the expense app and probably in other places, as the files were sent in an array to the post method. This commit fixes the issue by adding the check for arrays again. task-3527686
Brazilian credit notes now use the same numbering sequence as invoices, preventing duplicate document numbers and validation errors. This helps users create credit notes directly without being blocked by conflicts in electronic invoice numbering.
Original PR description
#### Steps to reproduce 1. Create a fresh DB with the Brazilian localization. 2. Create a new Credit Note (directly from the menu, not from an invoice). Confirm. 3. Observe that you get a…
#### Steps to reproduce 1. Create a fresh DB with the Brazilian localization. 2. Create a new Credit Note (directly from the menu, not from an invoice). Confirm. 3. Observe that you get a ValidationError: "Another entry with the same name already exists." because the name of the Credit Note is NFe 00000001, and an invoice called NFe 00000001 already exists. #### Analysis - The credit note should be called NFe 00000002, because in Brazil the same sequences should be used both for invoices and for credit notes of a given document type. - However, because the `refund_sequence` field is set to True on the 'Customer Invoices' journal, the sequence mixin doesn't consider invoices and credit notes as using the same sequence, and therefore doesn't consider the existing invoice when finding a new name for the credit note. #### Solution - Set the field `refund_sequence` to False on the journal created by the l10n_br template. - We also take the opportunity to move the code that provides a default name to the demo invoices to a separate file demo/account_demo.py, for consistency with other localizations.
Sales reports now group by the main product record rather than separating results by individual product variants. This makes product-level reporting match user expectations, while a separate grouping option remains available for product variants when that detail is needed.
Original PR description
Group by "Product" was grouping by product variant instead of product template. opw-3477918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes cases where form fields could keep showing a user-entered value even after Odoo's automatic field logic changed it back or encountered an error. Business users will see more reliable form behavior, especially for checkbox, text, and HTML-based fields that depend on automatic updates.
Original PR description
The goal of this commit is to resolve: ===================================== 1. When you edit a Char or Boolean field with an onChange that returns the value before editing, you must display the…
The goal of this commit is to resolve:
=====================================
1. When you edit a Char or Boolean field with an onChange that returns
the value before editing, you must display the value of the onChange.
2. In the model, html fields are always Markup fields. But when we evaluate
a modifier containing an html field, we use the server value (a string or false).
3. When we edit a field and its onChange returns an server error, we want to
revert its value to the valuea before edition.
Solution:
=========
1. Always render when applying a change, even if the value does not change,
because onChange returns the initial value. To do this, we'll apply
the changes to record.data, then apply the changes from onChange.
The value will therefore change, which will cause all the components
observing the value in record.data to render.
2. When we update an html field, its value will always be markup and
we'll store it as a string in _textValue so that we can evaluate the
modifiers without the markup. For changes coming from the onChange, we
will store the value in _textValue and apply markup on it for record.data.
3. When an onChange returns an server error, we will apply the changes and then
revert them directly. This will have the effect of triggering a rendering
on all the components observing to the record.data corresponding to
the changes and so displaying the values before editing.
How to reproduce:
=================
Case 1:
------
- Go to a form view containing a boolean field with an onChange
- Check the boolean field
- The onChange returns with the value false
Before this commit:
The boolean field is always checked
After this commit:
The boolean field is no longer checked
Case 2:
------
- Go to a form view containing an html field and an field "x" with
invisible ="not html_field" and an onChange
- Edit the field "x"
- The onChange returns the value false for "html_field".
Before this commit:
The field "x" is always displayed
After this commit
The field "x" is no longer displayed
Case 3:
------
- Go to a form view containing a char field with an onChange
- Edit the field
- onChange returns a server error
Before this commit:
The field is marked as invalid and contains the value after editing.
After this commit:
The field contains the pre-edit valuePrinting sales quote PDFs now continues even if the header or footer cannot be rendered. Instead of showing users a technical error, the issue is recorded in the log so the document can still be produced.
Original PR description
before this commit, on printing the report if there is an exception happens on rendering the header and footer, traceback is shown to user without skipping the exception AttributeError: 'sale.order.template' object has no attribute '_message_log' after this commit, if exception happens on rendering the header or footer, a message will be added in the log and report will be printed without traceback  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo can now initialize new databases correctly on PostgreSQL 15 and later when using the recommended limited-permission database user. This prevents setup failures caused by newer PostgreSQL permissions and keeps new deployments working without requiring administrator-level database access.
Original PR description
**Description of the issue/feature this PR addresses:** From PostgreSQL's point of view, as of version 15.0 and above the default behavior is to constrain ordinary users to user-private schemas. For…
**Description of the issue/feature this PR addresses:** From PostgreSQL's point of view, as of version 15.0 and above the default behavior is to constrain ordinary users to user-private schemas. For every user needing to create non-temporary objects, it's advised that they create a schema with the same name as that user (Recall that the default search path starts with $user, which resolves to the user name. Therefore, if each user has a separate schema, they access their own schemas by default.) This pattern is a secure schema usage pattern. See Section 5.9.6 https://www.postgresql.org/docs/current/ddl-schemas.html and https://www.postgresql.org/docs/release/15.0/ Databases migrated from previous versions of postgresql will have the default public schema writable, but new odoo instances on postgresql version 15 and above do not work. To fix this We'd create a new schema in the database that's the same name as our database user after we create our empty database **Current behavior before PR:** Initializing a new Odoo database on Postgres version 15.0 and above with a user with only the LOGIN and CREATE DATABASE roles would result in an error `permission denied for schema public` Because of this, no database tables are created on new databases using postgres V15.0 and above Desired behavior after PR is merged: Full functionality is restored by creating all tables in a schema that matches the database user --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where inserting an image in the website or mass mailing editor could add the text "[object HTMLImageElement]" instead of the image. Users can now insert images normally even when the editor is embedded in different page contexts.
Original PR description
Steps: - on website or mass_mailing, insert an image via the "/image" command, - a text node containing "[object HTMLImageElement]" is pasted instead of the expected content. Since [1], when inserting a node, the instanceof operator is used to compare that node to the Editor's document global `Node` object. While it fixed cases where there was as mismatch of `Node` objects (nodes created by the top document x nodes created via the iframe's document), it revealed errors elsewhere. Notably, the MediaDialog inserts an image node created by the top document, regardless if the editor is mounted in an iframe. This commit makes the "insert" command more permissive when resolving if `content` is a Node or a string. task-3543003 [1]: https://github.com/odoo/odoo/commit/bfe0c5fedf172f4c77002a4f54803b376ada43ce
This fix prevents an error when users create calendar records that include custom properties in the related form. It ensures the calendar creation dialog opens normally, improving reliability for teams using project tasks and custom fields.
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
Users who switch dark mode while working in the website backend now remain in the backend after the page reloads. This avoids unintentionally sending them to the public website page and makes the editing experience smoother.
Original PR description
*enterprise Since this task in community adds the user menu in the navbar, it is now possible to toggle the dark mode from the website backend. However, (1) toggling the dark mode reloads the page, and (2) since [commit 1], nothing in the displayed URL differentiates the frontend from the backend in the website app, meaning that reloading the page from the backend actually leads to the frontend page. This commit patches the `color_scheme_service` in order to remain in the backend if it is toggled from the website app. [commit 1]: https://github.com/odoo/odoo/commit/1c18b79972c3b0a97197b98390e0ba9fda703585 task-3381773
The recruitment document digitization message now uses "Resume" instead of "CV" when users do not have enough credits. This makes the wording clearer and more consistent for applicants and recruiters, with no functional change.
Original PR description
Change replaces word "CV" with word "Resume" in error message telling that you don't have enough credits to digitize document in application task-3539236
This update adjusts the Documents test suite to account for a brief delay before boolean toggle changes appear on screen. It helps keep automated checks stable and reduces the risk of false test failures after recent interface behavior changes.
Original PR description
The changes introduced to BooleanToggleField by the PR: https://github.com/odoo/odoo/pull/136924, mean that an update executed on a boolean field from a Component other than the BooleanToggleField displaying it requires waiting for one more nextTick for the change to be displayed. This is caused by useObserveRecord waiting for an animationFrame to execute its callBack and therefore in this case to apply the change of state to the BooleanToggleField.
This change fixes the WhatsApp point-of-sale settings so the receipt template can be selected when WhatsApp is enabled for POS. It prevents users from being blocked by a read-only field and restores the expected setup behavior.
Original PR description
before this commit, if the WhatsApp Enabled is pos setting the receipt template remains readonly and user cannot edit and change the template value after this commit, wrongly given invisible attribute will be changed to required attribute as in the lower version, ie, 16.3 and 16.4
Attachments now appear correctly in the Journal Items list preview. This fixes a display issue that prevented users from seeing attached files where expected, improving access to supporting accounting documents.
Original PR description
After the changes made in odoo/odoo/pull/114024, a related field is not fetched if invisible. This causes the mimetype in main_attachment_ids field to not be fetched in the Journal Items list view therefore no attachments are shown in the preview. This commit fixes the issue. task-3531478
This change makes an automated Studio test wait for an expected error before checking the result. It helps prevent random test failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
This commit ensures the error event is handled before the assert in in the "error when new app's view is invalid" studio test. This could lead to an nondeterministic error in the test. runbot-error-24580
This update adjusts an internal performance test threshold for Australian payroll accounting to reduce false failures caused by variable caching and data volume. It helps keep automated validation reliable without changing payroll features or user workflows.
Original PR description
Those tests could have some random requests, as there are a lot of records and the cache could have some random behavior according to the execution order, the number of installed module, so I'm gonna just bump it a little bit.
This update fixes Avatax accounting tests by removing a dependency on a sales-related field that is not always available. It helps ensure the Avatax module can be tested reliably regardless of installation order, reducing the risk of false test failures.
Original PR description
removed the reference to field invoice_policy, added in a module this one doesn't depend on (sales). This has been wrong since a long time and was only put into light with the recent changes of 70329177713131d3d6ec424137cad3702e9d38ae (#136490) where the order of modules' installation changed, avatax being installed before sales.