Tuesday, May 20, 2025
40 changes · saas-18.3
Enhancements to existing features
The VoIP softphone keypad now automatically adjusts the size of entered numbers as they get longer. This helps users keep the full input visible and easier to read while dialing.
Original PR description
This commit adds a new method to dynamically adjust the input font size based on the length of the input value in the softphone keypad.
Resolved issues and error corrections
This change ensures the extra information step in the website checkout flow is fully loaded before the test continues. It reduces random test failures, helping keep quality checks stable without changing the customer-facing shopping experience.
Original PR description
we need to make sure that Extra info page is properly loaded before clicking on continue, to avoid undeterministic errors. [runbot-181864](https://runbot.odoo.com/odoo/error/181864) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes => Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't). This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we d
Original PR description
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to…
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes => Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't). This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we declare them in in the csv. When creating those 0% taxes, the transition account had to be mapped. Since Belgium does not have any cash basis taxe, we relied on the first account used in the tax repartition of the tax to convert. However, those 0% taxes obviously had no account there (since they're 0% anyway), so we ended up not entering this condition https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L970 and mapping the transition account to None. Because of that, we did not create any equivalent for that account, for any of the taxes using it. This commit solves that by sorting the tax templates to first treat those with accounts in their tax repartition. We also fix here the fact that instantiating such cash basis taxes did not enable the "cash basis" setting on the company ; which didn't make any sense, and caused an error message when trying to edit the settings afterwards. Forward-Port-Of: odoo/odoo#210070
Pinning a message in Discuss now works even when the related conversation thread is not available on the message. This prevents an error during a common collaboration action and helps users keep important messages accessible.
Original PR description
*=mail,test_discuss_full_enterprise **Current behavior before PR:** Pinning a message would throw an error if the associated thread was not present on the message. **Desired behavior after PR is merged:** This commit ensures that pinning a message works properly. **Task**-4805076 related: [enterprise#85862](https://github.com/odoo/enterprise/pull/85862) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The AI agent configuration page now gives the title and subtitle enough space to display properly. This prevents important agent information from being cut off, making the page easier to read and use.
Original PR description
This PR fixes an issue about the title and subtitle of an AI agent being cut on the configuration form view. Prior to this PR, the layout was using a regular div, which badly computed the size of the inner content, which resulted in a cut text due to the lack of a `flex-grow-1` class, as we do in other form views. To handle the issue, we simply add the missing class to the layout. task-4793748 | saas-18.3 | This PR | |--------|--------| |  |  |
Planning Gantt shift labels now hide allocated hours when the shift is already allocated at 100%. This prevents redundant information from appearing in schedule blocks, making planning views easier to read for users.
Original PR description
Before this commit, when a shift has an allocated hours set, the allocated hours is displayed in the gantt pill even if the allocated percentage is at 100%. This commit adds the allocated_percentage field in the gantt view to make sure the allocated percentage is fetched to be able to know if the slot has an allocated percentage set to 100% if yes then the allocated hours will not be displayed in the display name of the gantt pill. This commit also reviews a bit the code to display or not the allocated hours to only call the parent method when it is really needed. task-4801407
This fixes an issue that caused an error when users tried to load sample manufacturing data after enabling work orders. The change restores missing demo data information so the shop floor setup works as expected.
Original PR description
This error occurs when trying to load sample data from the shop floor module with work orders enabled. It appears that a parameter has been removed by mistake on this quality check documents commit:https://github.com/odoo/enterprise/commit/7ebd2ec679cc7649baece6b21a1d78c399d8995b#diff-aed5e2f84ffd8889ad58e6b2a1ba2991b24d055d1fb8bb9d4803ac89bb16894aL236 **Steps to reproduce this error:** * Install MRP (No need of demo data) * `Settings>Enable work order` * Open shop floor and `Load samples` `Value error:not enough values to unpack (expected 6, got 5)` **Solution:** * Adding the missing title parameter in the demo data. **Sentry-6607676446**
This change uses python set subtraction over recordset \_\_sub\_\_ on calendar.attendees. Before this change, when doing a large calendar synchronization such as setting up Google Calendar, notified_attendees could be a large recordset of calendar.attendees. When performing a recordset subtraction in _notify_attendees, this uses \_\_sub\_\_ and browse multiple times. Synchronizing around 5000 events took about ~350 seconds (on my own calendar data), where _notify_attendees took ~313 seconds (
Original PR description
This change uses python set subtraction over recordset \_\_sub\_\_ on calendar.attendees. Before this change, when doing a large calendar synchronization such as setting up Google Calendar, notified_attendees could be a large recordset of calendar.attendees. When performing a recordset subtraction in _notify_attendees, this uses \_\_sub\_\_ and browse multiple times. Synchronizing around 5000 events took about ~350 seconds (on my own calendar data), where _notify_attendees took ~313 seconds (83%). After this change, _notify_attendees takes ~1 second operating on the same synchronization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210271
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673
Original PR description
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673
Before this commit, the filename for pdf reports when previewed from the portal is "\<database ID\>.pdf" instead of a readable name like "Sales-Order-S00001".pdf. This can be especially confusing if the database ID is a different number from the record's sequence number. Steps to reproduce ----- 1. Open a sales order in the customer portal 2. Select the Print button 3. From the pdf preview, Print -> Save to PDF 4. The downloaded filename is "\<database ID\>.pdf", also the browser title b
Original PR description
Before this commit, the filename for pdf reports when previewed from the portal is "\<database ID\>.pdf" instead of a readable name like "Sales-Order-S00001".pdf. This can be especially confusing if the database ID is a different number from the record's sequence number. Steps to reproduce ----- 1. Open a sales order in the customer portal 2. Select the Print button 3. From the pdf preview, Print -> Save to PDF 4. The downloaded filename is "\<database ID\>.pdf", also the browser title bar is just the database ID Cause ----- No filename is being set in the Content-Disposition header, so the browser takes the filename from the last segment of the URL which is the database ID. Solution ----- Set an inline Content-Disposition with the filename argument when previewing, similar to what is done when downloading. opw-4710501 Forward-Port-Of: odoo/odoo#210481 Forward-Port-Of: odoo/odoo#207357
**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out will happen at 17:00 if the company's tolerance in the attendance's setting is set at 0. Previously, it would happen at 16:00, resulting in only 7 worked hours for the attendance while the user may expect the attendance's worked hours to match the expected working hours of the schedule. **Solu
Original PR description
**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out…
**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out will happen at 17:00 if the company's tolerance in the attendance's setting is set at 0. Previously, it would happen at 16:00, resulting in only 7 worked hours for the attendance while the user may expect the attendance's worked hours to match the expected working hours of the schedule. **Solution** - include lunch attendances (not taken into account by `duration_hours`) in the total time that needs to be exceeded before an `hr.attendance` is automatically checked out. Note that this solution manages the case where `hr.attendance` are outside lunch periods (e.g. 8-12 and 13-17, but no attendance between 12-13). Though in that case, the automatic check out will be delayed by at least 1h. Note: a change was also made to account for 2 weeks calendars. opw-4402321 Forward-Port-Of: odoo/odoo#197395
Versions -------- - 17.0+ Steps ----- 1. Create a coupon that grants a discount; 2. add a second reward giving free products; 3. use a product tag to turn it into a multiproduct reward; 4. save program, generate coupons, and copy a code; 5. add the free product tag to two or more products; 6. go to eCommerce; 7. add any product to cart and go to checkout; 8. apply coupon code; 9. claim a reward. Issue ----- - Claiming a free product results in a traceback. - Claiming the dis
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a coupon that grants a discount; 2. add a second reward giving free products; 3. use a product tag to turn it into a multiproduct reward; 4. save…
Versions -------- - 17.0+ Steps ----- 1. Create a coupon that grants a discount; 2. add a second reward giving free products; 3. use a product tag to turn it into a multiproduct reward; 4. save program, generate coupons, and copy a code; 5. add the free product tag to two or more products; 6. go to eCommerce; 7. add any product to cart and go to checkout; 8. apply coupon code; 9. claim a reward. Issue ----- - Claiming a free product results in a traceback. - Claiming the discount does not apply the discount. Cause ----- Commit db3ffae3ef5a5 modified the reward claiming logic to allow for multiproduct rewards, but overlooked the possibility of the program having multiple rewards, multiproduct being one of them. It therefore passes all of the coupon's rewards to `_apply_reward`, which only expects a single reward. This is also a consequence of commit 6525d5fba40c, which moved part of the `claim_reward` logic to `pricelist`, without passing which reward was claimed to `pricelist`. Solution -------- Add an optional `reward_id` parameter to `pricelist`, letting it know which reward we intend to claim. opw-4778945 Forward-Port-Of: odoo/odoo#210694 Forward-Port-Of: odoo/odoo#209610
*: account,l10n_hu_edi,l10n_sa,purchase,purchase_stock,sale When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. The `:` character is inconsistent with other reports, but will be removed in the master forward port to avoid overriding stable translation. task-4730464 Enterprise PR: https://github.com/odoo/enterprise/pull/84281 | Issue solved in this PR | |--------| | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207725
The theme preview feature before selection was disabled in [1]. This commit precises the TODO comment that was added with it. It comes alongside a theme repo commit which actually disables the related nightly test of the feature... that was red since then. [1]: https://github.com/odoo/odoo/commit/7cb71e9479df0ee9af0b7ad39302857666726177 Related to task-3454790 Forward-Port-Of: odoo/odoo#210140
Original PR description
The theme preview feature before selection was disabled in [1]. This commit precises the TODO comment that was added with it. It comes alongside a theme repo commit which actually disables the related nightly test of the feature... that was red since then. [1]: https://github.com/odoo/odoo/commit/7cb71e9479df0ee9af0b7ad39302857666726177 Related to task-3454790 Forward-Port-Of: odoo/odoo#210140
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210351 Forward-Port-Of: odoo/odoo#210169
Original PR description
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210351 Forward-Port-Of: odoo/odoo#210169
Fix runbot error when using preset timing in tour. Now we have an async lock for the function `openPresetTiming` so when opening this popup we make sure the previous one is finished. Also, inside the tour `test_preset_timing` we added a step to wait for the synchronization to be finished before opening the preset timing popup again. runbot error: 213368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210089
Original PR description
Fix runbot error when using preset timing in tour. Now we have an async lock for the function `openPresetTiming` so when opening this popup we make sure the previous one is finished. Also, inside the tour `test_preset_timing` we added a step to wait for the synchronization to be finished before opening the preset timing popup again. runbot error: 213368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210089
since the product page is loaded asynchronously, we need to wait for the product page to be loaded before clicking on the attribute this is to avoid the issue where the attribute is not clickable and the test fails  as you can see in the screenshot products are not loaded yet ! build_error-163168 Forward-Port-Of: odoo/odoo#206416
Original PR description
since the product page is loaded asynchronously, we need to wait for the product page to be loaded before clicking on the attribute this is to avoid the issue where the attribute is not clickable and the test fails  as you can see in the screenshot products are not loaded yet ! build_error-163168 Forward-Port-Of: odoo/odoo#206416
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#210384 Forward-Port-Of: odoo/odoo#20
Original PR description
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#210384 Forward-Port-Of: odoo/odoo#209571
### Steps to reproduce: - Navigate to Time off app -> Reporting -> By type - Access any leave record - Notice it will open an allocation record form ### Cause: This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns. https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53 https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c7
Original PR description
### Steps to reproduce: - Navigate to Time off app -> Reporting -> By type - Access any leave record - Notice it will open an allocation record form ### Cause: This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns. https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53 https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L68-L70 in those two sub-queries the order of fetching the allocation_id and leave_id is not the same which cause that leave_id column will be always null and every id value -either leave_id or allocation_id- will be stored in allocation_id column. ### Fix: Since columns' order matter when fetching sub-queries we unified the order in both queries. opw-4723952 Forward-Port-Of: odoo/odoo#208773
Scenario: - add a cover snippet with 100% height at the top of the page - open the page on a mobile (eg. safari on iOS) - scroll down the page Result: there is a vertical jittering of the content of cover snippet when going down. Cause: we are setting the size in pixel to {viewport height} - {height of stuff (menu, logged in user bar, ...)} but the mobile browser changes the viewport height when going down and hiding the address bar UI, so the fixed pixel height is only updated wh
Original PR description
Scenario:
- add a cover snippet with 100% height at the top of the page
- open the page on a mobile (eg. safari on iOS)
- scroll down the page
Result: there is a vertical jittering of the content of cover snippet
when going down.
Cause: we are setting the size in pixel to {viewport height} - {height
of stuff (menu, logged in user bar, ...)} but the mobile browser changes
the viewport height when going down and hiding the address bar UI, so
the fixed pixel height is only updated when the code is called again
instead of being adapted smoothly.
Fix: set the height of the cover using 100dvh minus the size of the
content, so the height is increased/decreased smoothly by the
application of CSS.
opw-4575726
Forward-Port-Of: odoo/odoo#210222
Forward-Port-Of: odoo/odoo#209926When user tries to open accrued expense entry in purchase order, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` and ``purchase`` module - Create a new Bill > Add a line > Don't add a product > Save > Purchase matching > Select your bill > Add to PO > Add Down Payment > New PO will be created - Actions > Accrued Expense Entry Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/834e
Original PR description
When user tries to open accrued expense entry in purchase order, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` and ``purchase`` module - Create a new Bill > Add a…
When user tries to open accrued expense entry in purchase order, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` and ``purchase`` module - Create a new Bill > Add a line > Don't add a product > Save > Purchase matching > Select your bill > Add to PO > Add Down Payment > New PO will be created - Actions > Accrued Expense Entry Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/834eff6e770280e911bb99e2abab4ea42d4ca8ff/addons/account/wizard/accrued_orders.py#L170 Here, when ``is_purchase`` is true, ``is_downpayment`` will not be evaluated. As a result, down payment lines in purchase orders are not excluded. Since down payment lines do not have a ``product_uom``. so ``rounding`` will be 0.0 So, it will lead to the above traceback. sentry-6576645089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208254
Usecase: - Create a new company without warehouse - Create a purchase.order with a dropship type You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19) 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 guidel
Original PR description
Usecase: - Create a new company without warehouse - Create a purchase.order with a dropship type You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19) 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#194897
Before this commit, the `message sound on receiving new message` was sometimes failing. It occurs because the test uses the `waitFor` web method to wait for the message unread counter to change. However, `waitFor` has a much smaller timeout than `contains` (200ms vs 3s). In this particular scenario, receiving the bus notification, fetching the channel and rendering the chat hub initially can take a little bit more time than 200ms, making the test fail. This commit increases the time out to
Original PR description
Before this commit, the `message sound on receiving new message` was sometimes failing. It occurs because the test uses the `waitFor` web method to wait for the message unread counter to change. However, `waitFor` has a much smaller timeout than `contains` (200ms vs 3s). In this particular scenario, receiving the bus notification, fetching the channel and rendering the chat hub initially can take a little bit more time than 200ms, making the test fail. This commit increases the time out to match the `contains` one for this test. fixes runbot-159866 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#210547
Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order. Steps to reproduce: ------------------- * Create 2 pricelists, A and B, let's say A always adds a 10$ fee * Set both as available in the POS, with A being the default one * On the contact "Simplified invoice parner", set the pricelist A * Open pos * Change pricelist to B * Pay and validat
Original PR description
Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the…
Currently, when you make a simplified invoice in pos, the pricelist will always be set to the simplified invoice partner pricelist, even if you had specifically set another pricelist during the order. Steps to reproduce: ------------------- * Create 2 pricelists, A and B, let's say A always adds a 10$ fee * Set both as available in the POS, with A being the default one * On the contact "Simplified invoice parner", set the pricelist A * Open pos * Change pricelist to B * Pay and validate order > Observation: Order is not validated, 10$ left to pay Why the fix: ------------ Prior to the use of `set_partner`, we used to simply write the partner field of the order when using the simplified invoice partner. Now we are using `set_partner` which is a generic function that handles everything related to changing partners, such as updating pricelist. https://github.com/odoo/odoo/blob/69057e41fb4cd800d23401ead8ae11bf7cba7c64/addons/point_of_sale/static/src/app/models/pos_order.js#L941-L948 In our example since the default pos pricelist was manually changed it means that the intention was to use this set pricelist. What we do now in this case is to check if the pricelist was purposefully changed (it differs from the default pricelist), and in this case we want to use this pricelist on the order. opw-4662248 Forward-Port-Of: odoo/odoo#208880 Forward-Port-Of: odoo/odoo#208624
**Steps to reproduce:** - Install l10n_it_edi_ndd - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is computed - Create a credit note from the invoice - On credit note wizard, click on "Reverse and Create Invoice" - Check the created credit note **Issue:** The credit note is posted but its Document Type field (l10n_it_document_type) is empty. l10n_it_document_type should be computed when it do
Original PR description
**Steps to reproduce:** - Install l10n_it_edi_ndd - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is…
**Steps to reproduce:** - Install l10n_it_edi_ndd - Switch to an Italian company (e.g. IT Company) - Create an invoice - Confirm the invoice => Document Type (in "Electronic Invoicing" tab) is computed - Create a credit note from the invoice - On credit note wizard, click on "Reverse and Create Invoice" - Check the created credit note **Issue:** The credit note is posted but its Document Type field (l10n_it_document_type) is empty. l10n_it_document_type should be computed when it doesn't have a value already and the state of the move is "posted". The credit note will be rejected when sent to SDI because this field is empty. **Cause:** In the reverse method, the field is set to False in order to be recomputed. However, the compute method is triggered when the state changes, but the credit note not is already posted. Therefore the field will not be recomputed. **Solution:** Set the value to False before the creation of the credit note. So that, the field will be recomputed when posting the credit note. opw-4689755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210488 Forward-Port-Of: odoo/odoo#208654
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: Th
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: The checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. Desired behavior after PR is merged: The printed check will now match the format and alignment of the templates used here: https://checkdepot.net/collections/odoo-checks/products/odoo-checks-top- format. Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. opw-4557006 opw-4738359 Enterprise PR: https://github.com/odoo/enterprise/pull/84644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210074 Forward-Port-Of: odoo/odoo#208357
Scenario: - add a form with studio - change its action to "Create a Task" - delete the field "Full Name" - send the form with an unknown email Result: an error happens Cause: if the email does not find a user, the code expects the partner_name to always be present, even if it is an optional field. Fix: make the code work without partner_name field. opw-4773357 Forward-Port-Of: odoo/odoo#210160
Original PR description
Scenario: - add a form with studio - change its action to "Create a Task" - delete the field "Full Name" - send the form with an unknown email Result: an error happens Cause: if the email does not find a user, the code expects the partner_name to always be present, even if it is an optional field. Fix: make the code work without partner_name field. opw-4773357 Forward-Port-Of: odoo/odoo#210160
Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I
Original PR description
Description of the issue/feature this PR addresses: It's possible to setup an inherited view with groups if we update the mode Steps: - Open an inherited view form - Change its mode to "Base" - Add a group - Rollback the mode to "Inherited" - Save, no problem - Try to upgrade a module linked to this view Current behavior before PR: - Traceback as inherited view cannot have groups Desired behavior after PR is merged: - Save is not possible opw-3263438 opw-3774300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206321 Forward-Port-Of: odoo/odoo#156279
Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson
Original PR description
Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson first priority then customer's salesperson. Fix: - Swap priority to set first customer's salesperson opw-4757042 Forward-Port-Of: odoo/odoo#210557 Forward-Port-Of: odoo/odoo#209062
Because of commit https://github.com/odoo/odoo/commit/b5ba14bc77a12268e5ce1e2a7aa7e48ba209f876 tours are faster and don't wait much between two steps. Also, when removing or adding a facet in the search view, there is no way to determine that the subsequent reload has been done. The factet is removed or added immediately, the reload happens after. So, before the refactoring of macro.js, we waited a little bit longer, allowing the reload of the view to be done before going to the next s
Original PR description
Because of commit https://github.com/odoo/odoo/commit/b5ba14bc77a12268e5ce1e2a7aa7e48ba209f876 tours are faster and don't wait much between two steps. Also, when removing or adding a facet in the search view, there is no way to determine that the subsequent reload has been done. The factet is removed or added immediately, the reload happens after. So, before the refactoring of macro.js, we waited a little bit longer, allowing the reload of the view to be done before going to the next step. This commit mitigates this by making the dataset of the tour more dterministic in order to be able to check that in the DOM. It is possible that the problem occurs in 18.0 as well, so feel free to backport this fix. runbot-error-162145 Forward-Port-Of: odoo/odoo#210548
Problem: In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like: `setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function. Solution: When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an elemen
Original PR description
Problem:
In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like:
`setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function.
Solution:
When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an element.
Steps to reproduce:
1. Add enough text to make the editable area scrollable.
2. Insert a list (any type).
3. Copy some text and paste it into the last list element. → Even if the selection is in the viewport, it still scrolls
incorrectly.
opw-4745939
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#207673The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications. Steps to Reproduce: - Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop`
Original PR description
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by…
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications. Steps to Reproduce: - Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop` page - Navigate to the shop page and scroll to the last product - Add the last product to the cart - The pop-up does not appear unless you scroll back up Issue: - The add to cart pop-up is not visible when the user is scrolled down on the page Root cause: - The CSS class `position-absolute` restricts the pop-up to a specific location in the scrollable content Fix: - Replace `position-absolute` with `position-fixed` to keep the pop-up visible regardless of scroll position opw-4686886 Affected version - 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208973
Forward-Port-Of: odoo/enterprise#84190 Forward-Port-Of: odoo/enterprise#77188
Original PR description
Forward-Port-Of: odoo/enterprise#84190 Forward-Port-Of: odoo/enterprise#77188
- avoid duplicated ids in achievement report - avoid filtering too much in details - add some tests taskid: 4776256 Forward-Port-Of: odoo/enterprise#85109
Original PR description
- avoid duplicated ids in achievement report - avoid filtering too much in details - add some tests taskid: 4776256 Forward-Port-Of: odoo/enterprise#85109
### Steps to reproduce: - Create an invoice with a due date past for long time - Accounting > Customers, click on the partner of the invoice - In the page "Accounting" the "Follow-up Status" should be "In need of action" - Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually - Go back to the partner - The follow-up is send without the invoices ### Cause: This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but
Original PR description
### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually
- Go back to the partner
- The follow-up is send without the invoices
### Cause:
This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but it also changed it: it moved `'attachment_ids' not in options` from the end to the beginning. By doing that the line
`options.get('attachment_ids', self._get_invoices_to_print(options).message_main_attachment_id.ids)`
does not work anyore because `attachment_ids` is always in `options` so `_get_invoices_to_print` is never called.
### Solution:
Use `setdefault` instead of `get`.
opw-4716458
Forward-Port-Of: odoo/enterprise#85804
Forward-Port-Of: odoo/enterprise#85124The tours fails because when we edit the value in the input field of customer it clicks on the field and then fills out the value and then a change event is propagated and text based autocomplete results are shown (and m2o fields with partner autocomplete wizard are a tad bit slower), after that tours moves to next step and the new result dropdown menu is not loaded and it gets its reference from older menu which got closed in between and tries click it and no change is reflected but the n
Original PR description
The tours fails because when we edit the value in the input field of customer it clicks on the field and then fills out the value and then a change event is propagated and text based autocomplete…
The tours fails because when we edit the value in the input field of customer it clicks on the field and then fills out the value and then a change event is propagated and text based autocomplete results are shown (and m2o fields with partner autocomplete wizard are a tad bit slower), after that tours moves to next step and the new result dropdown menu is not loaded and it gets its reference from older menu which got closed in between and tries click it and no change is reflected but the new menu is not closed and tour continues to industry_fsm_report where we create a worksheet from a many2one field using create and edit so we click on the m2o input and wait for options but as partner field loaded dropdown is loaded it clicks on click and edit trying to create a new partner and opening thus fails the tour. Fix: - After entering the text to instantly load the dropdown by clicking on it and give time for loading of menu. task-4800194 Forward-Port-Of: odoo/enterprise#85905 Forward-Port-Of: odoo/enterprise#85622
Follow the changes made in community commit. When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. Note: there are leftovers `:` characters that will be removed on master forwardport to avoid wiping existing translation on stable (not worth) task-4730464 Community PR: https://github.com/odoo/odoo/pull/207725 Forward-Port-Of: odoo/enterprise#84281
Original PR description
Follow the changes made in community commit. When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. Note: there are leftovers `:` characters that will be removed on master forwardport to avoid wiping existing translation on stable (not worth) task-4730464 Community PR: https://github.com/odoo/odoo/pull/207725 Forward-Port-Of: odoo/enterprise#84281
- Turn on Inter-company transactions. Select to sync invoices and bills in two companies. - Create an invoice in company A for an individual contact belonging to company B, then send and print the invoice. - In the corresponding bill in Company B, the draft bill is created without any attachment_ids. In the method _process_send_and_print from account_inter_company_rule the moves_with_attachements does not check if a partner belong to a synced company. opw-4675654 Forward-Port-Of: odoo/e
Original PR description
- Turn on Inter-company transactions. Select to sync invoices and bills in two companies. - Create an invoice in company A for an individual contact belonging to company B, then send and print the invoice. - In the corresponding bill in Company B, the draft bill is created without any attachment_ids. In the method _process_send_and_print from account_inter_company_rule the moves_with_attachements does not check if a partner belong to a synced company. opw-4675654 Forward-Port-Of: odoo/enterprise#84552 Forward-Port-Of: odoo/enterprise#83431
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printi
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number. After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. opw-4557006 opw-4738359 odoo PR: https://github.com/odoo/odoo/pull/208357 Forward-Port-Of: odoo/enterprise#85578 Forward-Port-Of: odoo/enterprise#84644
## Version: 17.0+ ## Issue: Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal. ## Steps to reproduce: Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer: - Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date; - Confirm and create regular invoice: - Set `Invoice Date` to the s
Original PR description
## Version: 17.0+ ## Issue: Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal. ## Steps to reproduce: Ensure Stripe is well configured in `Test Mode`…
## Version:
17.0+
## Issue:
Stripe payments with an unregistered card on backdated subscriptions lead to Stripe API refusal.
## Steps to reproduce:
Ensure Stripe is well configured in `Test Mode` with `Credentials`; Create a new Sale Order with `Monthly Cleaning` as `Quotation Template` for any customer:
- Under `Other Info` tab, change the `Subscription` `Start Date` for a date at least 2 days before current date;
- Confirm and create regular invoice:
- Set `Invoice Date` to the same date as the subscription;
- Confirm and go to the invoice's preview and start payment process:
- Use a new card for payment;
- Check `Save my payment details` checkbox and pay.
## Cause:
The Stripe mandate needs to be filled with a start date at least equal to yesterday (https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-mandate_options-start_date). Subscription app sets the start date to the SO's `start_date` via https://github.com/odoo/enterprise/blob/5642ad28919081a44bb47c0d936aa51980178d09/sale_subscription/models/payment_transaction.py#L51-L52. The values are retrieved by `_stripe_prepare_mandate_options()` via https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L206 and sent to Stipe under a new structure given by https://github.com/odoo/odoo/blob/d231565ec9054556d025b093195a934f28d067c3/addons/payment_stripe/models/payment_transaction.py#L209-L220
## Fix:
Initial suggestion made in the `payment_stripe` module (https://github.com/odoo/odoo/pull/207451), but later moved to the origin of the issue. As of 2025-05-12, Stripe seems to have fixed the issue, but this patch is still applied as a safety measure.
opw-4654142
Forward-Port-Of: odoo/enterprise#85813
Forward-Port-Of: odoo/enterprise#85314