Wednesday, November 29, 2023
15 changes · 17.0
Resolved issues and error corrections
Website editors can now keep using the image Position setting for suitable hover effects in grid layouts. This prevents banner and grid images from unexpectedly shrinking when effects such as Overlay are applied, while still protecting shaped effects from unwanted cropping.
Original PR description
In grid mode, if an image is in an image column (with the class `o_grid_` `item_image`), it has the "Position" image option, allowing to select between "cover" (= the image takes the whole grid-area,…
In grid mode, if an image is in an image column (with the class `o_grid_` `item_image`), it has the "Position" image option, allowing to select between "cover" (= the image takes the whole grid-area, which means it could be "cropped") and "contain" (= the image is entirely visible and keeps its ratio in the available space). When there is a shape on the image, this option is hidden and it is "contain" by default (or else the shapes would be cropped). See commit [1]. Commit [2] added the "On Hover" animation option, to add hover effects on images. In order for the effect to be applied, a shape is needed and if no shape is specified, a dummy square shape is used instead. As there is a shape, if it is a grid image, the "position" is forced to "contain" (because of commit [1]). The issue is that while it is logical for some hover effects to never be "cover", as they could be cropped (i.e. "Outline", "Mirror Blur" and any effect with a shape selected), it is not the case for the other effects when there is no shape. This commit improves this by allowing the "Position" option to be used with these other hover effects when no shape is selected (so only with the dummy square shape). Steps to reproduce: - In edit mode, drop the "Banner" snippet. - Add the "Overlay" hover effect on the big image. => The image became "smaller" because it was forced to "contain". [1]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61 [2]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85 task-3568406
The Danish OIOUBL e-invoicing process now checks that the customer has a VAT number before generating the file. This helps prevent invalid electronic invoices from being created and reduces follow-up errors during submission.
Original PR description
The aim of this commit is verifying that the partner for who we want to generate an oioubl file has a vat number set. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a timing issue where early application errors could trigger another error because translations were not ready yet. Developer-focused error labels are no longer translated, making startup error handling more reliable without changing normal user workflows.
Original PR description
Before this commit, error message like "Uncaught Promise" were translated. However, it may happen that the error is created (and thrown) before the translation service is ready, i.e. before the translations are loaded. Indeed, the error service is started first and starts listening on errors that might be raised. If a module throws an error (e.g. rejects a promise) before the localization service is started, the error service being already set up, it catches it and instantiates the appropriate Error. Doing so, a "translation error" is thrown as translations aren't ready yet. Issue found while investigating on opw 3602193 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
The homeworking label in the calendar now uses dark text instead of inheriting white text from the calendar component. This fixes a readability issue where white text appeared on a white background, making the label difficult or impossible to read.
Original PR description
The text in the homeworking label inherits the color of `.fc-event` which is set by the Fullcalendar library. This causes the text to be white on a white background. task-3617332 part of task-3575827 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The keyboard shortcut for creating a todo was updated because the previous shortcut conflicted with a Windows system shortcut. Users can now create todos with Alt + Shift + T, reducing accidental system behavior and making the feature easier to use on Windows.
Original PR description
The current shortcut used to create a todo is already a shortcut on Windows used to switch to lens view, which is impractical. It was changed from "Alt + Ctrl + L" to "Alt + Shift + T".
The search box in the message search panel now uses the standard input styling, improving its appearance especially in dark mode. The search button styling was also adjusted for better consistency with other chatter actions and to keep the main form action visually prioritized.
Original PR description
This PR fixes issues related to the input located inside the search messages panel. Prior to this commit, the input was missing a `o_input` class, which is used across our input to set a transparent background to it. This is especially visible in dark mode. We also adapt the search button, switching its type from `primary` to `secondary` to emphasize the existing primary button within the form view and also providing better consistency across other actions within the chatter. task-3584006
Marketing automation template cards now display icons correctly instead of stretched images. The template layout also adapts better to dark mode, giving users a cleaner and more consistent visual experience.
Original PR description
This PR fixes some issues with the marketing automation templates : - The cards explaining each template use SVG that look stretched. To fix this, we use `fa-icons` that are identical to the SVG while providing a satisfying visual result. - With the improvements made on the new dark mode, the layout was not "dark mode proof", so we slightly changed the way we control the colors of this layout, mainly by introducing CSS variables that are overridden if the user switches to the dark mode. With these adaptations, we were also able to clean the SCSS file a bit. task-3575318
The "I am unavailable" button was appearing in multiple menus when it should only be visible in the "My planning" menu. This fix adds a condition to hide the button from other menus, ensuring users only see it in the correct location where it's intended to be used.
Original PR description
Description of the issue: I am unavailable' button should only be visible in the 'My planning' menu. Desired behavior after PR is merged: Button only visible in My planning menu,it will invisible from other menu. Fix: condition added to button if particular context not found make button invisible task-3280805 Forward-Port-Of: odoo/enterprise#51396 Forward-Port-Of: odoo/enterprise#43365
Miscellaneous changes
What are the steps to reproduce your issue? Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled. Have a product with a unit / purchase cost of 3.30125 Create Purchase for 1500.00 and receipt in. This creates an SVL and AML for 4951.88 Create Bill with unit cost of 3.30125 and total amount of 4951.88 Confirm Invoice What is the current behavior that you observe? The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 49
Original PR description
What are the steps to reproduce your issue? Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled. Have a product with a unit / purchase cost of 3.30125 Create Purchase for 1500.00 and…
What are the steps to reproduce your issue? Price Decimal Precision set at 5, currency at 2. Anglosaxon enabled. Have a product with a unit / purchase cost of 3.30125 Create Purchase for 1500.00 and receipt in. This creates an SVL and AML for 4951.88 Create Bill with unit cost of 3.30125 and total amount of 4951.88 Confirm Invoice What is the current behavior that you observe? The layer unit price value is calculated unrounded (line 304, purchase_stock/models/account_move_line.py) - so 4951.88 / 1500 = 3.30125333333. This is then subtracted from the Invoice unit price leaving a difference of 0.00000333333 Despite the price_unit difference being less than the precision this then multiplies out to be 0.005 that gets rounded to 0.01. A new SVL layer is created, and a new move valued at 0.01 and remaining value on existing correct layer is reduced by 1c. When anglosaxon attempts to reconcile the various moves, it is unable to because there is now a 1c difference in the sum of the relevant AML's. What would be your expected behavior in this case? Not to create useless SVL that is wrong Reconcile anglosaxon records normally. It happens due to the comparaison between the layer price unit that is not rounded and the price unit of the account.move.line that is rounded to the decimal accuracy. We want to keep the most accurate value so we modify _get_gross_price unit to recompute the unit price this way we ignore the rounding close #140410 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#141274 Forward-Port-Of: odoo/odoo#141152
before PR: when searching a product that doesn't exist in the shop, the error message "no results found for ..." appears, but when searching another failed product, we hit the cache and the same "..." is displayed. after PR: avoid using the cache for the empty results message opw-3496581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143359
Original PR description
before PR: when searching a product that doesn't exist in the shop, the error message "no results found for ..." appears, but when searching another failed product, we hit the cache and the same "..." is displayed. after PR: avoid using the cache for the empty results message opw-3496581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143359
Prior to this commit, products without assigned categories were not displayed in the sales details report. This issue was due to the report's logic excluding products that did not fall under any specific POS category. This commit introduces a change where products without categories are now considered under a default category named "Not Categorized" in the sales report. This ensures that all products, regardless of category status, are accounted for and visible in the sales details, improving
Original PR description
Prior to this commit, products without assigned categories were not displayed in the sales details report. This issue was due to the report's logic excluding products that did not fall under any specific POS category. This commit introduces a change where products without categories are now considered under a default category named "Not Categorized" in the sales report. This ensures that all products, regardless of category status, are accounted for and visible in the sales details, improving the comprehensiveness and accuracy of the report. opw-3594985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142749
Before this commit, browsers added suggestions when focusing fields. This commit removes these suggestions. Warning: there are two kind of autocompletion. One which suggests data you already entered and completes only the current field if chosen. The other is auto-fill which suggests your personal info like email, address, ... Only the first kind is fixed here, the second cannot be removed at the moment. task id: 3114291 Forward-Port-Of: odoo/odoo#143769 Forward-Port-Of: odoo/odoo#143309
Original PR description
Before this commit, browsers added suggestions when focusing fields. This commit removes these suggestions. Warning: there are two kind of autocompletion. One which suggests data you already entered and completes only the current field if chosen. The other is auto-fill which suggests your personal info like email, address, ... Only the first kind is fixed here, the second cannot be removed at the moment. task id: 3114291 Forward-Port-Of: odoo/odoo#143769 Forward-Port-Of: odoo/odoo#143309
Fix the email designer fullscreen icon size by adding the .img-fluid css class to make the icon image responsive and ensuring it won't scale beyond its parents. Task-3604699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142953
Original PR description
Fix the email designer fullscreen icon size by adding the .img-fluid css class to make the icon image responsive and ensuring it won't scale beyond its parents. Task-3604699 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142953
The bus service communicates with the websocket worker in order to deliver messages coming from the bus. Most of the time, it is using a `SharedWorker` but when this kind of worker is not available, it fallbacks on a `Worker`. During tests, the `SharedWorker` is mocked to prevent opening websockets on the server. However, the `Worker` is not. Since [1], opening websockets during tests is forbidden thus, any test relying on `Worker` and expecting a connection to be established would f
Original PR description
The bus service communicates with the websocket worker in order to deliver messages coming from the bus. Most of the time, it is using a `SharedWorker` but when this kind of worker is not available, it fallbacks on a `Worker`. During tests, the `SharedWorker` is mocked to prevent opening websockets on the server. However, the `Worker` is not. Since [1], opening websockets during tests is forbidden thus, any test relying on `Worker` and expecting a connection to be established would fail. This PR solves this issue by mocking the `Worker` constructor as well. [1]: https://github.com/odoo/odoo/pull/141519 Forward-Port-Of: odoo/odoo#143880 Forward-Port-Of: odoo/odoo#143795
[1] decoupled most of the discuss tests from demo data dependency. An override of `test_init_messaging` in the voip module still relies on demo data. This commit fixes the issue. [1]: https://github.com/odoo/odoo/pull/143115 Forward-Port-Of: odoo/enterprise#51640
Original PR description
[1] decoupled most of the discuss tests from demo data dependency. An override of `test_init_messaging` in the voip module still relies on demo data. This commit fixes the issue. [1]: https://github.com/odoo/odoo/pull/143115 Forward-Port-Of: odoo/enterprise#51640