Friday, December 22, 2023
23 changes · 17.0
Resolved issues and error corrections
This fixes an issue where users could not drag and reorder related records shown inside a form dialog. The change preserves the intended ordering rules from the form when the list view does not define its own order, making record organization work as expected.
Original PR description
Before this commit, in a non-editable x2many in list mode, if there is a field "A" with many2many_tags which is displayed as an x2many in list mode in the form dialog, it cannot be reordered with…
Before this commit, in a non-editable x2many in list mode, if there is a field "A" with many2many_tags which is displayed as an x2many in list mode in the form dialog, it cannot be reordered with handle field. Problem: When we extend a record from an x2many to a form dialog, we use the activeFields defined in the form view and patch them with those in the list view. Currently, we always use the default order from the list view even if it doesn't exist. So we always ignore the one defined in the form view. Solution: If there is no default order in the list view, we use the one in the form view. How to reproduce: - Go to a form view with an x2many field in list mode which contains an "A" field with the many2many_tags widget. - Click on a record in the x2many - A form dialog opens with field "A" in the form of an x2many in list mode, containing a handle field. - drag and drop a line to reorder the records Before this commit: It is not possible to reorder records After this commit: It is possible to reorder records Task ID: 3641933
This fixes a timezone mismatch that could incorrectly block valid time off requests. Employees can now request leave against their approved allocations when their personal time zone differs from the working schedule time zone.
Original PR description
Steps to reproduce: - Create Allocation for 20 days for Mitchell Admin and validate (12/01 to 12/31). - Set Working Schedule "Standard 40 hours/week" to UTC timezone. - Set Mitchell Admin's timezone to Europe/Zurich. - Create a time off with type Extra Time Off with dates 12/29 - 12/29 and try to save. - Receive Validation Error: There is no valid allocation to cover that request. Issues: You cannot request that leave due to a timezone mismatch, even though you should be able to. Solution: To solve the zone mismatch we use the employee timezone to compute the attendance intervals. opw-3619178
This fixes an issue where adding a new line or related record in a form could cause automatic calculations to ignore existing sibling records. Forms should now refresh with more accurate computed values, reducing the chance of incorrect information being shown while editing.
Original PR description
When we add a new record N to an one2many tree view from an existing record X form, during the onchange() on the one2many comodel, the cache of the N.one2many contains only the new record X (the siblings aren't in it). Because of this, the result of compute methods may be incorrect and the form won't be updated accordingly. See the test for a concrete example. Technically, this is due to _update_cache() forcing the inverse field value to the single value of the new record (`not cache.contains(inv_rec, invf)` is True), instead of also considering the original values (which is properly done by Field._update()). https://github.com/odoo/enterprise/pull/53298
This fix prevents form action buttons from appearing inside pop-up dialogs where they could disrupt the workflow. It helps users handle temporary or not-yet-saved records more reliably, reducing confusion and potential errors during data entry.
Original PR description
Prior to this commit, `ButtonBox` components were rendered inside `Dialog` ones. The approach created issues in the user flow, particularly in cases involving intermediary records that were not yet saved yet. task-3619180
This fix ensures restaurant point-of-sale order changes are sent to the printer before they are saved. Staff can now rely on the Order button to print new kitchen or preparation updates as expected, reducing missed preparation instructions.
Original PR description
Current behavior: When trying to print the changes of an order, nothing was printed. This was happening because we were first saving the changes before sending them to the printer. Because of this when we tried to retrieve the changes to print them, they were already saved and we were not retrieving anything. Steps to reproduce: - Setup a printer to print order changes - Create a new order in PoS restaurant - Add a product to the order - Click on the "Order" button - Nothing is printed opw-3625397 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Barcode scanning now shows a clear error message when something goes wrong instead of displaying a technical traceback. This improves the user experience by helping staff understand scanning issues without needing technical support.
Original PR description
**Before this PR:** Got a traceback instead of an error message on scanning a barcode. **Reason:** Until 16.4 error message send in the object via Eventbus, which removed in https://github.com/odoo/odoo/commit/72dbb75d4de529a35c45273ded472d038a7bb738 so because of that error message will be sent directly(not in object). **After this PR:** User will get an error message if anything wrong happened. **Task**:3524284
This update fixes two issues in the appointment scheduling system. First, it removes a restriction that prevented assigning multiple staff members to custom appointments, allowing more flexibility in scheduling. Second, it restores proper validation of all form fields during appointment creation, ensuring required information is always collected before submission.
Original PR description
1. Removes unique user constraint on custom appts. 2. Fix form validation in front end, making all fields validated. Task-3549573
This fix resolves a crash that occurred when opening the activity view in the Documents module during debug mode. The issue was caused by a missing required field parameter that wasn't being passed correctly. Users can now open the activity view without encountering errors.
Original PR description
Before this commit: When we try to open the activity view in debug mode we get a traceback. Technical Reason: - After the following [COMMIT](https://github.com/odoo-dev/enterprise/commit/127f512b1a72957eb23c41103ecab44e1fdce0e7#diff-78d9f8faf609f35072d4b2617a9e13b3f137a679efb2c46c84acf29da4edfe46R67), the static prop 'fields' was added to the `DocumentsInspector`. Hence when we turn on the debug mode (i.e. when validating the props), the `fields` prop is not found, resulting in a traceback. - The reason is that its value is not passed when called from the `DocumentsActivityRenderer`. - We do not get the traceback when debug mode is turned off, because in the activity view, the template rendered by the `DocumentsInspector` does not read the value inside the `fields` prop. After this commit: The activity view will be open without any issues. Task-3491723
This fix resolves a bug where changing the scheduled date of a Manufacturing Order would incorrectly reset quantity values back to the original Bill of Materials defaults. Users can now modify quantities in a Manufacturing Order without them being overwritten when updating the scheduled date. This ensures Manufacturing Orders maintain their customized values independently from the source Bill of Materials.
Original PR description
In a Manufacturing Order based on a BoM, changing the qty values and then change the scheduled date will reset the qty to the bom ones. This should not be the case. odoo: https://github.com/odoo/odoo/pull/143496 opw-3568943 Forward-Port-Of: odoo/enterprise#52254 Forward-Port-Of: odoo/enterprise#51822
This fix resolves a crash that occurred when users tried to delete a stage (column) in the Helpdesk kanban view when grouped by state. The issue was caused by recent changes to how the system tracks group information. Users can now successfully delete stages without encountering errors.
Original PR description
Since the refactoring of the relational model [1], group.resModel is the name of the model of the records, whereas before it was the name of the relation of the field we were grouped by (when grouped by a many2one field). Moreover, group.resId no longer exists, the id of the group is now stored in group.value, by consistency when grouped by other field types than many2one. Before this commit, a crash occurred when the user tried to delete a stage (a column) in the Helpdesk kanban view, when it was grouped by state_id. [1] https://github.com/odoo/odoo/pull/114024 OPW-3629005
Fixed a bug where the appointment booking system was not respecting the minimum scheduling hours set by administrators. Now when a business sets a minimum advance booking time (such as 48 hours), the system correctly prevents customers from booking appointments before that minimum time has passed. This ensures better control over scheduling and gives businesses adequate preparation time.
Original PR description
Steps to reproduce: - Install appointment app - Setup online meetings with minimum scheduling of 48 hours for example Issues: Minimum scheduling hours set are not respected. Solution: Set the local start to be the first possible schedulable date rounded to the next hour. opw-3359002 Forward-Port-Of: odoo/enterprise#52809 Forward-Port-Of: odoo/enterprise#50795
Fixed an issue where dark mode settings were not preserved after closing the Studio editor. Previously, users who switched to dark mode would see the interface revert to light mode when exiting Studio. This fix ensures the user's preferred color scheme is maintained throughout their session.
Original PR description
*: web_enterprise When opening Studio, the color scheme is reset to light mode. Before this commit, if the UI was in dark mode before opening Studio, when leaving it the dark mode isn't applied back. This commit fixes it by keeping track separately of the configured color scheme and the effective one in the "color_scheme" service. Steps to reproduce: * Switch to dark mode * Open Studio * Close it => color scheme is still "light" opw-3419363 Forward-Port-Of: odoo/enterprise#52880 Forward-Port-Of: odoo/enterprise#44026
This fix resolves a crash that occurred when users copied shifts in the Planning app and then navigated away before clicking the undo button. The undo notification now automatically disappears when leaving the Planning app, preventing the error that appeared when users tried to undo after switching to another screen.
Original PR description
Steps: - Install planning. - Copy shifts of the previous week. - A toaster notification appears with a `UNDO` button. Issue: - When this toaster notification appears, at that time if we close the `Planning` app and move to the home menu or another app, and then click on the `UNDO` button then a traceback appears stating that `Component is destroyed`. Cause: - We are moving back to the home screen so the state of the component is changed from `Mounted` to `Destroyed`. Fix: - When we move back to the Home menu this particular toaster notification containing the UNDO button should not be visible. We are achieving that using onWillUnmount. task-3522253 Forward-Port-Of: odoo/enterprise#53094 Forward-Port-Of: odoo/enterprise#47974
Portal users viewing project tasks now see the correct number of hours based on the invoicing policy setting. Previously, the task summary showed all timesheet hours while the task details only displayed validated timesheets, causing a confusing discrepancy. This fix ensures consistent hour reporting across both views.
Original PR description
Steps to reproduce: ------------------- - in Project settings activate "Timesheets" - in Timesheets select "Approved timesheets only" for invoicing policy - create a project with a task - add two timesheets to this task - validate one of these timesheets - share the project with a portal user - go to the portal view of the project with this user Issue: ------ The hours spent on this task is the sum of all timesheet. But if we click on the task, we see only the validated timesheet. Solution: --------- Add an unstored computed field to the task and override the template using `effective_hours`. The `portal_effective_hours` field takes into account the "invoicing policy" parameter and whether the user is portal or not. Note: ----- Partial backport of commit [^1]. [^1]: https://github.com/odoo/enterprise/commit/3c2832bbea94f5189f6f5b828c39f4b9e1f61a21 opw-3525606 Forward-Port-Of: odoo/enterprise#53100 Forward-Port-Of: odoo/enterprise#49635
This fix ensures that cohort view controls remain accessible and usable even when no data is displayed. Previously, when filtering resulted in no data or when changing measures, users couldn't interact with the view's buttons. Now the controls stay functional behind the empty state message, improving the user experience when working with cohort analysis.
Original PR description
This commit fixes an issue with the cohort view buttons which are not accessible when there is no data to display. This is annoying because it may happen when one changes the measures of the cohort view to one that won't display any data. The fix here is therefore to remove the data condition that enables to show the renderer so that even if it is blurred by the no content helper, buttons can still be interacted with. This commit also corrects the css selector which disables interactions with the renderer when sample data is present. Steps to reproduce: -go to any cohort view (ex: Helpdesk -> Reporting -> Tickets Analysis) -filter records with a giberish filter task-3626278 Forward-Port-Of: odoo/enterprise#53169
This fix resolves an issue where custom filters were appearing multiple times when viewing embedded content in Knowledge articles. The problem occurred when filters were imported from within Knowledge itself, causing duplicates to display. After this fix, filters will appear only once as intended.
Original PR description
**Steps to Reproduce** 1. Create an article. 2. Insert an embed. 3. Create a default filter from the search menu. 4. Now, create a new article, write the name, and click on 'Edit'. 5. Now, come back to the original article through Breadcrumb. 6. There are multiple filters with the same name. **Technical** The commit that introduces the issue is https://github.com/odoo/enterprise/commit/680171179b06de61ba2bb76aa233598b24427cb6, because before that commit, an imported state was supposed to come from outside of Knowledge, and therefore not possess the custom favorite filters. After that commit, imported states can now sometimes come from inside Knowledge, but the load override was not adjusted to account for that. **After this commit** Filters will not be visible multiple times in embed. **Task**-3562102 Forward-Port-Of: odoo/enterprise#52866
This update fixes how French VAT reports handle rounding requirements. Each line in the report is now properly rounded to whole numbers, and tax amounts are recalculated based on these rounded figures. This ensures compliance with French fiscal regulations and improves the accuracy of VAT reporting.
Original PR description
Each line of the french VAT report should be rounded to the unit. In addition, the tax amounts should be recomputed using the rounded base amounts! The rounding of each line is enabled using the 'integer_rounding' option introduced in https://github.com/odoo/enterprise/commit/1916433a951fb98baf1a54e6b6e0f8a3f59920a4. The recomputation of the tax lines base on the rounded base lines is done using aggregation expression (so the `tax` tags are no longer used in the report). The rounding difference is accounted during the closing entry. task-3607253 Forward-Port-Of: odoo/enterprise#52409
This fix ensures that analytic distribution models are properly applied when creating exchange difference lines during bank reconciliation. Previously, when users manually selected a different analytic distribution, it would be incorrectly replaced with the model's default distribution. Now the system correctly preserves user selections while also applying the appropriate model distributions.
Original PR description
When having an analytic distribution model set with account prefix matching exchenge diff accounts, this model is not taken into account at the creation of the exchange diff line on the…
When having an analytic distribution model set with account
prefix matching exchenge diff accounts, this model is not taken
into account at the creation of the exchange diff line on the
reconciliation widget.
With this commit, we add a dependency to the analytic compute
to enforce the computation at the creation of the exchange diff
line. We also keep trace of the analytic distributions selected
on the line to avoid them to be erased at the creation of the
exchange diff move.
Steps:
- Have a distribution model for exchange diff account prefix
- Have a payment and a statement line in two different currencies
and two different rate date
- In bank reco widget, select the statement line and select
payment as counterpart
- Select the exchange diff line created
--> The analytic distribution set on the model is not set on the form,
- Now select another analytic distribution, different than the one
set on the model
- Validate the reconciliation
- Go to the exchange diff move
--> The selected distribution has been replaced by the one set one the
model
opw-3603668
Forward-Port-Of: odoo/enterprise#53270
Forward-Port-Of: odoo/enterprise#52648The Estonian tax report has been updated to reflect the VAT rate increase from 20% to 22% effective January 1st, 2024. The tax report lines have been reorganized accordingly, with the new 22% rate now appearing as the primary line and the 20% rate as a secondary line. This ensures accurate tax reporting for Estonian businesses under the new regulatory requirements.
Original PR description
The VAT rate is increasing from 20% to 22% from January 1st, 2024. The tax report needs to be updated accordingly, with the 20% line becoming line 1.1 and 22% line becoming line 1. We also need to add the version in the XML output. Source: https://ncfailid.emta.ee/s/Gsi2rni6jNHg8nB See also odoo/odoo#145324 task-3615036 Forward-Port-Of: odoo/enterprise#53221 Forward-Port-Of: odoo/enterprise#52921
This fix restores WhatsApp administrators' ability to access model information when creating templates. WhatsApp admins are trusted users similar to mass mailing administrators, and they need this access to properly configure templates that interact with various business data. This change improves the user experience by allowing them to use a more intuitive interface instead of being limited to a dropdown list.
Original PR description
Globally reverts odoo/enterprise@74105d3fc1448cbd1b0942fd88759cf87f96bb7c Forward-Port-Of: odoo/enterprise#53181
This update corrects function signatures in the Bill of Materials (BOM) report to ensure proper compatibility with the latest system requirements. The fix adds a missing argument to report functions, preventing technical errors when generating BOM reports and ensuring the reporting feature works as intended.
Original PR description
Added `additional_product_metadata` argument to function overrides in enterprise.
The invoice extraction system was randomly selecting a currency when multiple matches were found (like '$' or 'kr' which could match different countries). This fix ensures the system only sets a currency when there is exactly one match, preventing incorrect currency assignments on invoices.
Original PR description
When the detected currency matches with multiple currency records, e.g. when '$' or 'kr' is detected, it shouldn't select a one of the record at "random". Now, it will only select a currency if there is a single match. Ticket #3620203 Forward-Port-Of: odoo/enterprise#53215
This fix resolves an issue where approval requests with custom binary fields could not be deleted, resulting in an error message. The system now properly handles binary fields by excluding them from certain business rule checks, allowing users to successfully delete approval records that contain binary field data.
Original PR description
Binary fields creates attachments and we don't want chatter business rules to also apply to those binary, so we filter them from the unlink hook. **steps to reproduce:** - add a binary field on approval.request - create a new approval.request, fill that binary field - unlink the record **before this commit:** - odoo.exceptions.MissingError: Record does not exist or has been deleted. (Record: approval.request(11,), User: 1) **after this commit:** - the request can be deleted opw-3558437 Forward-Port-Of: odoo/enterprise#51705