Wednesday, September 11, 2024
8 changes · 17.0
Enhancements to existing features
Automation rules can no longer be created for models that have no fields. This prevents users from selecting unusable models and avoids confusing warnings or errors during rule setup.
Original PR description
Before this commit: Previously, when creating automation rules, users could select models that did not have any fields. This would result in either an invalid domain warning or an error. Steps to reproduce: - Install base_automation. - Navigate to Settings > Technical > Automation > Automation Rules. - Give an appropriate name to the rule and select base as the model. After this commit: Users will no longer be able to create automation rules for models without fields. Task-3874560 ---
Resolved issues and error corrections
This fixes a configuration migration issue for hardware drivers so it looks for the intended old configuration file before moving settings into the newer odoo.conf file. It helps avoid missed settings during upgrades or migrations, reducing manual follow-up for affected installations.
Original PR description
The migration method from old config files to the new `odoo.conf` searched for a file named `subject` instead of `odoo-subject.conf`.
Features or functions removed from Odoo
An unused partner-related accounting function was removed because it was no longer called anywhere in the system. This is an internal cleanup that helps keep the accounting codebase simpler and easier to maintain, with no expected change for users.
Original PR description
The function mark_as_reconciled of res.partner was not used in the code, so it could be removed. task-4085127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
In some occasions, Authorize would decline a payment and provide the reason for it, but not mark the payment as in error. The customer would see that their payment is cancelled but not know what to do. That is because error messages were not processed in the case of declined payments. This commit makes eventual error messages (decline reasons) logged on the linked document's chatter and displayed on the /payment/status page. opw-4125895 Forward-Port-Of: odoo/odoo#178401
Original PR description
In some occasions, Authorize would decline a payment and provide the reason for it, but not mark the payment as in error. The customer would see that their payment is cancelled but not know what to do. That is because error messages were not processed in the case of declined payments. This commit makes eventual error messages (decline reasons) logged on the linked document's chatter and displayed on the /payment/status page. opw-4125895 Forward-Port-Of: odoo/odoo#178401
The donation snippet now reuses currency information while it is active instead of requesting it again after every text change. This reduces unnecessary background work and prevents visible page jumps while editing donation content.
Original PR description
Since 17.0 and [renderToElement], the snippet is rerendered (and thus starts anew) on every key input in the descriptions options. The donation's publicWidget fetches the currency to display every time on start, meaning that it does a query on every key press. This also triggers jumps on the screen. To avoid both issues, this commit caches the currency for the duration of the publicWidget life. [renderToElement]: f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b task-4032975
This change prevents an error when the Kenyan OSCU stock integration handles an empty purchase order. It improves reliability in purchase-related workflows and avoids failures in automated checks for new records.
Original PR description
Issue found when following [tests](https://runbot.odoo.com/runbot/build/65284466) broke When purchase.order was empty, _Compute_display_name was still trying to compute display name of purchase.order.lines, and this was causing error in test_display_name_new_record test. This pr fixes the issue.
Version: 16 Description of the issue/feature this PR addresses: A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is not on hand in menu "Accounting / Customers / Third Party Checks" if journal doesn't has "Existing Third Party Checks" incoming payment method. Steps to reproduce: 1) Log in with admin on runbot odoo enterprise 16 instance and install l10n_latam_check (Third Party and Deferred/Electroni
Original PR description
Version: 16 Description of the issue/feature this PR addresses: A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks"…
Version: 16 Description of the issue/feature this PR addresses: A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is not on hand in menu "Accounting / Customers / Third Party Checks" if journal doesn't has "Existing Third Party Checks" incoming payment method. Steps to reproduce: 1) Log in with admin on runbot odoo enterprise 16 instance and install l10n_latam_check (Third Party and Deferred/Electronic Checks Management) module. 2) Go to "Accounting / Configuration /Accounting / Journals" and create a new journal of type "Cash" and add incoming payment method "New Third Party Checks".  3) Create a new customer payment with journal created on step 2 and "New Third Party Checks" payment method and confirm.  4) Go to menu Third Party Checks and the check received on step 3 is not on hand.  Current behavior before PR: A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is not on hand on tree view in "Accounting / Customers / Third Party Checks" if the journal doesn't has "Existing Third Party Checks" incoming payment method. Desired behavior after PR is merged: A third party check received in a customer payment with journal with type "Cash" and Incoming payment method "New Third Party Checks" is on hand on tree view in "Accounting / Customers / Third Party Checks" if the journal doesn't has "Existing Third Party Checks" incoming payment method. Ticket Adhoc side: 77887 Task Latam side: 1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174283
Previously, setting the `size` prop to `fullscreen` in the `Dialog` component caused an error in debug mode, as the `fullscreen` utility class from Bootstrap was not included in the props. This commit resolves the issue by allowing the `fullscreen` option in the `size` props, ensuring compatibility with Bootstrap's utility classes. Forward-Port-Of: odoo/odoo#174588
Original PR description
Previously, setting the `size` prop to `fullscreen` in the `Dialog` component caused an error in debug mode, as the `fullscreen` utility class from Bootstrap was not included in the props. This commit resolves the issue by allowing the `fullscreen` option in the `size` props, ensuring compatibility with Bootstrap's utility classes. Forward-Port-Of: odoo/odoo#174588