Wednesday, February 26, 2025
58 changes · saas-18.2
Enhancements to existing features
The accounting reconciliation setup now shows the Counterpart Items section in the relevant invoice matching scenario with payment tolerance configured. This makes it easier for users to review and configure matching rules without hidden fields causing confusion.
Original PR description
…ing' and payment_tolerance_param > 0 - I have modified the Counterpart Items page invisibility condition to be visible when rule_type == 'invoice_matching' and payment_tolerance_param == 0 task-4595853 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
Resolved issues and error corrections
This fix updates an internal performance test after an accounting report was added to the menu. It helps keep automated checks accurate so future changes are judged against the right expectations, with no direct impact on day-to-day users.
Original PR description
The following PR: https://github.com/odoo/enterprise/pull/77895 introduced a new report in the menu: `account_reports.menu_action_account_report_tree` without incrementing the menu test query counter. Extra SQL query log: ``` odoo.sql_db: [0.308 ms] query: SELECT model, res_id FROM ir_model_data WHERE module='account_reports' AND name='menu_action_account_report_tree' ``` rb-134659
Miscellaneous changes
To configure the RPI display as customer display we needed: **Before this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display, - Go to "Configuration -> Settings", - Scroll until "Customer Display" then select "An IoT-connected system. **After this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display. **Note:** the "Customer Display" setting is now only used for a second display. That means that customer display can now
Original PR description
To configure the RPI display as customer display we needed: **Before this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display, - Go to "Configuration -> Settings", - Scroll until "Customer Display" then select "An IoT-connected system. **After this commit:** - Go to configuration, - Check "IoT Box" checkbox, - Select a display. **Note:** the "Customer Display" setting is now only used for a second display. That means that customer display can now be opened on both an IoT Display and a new window. The Customer Display now also opens automatically on the IoT Box display while opening PoS. Task: 4585446 Forward-Port-Of: odoo/odoo#199294 Forward-Port-Of: odoo/odoo#198755
The website event sales test setup now assigns a country so tax creation works reliably when demo data is not installed. This prevents automated test crashes and helps keep release validation stable.
Original PR description
Taxes require a country_id when created and infer it from the company, however without demo data, the company has no country_id leading to a crash during the setUpClass. We now fix a country at the start of the test to make sure we have one. Runbot Error 114358 Runbot Error 114359
This fixes portal test tours so they no longer depend on demo customer address data being present. It helps ensure automated checks pass reliably in installations that do not include sample data, reducing false build failures.
Original PR description
Some portal tours relied on partner values being set, however state_id was missing when the base was installed without demo data. Runbot Error 134882 Runbot Error 134883
This change makes automated checks for resizing schedule items in the Gantt view more dependable. It reduces false test failures, helping teams validate future updates with greater confidence without changing user-facing behavior.
Original PR description
This commit fixes the pill resize tests by waiting for the right badge text to appear before releasing the handles. The tests previously failed intermittently because the badge text was incorrect, as it didn't have enough time to process all drag action events before being checked. This should be a more surefire way to get rid of the indeterminism than in https://github.com/odoo/enterprise/pull/79847/commits/91aa56d5adc635a3c7ae92d9533024b0ee87fcfa
Gantt view badges now show date and time details that match the current zoom level, avoiding unnecessary hour details when they are not useful. Selection badges also show the correct dates instead of being shifted, helping users plan and review schedules more accurately.
Original PR description
First commit adjusts the Gantt time display badges to omit hours when the precision is too low for them to be relevant. Second commit fixes an issue where badges displayed incorrect dates when selecting cells. The dates were shifted one sub-column to the left.
This fix makes purchase order updates work correctly when linked to approvals. It also reduces unnecessary database work, helping the process run more efficiently without changing user workflows.
Original PR description
The `write` method for `purchase.order` was not correctly overridden in `approvals_purchase`. This commit fixes it so as to avoid unnecessary db queries (i.e. `search` calls) and incorrect reassignment of the values of the `self` recordset. Also does a small improvement of using a defaultdict instead of manually recreating its logic for a normal dict. follow-up to: odoo/enterprise#71294 odoo/enterprise#79559 backport of https://github.com/odoo/enterprise/pull/79953
The Swiss payroll accounting demo data was updated to use the current phone field after an older mobile field was removed. This prevents demo data loading errors and keeps test environments running smoothly.
Original PR description
A recent change (https://github.com/odoo/enterprise/pull/75203) removed the field `mobile` on the `res.partner` model, however the demo data in `l10n_ch_hr_payroll_account` was not fully adapted, leading to error and failure to load demo data. This commit changes the field `mobile` to `phone` to avoid the issue. Runbot Error: https://runbot.odoo.com/odoo/action-573/114995
The signature sharing test was updated so it no longer turns off an already-shared request before checking clipboard behavior. This keeps automated checks aligned with the intended user flow and preserves the restriction on the download button.
Original PR description
Before this commit, the `shared_sign_request_tour` tour was failing in the clipboard check because the step just before clicked the toggle making it hidden, which was not necessary as it is already shared. After the commit, we no longer click the toggle to share the request as it already opens as shared. Additionally, we propagate the download button restriction from odoo/enterprise#80070. runbot-116600
This update prevents the Loans app from failing during direct installation when expected setup data is missing. It improves reliability for teams enabling the module and reduces disruption during deployment or testing.
Steps: - Set domain of an embedded action to false - this override the default value - Try to use the embedded action Actual result: - Error due to invalid domain Expected result: - Embedded action work and use empty domain as default opw-4529210 opw-4563505 Forward-Port-Of: odoo/odoo#197904 Forward-Port-Of: odoo/odoo#196919
Original PR description
Steps:
- Set domain of an embedded action to false
- this override the default value
- Try to use the embedded action
Actual result:
- Error due to invalid domain
Expected result:
- Embedded action work and use empty domain as default
opw-4529210
opw-4563505
Forward-Port-Of: odoo/odoo#197904
Forward-Port-Of: odoo/odoo#196919Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197841 Forward-Port-Of: odoo/odoo#1977
Original PR description
Previously, if a request in the Nilvera Client failed due to connectivity issues, a traceback was thrown. This behavior caused upgrade CI failures because the internet is blocked and check_nilvera_customer would be triggered for newly created partners. This commit enhances the exception handling for all requests and fixes the upgrade CI issue by silently exiting the function when a connectivity problem is detected. no task ID. Forward-Port-Of: odoo/odoo#197841 Forward-Port-Of: odoo/odoo#197797
In this PR https://github.com/odoo/enterprise/pull/78465 the test is failing because it is not taking the override into account as it is not a post_install. opw-4192775 Forward-Port-Of: odoo/odoo#199032 Forward-Port-Of: odoo/odoo#198004
Original PR description
In this PR https://github.com/odoo/enterprise/pull/78465 the test is failing because it is not taking the override into account as it is not a post_install. opw-4192775 Forward-Port-Of: odoo/odoo#199032 Forward-Port-Of: odoo/odoo#198004
In the config page of the self order there is an option to download a zip containing all of the table qr codes in png format. In this commit we include also svg variants for each qrcode in the zip file. This is helpful for certain applications, for ex engraving the qr codes on coasters, using laser engraving machines. Task: 4575936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197772
Original PR description
In the config page of the self order there is an option to download a zip containing all of the table qr codes in png format. In this commit we include also svg variants for each qrcode in the zip file. This is helpful for certain applications, for ex engraving the qr codes on coasters, using laser engraving machines. Task: 4575936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197772
This commit reverts: https://github.com/odoo/odoo/commit/d7d3ed847f147dac23264e91b5d802cd67be6860 After discussing with POS PO the behavior introduced in the commit is not desirable and cannot be introduced in stable. # How to reproduce the issue: - In Pos Product Categories, create a category "Parent", - Create another category "Child" with its parent being "Parent" - Create a new product with the POS category "Parent/Child" - In the pos product displayed, the category display
Original PR description
This commit reverts: https://github.com/odoo/odoo/commit/d7d3ed847f147dac23264e91b5d802cd67be6860 After discussing with POS PO the behavior introduced in the commit is not desirable and cannot be introduced in stable. # How to reproduce the issue: - In Pos Product Categories, create a category "Parent", - Create another category "Child" with its parent being "Parent" - Create a new product with the POS category "Parent/Child" - In the pos product displayed, the category display is "Child" and not "Parent" https://github.com/odoo/odoo/commit/d7d3ed847f147dac23264e91b5d802cd67be6860, made the POS category visible only if there is a product in it. However, if the parent category has no products, it won't be displayed. opw-4561712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198406 Forward-Port-Of: odoo/odoo#197794
Sometimes, a tag is added after the release (e.g. f221381fbdf8) and this lead to an error when load_account_translations is executed (e.g. when updating a language translations). Do not crash but log an error instead. Forward-Port-Of: odoo/odoo#199062
Original PR description
Sometimes, a tag is added after the release (e.g. f221381fbdf8) and this lead to an error when load_account_translations is executed (e.g. when updating a language translations). Do not crash but log an error instead. Forward-Port-Of: odoo/odoo#199062
Before this PR, live chat was closed automatically when the operator left the channel. However, it should not be closed until the last operator or the visitor leaves. This PR fixes the issue. task-4575328 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#199255
Original PR description
Before this PR, live chat was closed automatically when the operator left the channel. However, it should not be closed until the last operator or the visitor leaves. This PR fixes the issue. task-4575328 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#199255
**Current behavior before PR:** - The html_sanitize method sanitized certain banner attributes, such as contenteditable, role, and aria-label. This caused an issue where, when a blur event was triggered, the innerHTML of the current banner would be replaced with sanitized HTML. As a result, these attributes were removed, and the absence of the contenteditable attribute made it impossible to place the cursor inside the banner. **Desired behavior after PR is merged:** - Now, when the norm
Original PR description
**Current behavior before PR:** - The html_sanitize method sanitized certain banner attributes, such as contenteditable, role, and aria-label. This caused an issue where, when a blur event was triggered, the innerHTML of the current banner would be replaced with sanitized HTML. As a result, these attributes were removed, and the absence of the contenteditable attribute made it impossible to place the cursor inside the banner. **Desired behavior after PR is merged:** - Now, when the normalize method is called, the `contenteditable="true"` attribute will be applied to all elements with the `o_editable` class, and the `contenteditable="false"` attribute will be applied to all elements with the `o_not_editable` class. task-4297729 Forward-Port-Of: odoo/odoo#198399 Forward-Port-Of: odoo/odoo#189532
Issue: ------ Case: User Settings menu is basically used to handle created users but when clicking on the `New` button within the User Settings the form view corresponding to that model i.e; `res.users.settings` will be opened which is an inappropriate behavior. Whenever a User is created that user will be reflected within that menu. There's no meaning of having `New` button when no user is created to handle. Solution: ----------- Some users do not have a user settings yet, so it is a p
Original PR description
Issue: ------ Case: User Settings menu is basically used to handle created users but when clicking on the `New` button within the User Settings the form view corresponding to that model i.e;…
Issue: ------ Case: User Settings menu is basically used to handle created users but when clicking on the `New` button within the User Settings the form view corresponding to that model i.e; `res.users.settings` will be opened which is an inappropriate behavior. Whenever a User is created that user will be reflected within that menu. There's no meaning of having `New` button when no user is created to handle. Solution: ----------- Some users do not have a user settings yet, so it is a perfectly valid use case to create one. We should not artificially prevent acceptable behavior in technical/admin menus. Steps to reproduce: ------------------------ 1. Create a database in version 16.0. 2. Go to `User Settings`. 3. Click On `New` button. Try making changes and save. 4. An Invalid Field `User` error will Occur. This is because there's a many2One field i.e; `user_id` within the tree and form views which is basically an existing user. The `New` button will open a form view with no User which is a must. And will cause the Invalid field error when trying to save any change. Ref: https://github.com/odoo/odoo/blob/16.0/addons/mail/views/res_users_settings_views.xml#L24 Ref Screenshot:  Co-Authored By - @seb-odoo Forward-Port-Of: odoo/odoo#196844 Forward-Port-Of: odoo/odoo#193400
Before this commit, avatars in the discuss command palette (`@` mode in ctrl-k) could have images stretched. This happens due to missing `.o_object_fit_cover`, which is important in all discuss images. Before  After  Forward-Port-Of: odoo/odoo#199315
Original PR description
Before this commit, avatars in the discuss command palette (`@` mode in ctrl-k) could have images stretched. This happens due to missing `.o_object_fit_cover`, which is important in all discuss images. Before  After  Forward-Port-Of: odoo/odoo#199315
Steps to reproduce the bug: - Create two storable products: - P1, weight: 1KG - P2, weight: 2KG - Create a delivery order: - 1 unit of P1 and P2 - Mark it as "To Do" - Set the quantity to 1 for P1 and 0 for P2 - Print the operation type Problem: Only product P1 appears in the report, but the total weight is 3KG instead of 1KG. opw-4547704 Forward-Port-Of: odoo/odoo#198763
Original PR description
Steps to reproduce the bug:
- Create two storable products:
- P1, weight: 1KG
- P2, weight: 2KG
- Create a delivery order:
- 1 unit of P1 and P2
- Mark it as "To Do"
- Set the quantity to 1 for P1 and 0 for P2
- Print the operation type
Problem:
Only product P1 appears in the report, but the total weight is 3KG instead of 1KG.
opw-4547704
Forward-Port-Of: odoo/odoo#198763In this commit: ========== - We are removing the tax and total summary from the split screen. task-4551695 Forward-Port-Of: odoo/odoo#197282
Original PR description
In this commit: ========== - We are removing the tax and total summary from the split screen. task-4551695 Forward-Port-Of: odoo/odoo#197282
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, disp
Original PR description
Steps to reproduce: - Set up the editor with a link at the end of a line. - Refresh to start with fresh content. - Place the cursor at the end of the line with the link. - Notice that the cursor defaults inside the link, displaying the green overlay. - Attempt to type after the link—this requires pressing right arrow key to exit. Description of the issue/feature this PR addresses: - Clicking at the end or start of a line with a link placed the cursor inside the link by default, displaying the green overlay. - Typing outside the link required pressing the arrow key. Current behavior before PR: - Placing the cursor at the start or end of a line with a link now defaults to positioning it outside the link. - Green overlay is no longer shown, enabling direct text entry beside link. - Accessing the link requires an intentional left or right arrow key press. task-4089085 Forward-Port-Of: odoo/odoo#197606 Forward-Port-Of: odoo/odoo#186213
**Current behavior:** Using a pricelist with multiple items for the same product (tmpl) where each item has a different `min_quantity` threshold, the "first" available pricelist item/rule will always be applied to the order. **Expected behavior:** The rule with the maximum `min_quantity` value should be preferred. **Steps to reproduce:** 1. Create a new product & pricelist, where the pricelist has 2 pricelist items for the product * First item: `min_quantity: 2`, `fixed_price: 10` * S
Original PR description
**Current behavior:** Using a pricelist with multiple items for the same product (tmpl) where each item has a different `min_quantity` threshold, the "first" available pricelist item/rule will always…
**Current behavior:** Using a pricelist with multiple items for the same product (tmpl) where each item has a different `min_quantity` threshold, the "first" available pricelist item/rule will always be applied to the order. **Expected behavior:** The rule with the maximum `min_quantity` value should be preferred. **Steps to reproduce:** 1. Create a new product & pricelist, where the pricelist has 2 pricelist items for the product * First item: `min_quantity: 2`, `fixed_price: 10` * Second item: `min_quantity: 3`, `fixed_price: 20` 2. Open a new PoS session and select 2 of the product -> see that the price is correct per the price list rule 3. Add a 3rd product unit -> the same pricelist rule is used instead of the newly-available one **Cause of the issue:** Since commit: 5620a16 when the latest rule selection logic was added, there isn't consideration made for which rule should "tie-break". **Fix:** When looping over available product_template rules, only over-write the last rule if the current has greater `min_quantity`. opw-4533775 Forward-Port-Of: odoo/odoo#198971
One single dialog was used to change the IoT Box hostname and connect it to a database. These dialogs have been splitted. Additionnaly, the hostname update is now performed through python instead of bash.   Forward-Port-Of: odoo/odoo#198785
Original PR description
One single dialog was used to change the IoT Box hostname and connect it to a database. These dialogs have been splitted. Additionnaly, the hostname update is now performed through python instead of bash.   Forward-Port-Of: odoo/odoo#198785
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198413 Forward-Port-Of: odoo/odoo#197502
Original PR description
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198413 Forward-Port-Of: odoo/odoo#197502
Currently searching with the reference requires to enter the full reference to find the product Steps to reproduce: ------------------- * Modify the Acoustic bloc screen product with an internal reference as TEST_01 * Open pos session * Search TEST > Observation: The Acoustic bloc screen is not in the result Why the fix: ------------ We don't require the `default_code` to be an exactMatch anymore, we make it an inclusion matching. opw-4587548 Forward-Port-Of: odoo/odoo#199073 Fo
Original PR description
Currently searching with the reference requires to enter the full reference to find the product Steps to reproduce: ------------------- * Modify the Acoustic bloc screen product with an internal reference as TEST_01 * Open pos session * Search TEST > Observation: The Acoustic bloc screen is not in the result Why the fix: ------------ We don't require the `default_code` to be an exactMatch anymore, we make it an inclusion matching. opw-4587548 Forward-Port-Of: odoo/odoo#199073 Forward-Port-Of: odoo/odoo#198841
In the past, there was an `led_status.sh` service that would turn on the status LED on the Pi as long as the Odoo service was running. This was removed in 9f5e558 due to it no longer working on newer versions of the OS and causing errors during checkout. This commit restores LED status functionality via Python instead of a bash script, and can show more information: - LED green -> Connected to internet and Odoo DB - LED blinking green -> Connected to internet, waiting for DB - LED red
Original PR description
In the past, there was an `led_status.sh` service that would turn on the status LED on the Pi as long as the Odoo service was running. This was removed in 9f5e558 due to it no longer working on newer versions of the OS and causing errors during checkout. This commit restores LED status functionality via Python instead of a bash script, and can show more information: - LED green -> Connected to internet and Odoo DB - LED blinking green -> Connected to internet, waiting for DB - LED red -> No internet connection task-4589270 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198340
Before this commit, the IoT box would print its status only when the printer driver was started. If there was no pairing code at this point (e.g. you haven't connected to WiFi yet) the only way to get it to print would be to restart the IoT box. After this commit, as well as printing the pairing code upon start-up, every time a pairing code is generated the status will be printed if any USB printers are connected. This also means when the pairing code is refreshed, a new status ti
Original PR description
Before this commit, the IoT box would print its status only when the printer driver was started. If there was no pairing code at this point (e.g. you haven't connected to WiFi yet) the only way to get it to print would be to restart the IoT box. After this commit, as well as printing the pairing code upon start-up, every time a pairing code is generated the status will be printed if any USB printers are connected. This also means when the pairing code is refreshed, a new status ticket will be printed automatically. task-4599187 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198986
runbot-error-id: 111973 After deleting an order, the runbot was clicking so fast on the register button that it was creating another order. This commit checks that the deletion of the order is fully finished before clicking on register. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199202
Original PR description
runbot-error-id: 111973 After deleting an order, the runbot was clicking so fast on the register button that it was creating another order. This commit checks that the deletion of the order is fully finished before clicking on register. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199202
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check tha
Original PR description
Issue: ======== In `SplitBillScreenTour2`, navigating back and forth between **FloorScreen** and **ProductScreen** triggered a `SyncAllOrders` call. Immediately after, another `SyncAllOrders` call was sent from `createSplittedOrder`. Since the first request was still in progress, the second request sometimes sent only one order to the backend. This caused the original order to be filtered out from `syncingOrders`, leading to inconsistencies. Fix: ======= Step were added to check that the request is processed. **Runbot Error**: 114938 Forward-Port-Of: odoo/odoo#199069 Forward-Port-Of: odoo/odoo#198326
In this commit: ---- - Improved the dialog title for better clarity. - Product name separated in title. - Adjusted attribute line size for better readability in print. task-4551282,4570086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197018
Original PR description
In this commit: ---- - Improved the dialog title for better clarity. - Product name separated in title. - Adjusted attribute line size for better readability in print. task-4551282,4570086 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197018
Following the ticket opw-4523417 there is a lack of logging related to printing in hw_drivers module which makes it difficult to analyse the issued on the client's side, especially on Windows IoT This PR adds 1) some logs upon receiving of a printing request via longpolling route 2) some logs when the methods of printing are being called 3) some logs when these methods have finished their job Since for printing the Odoo database isn't notified of a succeful printing this is very much ne
Original PR description
Following the ticket opw-4523417 there is a lack of logging related to printing in hw_drivers module which makes it difficult to analyse the issued on the client's side, especially on Windows IoT This PR adds 1) some logs upon receiving of a printing request via longpolling route 2) some logs when the methods of printing are being called 3) some logs when these methods have finished their job Since for printing the Odoo database isn't notified of a succeful printing this is very much needed Forward-Port-Of: odoo/odoo#197823 Forward-Port-Of: odoo/odoo#197687
Before this commit, the pricelist was not considered when displaying product prices in the self-ordering, leading to incorrect pricing information. This commit ensures that the pricelist is correctly applied. opw-4190268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191662 Forward-Port-Of: odoo/odoo#182884
Original PR description
Before this commit, the pricelist was not considered when displaying product prices in the self-ordering, leading to incorrect pricing information. This commit ensures that the pricelist is correctly applied. opw-4190268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191662 Forward-Port-Of: odoo/odoo#182884
Before this commit: =================== - when creating a discount and loyalty program type coupon with rules for minimum quantity and purchase equals 1, along with a specific product reward, `multiple reward order lines` were erroneously generated if the coupon balance exceeded 1. - upon refreshing the page, the reward line quantity would increment incorrectly. After this commit: ================== - with this commit, only one reward order line is created per coupon application, a
Original PR description
Before this commit: =================== - when creating a discount and loyalty program type coupon with rules for minimum quantity and purchase equals 1, along with a specific product reward, `multiple reward order lines` were erroneously generated if the coupon balance exceeded 1. - upon refreshing the page, the reward line quantity would increment incorrectly. After this commit: ================== - with this commit, only one reward order line is created per coupon application, and the coupon now correctly applies only once, resolving the previous inconsistencies. task - 3869549 Forward-Port-Of: odoo/odoo#196109 Forward-Port-Of: odoo/odoo#162359
Before this commit, when chat windows are open above form view, the scrollbar of form view was shown above the chat window. Steps to reproduce: - open project task with pad aside (1080p+ screen) - open 2 or 3 chat windows - type many lines in project task pad to make form view scrollable - (optional) scroll on the form view => the scrollbar is above the chat windows This happens from a recent change [1] that increased the z-index of statusbar and ribbon of form view. This had the side-
Original PR description
Before this commit, when chat windows are open above form view, the scrollbar of form view was shown above the chat window. Steps to reproduce: - open project task with pad aside (1080p+ screen) -…
Before this commit, when chat windows are open above form view, the scrollbar of form view was shown above the chat window. Steps to reproduce: - open project task with pad aside (1080p+ screen) - open 2 or 3 chat windows - type many lines in project task pad to make form view scrollable - (optional) scroll on the form view => the scrollbar is above the chat windows This happens from a recent change [1] that increased the z-index of statusbar and ribbon of form view. This had the side-effect of also making z-index of scrollbar as high as their new z-index, which is `$zindex-sticky: 1020`. Chat window z-index was `$zindex-dropdown + 1: 1001`, slightly higher than the z-index of document views elements that were also negatively affecting chat windows [2]. This commit fixes the issue by increasing even more the z-index of chat windows, from 1001 to 1020. This puts them at the same level as sticky. Task-4604254 Before  After  [1]: https://github.com/odoo/odoo/pull/197581 [2]: https://github.com/odoo/odoo/pull/198362 Forward-Port-Of: odoo/odoo#199269
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
Original PR description
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197117
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a giv
Original PR description
- In calendar, when only one employee (different from the user) was selected as an attendeed in the calendar sidebar, the working location of this employee was not displayed. To work around this, switch to `multiCalendar` in that case. - When the current user was not selected as an attendee, it was possible to add a working location for the user on a day even if there was already an exisiting one. To avoid this, always fetch the user's working location to check if one already exists for a given day, but only display them if the user's filter is active. - Work locations were not displayed when "Everybody's calendar" was selected because the elements of `attendeeIds` had the wrong type. opw-4373391 Forward-Port-Of: odoo/odoo#192023
Before this commit, style of message notification icon (e.g. envelope) was not subtle enough. Intent was to use `text-600`, but due to typo this was not actually used (was `NaN` so does nothing). Also this wasn't clear this button is clickable, due to lack of moouse hover feedback. This commit fixes the issue by having an opacity change on mouse hover. When there's a failure, the static opacity is lower so that failed notifications are a bit more noticeable. Also message notification wi
Original PR description
Before this commit, style of message notification icon (e.g. envelope) was not subtle enough. Intent was to use `text-600`, but due to typo this was not actually used (was `NaN` so does nothing). Also this wasn't clear this button is clickable, due to lack of moouse hover feedback. This commit fixes the issue by having an opacity change on mouse hover. When there's a failure, the static opacity is lower so that failed notifications are a bit more noticeable. Also message notification with label had slightly improper style that make them less look like a button: buttons should have a bit of font weight, and also the label was too big compared to icon. This commit also fixes that issue. Before  After  Forward-Port-Of: odoo/odoo#198946 Forward-Port-Of: odoo/odoo#198505
Before this commit, a conversation that was both recent and contained mentions could be displayed twice in the discuss command palette. This was the case with DM chats. An item should be present only once in the command palette, and if a conversation has both mentions and is recent, it should be present only in the most important category "mentions". The problem occurs because duplicate mentioned and recent conversations are tracked on mentioned channels, using either the conversation or t
Original PR description
Before this commit, a conversation that was both recent and contained mentions could be displayed twice in the discuss command palette. This was the case with DM chats. An item should be present only…
Before this commit, a conversation that was both recent and contained mentions could be displayed twice in the discuss command palette. This was the case with DM chats. An item should be present only once in the command palette, and if a conversation has both mentions and is recent, it should be present only in the most important category "mentions". The problem occurs because duplicate mentioned and recent conversations are tracked on mentioned channels, using either the conversation or the persona of correspondent for DM chat. The check on mentioned persona was mistakenly omitted, thus a DM chat could be present in mentions and recents. This commit fixes the issue by properly checking whether the persona of DM chat was already in "mentions", so that it's not elligible in the "recent" category if that's the case. task-4510209 Before <img width="658" alt="Screenshot 2025-02-24 at 14 07 44" src="https://github.com/user-attachments/assets/fab6e6bb-fead-4c31-9fd4-4a2a3a4e895f" /> After <img width="661" alt="Screenshot 2025-02-24 at 14 07 52" src="https://github.com/user-attachments/assets/cf70035a-42b0-47df-96a3-1a95580d18a2" /> Forward-Port-Of: odoo/odoo#199022
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/
Original PR description
Indonesia officially added new provinces in 2022. - Papua Barat Daya was forgotten in an old PR. - Papua Pengunungan was assigned ISO code PE, not PP. In 16.0, we just change the ISO code. The XMLID will be corrected in master. Codes: https://www.geonames.org/ID/administrative-division-indonesia.html Official Document: https://peraturan.bpk.go.id/Details/232726/uu-no-29-tahun-2022 Wikipedia in English: https://en.wikipedia.org/wiki/Provinces_of_Indonesia Original PR: odoo/odoo#193103 Forward-Port-Of: odoo/odoo#199035
This commit avoids random error in test_group_by_country_and_product For more information: - https://runbot.odoo.com/odoo/action-573/114881 - https://runbot.odoo.com/odoo/runbot.build.error/116798 The error is caused because there are two pickings: one with a single move and the other with two moves. In the test, we should modify the move line that is alone. Since the order was not checked, the action done for the wave could return a wizard to create a backorder because we modified t
Original PR description
This commit avoids random error in test_group_by_country_and_product For more information: - https://runbot.odoo.com/odoo/action-573/114881 - https://runbot.odoo.com/odoo/runbot.build.error/116798 The error is caused because there are two pickings: one with a single move and the other with two moves. In the test, we should modify the move line that is alone. Since the order was not checked, the action done for the wave could return a wizard to create a backorder because we modified the quantity of a move line to 0 in a picking that has multiple move lines. Forward-Port-Of: odoo/odoo#198820
Starting from January 6th, 2025, USPS _silently_ migrated to a new developer portal (devloper`s`.usps.com instead of developer.usps.com). See: https://developer.usps.com/getting-started. The new portal also introduces new base URL for their endpoints (See: https://developers.usps.com/sites/default/files/2024-10/USPS%20API%20Cloud%20Enrollment.pdf). Users who registered after this date didn't manage to use Odoo shipping connector for USPS since it used the old endpoints. This commit updat
Original PR description
Starting from January 6th, 2025, USPS _silently_ migrated to a new developer portal (devloper`s`.usps.com instead of developer.usps.com). See: https://developer.usps.com/getting-started. The new portal also introduces new base URL for their endpoints (See: https://developers.usps.com/sites/default/files/2024-10/USPS%20API%20Cloud%20Enrollment.pdf). Users who registered after this date didn't manage to use Odoo shipping connector for USPS since it used the old endpoints. This commit updates the used endpoints so that it's compatible with the new portal. opw-4576028 Forward-Port-Of: odoo/enterprise#80152
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental
Original PR description
Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. Solution To fix this, this commit adds Rental Settings making the rental_loc_id field visible in the res_company view, allowing customers to select their desired rental location and resolve the issue independently. - opw-3973957 - opw-4488182 - opw-4545985 Forward-Port-Of: odoo/enterprise#80140 Forward-Port-Of: odoo/enterprise#79785
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours - Change the start or end date of the task - Notice allocated hours didn't change ### Current behavior before PR: This is happening because we are supposed to only compute the allocated hours when the task is getting created and after this we don't re-calculate it but the user can edit i
Original PR description
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours -…
### Steps to reproduce: - Create a project with 'Timesheets' option deactivated - Create a task with a planned start date and end date - Check the task in the gantt view, notice the allocated hours - Change the start or end date of the task - Notice allocated hours didn't change ### Current behavior before PR: This is happening because we are supposed to only compute the allocated hours when the task is getting created and after this we don't re-calculate it but the user can edit it manually but if the 'Timesheets' option is false the allocated hours won't be shown in any form to be edited so only if the 'Timesheets' option is deactivated for the project we should re-compute the allocated hours ### Desired behavior after PR is merged: Add another condition where if the project allows timesheets we don't re-compute the allocated hours field if it doesn't allow timesheets we re-compute it. opw-4192775 Forward-Port-Of: odoo/enterprise#80047 Forward-Port-Of: odoo/enterprise#71681
**To replicate:** 1. Install a localization reports module (e.g. l10n_lu_reports) 2. Create two branches for the company in the localization: one with a different VAT, and another without VAT (it takes the same VAT as the closest parent with VAT) 3. In Accounting > Reporting > Tax Report 4. Select only the company with a different VAT. The button to export an XML is not enabled. 5. Select the parent company and the company without VAT. The button to export an XML is not enabled. **Issue:
Original PR description
**To replicate:** 1. Install a localization reports module (e.g. l10n_lu_reports) 2. Create two branches for the company in the localization: one with a different VAT, and another without VAT (it…
**To replicate:** 1. Install a localization reports module (e.g. l10n_lu_reports) 2. Create two branches for the company in the localization: one with a different VAT, and another without VAT (it takes the same VAT as the closest parent with VAT) 3. In Accounting > Reporting > Tax Report 4. Select only the company with a different VAT. The button to export an XML is not enabled. 5. Select the parent company and the company without VAT. The button to export an XML is not enabled. **Issue:** In some Tax Reports and EC Sales Reports with branch companies, the additional buttons are not enabled properly, even when all companies with the same VAT are selected. **Expected behavior:** If all branches with the same VAT are selected, export buttons should be available. **Cause of the problem:** In the tax report handler and EC sales report handler, `_custom_options_initializer()` calls the function `_enable_export_buttons_for_common_vat_groups_in_branches()`, which should enable the buttons if branches with the same VAT are selected. When extending `_custom_options_initializer()`, the call to super happens before extra buttons are added. These additional buttons are not included in the call to `_enable_export_buttons_for_common_vat_groups_in_branches()`. **Fix:** Instead of calling the function in _custom_options_initializer, add an option key to check and enable export buttons. This check is now done in `get_options()`, using the same logic previously applied in `_enable_export_buttons_for_common_vat_groups_in_branches`. As `get_options()` is called after the custom options initializer, all buttons are enabled if all branches with the same VAT are selected. task-4061157 Forward-Port-Of: odoo/enterprise#79227
Currently, the error message occurs when failed to fetch the account metrics. ``` Error Message: Failed to fetch the account (2) metrics: '{\n \'title\': \'Unauthorized\',\n \'type\': \'about:.. ``` This error message occurs when fetching social stream posts and refreshing statistics, so replace a logger error message with a logger warning message at [1], [2] to prevent more error logs in a terminal. link [1]: https://github.com/odoo/enterprise/blob/6e581b9dbf0c141e212f1641fc9cb37a05
Original PR description
Currently, the error message occurs when failed to fetch the account metrics.
```
Error Message: Failed to fetch the account (2) metrics: '{\n \'title\':
\'Unauthorized\',\n \'type\': \'about:..
```
This error message occurs when fetching social stream posts and refreshing statistics, so replace a logger error message with a logger warning message at [1], [2] to prevent more error logs in a terminal.
link [1]: https://github.com/odoo/enterprise/blob/6e581b9dbf0c141e212f1641fc9cb37a05140cff/social_twitter/models/social_live_post.py#L48
link [2]: https://github.com/odoo/enterprise/blob/af2db721417794ccda73ab83da388a782c94a911/social_twitter/models/social_stream.py#L91
sentry-4536687715
Forward-Port-Of: odoo/enterprise#64432Before this commit, the runbot would fail with Script Timeout when executing the `shared_sign_request_tour` tour. The main problem was the title of the modal being changed from "All done!" to "It's signed!" without updating the tour itself. The secondary problem was the limitation added in the tour of clicking a button inside a modal: this one is not allowed anymore. After this commit, we removed the 'Download button' trigger in the tour as it is not allowed anymore and updated the string
Original PR description
Before this commit, the runbot would fail with Script Timeout when executing the `shared_sign_request_tour` tour. The main problem was the title of the modal being changed from "All done!" to "It's signed!" without updating the tour itself. The secondary problem was the limitation added in the tour of clicking a button inside a modal: this one is not allowed anymore. After this commit, we removed the 'Download button' trigger in the tour as it is not allowed anymore and updated the string for the correct modal title in the tour, from "All done!" to "It's signed!". runbot-98514 Forward-Port-Of: odoo/enterprise#80070
_unlink_except_government_document() is only defined in account_edi, which is not a dependancy of this module... but we don't need to call super for an ondelete constraint. runbot error: 114255 Forward-Port-Of: odoo/enterprise#79460
Original PR description
_unlink_except_government_document() is only defined in account_edi, which is not a dependancy of this module... but we don't need to call super for an ondelete constraint. runbot error: 114255 Forward-Port-Of: odoo/enterprise#79460
…emplate context if mail_notification_light is customized Steps to reproduce : ---- - customize mail_notification_light template with a field from record (with Studio or with inherited template) - confirm a Hr Appraisal or send a Hr Appraisal Survey Error before this commit : ---- - RPC error odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'record' Template: mail.mail_notification_light Explanation : ---- We add the record in the template
Original PR description
…emplate context if mail_notification_light is customized Steps to reproduce : ---- - customize mail_notification_light template with a field from record (with Studio or with inherited template) - confirm a Hr Appraisal or send a Hr Appraisal Survey Error before this commit : ---- - RPC error odoo.addons.base.models.ir_qweb.QWebException: Error while render the template KeyError: 'record' Template: mail.mail_notification_light Explanation : ---- We add the record in the template context, therefore any field from the record can be called Forward-Port-Of: odoo/enterprise#74943
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise
Original PR description
The kanban has been reworked with https://github.com/odoo/odoo/pull/167751 and odoo/enterprise@23426182d92198cf977d7eecbfb3d47117d80c59 Before this commit when a field is empty (the record has no value for a field) in the kanban editor -- new version -- that field had no size and was virtually invisible. This was because one little line of code was missing to enable the feature of applying a placeholder in the empty field to make it visible. opw-4526492 Forward-Port-Of: odoo/enterprise#80127 Forward-Port-Of: odoo/enterprise#79812
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invo
Original PR description
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invoice and payment amounts (`invoice_amount / payment_amount`). This approach removes rounding discrepancies and ensures consistent values in the XML, preventing these rejections. Forward-Port-Of: odoo/enterprise#79899 Forward-Port-Of: odoo/enterprise#79038
Due to input cell overflow, a stopgap solution was to always display demand and replenish cells on 2 lines when actual and forecasted/replenish were both activated. This is considered sub-optimal and this fix was made. When the view is loaded or reloaded due to manual changes, the DOM is updated depending on if overflow is detected in input cells. task 4420441 Forward-Port-Of: odoo/enterprise#73494
Original PR description
Due to input cell overflow, a stopgap solution was to always display demand and replenish cells on 2 lines when actual and forecasted/replenish were both activated. This is considered sub-optimal and this fix was made. When the view is loaded or reloaded due to manual changes, the DOM is updated depending on if overflow is detected in input cells. task 4420441 Forward-Port-Of: odoo/enterprise#73494
This traceback arises when the user tries to change the orders from one stage to another. after deleting the last stage in another tab. To reproduce this issue:- 1) Install `pos_restaurant` 2) Duplicate the tab and open the preparation display in one tab 3) In another tab delete the last stage(`complete`) for the above preparation display 4) In the first tab click any product of an order from the `ready` stage 5) Now click the `ready` icon of that order 5) At the terminal you will
Original PR description
This traceback arises when the user tries to change the orders from one stage to another. after deleting the last stage in another tab. To reproduce this issue:- 1) Install `pos_restaurant` 2)…
This traceback arises when the user tries to change the orders from one stage to another.
after deleting the last stage in another tab.
To reproduce this issue:-
1) Install `pos_restaurant`
2) Duplicate the tab and open the preparation display in one tab
3) In another tab delete the last stage(`complete`) for the above preparation display
4) In the first tab click any product of an order from the `ready` stage
5) Now click the `ready` icon of that order
5) At the terminal you will see a traceback
Error:-
```
IndexError: list index out of range
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/pos_preparation_display/models/preparation_display_orderline.py", line 51, in send_stricked_line_to_next_stage
next_stage_id = stage_ids.ids[current_stage_index + 1]
```
When the user clicks on the current stage icon it is supposed to go to the next stage with the help of the current stage index + 1.
But, because the user deleted the next stage it leads to an index error
After applying this will resolve the issue by preventing the user to modify stages
when there is an active session for that preparation display. Which making the code more robust
sentry-5056416790
Forward-Port-Of: odoo/enterprise#59415### This commit fixes two issues introduced by [cdf65f563e6](https://github.com/odoo/odoo/pull/185954/commits/cdf65f563e6dc09ca238395e480da095232ac044): 1. Edit action incorrectly enabled for knowledge embedded view filters - These filters are not linked to server records in Knowledge - Attempting to edit leads to unwanted filter record creation - Should use delete action instead of edit for these cases 2. Favorites being lost in embedded views due to reconciliation - `_rec
Original PR description
### This commit fixes two issues introduced by [cdf65f563e6](https://github.com/odoo/odoo/pull/185954/commits/cdf65f563e6dc09ca238395e480da095232ac044): 1. Edit action incorrectly enabled for…
### This commit fixes two issues introduced by [cdf65f563e6](https://github.com/odoo/odoo/pull/185954/commits/cdf65f563e6dc09ca238395e480da095232ac044): 1. Edit action incorrectly enabled for knowledge embedded view filters - These filters are not linked to server records in Knowledge - Attempting to edit leads to unwanted filter record creation - Should use delete action instead of edit for these cases 2. Favorites being lost in embedded views due to reconciliation - `_reconciliateFavorites` deletes SearchItems that can't be reconciled - Embedded view filters are dissociated from record values - Results in loss of favorite filters when inserting views Solution: - Override `_reconciliateFavorites` to skip reconciliation for embedded views - Override `web.SearchBarMenu.FavoriteItem` to: * Restore delete action for embedded view filters * Add proper title and icon * Reimplement a `deleteFavorite` flow by patching `SearchBarMenu` - Reintroduce `deleteFavorite` in KnowledgeSearchModelMixin Reproduce Steps: 1st Issue: Create embedded view with "/kanban" or insert from another module - Add filter > edit action is present 2nd Issue: In any module - Add favorite filter - Insert view into Knowledge article - Filter is missing opw-4518370 Forward-Port-Of: odoo/enterprise#79725
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
Original PR description
In the follow up process, while the wizard's text is displayed correctly, the text in the chatter and in the pdf would contain too many carriage returns. The error is linked to the use of the text widget in the xml, which doesn't seem necessary in this case and is therefore removed. task-4574941 Forward-Port-Of: odoo/enterprise#79925 Forward-Port-Of: odoo/enterprise#79517
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570
Original PR description
In the expense app, a button enables to refund an expense directly in the payslip. This button is however not visible for payroll manager, while the action behind is. This commit solves the issue. task-4570975 Forward-Port-Of: odoo/enterprise#79879 Forward-Port-Of: odoo/enterprise#79570