Daily updates from Odoo
Wednesday, March 13, 2024
19 changes · saas-17.1
Resolved issues and error corrections
This update fixes a minor issue where the Google and Outlook calendar sync buttons wouldn't automatically update their status after a sync restart. By introducing new states for reactive values, the buttons now correctly reflect the current sync status, improving user experience.
Original PR description
This PR aims to fix an issue with google/outlook sync buttons: The button state doesn't update automatically after restarting the sync. Changes: Introduced new states for the reactive values of the model, which control how the button is displayed. Task: 3731623 Forward-Port-Of: odoo/odoo#155174
This update fixes a discrepancy in the shipping dates used when creating procurement orders through Point of Sale. Previously, the scheduled delivery date was incorrectly calculated by one day. This change ensures accurate date planning for deliveries, improving order fulfillment and reducing potential delays.
Original PR description
Since `shipping_date` is a field `Date` but `date_planned` is a field `datetime`, before this commit, the `date_planned` in picking was one day less. complementary to https://github.com/odoo/odoo/commit/fe9e230b500af316e6f80af453a4073d9dff24b7 - Enable `Allow Ship Later` into a pos config - Create a new order and set a `Ship Later Date`  - Go to backend and navigate to picking and Scheduled Date is 02/27 instead of 02/28  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#154533
This update resolves a technical error that occurred when a user deleted a company within Odoo. The fix ensures that onboarding progress data is properly removed, preventing errors and maintaining data consistency. This improves the stability of the accounting and sales modules.
Original PR description
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open…
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open Accounting 7. You receive an error: > ValueError: Expected singleton: onboarding.progress(1, 2) ### Explanation: In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all. https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69 This is due to the fact that some onboardings are not related to a company while others are. After that, getting the `onboarding_state` will trigger an `ensure_one` check. In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it. ### Suggested fix: `ondelete` decorator would require the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade. opw-3762382 Forward-Port-Of: odoo/odoo#155407
This update fixes inconsistent alert margins in Odoo forms, ensuring a cleaner and more professional appearance. By standardizing the margin for alerts above form sheets, the design is now more aligned with the status bar and other key UI elements. This change impacts several modules including account, sales, and CRM.
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR introduces a custom property `--alert-margin-bottom` which allows the customization of the alert's margin bottom depending on its context. This ensure that an alert rendered in the form view above the form_sheet will receive the appropriate margin as long as there is no utility class or override on the alert with this property, which is why this PR removes the mb-x classes or inner styling on the impacted alerts. task-3577058 Enterprise PR: https://github.com/odoo/enterprise/pull/52726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156927 Forward-Port-Of: odoo/odoo#146196
This update fixes an issue where holiday accrual calculations were not updating correctly when the end date of an accrual plan was set in the past. Previously, the system didn't reflect changes to the accrual plan's end date when calculating the number of accrued days. Now, the system accurately updates the number of days based on the date_from, accrual_plan_id, and date_to, ensuring accurate holiday accrual tracking.
Original PR description
Description of the issue/feature this PR addresses:
Create an allocation for an accrual plan in the past will prevent number_of_days computation
- Create an accrual plan to give 1 day per month
- Create an allocation with this plan
- Update date_from and/or accrual_plan_id
- number_of_days is updated
- Set date_to in the past (1)
- Update date_from and/or accrual_plan_id (1)
- Set date_to in the future (1)
- Update date_from and/or accrual plan
- number_of_days is updated
Current behavior before PR:
- (1) number_of_days is not updated
- number_of_days is computed from date_from to now
Desired behavior after PR is merged:
- number_of_days updated on date_from/accrual_plan_id/date_to change
opw-3764865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#157030This update corrects a translation error in the German localization of the 'l10n_din5008_sale' module. "Sales Order" now correctly translates to "Auftragsbestätigung" in German, ensuring accurate reporting and user experience. This was a previous fix that was accidentally reverted during a system update.
Original PR description
In the German localization, "Sales Order" MUST be translated as "Auftragsbestätigung". In all other cases it can remain as "Verkaufsauftrag". Term was previously corrected but then overwritten by accident during fw-port that used old translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157424
This update corrects a visual issue where a tax destination field was incorrectly hidden in the partner view when displayed within a list of related items. The fix utilizes the correct 'column_invisible' attribute to ensure the field is properly visible. This resolves a minor cosmetic problem, improving the overall user experience.
Original PR description
In one2many, for the view, the attribute to hide a field should be column_invisible and not invisible --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157356
This update fixes an issue where orderpoints weren't being created correctly for products moving through warehouse sublocations. Previously, only specific outgoing movements triggered orderpoint updates. Now, any movement from a sublocation within the main warehouse location will automatically generate a new orderpoint, ensuring accurate inventory management.
Original PR description
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of…
Description of the issue/feature this PR addresses: The condition to decide which moves to consider to create new orderpoints is incorrect. For example any move from a location that is sublocation of the main warehouse location should be considered as a out move. The inverse condition doesn't make much sense. Current behavior before PR: Let's use a simple example: - create a new product. - create an outgoing movement from shelf 1. - click on "Replenisment" menu. No orderpoint for the new product.  Desired behavior after PR is merged: A new orderpoint should have been created at WH/Stock for that product. See below with the fix:  @ForgeFlow --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157287 Forward-Port-Of: odoo/odoo#156903
This update fixes an issue where the price displayed in the shopping cart wasn't correctly reflecting the customer's website tax settings (tax included or excluded). The fix ensures that the cart price accurately calculates the product price, including any applicable taxes, based on the configured website settings. This improves the accuracy and consistency of pricing for customers.
Original PR description
To reproduce: ============= - In the Settings: Product prices displayed on the website set as "Tax Included". - Created a test product (for example price 100$ tax 15%). - Created a price list with fixed price 15$ for all products - Pricelist configured as "Selectable" and set to "Show public price & discount to the customer". - on the product shop page, the price is 17.25$ instead of 115$ (which is the correct). - add product to cart and check the cart price, it's 17.25$ instead of 100$. Problem: ======== on the shop page the prices is calculated through combination. But in the cart, it's retrived directly from `sale.order.line`. Solution: ========= do same calculation in the cart as in the shop page through combination. opw-3771242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157357
This update fixes an issue where the 'Put in Pack' feature within batch picking was incorrectly handling multiple pickings, leading to inaccurate package assignments. The change ensures that only the intended move is placed in a package, resolving a potential for incorrect inventory tracking and shipping charges. This improves the reliability of the delivery process.
Original PR description
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking…
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened). Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product] Flow 1: batch picking + put in pack for single picking - Create 2 pickings of any operation type - Create a new batch picking with these 2 pickings - Open 1 of those pickings directly (i.e. not in the batch) - Click on "Put in Pack" Expected result: Only the move from the open picking is put into a package Result before this commit: Both pickings have their moves put into the same package Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it === Flow 2: batch picking (or multi-record calling of `action_put_in_pack`) - Create 2 receipt pickings (or any picking where picking_type_id.show_reserved != False) - Create a new batch picking with these 2 pickings - Open batch picking + click "Put in Pack" Expected result: All moves in the batch are put into a package Result before this commit: Stack trace because self.immediate_transfer is a boolean and cannot be called for more than 2 records (i.e. breaks singleton check) Additional notes: In theory batch picking creation has checks to avoid batches where there are pickings with more than 1 picking type or have different `show_reserved` values, but because `_package_move_lines` is a method that can be called in different use cases (including multi-record pickings) via customizations/future code changes, we add in checks to prevent put in pack from finishing in those cases to avoid unexpected behavior/stack traces. I.e. remember to respect existing `self.ensure_one` checks since they're probably there for a reason. === Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1) - Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them) - Add both pickings to a batch - Click "Put in Pack" in the batch picking Expected result: None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings) Result before this commit: All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur Additional notes: This is the use case that was intended to be avoided when flow was originally decided to not be handled --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157224 Forward-Port-Of: odoo/odoo#156068
This update corrects a visual issue where text within the searchbar was invisible due to a color mismatch with the background. The fix ensures sufficient contrast for readability, particularly when using dark themes. This improves the user experience for all customers.
Original PR description
Steps to reproduce the bug: - Open the homepage and enter edit mode. - Click on the "Theme" tab. - Select the 4th color from the theme options and choose "black". - Drag and drop a "Search" snippet onto the page. - Save the page to exit edit mode. - Enter text in the searchbar input. - Bug: The text is not visible because its color is the same as the background color of the input. This bug appeared since this commit [1] where the "bg-light" class was added to the searchbar input. This caused the text color of the input, which by default is the same as the body color, to become invisible when the background color of the body is dark. To fix this, we now adjust the text color of the input based on the background color of the input. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3751401 Forward-Port-Of: odoo/odoo#156042
This update resolves an issue where margins were not correctly displayed on the form for fixed-price carriers after switching between fixed and variable pricing. The fix ensures that margins are accurately reflected in the system when using fixed-price carriers, improving the accuracy of shipping cost calculations. This change was made to address a reported bug and improve the user experience.
Original PR description
Steps to reproduce: - Create a shiping method based on rule - Set margins and then swith back to fixed price Bug: since this PR https://github.com/odoo/odoo/pull/108794 margins aren't displayed on the form anymore for fixed price but they are still set on the model if we edit the delivery type opw-3759128 Forward-Port-Of: odoo/odoo#155778
This update fixes a reporting issue where the revaluation of inventory wasn't accurately reflecting the updated value in the general ledger report. The fix ensures that the reported valuation correctly displays the total value (including the added value) after the revaluation process, resolving a discrepancy in the financial reporting.
Original PR description
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office…
### Steps to reproduce: - Install **Sales**, **Accounting** and **Inventory** apps. - Go to **Inventory** > **Configuration** > **Products** > **Product Categories**. - Open **All / Saleable / Office Furniture** and: - Set the Inventory Valuation as **Automated** - Set the Costing Method as **First In First Out (FIFO)** - Go to **Inventory** > **Reporting** > **Inventory Valuation** - Open the toggle header then Click on the plus button at the header. - In the popup shown -Notice how the current value is 0-, set: - Added Value to **1000** - Counterpart Account to **600000 Expenses** - Click on **REVALUE**, a new report appears. - Open the newly created report > **Other Info**, open the **Journal Entry**. - In the Journal Items tab, notice the label says that `the valuation was changed from 1000 to 2000` while it should be `the valuation was changed from 0 to 2000`. ### Investigation: - the `current_value_svl` field is related to `product_id.value_svl` https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L34 - Which get computend using `_compute_value_svl()` depending on `stock_valuation_layer_ids` - When we revaluate, we trigger `action_validate_revaluation` that performs this line https://github.com/odoo/odoo/blob/7152fa4fb4a8b66ae72bbdc8177f2a787161f594/addons/stock_account/wizard/stock_valuation_layer_revaluation.py#L110 creating new stock.valuation.layer triggering the `_compute_value_svl()` method setting the product `value_svl` to the updated value (current + added) which then updates `current_value_svl` being a related field - That's why now `current_value_svl` is the _new_ value and not the _old_ one. opw-3715522 Forward-Port-Of: odoo/odoo#154239
This update removes a restriction that prevented users from setting payment terms to negative days. Previously, negative payment terms were blocked, but they functioned correctly. This change allows for flexibility in payment term definitions, particularly for payments due before the end of the month.
Original PR description
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before. There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days. To fix, we remove the constraint _check_positive. To reproduce the issue: - Go to Accounting -> Configuration -> Payment Terms - Edit/Create a Payment Term with a negative value in the 'After' column - When saving, a Validation error appears task-3751491 Forward-Port-Of: odoo/odoo#154617
This update corrects a minor issue where clicking a tag in the website blog sidebar would trigger an unnecessary redirect. The fix ensures the system uses the tag name directly, eliminating the redundant URL and improving user experience. This change enhances the overall stability and performance of the blog section.
Original PR description
In all cases, we will fetch the record since we display the name, so it has no extra cost to slug the record instead of the id, and it will prevent an extra redirect from /tag/1 to /tag/name-1 on click. opw-3752989 Forward-Port-Of: odoo/odoo#157493 Forward-Port-Of: odoo/odoo#157473
This update enhances the data module installation process by displaying clear error messages and automatically rolling back any changes if an installation fails. This prevents incomplete installations and ensures data integrity, providing a more reliable experience.
Original PR description
Before this commit, when an error occurred during the installation of a data module, there was no displayed error nor a rollback to remove data already installed from the module. This commit makes sure that, if an error occurs, it is displayed through a UserError that will do a rollback to remove every record from the module. Task-3794899 Forward-Port-Of: odoo/odoo#148823
This update fixes a bug where the website event URL matching process failed when an event title was removed. Previously, the URL format relied on a hyphen, but removing the title resulted in a mismatch. The fix now correctly extracts the event ID regardless of the title's presence, ensuring consistent URL generation and functionality.
Original PR description
Issue: When editing with the editor an event and removing the title we get an issue since the url that we usually got is formatted like: '/event/title-3/register' where title is our event title and 3 the id, but when leaving the title blank the url will change to be like: '/event/3/register' in this case the match will no longer find anything since we no longer have a '-' on our url. Steps to reproduce: 1. Install website_event and go to the website view of any event. 2. Edit the event, and leave the title blank. 3. Save, and try to edit again the same title. Solution: We can directly get the id without the preciding '-', in this case we will get the id in both cases without having mismatch error. opw-3783998 Forward-Port-Of: odoo/odoo#157130
This update resolves an issue where a group chat test occasionally failed due to inconsistent member ordering. The change ensures the correct thread name is always displayed by explicitly defining the order of members within the chat, improving reliability and user experience.
Original PR description
The `unnamed group chat should display correct name` test checks that the name of a thread is updated after being invited. Sometimes, the test fails because the order of the members is different. We should maintain the desired order, not rely on what the server sends or how the data are handled internally by the javascript code. This PR adds the `sort` option to the `channelMember` field to ensure the order will always be the same. fixes runbot-58955
This update fixes an issue where the subcontracting Bill of Materials (BoM) overview sometimes displayed incorrect negative values. This change ensures that the overview accurately reflects component availability, leading to more reliable reporting and decision-making for subcontracting operations. The fix addresses a technical detail related to how subcontractor locations are handled.
Original PR description
Task: 3607854 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#144702