Friday, December 22, 2023
8 changes · 17.0
Resolved issues and error corrections
This fixes a broken layout in the import module dialog so the form displays correctly. Users benefit from a cleaner, more usable screen when importing modules, with no change to underlying business processes.
Original PR description
Before this commit, the layout of the import module form view (in the dialog) was broken. This was due to unnecessary and wrong use of col/colspan attributes. 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
Event attendee badges now show the attendee's own company name instead of the event organizer's company. This prevents incorrect company information from appearing on printed or generated badges, improving accuracy for event participants and organizers.
Original PR description
Following the event badge redesign in odoo/odoo@1da6cbc4c, we should display on the attendee's badge (report) the attendee's company name (`company_name`) instead of the event's company (`company_id`) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar filter items in the sidebar and mobile panel now appear in ascending order, making lists easier to scan. Numeric labels are sorted more naturally, while empty-value items remain at the end as before.
Original PR description
Before this commit: Filter items in the sidebar/panel are sorted DESC. Items without value are put at the end of the sorted list (eg : Open Shifts) After this commit: Filter items are sorted ASC. Label that begins with numeric are also sorted correctly. Items without value are stull put at the end of the sorted list. task~3524031
The website page properties dialog now displays its footer buttons in the correct position. This removes a small visual issue that could make the duplicate and delete page actions look out of place.
Original PR description
Steps to reproduce: Go to the website's home page > Site > Properties > The control panel buttons in the footer of the "Page Properties" dialog are not aligned correctly. The "Page Properties" dialog…
Steps to reproduce: Go to the website's home page > Site > Properties > The control panel buttons in the footer of the "Page Properties" dialog are not aligned correctly. The "Page Properties" dialog extends the `FormViewDialog` component and updates its template using `xpath` to add extra buttons on the right side of the footer (to "duplicate" & "delete" the current page). But since [1], a `w-100` class has been added to the default button container (`.o_cp_buttons`) on form view dialogs to get the same result as the "More Options" button on `Calendar > Quick Create` dialogs (the difference here is that the extra button was added inside the default buttons wrapper, while on page properties, the buttons are added next to it). The goal of this commit is to "safely" fix this misalignment issue on stable by simply removing the `w-100` class for the page properties dialog. On master, we will replace the template structure with the following implementation: - Inherit `web.FormViewDialog.ToOne.buttons` instead of the whole `web.FormViewDialog` template. - Add the extra buttons inside the `.o_cp_buttons` > `.o_form_buttons_edit` using `xpath`. - Use this template as `this.viewProps > buttonTemplate` - Pass the `clonePage` & `deletePage` handlers as props to the form controller, where the `buttonTemplate` template will be called. This way, the page properties buttons will have the same structure as on the calendar dialog. [1]: https://github.com/odoo/odoo/commit/7dd6e5d1a55de99a4212abc6f24490e47d9ce5bb task-3642712
Contact phone and mobile details now display in a cleaner, stacked layout when printing purchase requests for contacts with full address information. This prevents contact information from being split awkwardly, making printed documents easier to read.
Original PR description
Phone and mobile numbers are not well displayed on contact widget.. This is because of the display flex that split the column in two if there is too much information. We remove the display flex + flex column as all the children of the element are div, which is a block element, therefore they are already arranged one on top of the other. Steps: - Having a contact X with full address informations (address, name, phone) - With purchase module, you see the bug by printing a RFQ for the contact X opw-3626486
This update removes a flex display setting from the customer statements report to align with recent changes made across the Odoo platform. This ensures consistent formatting and appearance of customer statement reports throughout the system.
Original PR description
Remove flex display in order to be consistent with https://github.com/odoo/odoo/pull/146455 opw-3626486
This update removes a temporary workaround in the marketing automation campaign form that is no longer needed. The underlying issue has been resolved in the core system, allowing us to simplify the code and improve maintainability.
Original PR description
This reverts commit 31dc1d2e9985f739fed52b3c04459ed9068acda5 because the root cause has been fixed in the ORM, see the community version. https://github.com/odoo/odoo/pull/146778
This update resolves a recurring test failure in the Documents Spreadsheet module that was causing infinite loops during testing. The fix improves the reliability of automated tests by using a more appropriate testing method that doesn't interfere with the normal operation of background services. This ensures tests run consistently without disruptions.
Original PR description
Since [1], the `toggleCogMenuSpreadsheet` helper patches the `setTimeout` function. This sometimes leads to infinite recursion when the `multi_tab` service has enough time to initialize: this service make use of `setTimeout` to call the `heartbeat` method repeatedly. Moreover, patching the `setTimeout` method is not a good idea since it makes this method synchronous which totally changes the flow that is tested. This PR fixes this issue by using the `contains` helper instead: this method will wait for the element to be inserted in the DOM and perform the assertion afterwards. fixes runbot-24889 [1]: https://github.com/odoo/enterprise/pull/41851 Forward-Port-Of: odoo/enterprise#53212