Tuesday, October 15, 2024
58 changes · 18.0
Enhancements to existing features
The portal now checks that a selected state or province matches the chosen country and requires it when the country’s rules make it mandatory. This helps prevent incorrect or manipulated address data from being submitted, improving data quality and reducing downstream errors.
Original PR description
Description of the issue/feature this PR addresses: Currently, there is no validation ensuring the selected state corresponds to the chosen country, nor checks that enforce a state selection when required by the country. Current behavior before PR: Users can select a state that doesn't belong to the selected country. No validation exists to require a state selection when the country mandates it. Desired behavior after PR is merged: The selected state will be validated to ensure it belongs to the selected country. A state will be mandatory when the country requires it, and appropriate error messages will be shown when these conditions are not met. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal now checks that a selected state or province matches the chosen country and requires it when the country rules say it is mandatory. This helps prevent incorrect or manipulated address data from being submitted, improving data quality and reducing downstream errors.
Original PR description
Description of the issue/feature this PR addresses: Currently, there is no validation ensuring the selected state corresponds to the chosen country, nor checks that enforce a state selection when required by the country. Current behavior before PR: Users can select a state that doesn't belong to the selected country. No validation exists to require a state selection when the country mandates it. Desired behavior after PR is merged: The selected state will be validated to ensure it belongs to the selected country. A state will be mandatory when the country requires it, and appropriate error messages will be shown when these conditions are not met. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can no longer manually create, update, or delete analytic items that are tied to journal items. This keeps analytic reporting aligned with the journal item's analytic distribution and prevents mismatched accounting data.
Original PR description
The analytic items related to a journal item are generated from the journal item's analytic distribution. But it is possible for a user, by accessing the analytic items view, to create/updtate/delete analytic items related to a journal item. The analytic distribution is then unsynced with the analytic items. With this commit, it is no longer possible, so the analytic items of a journal item will always reflect its analytic distribution. task-3977961
Developers can now adjust which website content containers are monitored for third-party iframe blocking through a dedicated website method instead of changing hard-coded logic. This keeps consent protection behavior intact while making customer-specific website customizations cleaner and safer to maintain.
Original PR description
Commit [958b41c4] added support to prevent 3rd-party iframes from loading without proper consent. As some iframes are built client-side, preventing them from loading required getting their container by their class. Those classes are stored in a set. Allowing any user to update that set does not make sense, but to make it possible for developers to update it through custos, this commit retrieves it from a method on the Website model instead of hard-coding it in the middle of a function. [958b41c4]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 task-4045932
Accounting reports can now group results by account code, making financial information easier to review and compare. This supports clearer reporting for businesses that rely on account-code based analysis.
Original PR description
PoC for TSB.
This update aligns the accounting app with a related platform change that prevents accidental changes or deletions of analytic entries tied to journal items. It helps preserve the integrity of accounting data while still allowing approved system processes to make necessary updates.
Original PR description
Adapt to community PR, which add a context key requirement in order to delete an analytic item related to a journal item. Community PR: odoo/odoo#182608 task-3977961
Resolved issues and error corrections
This fixes account code availability checks so codes mapped from other companies no longer incorrectly block new accounts. Businesses using multiple companies can reuse valid account codes in the intended company without unnecessary setup conflicts.
Original PR description
In #181352, we relaxed the constraint that prevented accounts from being mapped to an account code in a company the account doesn't belong to, if there already exists an account in that company that already has that code. That constraint was annoying because it meant that mapping an account to a code in a different company would "reserve" that code in the other company's CoA. When we relaxed that constraint, we forgot to modify '_search_new_account_codes' such that the previously-reserved codes would now be available for new accounts. This commit fixes that. task-none
Miscellaneous changes
Forward-Port-Of: odoo/odoo#183427 Forward-Port-Of: odoo/odoo#183367
Original PR description
Forward-Port-Of: odoo/odoo#183427 Forward-Port-Of: odoo/odoo#183367
Discount descriptions on sales orders now display more clearly with the updated product description layout. This helps sales teams and customers better understand applied discounts without confusing or poorly formatted text.
Original PR description
c3e98851d9b509e97fbcc78616ff5580222425d1 introduced a new widget for products' descriptions on SO. This commit aims to fine-tune the behavior of discount description to better fit the new display.
The message action label was shortened from “Copy Message Link” to “Copy Link” in mail and live chat. This makes the interface cleaner and easier to scan without changing the underlying behavior.
Original PR description
Shorter is better. Part of Task-4260440 
The Italian electronic invoicing direct debit flow now identifies payments more accurately after a status change in Odoo. This prevents already paid transactions from being missed when determining the payment method, reducing errors in Italian payment reporting.
Original PR description
When computing the payment method, we searched for `in_process` but now we consider them `paid`, so we're just checking for `not draft` payments instead. Related PR: odoo/odoo#178235 Runbot link: https://runbot.odoo.com/web#id=76193&model=runbot.build.error&menu_id=405 runbot-76193
Quotation template users are now prevented from uploading unsupported file types in the quote builder. This avoids confusing upload failures and system errors when non-PDF files are selected.
Original PR description
Currently, an exception was generated when the user uploaded a non-pdf file in Quate Builder of quotation templates. error: `UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte` This commit will fix the above issue by preventing uploading non-supported files that were uploaded by users. sentry-5962839786
This fix prevents the point of sale from failing when a product does not have an Indian HSN code set. Cashiers can add such products to orders normally, reducing interruptions during sales.
Original PR description
Before this commit, adding a product without the l10n_in_hsn_code field to an order would cause an error, as the system expected this field to be a string. opw-4254621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where extra browser launch settings could be lost when fullscreen or kiosk mode was enabled. It helps hardware-connected browser sessions open with the intended options and restores fullscreen behavior in Firefox.
Original PR description
Before this PR, the `Browser` helper class used a `chromium_additional_args` variable to keep track of extra command line arguments. However, it's contents were overwritten by the `fullscreen()` and `enable_kiosk_mode()` functions, causing the additional arguments to be lost. This PR removes the variable and instead constructs the argument list when `open_browser` is called. It also fixes fullscreen mode in Firefox by restoring a keypress call that was removed in v18. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The To-Do form view now expands to use the available screen height, matching the experience users already have with task forms. This also fixes related resizing behavior for rich text fields when records are saved or changed with the pager, making editing more consistent.
Original PR description
Before this commit, the height of the form view does not really take the whole space available in the screen as it is the case in the form view of task. This commit makes sure the height of the form view in To-Do app takes the whole screen height as task form view.
This update resolves several operational issues across Odoo, including Finnish VAT reporting, manufacturing work order quantities and durations, purchase valuation rounding, POS superuser access, image thumbnails, and editor toolbar behavior. These fixes improve reporting accuracy, reduce accounting corrections, and make day-to-day workflows more reliable for 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
The self-order payment page now starts the payment process only after the page is mounted, avoiding repeated page renders. This prevents duplicate Razorpay terminal requests for the same order, reducing payment errors and improving checkout reliability.
Original PR description
Before this commit: =================== The payment page was being rendered multiple times due to the `onWillStart` method triggering the `startPayment` method multiple times. This led to multiple requests being sent to the Razorpay terminal for the same order. After this commit: ================== Replaced `onWillStart` with `onMounted` to initiate the `startPayment` method. This prevents duplicate requests to the Razorpay terminal for the same order, ensuring the payment process is handled efficiently. Task- 4254682
Employees on flexible-hour schedules now get a single work entry when their attendance spans lunch. This prevents inflated or fragmented work records and keeps payroll-related time tracking aligned with actual attendance.
Original PR description
Steps --- * Create a flexible hours working schedule * Create a running contract for some employee that uses this schedule * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated. But we want only one (10 - 20). * 10 - 12 * 13 - 20
Restaurant point of sale users can now print a bill for an order that has not yet been sent without triggering an error. The change prevents the system from trying to update an order in the backend before it has been fully created there, avoiding an interruption during service.
Original PR description
Steps to reproduce : -------------------------- - Install the pos_restaurant module. - Open session and add something to order. - Don't order them and try to print the bill. Issue : -------- - There will be a traceback as it was trying to update order at backend. Cause : --------- - The order is still draft and have string_id so we can't update it. Fix : ------ - Only update if order is created at backend and have integer id.
Exported journal reports in PDF format now include appropriate side margins. This prevents content from running to the edge of the page, making printed or shared reports easier to read and more professional.
Original PR description
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189
Manufacturing users can now post work-in-progress accounting entries even when a work order has been started but its time tracking has not yet been ended. This avoids a blocking error and helps keep manufacturing accounting actions usable during normal operations.
Original PR description
before this commit, if user tries to open/generate WIP entry for manufacturing without recording the end time in the time tracking inside the work order a traceback is shown to user * create a manufacturing order that generate work order * in the work orders generated, start a work order * now click on POST WIP accounting entry from action * traceback is shown after this commit, no traceback wont be shown in the above scenario
This fix updates checkout test flows so rental orders correctly reach the delivery step before confirmation. It helps ensure the online rental checkout experience is validated reliably and reduces the risk of unnoticed checkout issues.
Original PR description
…checkout _* = website_sale_renting, website_sale_stock_renting Added the 'tourUtils.confirmOrder(),' to fix the tour.
With this commit, the test test_ui is imported and runs smoothly. task-4143417 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#183386 Forward-Port-Of: odoo/odoo#181761
Original PR description
With this commit, the test test_ui is imported and runs smoothly. task-4143417 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#183386 Forward-Port-Of: odoo/odoo#181761
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy be
Original PR description
Before this PR: - The state field on the res_company form is not automatically populated based on the entered GST number - On the res_company and res_partner, even if there is a mismatch between the GST number and state no warning is shown After this PR: - The state field on the res_company form now automatically populates based on the entered GST number - A validation check is implemented for both res_company and res_partner forms. Users will receive a warning if there's a discrepancy between the GST number and the corresponding state. Task ID - 4055948 Forward-Port-Of: odoo/odoo#183585 Forward-Port-Of: odoo/odoo#178910
Issue 1: Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens. Issue 2: Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional color
Original PR description
Issue 1: Previously, the chart was being overlapped by the navigation on smaller screen sizes. This commit fixes the issue by limiting the max-width for navigations and also hiding the button text for smaller screens. Issue 2: Previously, after a certain amount of data, the bar colors defaulted to black as the dataIndex exceeded the colors array. This commit fixes the issue by using the modulo operation on dataIndex with the colors array to repeat the colors, and also added additional colors referenced from reporting. Task-4089537 Forward-Port-Of: odoo/odoo#183315 Forward-Port-Of: odoo/odoo#175704
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, t
Original PR description
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page -…
Steps to reproduce the issue: - Have 2 different authenticated browser (one as `admin` and one as `demo`) - With the `demo browser`, change your own language to French -> Reload the main menu page - With the `admin browser`, update the demo user language from the Settings to English - Reload the page on the `demo browser`, the menus will have stayed in French while the rest of the page is translated in English Details: - Only the first query after the following step will have an issue, the problem corrects itself on the second refresh. - Could not reproduce on the runbot but could do it locally and on Odoo.SH (in 16.0) and on `odoo.com` free database (18.0). This issue was already discussed more than a year ago (https://github.com/odoo/odoo/pull/110207) but was finally closed without being merged. The problem can now be fully reproduced while previously, it was a bit blurry. 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#182640
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 Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421
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 Description of the issue/feature this PR addresses: When a new account is added and the chart is loaded for the child company before the parent, the account will be created for both companies Current behavior before PR: Desired behavior after PR is merged: see also https://github.com/odoo/enterprise/pull/71421 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182706
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#183664 Forward-Port-Of: odoo/odoo#182859
Original PR description
when a field object is not _toplevel, it may be shared with multiple registries and should be readonly in any case 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#183664 Forward-Port-Of: odoo/odoo#182859
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Original PR description
This commit will add an underscore to a dict key to avoid any problem that might arise in the future. no task id Related commit: https://github.com/odoo/odoo/commit/2f2f5f63e8d0ab9729bffa25192a7ef9a2da5fb9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183531
Version: saas-17.4 Issue: When only one delivery method is available, the checkout process skips the delivery page and redirects directly to payment, which confuses users. Fix: Removed the redundant `can_skip_delivery_step` logic. - Updated `shop_checkout` to always go through the delivery step if the order has deliverable products. - Now checking `order_sudo._has_deliverable_products()` to determine if delivery selection is needed. - Orders with non-deliverable products skip the
Original PR description
Version: saas-17.4 Issue: When only one delivery method is available, the checkout process skips the delivery page and redirects directly to payment, which confuses users. Fix: Removed the redundant `can_skip_delivery_step` logic. - Updated `shop_checkout` to always go through the delivery step if the order has deliverable products. - Now checking `order_sudo._has_deliverable_products()` to determine if delivery selection is needed. - Orders with non-deliverable products skip the delivery step and go directly to payment. The delivery page will now be displayed regardless of the number of delivery methods, improving user experience by allowing them to review their delivery details before payment. Forward-Port-Of: odoo/odoo#182269
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors
Original PR description
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the…
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. Another fix (from [2]) was added later to exceptionally authorize the editor's creation for "invisible" elements in translate mode, with a small adaptation on `_activateSnippet()` to prevent activating invisible snippets when their related sidebar buttons are clicked. This code unintentionally leads to keeping the old editors created for a text snippet when switching to another one in the DOM. To fix this behaviour, we still need to ensure existing editors are destroyed so we only create the ones we need in translate mode. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3 task-3975683 Forward-Port-Of: odoo/odoo#182813 Forward-Port-Of: odoo/odoo#168642
Before this commit, the IOT was using an old system to render pages on the IOT box. This commit refactors the homepage to use the new owl system. taskId: 4134163 Forward-Port-Of: odoo/odoo#181716 Forward-Port-Of: odoo/odoo#177895
Original PR description
Before this commit, the IOT was using an old system to render pages on the IOT box. This commit refactors the homepage to use the new owl system. taskId: 4134163 Forward-Port-Of: odoo/odoo#181716 Forward-Port-Of: odoo/odoo#177895
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img
Original PR description
Issue: ====== webp images doesn't appear in outlook Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover block and replace the background image with a .webp one - Add text-image block and replace the image with a .webp one - Test it and open the email with outlook desktop - The images doesn't appear in the email. Solution: ========= We replace the .webp images when converting inline. For image elements: we just create another img element with the png version. For background-image: we create the png image and we replace the url of background-image style with the dataURL of the canvas. opw-3776054 Forward-Port-Of: odoo/odoo#177216
opw-4224602 Forward-Port-Of: odoo/odoo#183559
Original PR description
opw-4224602 Forward-Port-Of: odoo/odoo#183559
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a d
Original PR description
When installing Event via the Apps menu, you actually install website_event (and therefore Website). This means that the next action the user has to take is installing a theme. In the case of a demo setup, the cron for the mail scheduler of Event will launch immediately post-install and will run for a rather long time, preventing any other module from installing (because module installations are blocked whilst a cron is running). This means that after installing the Website event in a demo setup, the user is the prevented from finishing the website setup until the cron is finished. This commit introduces a 'grace period' of 15min until the cron first runs, making it possible to finish the website setup right away. Forward-Port-Of: odoo/odoo#182668 Forward-Port-Of: odoo/odoo#182488
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
Original PR description
A frequent issue is the GC cron times-out when deleting attachments, due to a lack of index on the Fkey `message_main_attachment_id`, forcing Postgres to do a `Seq.Scan` on potentially really large tables to check if it needs to set the Fkey to `NULL`. Therefor we add the missing index. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183302
To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
Original PR description
To avoid confusion, the field previously labeled as 'Purchase Order' has been renamed to 'Purchase Order Warning'. This clarifies that the field relates to triggering purchase warnings, not managing purchase orders themselves. This change only affects the field label, ensuring consistency in user expectations without altering the filter content or behavior. OPW-4141054 Forward-Port-Of: odoo/odoo#180176
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
Original PR description
The check is comparing an empty recordset to False, which is not equal. Credits to @JZorko https://github.com/odoo/odoo/pull/171478 task-no Forward-Port-Of: odoo/odoo#183545
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
Original PR description
In the Calendar app with the Arabic language, there is no AM/PM distinction or 24-hour clock option. Users can only select a time between 1 and 12 without the ability to specify AM or PM. This issue is caused by the missing %p placeholder in the Arabic record of the res.lang.csv file. OPW-4182242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180858
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183507 Forward-Port-Of: odoo/odoo#183136
Original PR description
On mobile, whwen a domain is selected in the SearchPanel, there is a red dot that indicates there is a domain applied. This red dot is useless because we actually see that the domain is selected. This commit removes it. task-4246980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183507 Forward-Port-Of: odoo/odoo#183136
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale
Original PR description
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly…
Versions -------- - saas-17.2+ Steps ----- 1. Go to eCommerce; 2. go to a product page with variants; 3. open editor; 4. drag & drop a "Products" block from Dynamic Content; 5. click on the newly added block; 6. set filter to "Recently Viewed Products"; 7. save; 8. change an attribute of the current product; 9. use the added carousel to go back to the previous variant. Issue ----- Nothing happens. Cause ----- Commit 016a72bae9c3 changed the event listener on website_sale from `hashchange` to `popevent` with a check on the event's `state?.newURL` attribute. Issue is that this will always be `undefined`, as there's no logic in place to push or replace states[^1] when viewing products. Solution -------- Revert the change, and have the listener trigger on `hashchange` events[^2] again. > [!Note] > In the future we could consider moving away from using the URL hash property[^3] for storing product attribute ids to a more conventional practice, as was intended by the commit that made this change. opw-4150284 [^1]: https://developer.mozilla.org/en-US/docs/Web/API/PopStateEvent/state [^2]: https://developer.mozilla.org/en-US/docs/Web/API/Window/hashchange_event [^3]: https://developer.mozilla.org/en-US/docs/Web/API/URL/hash Forward-Port-Of: odoo/odoo#183373 Forward-Port-Of: odoo/odoo#183210
Forward-Port-Of: odoo/odoo#183000
Original PR description
Forward-Port-Of: odoo/odoo#183000
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant wa
Original PR description
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White'…
**Steps:** - Create a product with two variants (e.g., Steel & White and Aluminum & White). - Enable 'Product Reference Price' in the settings. - Set the base_unit_price of the 'Steel & White' variant to 0. - Go to the product page on the website and observe that the base unit price disappears for all variants, even though it should be displayed for the other variants. **Issue:** - The base_unit_price for product variants was not being displayed when the base_unit_price of one variant was set to 0. This caused the price to disappear for all variants in the template, even when other variants had valid base_unit_price values. **Cause:** The condition in the template was relying on a falsy check, which incorrectly evaluated 0 as a falsy value and prevented the display of base_unit_price for all variants, including those with valid prices. **Fix:** The condition in the template was updated to check for the existence of base_unit_price explicitly using if condition effectively. This ensures that even when base_unit_price is 0, it will still be displayed, while preventing the field from disappearing for other variants. Affected Version: 17.0~master opw-4061530 Forward-Port-Of: odoo/odoo#183281
we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180312
Original PR description
we have the same functionality before this commit https://github.com/odoo/odoo/commit/ab0bdf0192120671010634978f202da35ddfc79f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180312
…eckbox The default value of the Peppol checkbox in the Print & Send wizard depends on the presence/absence of warnings. In [the refactoring of warnings][1], we broke the previous behavior. We decided to show the warnings only when relevant, thus only when the checkbox is selected. Since the computation of the "checked" valued is based on the warnings, there is kind of a bad cyclic dependency. The warnings won't be set, therefore the checkbox will be checked on invoices where it shouldn't.
Original PR description
…eckbox The default value of the Peppol checkbox in the Print & Send wizard depends on the presence/absence of warnings. In [the refactoring of warnings][1], we broke the previous behavior. We decided to show the warnings only when relevant, thus only when the checkbox is selected. Since the computation of the "checked" valued is based on the warnings, there is kind of a bad cyclic dependency. The warnings won't be set, therefore the checkbox will be checked on invoices where it shouldn't. This is particularly problematic for automatic flows. It was a bad design to have a computation that depends on the warnings, both shouldn't be directly linked. [1]: <https://github.com/odoo/odoo/commit/7dbcdd24cd3d8e0b6744847234a983f3361e296a> task-no Forward-Port-Of: odoo/odoo#183534
Before this commit: =================== - The kitchen order ticket was not printing correctly when the kiosk was configured with online payment, the ticket printed with incomplete or incorrect details. After this ticket: ================ - The kitchen order ticket now prints correctly when using kiosk self order. - Ticket layout has been improved, with proper margin and padding adjustments for better readability. Task- 4182015 Forward-Port-Of: odoo/odoo#180143
Original PR description
Before this commit: =================== - The kitchen order ticket was not printing correctly when the kiosk was configured with online payment, the ticket printed with incomplete or incorrect details. After this ticket: ================ - The kitchen order ticket now prints correctly when using kiosk self order. - Ticket layout has been improved, with proper margin and padding adjustments for better readability. Task- 4182015 Forward-Port-Of: odoo/odoo#180143
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 25 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183598 Forward-Port-Of: odoo/odoo#183358
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
Original PR description
PoS receipt should show fiskaly information but they are not shown Steps to reproduce: ------------------- * Setup you db with fiskaly * Start a PoS and sell any product > Observation: The receipt doesn't contain any information opw-4216415 Forward-Port-Of: odoo/enterprise#71779
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71802
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks
Original PR description
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer >…
Steps to reproduce: - Helpdesk app > Any team > : Menu > Enable 'Timesheets' setting - Timesheets app > Start timer - Set your helpdesk project and any task (Do not add a description) - Stop timer > Do it again with same the project and a different task - Stop timer > Time is added to previous timesheet The expected behavior would be to create a new timesheet since the task is different. The reason both timesheets are merged is that we check 'task_id' for redundance while helpdesk 'tasks' are instead recorded in the 'helpdesk_ticket_id'. Since it is forbidden for a timesheet to have both a 'task_id' and 'helpdesk_ticket_id', it is guaranteed that task_id will be False for both of our entries, leading to a merge. Similarily we can use that property since adding helpdesk_ticket_id to the domain won't change the usual behavior (the field will always be False if the project is not from Helpdesk) to add an extra condition here. Source: we have a contraint '_check_no_link_task_and_ticket' which ensures that. opw-4203678 Forward-Port-Of: odoo/enterprise#71784
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw
Original PR description
Steps to reproduce: - Any project > Gantt view > Add any groupby filter The weekends are no longer greyed out like they were without the filter. This happens because _gantt_unavailablities in this module defers calls to the super() method which is empty unless the field is user_id. This makes sense since we don't want to get unavailability by employee if the tasks are not sorted by user, we could however use company leaves instead of leaving every day as available under other filters. opw-4237953 Forward-Port-Of: odoo/enterprise#71841
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime mod
Original PR description
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda…
This commit targets to fix two errors: 1. With an invoice that has a sale order related to it, when using the Addenda Autozone a traceback appeared. In attribute t-att-PODATE for the Autozone Addenda we are sending a datetime object to the strptime function of datetime which in reality it needs to receive a string object instead. This raises a TypeError Since the objective is to set a string date, we convert the date_order into a string date using strftime function from datetime module - Install 'Sales' application and 'l10n_mx_edi' module - In a company with mexican localization selected go to Sales > Quotations and create a new Order - Select a contact with the Addenda Autozone selected - Confirm it and create the corresponding invoice - Confirm the invoice and generate the CFDI 2. Traceback with invoice that have multiple sale order linked. In attribute t-att-PODATE for the Autozone Addenda is not expecting a recordset when initializing the value of sale_id, this causes a ValueError: expected singleton error when retrieving value of date_order when we create a invoice for multiple sale orders Initialize sale_id with the first order retrieved to use it task-no Forward-Port-Of: odoo/enterprise#71939 Forward-Port-Of: odoo/enterprise#71875
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 Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
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 Forward-Port-Of: odoo/enterprise#71953 Forward-Port-Of: odoo/enterprise#71421
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
Original PR description
…sales Steps to reproduce:: [l10n_fr] - create a customer, BE Company; delivery adress USA - create an invoice for the customer - Go to EC Sales Report Issue: The transaction is displayed Solution: When there is a delivery adress is specified, the country should be the the EC countries. If not specified, the company should be in the EC Countries opw-4131299 Forward-Port-Of: odoo/enterprise#69960
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an a
Original PR description
### [FIX] account_report: fix indentation in xlsx export Currently the indentation of XLSX export of reports was sometimes broken. The current implementation only supported up to three levels of indentation in the export as well. This fix supports a virtually infinite number of indentation levels and fixes the indentation in the XLSX exports. ### [I18N] account_reports: update terms ### [IMP] account_reports: move account code column to the right in xlsx Currently, when exporting an accounting report as XLSX file, we add a column for the account codes on the very left of the sheet. This looks a bit weird and is not the most important information to have as a first column. In this commit, we move the column to the right so the name of the line will be first, followed by the account code (if applicable). We also add a column name for the account codes. task-3986483 Forward-Port-Of: odoo/enterprise#71866 Forward-Port-Of: odoo/enterprise#67111
Before this commit the following error was observed: File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate self.assertInvoicePaid(self.invoice) File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match") AssertionError: 1206.3700000
Original PR description
Before this commit the following error was observed:
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 112, in test_subscription_invoice_automate
self.assertInvoicePaid(self.invoice)
File "/data/build/enterprise/test_sale_subscription/tests/test_subscription_payment_integration.py", line 66, in assertInvoicePaid
self.assertEqual(invoice.amount_paid, invoice.amount_total, "Amount should match")
AssertionError: 1206.3700000000001 != 1206.37 : Amount should match
Runbot errors: 100947, 100946, 100945, 100944, 100944
Forward-Port-Of: odoo/enterprise#71843…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
Original PR description
…ountant *: account_reports, account_online_synchronization Configuration steps on empty Bank, Misc journals should not be shown for users that do not have the Administrator/Accountant rights. They don't have the necessary rights to execute those actions anyway. This commit hide the configuration steps for non-accountant users. task-4149584 Forward-Port-Of: odoo/enterprise#71210
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878
Original PR description
https://github.com/odoo/odoo/commit/351b047c3726527d8f59c0ba701c8934dd7c9af5 changed how the chatter is added to a view and updated the codebase except for this module. This commit fixes this. Forward-Port-Of: odoo/enterprise#71878