Monday, December 9, 2024
20 changes · saas-17.4
Resolved issues and error corrections
Fixed an issue where contacts created from CRM leads could miss phone details when the lead had both an email address and contact name. This ensures newly created contacts keep the expected information, reducing manual data cleanup for sales teams.
Original PR description
Reproduce --- - install crm - enable leads - create lead with: email, phone, contact name - send email (that creates contact) - BUG: phone not filled in the contact note: email is only needed to send email thus create partner note2: bug doens't happen without contact name opw-4225694
Purchase document templates now show the readable Incoterm code instead of an internal system reference. This avoids confusing text on supplier-facing documents and makes trade terms clearer for users and partners.
Original PR description
Fixed an issue where the Incoterm was incorrectly displayed as the full object representation `account.incoterm(1,)` instead of its human-readable code. opw-4342104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes an automated online shop test wait for the page address to settle before checking it. It reduces intermittent test failures, helping keep the sales website validation process more stable without changing customer-facing behavior.
Original PR description
In this commit, we fix a undeterministic behavior about check the pathname of window in function assertPathName. In this function, we check the url of the window but the url can changes few ms after the DOM has been loaded. So the check can occurs after the DOM has been loaded. To avoid this behavior, we wait for the pathname instead of check it direclty. runbot-error-id~70316
Restricting a blog to a specific website no longer causes an error when the blog form includes blog posts added through Studio. This keeps website administrators from being blocked while configuring blogs for individual websites.
Original PR description
Steps to reproduce: - Install the Blog module and Studio app (enterprise). - Navigate to the website editor. - Go to Menu Configuration > Blogs. - Select a blog to edit. - Click on the Studio icon to customize the view. - Add the existing field "Blog posts" to the view. - Close Studio. - Restrict the blog to a specific website by selecting one. - A traceback occurs. Since [1], invisible fields now trigger "onchange" methods and "compute" methods while processing views. This exposes a bug when attempting to slugify a website URL for a blog that hasn't been assigned an ID yet. [1]: https://github.com/odoo/odoo/commit/db63cb770365be1f81ba051fe6ca5a246dbc9036 opw-4365920
The Time Off overview no longer crashes for employees who do not have administrator or officer-level access. This lets regular users view the overview page reliably without encountering an error screen.
Original PR description
**Issue:** When accessing the "Overview" menu in the Time Off module as a user without admin or officer-level access rights, a traceback error occurs. **Steps to reproduce:** 1- Log in as a user without admin or officer-level access rights for Time Off. 2- Time Off > Overview. A traceback error is displayed. opw-4378432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
List views now recalculate column widths after the browser window is resized. This prevents tables from staying too wide or too narrow after a user manually adjusts a column, improving readability and use of available screen space.
Original PR description
In a list view, first manually resize a column. Doing so, the table can either overflow (if the column has been extended), or be smaller that the available space. Then, resize the page. Before this commit, the table kept is previous width, i.e. it could not benefit from the potential available space that came from resizing the window. With this commit, we force the whole widths computation to be reset after a window resize. Followup of https://github.com/odoo/odoo/pull/170511 opw~4318312 task~4221195 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
Steps to reproduce: - Install the l10n_cl_edi module - Create an invoice - Some terms are not translated : - Where it says: .. should say: .. - Donce dice: .. deberia decir: .. Issue: Some translation were missing making it incorect for the Chile localization. This comes from the [changes](https://github.com/odoo/enterprise/commit/33b6cafdf3985df255ef44) Fix: Updated the .pot and the .po accordingly to include the terms so the translation is correct. opw-4350114
Original PR description
Steps to reproduce: - Install the l10n_cl_edi module - Create an invoice - Some terms are not translated : - Where it says: .. should say: .. - Donce dice: .. deberia decir: .. Issue: Some translation were missing making it incorect for the Chile localization. This comes from the [changes](https://github.com/odoo/enterprise/commit/33b6cafdf3985df255ef44) Fix: Updated the .pot and the .po accordingly to include the terms so the translation is correct. opw-4350114
Miscellaneous changes
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be use
Original PR description
The file viewer tries to show the document from the url obtained from the defaultSource function in file_model.js. This function builds the url using urlRoute. Before the fix, the urlRoute is the url from the attachment. This causes the PDF viewer to fail because it has a same-origin policy. This fix avoids to use the url to the one from the attachment's url directly so that the viewer can show the document correctly with the computed urlRoute. The attachment url does not need to be used at all, as the odoo server will properly direct. Forward-Port-Of: odoo/odoo#189080 Forward-Port-Of: odoo/odoo#187970
**Description of the issue/feature this PR addresses:** To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha): > All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA. However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout p
Original PR description
**Description of the issue/feature this PR addresses:**
To quote [the Odoo documentation](https://www.odoo.com/documentation/16.0/applications/websites/website/configuration/recaptcha.html?highlight=recaptcha):
> All pages using the Form, Newsletter Block, Newsletter Popup snippets, and the eCommerce Extra Step During Checkout form are now protected by reCAPTCHA.
However, it's still possible for a bot to register itself to free events, as it doesn't have to go through the checkout process.. and cause quite a mess.
This commits adds a recaptcha to the new registrations form.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#189548
Forward-Port-Of: odoo/odoo#186991This commit adds the E-invoicing app for Jordan. The E-invoicing is mandatory for businesses in Jordan as the end of May 2024. It is a backport of this PR: https://github.com/odoo/odoo/pull/182983 task-3895493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176625
Original PR description
This commit adds the E-invoicing app for Jordan. The E-invoicing is mandatory for businesses in Jordan as the end of May 2024. It is a backport of this PR: https://github.com/odoo/odoo/pull/182983 task-3895493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176625
**Problem**: When invoking a callback after a hotkey press (e.g., `Alt + B`), the following code: https://github.com/odoo/odoo/blob/bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e/addons/web/static/src/core/hotkeys/hotkey_service.js#L286 fails to save the record. **Solution**: Instead of focusing directly on the `el` element, `blur` the `activeElement` to be sure that any changes are saved. **Steps to reproduce**: 1. Open any sale order. 2. Edit the *Terms and Conditions* field. 3. Press `
Original PR description
**Problem**: When invoking a callback after a hotkey press (e.g., `Alt + B`), the following code: https://github.com/odoo/odoo/blob/bafa915f85fb8fc6ca2ae7d194a4593cb2463c2e/addons/web/static/src/core/hotkeys/hotkey_service.js#L286 fails to save the record. **Solution**: Instead of focusing directly on the `el` element, `blur` the `activeElement` to be sure that any changes are saved. **Steps to reproduce**: 1. Open any sale order. 2. Edit the *Terms and Conditions* field. 3. Press `Alt + B` while the input is focused. 4. Observe that the changes are not saved. opw-4219357 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189163 Forward-Port-Of: odoo/odoo#185960
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025
Original PR description
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the…
Steps - create an accrual plan with a level giving 1 hour every month and a carry over with a maximum of 4 hours. Set accrued gain time at the start of the period and carry-over time at start of the year. - create an allocation using this accrual plan, for a time off type in days, set the start date on the first day of next year. - go to Time Off Dashboard - check the balance on the middle of the month of the following year (e.g. 15 january 2026 if the allocation starts on 1 january 2025). -> ~14 days of time off available: the max postpone amount is not applied, the time gained is in days and not in hours and more than 1 day is gained/month (balance a few days after the start of the allocation should be +1 added_value but is more than that). Causes: - the maximum amount of carry over `postpone_max_days` is applied in days even if the accrual `added_value` is in hours and the UI shows `postpone_max_days` as "Up to X hours". - `get_future_leaves` returns a number of hours if the allocation is in hours, even if the time off type is in days. - the number of hours from the accrual at the beginning of the allocation is too high if the start of the accrual is in the future and gain time added at the start of the period due to cache not being invalidated. https://github.com/odoo/odoo/blob/19c7737fc05539079cde8641bab608c605efacc5/addons/hr_holidays/models/hr_leave_allocation.py#L575-L578 opw-4272315 Forward-Port-Of: odoo/odoo#185699
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records.This [file](https://github.com/odoo/odoo/pull/180029/commits/7b6fb92891e58c3d1de1cb9bd9b4c28354ba6f92) was merged last week. comm PR odoo/odoo#182706 ent PR odoo/enterprise#71421 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I co
Original PR description
In migration and init scripts, when loading the chart of accounts or parts of it, we should always start with the parent companies to avoid creating duplicate chart records.This [file](https://github.com/odoo/odoo/pull/180029/commits/7b6fb92891e58c3d1de1cb9bd9b4c28354ba6f92) was merged last week. comm PR odoo/odoo#182706 ent PR odoo/enterprise#71421 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#183731
Currently, a traceback occurs when the user changes the SMS iap URL and tries to test SMS mailing. To reproduce this issue: 1) Install `mass_mailing_sms` 2) Add 'B' in the SMS `IAP` URL from the `settings/technical/iap` 3) Open any SMS marketing record and click on the `Test` button Error:- ``` ValueError: unsupported format character 'B' (0x42) at index 152 ``` When the user gives the 'B' in the URL string, it is converted to `%B%` in the URL. As it leads to a traceback as `%s
Original PR description
Currently, a traceback occurs when the user changes the SMS iap URL and tries to test SMS mailing. To reproduce this issue: 1) Install `mass_mailing_sms` 2) Add 'B' in the SMS `IAP` URL from the `settings/technical/iap` 3) Open any SMS marketing record and click on the `Test` button Error:- ``` ValueError: unsupported format character 'B' (0x42) at index 152 ``` When the user gives the 'B' in the URL string, it is converted to `%B%` in the URL. As it leads to a traceback as `%s` is used to format two strings. https://github.com/odoo/odoo/blob/a98a8859696f5a69afe2954a3f5493b611ee252b/addons/sms/tools/sms_api.py#L59 This error occurs when using the old-style string formatting (%s) within an f-string. When using f-strings, we don't need to mix them with the % formatting method. We can replace the `%` formatting with the `format` method. sentry-6072287605 Forward-Port-Of: odoo/odoo#187827
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189448 Forward-Port-Of: odoo/odoo#189410
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v2.5.2 Forward-Port-Of: odoo/odoo#189448 Forward-Port-Of: odoo/odoo#189410
before this commit, when users applied a filter Invoice or Other in the My Invoices portal and then changed the page number, the selected filter was removed, resetting to the default view. This commit resolves the issue by ensuring the filterby parameter is preserved in the pager's url_args, allowing the selected filter to persist across pagination. opw-4367525 Forward-Port-Of: odoo/odoo#188930
Original PR description
before this commit, when users applied a filter Invoice or Other in the My Invoices portal and then changed the page number, the selected filter was removed, resetting to the default view. This commit resolves the issue by ensuring the filterby parameter is preserved in the pager's url_args, allowing the selected filter to persist across pagination. opw-4367525 Forward-Port-Of: odoo/odoo#188930
Version: - 17.0 Steps to reproduce: - Click on the Connect button, which redirects to the authentication wizard. - On the authorization page, click on the Cancel button. issue: - Clicking on the Cancel button does not return an authorization code, causing a traceback error. solution: - Added a condition to handle the Cancel action. If the user clicks Cancel, redirect to the provider form view without causing an error. opw-4377802 Forward-Port-Of: odoo/odoo#189757 Forward-Port-O
Original PR description
Version: - 17.0 Steps to reproduce: - Click on the Connect button, which redirects to the authentication wizard. - On the authorization page, click on the Cancel button. issue: - Clicking on the Cancel button does not return an authorization code, causing a traceback error. solution: - Added a condition to handle the Cancel action. If the user clicks Cancel, redirect to the provider form view without causing an error. opw-4377802 Forward-Port-Of: odoo/odoo#189757 Forward-Port-Of: odoo/odoo#189526
Steps to reproduce: 1. Have a VAT number (or company registry) with dots (e.g.: BE1234.678.28) 2. Import a valid SODA file with the same VAT number 3. Error: "The imported document doesn't seem to correspond to this company's VAT number nor company id" Why it happens: This happens because the regex was taking only the first matching group (1234 in the example above). Solution: Instead of searching the first group of the regex, we can subtract all chars and only keep digits to have a v
Original PR description
Steps to reproduce: 1. Have a VAT number (or company registry) with dots (e.g.: BE1234.678.28) 2. Import a valid SODA file with the same VAT number 3. Error: "The imported document doesn't seem to correspond to this company's VAT number nor company id" Why it happens: This happens because the regex was taking only the first matching group (1234 in the example above). Solution: Instead of searching the first group of the regex, we can subtract all chars and only keep digits to have a valid Belgian VAT number that can be used when checking correspondence between the company VAT and the imported SODA file VAT. opw 4347926 Forward-Port-Of: odoo/enterprise#75111
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate
Original PR description
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource…
Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate 7. Validation Error Cause of the issue: --- Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line is used on the fields calendar_event_id and appointment_resource_id. However, the model appointment_booking_line has another required field capacity_reserved. So when inserting into the table: https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 Only the two specified columns/fields are set, but not the third required field capacity_reserved. Which causes a SQL error "violates not-null constraint" opw-4187159 Forward-Port-Of: odoo/enterprise#74327 Forward-Port-Of: odoo/enterprise#71489
Fixing a traceback when selecting text, because the t-on-click was triggered but the target had no attribute. task: 4260301 Forward-Port-Of: odoo/enterprise#74957 Forward-Port-Of: odoo/enterprise#74509
Original PR description
Fixing a traceback when selecting text, because the t-on-click was triggered but the target had no attribute. task: 4260301 Forward-Port-Of: odoo/enterprise#74957 Forward-Port-Of: odoo/enterprise#74509