Thursday, April 3, 2025
16 changes · saas-17.4
Resolved issues and error corrections
This fixes an issue on mobile where navigating between records could show the previous pager number instead of the current one. Users now see accurate record positions when moving through list or kanban records, reducing confusion during mobile use.
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to any list/kanban view - Open a record - Use the pager to switch to the next record => "1 / x" is displayed where x is the total amount of records - Click next => "2 / x" is displayed - Click previous => "3 / x" is displayed The pager is displaying the values before the switch has been made. Cause of the issue ================== When sending `this.value` on the `PAGER_UPDATED_EVENT` bus, the props have not been updated yet. This means that we send the previous value. Solution ======== We send the event once either the offset, limit or total props have been updated. opw-4666878
This update fixes an automated project workflow test that could fail because it moved ahead before a new record was fully created. It improves the reliability of internal quality checks for this version without changing day-to-day user behavior.
Original PR description
The tour only fails in saas-17.4 due to the tour not waiting for new record to be created, thus when record is refreshed next step is broken making the tour fail. This is already fixed in 18.0+ in PR https://github.com/odoo/odoo/pull/185691.
The rental website checkout now avoids errors when customers select times that fall during daylight saving time changes. This helps prevent failed purchases or booking interruptions around clock-change periods.
Original PR description
Pytz raises a `NonExistentTimeError` or an `AmbiguousTimeError` when trying to get the offset of a non localized datetime during the daylight saving changing time. Remark: the `_is_customer_in_the_same_timezone` method name should be changed in master as it does the complete opposite. runbot error 162039 Fix courtesy of @Xavier-Do
Rental product pages no longer show a $0.00 rental price when the website is configured to prevent sales of zero-priced products. This avoids confusing customers by keeping the product page consistent with the “Not Available for Sale” message.
Original PR description
Versions -------- - saas-17.4+ Price already hidden in 17.0 & earlier. Steps ----- 1. Set website to prevent sale of zero-priced products; 2. create a zero-priced pricelist; 3. create a rental product; 4. set a rental price of $0 on the zero-priced pricelist; 5. go to rental product page on website. Issue ----- It displays "$0.00/day" above the "Not Available for Sale" text. Cause ----- The rental price element doesn't check whether zero-priced products should be made available for sale. Solution -------- If the rental price is zero, and the website prevents sale of zero-priced products, hide the rental price element. We can use `combination_info['prevent_zero_price_sale']` for this thanks to commit 1f827ac1fad opw-4643155
This corrects a forward-port mistake in the inter-company sales and purchasing rules module. It removes logic that had already been moved elsewhere, helping prevent duplicated behavior and keeping the module split consistent.
Original PR description
This commit fixes a mistake made in [1] during the forward port of [2]. The issue being that the `sale_purshase_inter_company_rules` module was split in two, to extract the stock related logic in its own module. This was not caught correctly during the forward-port and two lines that were originally moved, were mistakenly re-added. [1] 7e5ef6294b6be31173fb67013bee85144ae586cf [2] odoo/enterprise#82079
Miscellaneous changes
Steps to reproduce: 1. Create a survey with 'multiple choice: only one answer' question no.1 2. Go to the question's options Tab > enable these three options 'Show comment field' & 'Comment is an answer' & 'Mandatory answer'. (For question no.1) 3. Add a second question to that survey. (any type) 4. Test the survey. 5. Click on the continue button without selecting the answer. 6. The error message overlaps the comment field Technical reason: The height of the `<div>` containing the <te
Original PR description
Steps to reproduce: 1. Create a survey with 'multiple choice: only one answer' question no.1 2. Go to the question's options Tab > enable these three options 'Show comment field' & 'Comment is an answer' & 'Mandatory answer'. (For question no.1) 3. Add a second question to that survey. (any type) 4. Test the survey. 5. Click on the continue button without selecting the answer. 6. The error message overlaps the comment field Technical reason: The height of the `<div>` containing the <textarea> was not properly set. After this commit: The alert message should be displayed below the comment field. Task-4663115 Forward-Port-Of: odoo/odoo#203209
Versions -------- - 17.0 - saas-17.4 Commit de302c2d3630 removed the `ir.property` model in 18.0+ Steps ----- 1. Have 2 companies; 2. set a payment term on a commercial partner; 3. switch to other company; 4. create a partner with commercial partner as their company & save; 5. remove the commercial partner & save; 6. re-add the commercial partner & save. Issue ----- > The operation cannot be completed: duplicate key value violates unique constraint "ir_property_unique_index"
Original PR description
Versions -------- - 17.0 - saas-17.4 Commit de302c2d3630 removed the `ir.property` model in 18.0+ Steps ----- 1. Have 2 companies; 2. set a payment term on a commercial partner; 3. switch to other…
Versions -------- - 17.0 - saas-17.4 Commit de302c2d3630 removed the `ir.property` model in 18.0+ Steps ----- 1. Have 2 companies; 2. set a payment term on a commercial partner; 3. switch to other company; 4. create a partner with commercial partner as their company & save; 5. remove the commercial partner & save; 6. re-add the commercial partner & save. Issue ----- > The operation cannot be completed: duplicate key value violates unique constraint "ir_property_unique_index" > DETAIL: Key (fields_id, COALESCE(company_id, 0), COALESCE(res_id, ''::character varying))=(7155, 1, res.partner,381799) already exists. Cause ----- Commit 7690479 added the `_company_dependent_commercial_sync` method to sync properties between partners & their commercial partners. It does this by looking for properties that exist from companies other than the current one, and attempts to copy them. When copying them, it's possible it attempts to create a duplicate key. Solution -------- Unlink existing properties for the current partner before copying new ones. opw-4679276 Forward-Port-Of: odoo/odoo#203968
Fixing up commit 6b4c35fbc47ef1d23c1991f06de09072e0072085 which introduced non stable changes sentry-6489805050 Forward-Port-Of: odoo/odoo#204347
Original PR description
Fixing up commit 6b4c35fbc47ef1d23c1991f06de09072e0072085 which introduced non stable changes sentry-6489805050 Forward-Port-Of: odoo/odoo#204347
Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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.co
Original PR description
Commit 2afc30a introduced reward validation before payment, due to this if promotion expired during payment step during checkout, error informing that promotion was expired was thrown, but user was not able to do anything about. Info about refreshing page has been added. opw-4573640 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#203395
Since `purchase_price` depends on their `move_ids.picking_id.state`, we risk overwriting manual edits to the field at various points in an ordinary processing of a sale, here specifically during order confirmation. Prior to commit: e24d922 standard cost method product lines would not have their `purchase_price` recomputed, while non-standard product would (meaning manual edits will only be saved for standard cost lines). This is a partial revert of that commit to bring back the beha
Original PR description
Since `purchase_price` depends on their `move_ids.picking_id.state`, we risk overwriting manual edits to the field at various points in an ordinary processing of a sale, here specifically during order confirmation. Prior to commit: e24d922 standard cost method product lines would not have their `purchase_price` recomputed, while non-standard product would (meaning manual edits will only be saved for standard cost lines). This is a partial revert of that commit to bring back the behavior of non recomputed standard cost lines' `purchase_price` Additionally, we re-fix the use-case from the aforementioned commit by allowing `purchase_price` recomputation (and overwrites) when a line has no product qty but does have delivered qty (indicating it was added from the delivery rather than directly on the sale order itself. Forward-Port-Of: odoo/odoo#202854
Before this commit, it was possible to have a `videoError` caused by (or happening during) the destruction of the video component. This error should not be retained as playing the video is no longer useful when the component is destroyed. Forward-Port-Of: odoo/odoo#204470
Original PR description
Before this commit, it was possible to have a `videoError` caused by (or happening during) the destruction of the video component. This error should not be retained as playing the video is no longer useful when the component is destroyed. Forward-Port-Of: odoo/odoo#204470
In a previous commit 4a6af867dd2eb13659c93e553d5e553cacb3048d, price was intended to be hidden when prevent zero sale is enabled. However the fix wrongly removed the outer div containing also the editable price that can be updated from the editor. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204524
Original PR description
In a previous commit 4a6af867dd2eb13659c93e553d5e553cacb3048d, price was intended to be hidden when prevent zero sale is enabled. However the fix wrongly removed the outer div containing also the editable price that can be updated from the editor. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204524
Forward-Port-Of: odoo/enterprise#82791
Original PR description
Forward-Port-Of: odoo/enterprise#82791
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashe
Original PR description
Steps to reproduce ================== - Install knowledge,contacts,web_studio - Open a contact record - Open studio - Add a many2many pointing to a knowledge article - Save and exit studio - Link an article and open it => this.env.ensureArticleName is not a function Cause of the issue ================== The knowledge article view uses a js_class and contains widgets that except the custom subenv from the controller. As the js_class isn't used in x2many views, the view crashes. Solution ======== We can simply blacklist that model when searching for relations to add opw-4513295 Forward-Port-Of: odoo/enterprise#81068
[FIX] hr_appraisal: prevent TypeError for raw record data The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None. This occurred because the code attempted to create a set from the None value directly. Steps to reproduce: ------------------- * Open Appraisal app and click on an employee's card * Activate debug mode * From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+ > Observation: Fil
Original PR description
[FIX] hr_appraisal: prevent TypeError for raw record data
The read method in hr_appraisal.py was raising a TypeError 'NoneType object is not iterable' when the fields parameter was None.
This occurred because the code attempted to create a set from the None value directly.
Steps to reproduce:
-------------------
* Open Appraisal app and click on an employee's card
* Activate debug mode
* From the bug dropdown click on 'View Raw Record Date' or 'Data' in 18.0+
> Observation:
File "/data/build/enterprise/hr_appraisal/models/hr_appraisal.py", line 539, in read
check_notes = set(fields) & {'note', 'assessment_note'}
^^^^^^^^^^^
TypeError: 'NoneType' object is not iterable
Why the fix:
------------
set() requires an iterable. By adding this condition, we avoid iterating over NoneType. This maintains the intended default functionality while preventing the crash.
opw-4631142
Forward-Port-Of: odoo/enterprise#81758When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a no
Original PR description
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this…
When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref. (Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.) Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer. While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0. When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer. As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again. opw-4681035 Forward-Port-Of: odoo/enterprise#82754