Wednesday, October 30, 2024
21 changes · 17.0
Enhancements to existing features
The Spanish localization now includes a new tax grid for Modelo 390 line 110. Taxes already reported on the related Modelo 303 line are linked to this new grid, helping keep annual VAT reporting aligned and easier to complete.
Original PR description
[IMP] l10n_es: Add new tax grid for es *Create a new tax grid mod390[110] *Add this tax grid to all taxes in l10n_es on Distribution lines that already have mod303[120] *Make the modelo 390 use that tax grid on the line 110 task-4058894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes a case where website pages could incorrectly rely on missing session data when checking a user’s access rights. The system now falls back to a direct check when needed, helping ensure user-specific features appear or behave correctly without loading extra data for all visitors.
Original PR description
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there,…
Commit [1] optimized the `has_group` util to avoid a RPC for information that is already in the session_info. The problem is that it supposed that this information would always be available in there, which was already not the case for the frontend `session_info` when this was done. This commit simply makes the util not cache a value if there was actually no found value, and thus let the util falls back to making a RPC if needed. Note that in 18.0, the user service is actually not a service anymore (since commit [2]) and is the only truth of information about user data (since commit [3]), so this makes this even more important. We could consider adding the same group information in the frontend session_info in the future, but in general we want to avoid loading any useless information for visitors and would not mind the extra RPC for connected ones when it comes to the website. [1]: https://github.com/odoo/odoo/commit/da257e9d572047617cdfaac33fbe47983e8ab30d [2]: https://github.com/odoo/odoo/commit/3fb72654a898eb5c5b1c89279b0638dab8e3881d [3]: https://github.com/odoo/odoo/commit/182b0554882a2eeb5d86c9cb6fdaed6618b2615b Related to task-4290643
Miscellaneous changes
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#184240 Forward-Port-Of: odoo/odoo#176074
Original PR description
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#184240 Forward-Port-Of: odoo/odoo#176074
This fixes recurring project tasks so the system only prepares the next task when one is actually needed. It helps prevent unwanted child tasks from being created, reducing clutter and avoiding extra cleanup for project teams.
Original PR description
Currently, the _create_next_occurence_values method is always called, even if no next occurences need to be created. This is bad, because if the next condition in the code is falsy, we would have created child tasks for nothing since childs are created using copy() in the method to handle recursion. This PR will fix it by checking beforehand if any next occurence should be made, and call _create_next_occurrence_values only if so. task-4269547
The datetime picker now correctly handles default times whose minutes do not match the usual 5-minute increments. This prevents misleading minute values from appearing when users create filters, improving confidence that selected dates and times are applied as expected.
Original PR description
Steps to reproduce ================== - Open any list/kanban view - Add a custom filter - Select a datetime field, for example Created on => The default value is the current datetime If you click on the datetime field, the datetimepicker is opened but the minutes are set to 00. If you click on apply, 00 is not set. Cause of the issue ================== The DateTimeInput has a rounding props (by default 5). If we open it with a value that has the minutes not rounded by that amount, 00 will be displayed instead because a <select/> is used, and only the rounded values are present. Solution ======== Round the default value to the nearest 5 minutes opw-4170906
The text editor customization panel now clearly highlights the currently selected dropdown option. This makes editing pages easier and more consistent by reducing confusion when choosing formatting or customization settings.
Original PR description
Before this commit, the selected value in dropdowns within the text editor toolbar was barely visible. This commit adds styles to highlight the selected option, making it clearly visible and aligned with the other dropdowns for better user experience and consistency. Before:  After:  task-4150489
Pressing Escape while viewing a thread action in a chat window now closes just that thread action instead of closing the whole chat window. This makes chat navigation less disruptive and helps users keep their conversation window open while backing out of a sub-view.
Original PR description
Before this PR, pressing the `Escape` key in an open thread action within the chat window would close the entire chat window rather than just the thread action. This PR fixes the issue by ensuring `Escape` closes only the active thread action. task-4290661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Default exports now exclude fields that are hidden from users. This keeps exported spreadsheets focused on visible, relevant business data and avoids exposing technical calculation fields by default.
Original PR description
Currently, the invisible fields are considered in the export default fields. It doesn't make sense from a user perspective as those are generally technical fields used for computation. This wasn't the case prior to v17. The fix is to filter the invisible fields. task-4277023
This update resolves an issue where the Helpdesk module was incorrectly creating an empty partner record when attempting to 'Plan Intervention' on a ticket without a defined contact. The fix prevents the system from generating a partner when required information is missing, ensuring data integrity and preventing unnecessary record creation.
Original PR description
Steps: Create a ticket with no partner. Click on 'Plan Intervention'. The modal opens. Issue: See that a partner "@" has been created and set. Cause: Clicking on the button calls `action_generate_fsm_task`, which calls `_find_or_create_partner`, but the args, `self.partner_name` and `self.partner_email`, are empty. Solution: Not try to create a partner when the fields both empty. task-4265584
This update resolves an issue where the preparation display would generate an error if a product's category wasn't found. The change ensures that the display gracefully handles missing categories, preventing errors and improving the user experience. This backport addresses a previous bug.
Original PR description
Before this commit, if one of the product's categories was not included in the preparation display, it would lead to an error. Backport of https://github.com/odoo/enterprise/pull/66479 opw-4292494
This update fixes a calculation error in the Deferred Expense Report. When the report's end date is before its start date (e.g., looking at a previous month), the report was incorrectly displaying negative amounts. This change ensures the report accurately shows a zero amount in these scenarios, preventing incorrect financial reporting.
Original PR description
Version: 17.0+ Issue: In the Deferred Expense Report, there is a missing check for if the `period_end` is before the `period_start` for when the deferred method is 'day'. If the `period_end` is in the same month as selected month of the report, the later column will compute the amount to be negative of the `amount_per_day` times the difference of days. For example, if the end date is 2024-11-04 and we look at the month of November, the later column will display the negative amount of 26 days. In this example the amount is expected to be 0. Purpose of this PR: To add an additional condition, if the `period_end` is before the `period_start` then the amount should be 0. opw-4231549
This update fixes an issue where return labels were incorrectly using the customer's information as the shipper. Now, the shipper field accurately reflects the original sender (ship-to) ensuring correct billing for returned shipments. This improves the accuracy of our return processes.
Original PR description
**Current behavior:** Return labels are being generated with the `shipper` field set to the partner defined on the delivery picking (i.e., customer). **Expected behavior:** `shipper` should match the `ship_to` field (the original sender) as this field informs who gets billed for the return shipment. **Steps to reproduce:** Generate a return label with `delivery_ups_rest`. **Cause of the issue:** The return label is generated with `shipper=picking.partner_id`. **Fix:** Set it to `shipper=picking.picking_type_id.warehouse_id.partner_id` (which matches the `ship_to` argument). opw-4147118 Forward-Port-Of: odoo/enterprise#72482
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185817
Original PR description
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185817
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification challenge` record 3) Create a new `goal` in the gamification challenge 4) Make sure the goal has the definition as `Automatic: sum on a field` 5) Select the model as `account` 6) Uninstall the invoicing module and start the `challenge` of that gamification. Error:- ``` KeyError: Fals
Original PR description
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification…
Currently, a traceback occurs when the user deletes a module which is having a gamification goal record. To reproduce this issue: 1) Install `sale` and `gamification` 2) Create a new `gamification challenge` record 3) Create a new `goal` in the gamification challenge 4) Make sure the goal has the definition as `Automatic: sum on a field` 5) Select the model as `account` 6) Uninstall the invoicing module and start the `challenge` of that gamification. Error:- ``` KeyError: False ``` The value of the model_id became `False` when the user deletes a module used in goal. This leads to a traceback as model_id is used for the reference of obj https://github.com/odoo/odoo/blob/d9603e93d2ab5e0b9fd1948dfd3e3bee20ede599/addons/gamification/models/gamification_goal.py#L164-L165 We can resolve this issue by adding `ondelete='cascade'` in the field definition. Where the record will be deleted if the corresponding model is uninstalled. sentry-4089991441 Forward-Port-Of: odoo/odoo#180307
Currently, when the stock scheduler is run, a new cursor is created and the result is rolled back even if all tasks succeeded. Even though tasks themselves are not rolled back because they are run using new other cursors, rolling it back is not correct and it makes harder to test the scheduler feature. The rollback was introduced in da6bd90e by mistake. This commit makes the transaction to be rolled back only when the current transaction actually failed. --- I confirm I have signe
Original PR description
Currently, when the stock scheduler is run, a new cursor is created and the result is rolled back even if all tasks succeeded. Even though tasks themselves are not rolled back because they are run using new other cursors, rolling it back is not correct and it makes harder to test the scheduler feature. The rollback was introduced in da6bd90e by mistake. This commit makes the transaction to be rolled back only when the current transaction actually failed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175621
Update branding logo and icon in windows installer. Old forgotten task Task-2862802 Forward-Port-Of: odoo/odoo#185650
Original PR description
Update branding logo and icon in windows installer. Old forgotten task Task-2862802 Forward-Port-Of: odoo/odoo#185650
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "H
Original PR description
Problem: Certain `ir.actions.act_window` actions contain a context with `active_id`, which causes issues when set as home actions, as `active_id` will not be defined in that context. Solution: Prevent the selection of actions that include `active_id` in their context from being set as home actions. Steps to reproduce: 1. Enable debug mode. 2. Navigate to `Settings / Users & Companies / Users`. 3. Select the current user from the list. 4. Under Preferences / Menus Customization set "Home Action" to "Quotations and Sales." 5. After that: each time you go to backend homepage (/) you get a traceback error instead of the app dashboard opw-4283156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185319
Use normalized emails for comparison to avoid issues linked to formatting. Task-4281171: [mail] {email/smtp}_from normalized comparison Forward-Port-Of: odoo/odoo#185749
Original PR description
Use normalized emails for comparison to avoid issues linked to formatting.
Task-4281171: [mail] {email/smtp}_from normalized comparison
Forward-Port-Of: odoo/odoo#185749When an event is created with a private address attendee and an internal user attendee who has minimal contacts permissions, the internal user with minimal contacts permissions would encounter an access error when trying to sync with Google. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183480
Original PR description
When an event is created with a private address attendee and an internal user attendee who has minimal contacts permissions, the internal user with minimal contacts permissions would encounter an access error when trying to sync with Google. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183480
Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e. ``` E-wayBill Sent Number -> 0 Validity -> None ```  where as in the response attachment of eWaybill, the ewaybill number does exist In this commit, we resolve the above issue and the correct ewaybil
Original PR description
Issue found at commit: https://github.com/odoo/odoo/commit/0e8f3d5c42b4f219e4e7db6915dd1dd7ec45e4b4 After the above mentioned commit when using eWaybill with e-Invoicing the log note of ewaybill i.e. ``` E-wayBill Sent Number -> 0 Validity -> None ```  where as in the response attachment of eWaybill, the ewaybill number does exist In this commit, we resolve the above issue and the correct ewaybill number gets logged opw-4280093 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#185680
This pull request updates the French translations for the l10n_fr_fec_import and l10n_fr_reports modules. These updates ensure that the Odoo Enterprise software is correctly localized for French-speaking users, improving the user experience and accuracy of reports and data import functionalities.
Original PR description
*l10n_fr_fec_import,l10n_fr_reports Related to https://github.com/odoo/odoo/pull/185817 Forward-Port-Of: odoo/enterprise#73048