Friday, March 8, 2024
19 changes
14 changes
Resolved issues and error corrections
This update resolves a visual issue where the mandatory day color disappeared when hovering over it in the month view. The change adjusts the styling to ensure the correct color is consistently displayed, improving the user experience and visual clarity of the calendar.
Original PR description
Commit (1) introduced a fix on the mandatory day style. But it also creates another color issue: when we hover a mandatory day in the month view the mandatory color dissapears. This commit adapts the selector to handle this issue. (1): d75343d7d83ad56a7532038f01a2038c7e16f15f task-3758658 Part of task-3575827 | The issue | |--------| |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155201
This update fixes an issue where product names within Point of Sale sessions were consistently displayed in English, regardless of the selected language. The fix ensures that product names are correctly translated based on the user's chosen language setting, improving the user experience for international customers. This was a simple bug fix related to language context.
Original PR description
### Steps to reproduce: - Install **pos** app. - Add a new language (ex. french). - Switch to the new language. - Go to pos app, and open a new session. - Notice how the products' names are still in english. ### Investigation: - the source of the product name (`display_name`) is https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.xml#L49 - which is computed by `_compute_display_name()` method in https://github.com/odoo/odoo/blob/de4627069ea2b45544e0c34ff5653cf5f28a1da1/addons/product/models/product_product.py#L465 - However the context of the `product.product` provided only contains `display_default_code` lacking `lang` needed for translating the name. opw-3760448
This update fixes an issue where report placeholders were incorrectly including irrelevant data, leading to report errors. The changes also cleaned up unused placeholders to improve report efficiency and clarity. This ensures purchase order reports are accurate and reliable.
Original PR description
Previous PR: odoo/odoo#135739 added in report placeholders for the sake of easier editing of reports with studio. Unfortunately it didn't check that these placeholders aren't printed with real records which results in junk being included in the report, so we add in conditions to avoid this situation. Also, since the report was already being edited, clean up some of the placeholders because they didn't make sense/ didn't do anything (e.g. the `address` values weren't used + already have a special placeholder in studio => remove them). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156674
This update resolves an issue where users with stock manager permissions in Odoo were encountering errors when deactivating stock picking types within the Point of Sale module. The change adds a necessary security check to ensure that POS configuration access is properly controlled, preventing unauthorized modifications and improving stability. This ensures consistent POS functionality for all users.
Original PR description
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#154888
This update corrects a calculation error in the Gantt chart's progress bar, ensuring accurate representation of employee attendance and contract-related work. Previously, the progress bar didn't account for contract durations, leading to inaccurate visual displays. This fix improves the clarity and reliability of the Gantt chart for HR managers.
Original PR description
Currently the progressbar computation are not contract-aware, we fix this here task-3777971 Forward-Port-Of: odoo/odoo#156040
This update fixes a problem where taxes weren't correctly identified as changed after a fiscal localization reload, specifically when taxes lacked repartition lines. The fix ensures that changes to taxes with different repartition lines are properly detected, preventing incorrect updates to tax settings.
Original PR description
To reproduce: - Install l10n_it - Go in settings - Fiscal Localization => reload - Go to the taxes => You will find taxes with [old] prefix The issue comes that we want to consider that a tax has changed if it has different repartition lines. We don't consider taxes that are defined without repartition lines. The template will have no lines, but the compute on actual taxes will generate default ones. It then considers that the tax has changed. task-3777629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156028
This update fixes a blurry image issue in the Odoo blog posts, specifically within dynamic snippets. The problem stemmed from how images were initially handled, leading to poor quality. The fix ensures all blog images are properly resized, resulting in clearer and more professional-looking blog posts.
Original PR description
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are…
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are not resized down / impacted - Some of the layout are working fine - For the problematic layouts, the problem gets worst when you select only one or two "Fetched Elements". Steps to reproduce: - Add an image on a blog post (you can just download the one on the PR, see at the end of this message) - Add a "Blog Posts" dynamic snippet on a page - Select "Card Layout" - By default, you'll see that the image is very blurry. If you select 2 (or 1) instead of 3 fetched elements, it will get even worst. Note that it's like that since forever, when it was introduced with https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5 opw-3771992 Image to test:  Forward-Port-Of: odoo/odoo#156381
This update resolves a bug that occurred when closing recurring tasks in Odoo. The issue stemmed from a duplicate creation of follower records, leading to a validation error. The fix ensures that the creation process avoids this duplication by temporarily disabling automatic follower creation during recurring task updates.
Original PR description
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the…
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the original task in the new one, but it happens that we create a `mail_followers` twice which violates an SQL constraint of `mail_followers`. https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262 the create method will create `mail_followers` for the task and as the condition that follows is truthy in this use-case `_insert_followers` will be called and create `mail_followers` again. - In previous versions we didn't face this issue because the creation of occurences was done by a cron, so the condition was never truthy thanks to `and self.env.user.active`. Solution: ========= to make sure the conditon stays falsy, we set `mail_create_nosubscribe` in context to `True` when creating the next occurence. opw-3742737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156900 Forward-Port-Of: odoo/odoo#154927
This update ensures that tracking numbers displayed in the Point of Sale system now accurately match the information recorded in the backend. Previously, tracking numbers were inconsistent due to changes in the session ID. This fix improves data accuracy and provides a more reliable experience for users managing paid orders.
Original PR description
Before this commit, when loading paid orders, the tracking number would differ from the backend. This discrepancy was due to the fact that the `pos_session_id` was being changed to the current session. opw-3788982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156733
This update allows individual company branches to set their own default tax rates within Point of Sale (POS). Previously, all branches used the same tax settings as the parent company. This change improves flexibility and accuracy for businesses with multiple locations.
Original PR description
Before this commit: When a company having branches, they uses the same taxes as the parent company, In POS settings, the default tax used a company domain which does not allow branch to change the default tax After this commit: A branch is allowed to change the default tax task-3775857 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#156434
This update resolves an issue where users without registration permissions would receive an access error when attempting to change the partner on a Sales Order. By using 'sudo,' the system now behaves consistently with other related processes, ensuring a smoother experience for all users. This prevents unexpected errors and maintains data integrity.
Original PR description
If the user doesn't have rights to registrations and tries to change the partner on a SO, this will raise an access error even if there's no registrations linked to the SO. We use sudo to be coherent with what is done in _update_registrations. 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#151920 Forward-Port-Of: odoo/odoo#151506
This update resolves an issue where POS users wouldn't be able to access the self-order mobile menu if they lacked access to the initial company setup. The fix ensures the correct company access settings are applied, preventing access errors when managing multiple companies within the POS system. This improves the user experience for businesses utilizing the self-order feature.
Original PR description
Before this commit, if the POS user didn't have access to the first company, an access error would be raised when accessing the self-order page. The steps to reproduce this issue are as follows: 1. Add another company and set up POS self-order. 2. Remove the other company from the Marc user. 3. Open the POS in the new company. 4. Try to access the mobile menu. This would result in an access error. The issue was that the first company existed in the `allowed_company_ids` in the context. To solve this, we need to correctly set the `allowed_company_ids` in the context. opw-3744500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156357
This update fixes an issue where landed costs were incorrectly applied to the full MO quantity (1000) instead of the actual produced quantity (900). The change reflects a new definition of a field that now accurately tracks initial demand, ensuring landed costs are calculated correctly for partial production runs.
Original PR description
Steps to reproduce: - Create an MO qty = 1000 - Only produce 900 - Create a landed cost for that MO Bug: landed cost is applied on 1000 units instead of 900 starting V17 definition of the field (product_ty) has been changed to reflect the intial demand apply same fix as in: https://github.com/odoo/odoo/pull/137864/files#diff-d41327f63c4c3d8d369a3f8622f794aa03f79f5f93d9ec01dfa5c179fd8f31eaR159-R162 opw-3696385 Forward-Port-Of: odoo/odoo#156366
This update resolves a technical issue that prevented users from creating orderpoints when archived locations were involved. Previously, the system would throw an error (KeyError). Now, orderpoint creation correctly considers archived locations, ensuring accurate inventory calculations and preventing disruptions to the ordering process.
Original PR description
orderpoint creation should also consider archived location while building the domain or else users will be faced with a `KeyError` Description of the issue/feature this PR addresses: Fixes KeyError when creating orderpoints Current behavior before PR: Users are faced with a KeyError Desired behavior after PR is merged: KeyError is fixed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156965 Forward-Port-Of: odoo/odoo#155397
5 changes
Resolved issues and error corrections
Fixed the positioning of the SLA Deadline filter in the Help Desk search interface. The filter was incorrectly appearing under Properties instead of being grouped with the Create Date filter. This improves the user experience by organizing related date filters together in a more logical way.
Original PR description
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Solution: - Changing the Xpath(Field as an Xpath) as SLA DeadLine allows the Properties filter to be added and SLA Deadline to be under Create Date Filter task-3707563
The "insert in spreadsheet" button in pivot views was incorrectly showing a tooltip with "0" when active. This fix removes the unwanted tooltip, which should only appear when the button is disabled due to duplicate grouping options. The update also removes redundant test code that was duplicating existing test coverage.
Original PR description
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port-Of: odoo/enterprise#58297 Forward-Port-Of: odoo/enterprise#58160
Fixed a bug in the website blog module where blog post redirects were keeping unnecessary extra parameters in the URL. The fix simplifies the redirect logic to avoid duplicate query parameters that were being added in an incorrect format, resulting in cleaner and more reliable blog post URLs.
Original PR description
Don't try to keep extra params and co. Keep it simple... Else we should pop from request.params `blog` and `post` keys because now they are converted as query param with the slug format: /blog/name-1/post-1?blog=blog.blog(1,)&question=blog.post(1,) Forward-Port-Of: odoo/odoo#156890
A recent code update accidentally removed the ability to translate the "Save current search" option in the filters dropdown. This fix restores translation support for this feature, ensuring users in different languages can see this option in their preferred language.
Original PR description
Due to a refactor of the code in [1], the string "Save current search" in the filters dropdown was not translatable anymore. This commit fixes that, so it is translatable again. [1] 976491e01272336bc34abcdcec2718f83e19c5fc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156915
This update corrects a translation mistake in the French localization module that was introduced in a previous commit. The fix ensures that French language text displays correctly for users in France, improving the accuracy of the system's French interface.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/8bee46f117b1e6822429e8688f70cb27cc237bb4 We have translated the l10n_fr localisation, but we made a mistake on a line. This PR will correct the translation issue Task: 3792865 opw-3754691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr