Friday, March 8, 2024
22 changes · saas-17.1
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 corrects an issue where Saudi invoices weren't being validated correctly due to timezone differences. The fix ensures that the invoice date is accurately compared, regardless of the user's location. This prevents invoices from being incorrectly flagged and ensures proper compliance with Saudi regulations.
Original PR description
Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * make sure user timezone is Asia/Riyadh * create and post an invoice between these time from 12:00 to 3:00 Cause ----- EDI Invoice could be validated closes odoo/odoo#155363 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#155895
This update resolves a discrepancy in invoice tax calculations, specifically when simulating EPD lines. The fix ensures that tax calculations are correctly applied by using the commercial partner instead of the partner ID during the simulation process, resulting in accurate tax totals.
Original PR description
Set 'Rounding Method' to 'Round globally' Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)' Create a Payment term with 1% discount if paid before 30 days Create a company partner with child contact Create an invoice: - Add as partner the company partner (parent contact) or no contact at all (makes no difference) - Add a line with product 420.99, tax 21% not included - Add the payment term Tax total will show 87.52 Add the child contact as partner (set again payment terms if needed) Issue: Tax total will show 87.53 This occurs because, when simulating the not yet stored epd vals, we create the line using the `partner_id` and not the commercial partner. Then, when tax amounts are aggregated and rounding errors are managed the partner is used as grouping key to retrieve vals, so we don't fix the rounding error correctly opw-3661210 Forward-Port-Of: odoo/odoo#154174
This update streamlines the order preparation process in the restaurant POS module. Previously, note changes would reset the order, and order stages weren't sorted by product category. Now, notes are updated directly, products are categorized, and the system only sends crossed-out lines to the next stage, improving efficiency and accuracy.
Original PR description
Behavior before the changes: - When a note was modified, it cancelled the old orderline and recreated it with the new note. - Products were not sorted by category in the order preparation display. - Clicking on the header of an order sent it directly to the next stage, regardless of whether lines were crossed out or not. - There were brackets around the order number. Behavior after changes: - When a note is modified, it is modified directly on the existing orderline. - Products are now sorted by category in the order. - Clicking on an order header sends only the crossed-out lines to the next stage. If no line is crossed out, the entire order is sent. - There are no longer any brackets around the order name. taskId: 3764317 enterprise PR: https://github.com/odoo/enterprise/pull/57385 Forward-Port-Of: odoo/odoo#155246
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 fixes a limitation where only one automation rule could be triggered for incoming messages on Helpdesk tickets. The change ensures that multiple rules can now be active for the same trigger, providing greater flexibility in automating helpdesk workflows. This improves the efficiency of automated responses and ticket management.
Original PR description
Steps to reproduce: - Install base_automation_hr_contract and helpdesk - Setup two automation rules with model "Helpdesk Ticket" and "On incoming message" as trigger - Create a ticket in helpdesk Issues: Traceback is shown because `_message_post` doesn't have the origin attributes. This is due to the closure being wrong as explained here: https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L686-L691 Solution: Encapsulate the `_message_post` function definition, so that each times we patch message_post we patch it with a new function. This wasn't the case before since `_message_post` wasn't isolated. This solution is similar to the other method patched. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L711-L734 opw-3758851 Forward-Port-Of: odoo/odoo#155596
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
The product search feature in the Point of Sale system has been optimized to handle large product databases more efficiently. By increasing the delay before search queries are triggered, we've reduced performance issues and improved the overall responsiveness of the system when users are searching for products.
Original PR description
Before this commit, searching for a product in the product screen was problematic when dealing with large databases. The search function was triggered too frequently, leading to performance issues. With this commit, I have increased the debounce time for the product search. This reduces the frequency of search operations when user is typing. opw-3788796 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156806
This update corrects a display issue where data from a secondary company (compB) was incorrectly shown on the accounting dashboard. The fix ensures that data is accurately reflected only for the user's designated main company (compB), resolving a potential confusion regarding company-specific financial information. This improves data clarity and accuracy for users managing multiple companies.
Original PR description
Setup 2 companies with a COA: compA & compB For compA, have a journal having some data Give you access to compA & compB but make sure compB is your main company => samples data are displayed on the accounting dashboard for the journal Setup 2 companies with a COA: compA & compB, compB being a branch of compA For compA, create a journal Add some data into this journal using compB Give you access to only compA => you should not be able to see the data from compA since the data belongs to compB Introduced by: https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf issue: 3722386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156737 Forward-Port-Of: odoo/odoo#153641
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
This update fixes a bug where German businesses using the SKR03 fiscal localization were incorrectly flagged as not requiring VAT. The change ensures that fiscal positions with a VAT ID are automatically marked as requiring VAT, aligning with German tax regulations. This prevents potential errors and ensures accurate accounting for our German customers.
Original PR description
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal…
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: - The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: - We update the data file of the fiscal localization to the expected value opw-3721912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156934 Forward-Port-Of: odoo/odoo#156444
This update fixes an issue where invoices imported through the l10n_it_edi module were consistently being added to the first company in a multi-company setup. Now, invoices are correctly imported into the company they belong to, ensuring accurate accounting records across all businesses.
Original PR description
When the Cron runs in a multi-company environment, all invoices imported only in first company. They should be imported in the company they belong to. Ticket link: https://www.odoo.com/web#model=project.task&id=3744537 opw-3744537 Forward-Port-Of: odoo/odoo#156462