Friday, February 21, 2025
66 changes · saas-18.1
Enhancements to existing features
Live chat no longer shows the unnecessary notification that the Welcome bot left the channel after handing a conversation to an operator. This keeps the chat cleaner and avoids distracting customers or operators with system messages that do not add value.
Original PR description
**Current behavior before PR:** prior to this PR when Welcome bot leave after fw to operator it posts notification message like `Welcome bot left the channel` which is unnecessary. **Desired behavior after PR is merged:** now it will not post any messages regarding `Welcome bot left the channel` . task-4410808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Mailbot now sends the correct command when triggering a saved automated response. This prevents the wrong response action from being used, making automated chat assistance more reliable for users.
Original PR description
Before this commit, the mailbot was sending the wrong command to trigger the canned response. This commit fixes the command to be sent and updates the translations accordingly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, lead
Original PR description
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the…
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, leading to inconsistent URLs. Steps to reproduce: 1. Context: The database has two companies, Company A and Company B, each with their own custom domains, Domain A and Domain B. 2. Log in to the database using Domain A. - Post a link via social marketing for Company A. The short URL will use Domain A. 3. Switch to the Company B. - Post the same link via social marketing for Company B. The short URL will now incorrectly use Domain A instead of B. While the short URL still redirects to the correct content, the domain in the short URL is inconsistent and depends on the last logged-in domain. OPW-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194331
The restaurant point-of-sale setup is now included with standard data instead of depending on demo data. This makes restaurant configurations available in non-demo environments, reducing setup issues for real deployments.
Original PR description
In this commit, The restaurant scenario loads in data instead of the demo. related PR: https://github.com/odoo/odoo/pull/194777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Editing messages in Chatter now follows the same shortcut used when posting new Chatter messages: Ctrl-Enter saves, while Enter adds a new line. This prevents accidental saves and makes editing longer business notes more consistent and predictable.
Original PR description
Before this commit, editing a message was always saving it with `Enter`, including in Chatter. This is a unintentional regression of https://github.com/odoo/odoo/pull/186084 that made improvements to…
Before this commit, editing a message was always saving it with `Enter`, including in Chatter. This is a unintentional regression of https://github.com/odoo/odoo/pull/186084 that made improvements to composer. Sending messages in chatter uses `Ctrl-Enter`, and `Enter` is used to make new lines. In discuss channels, this is the opposite: `Enter` to send a message, and `Shift-Enter` to make new lines. This difference looks strange, but it makes actually sense: `Enter` is the fastest for quick chat messages, whereas `Ctrl-Enter` is more appropriate when making long formatted message, which is generally the case in chatter. The editing of message in chatter should also use `Ctrl-Enter`, for consistency with posting a new message and also chatter messages are still long when editing them. This commit fixes this issue. Task-4593105 Before <img width="854" alt="Screenshot 2025-02-20 at 16 40 22" src="https://github.com/user-attachments/assets/9e9153a5-f67d-492b-9cac-ff74150f2873" /> After <img width="841" alt="Screenshot 2025-02-20 at 16 40 00" src="https://github.com/user-attachments/assets/e879d0d9-223b-45df-8111-517b02f30377" />
Starting the Furniture Shop scenario now completes successfully instead of showing an error. The fix ensures the demo user has an email when posting setup messages, so setup logs can be recorded properly.
Original PR description
Steps to reproduce: -------------------------- - Start db without demo data. - Click on furniture shop. Issue: -------- - There will be a TB while loading the furniture scenario. Cause: --------- - The user used in demo data doesn't have an email and it tries to post message in chatter. Fix: ----- - We have assigned a demo email to the user to avoid TB and also have the logs in chatter. Task: 4486094
Pressing Tab in the live chat window now prioritizes active conversations instead of reopening ended ones. This prevents confusion for operators and keeps their focus on the relevant chat when a conversation has already ended.
Original PR description
**Current behavior before PR:** When a user had an open live chat window and pressed the Tab key, it resulted in an ended chat window being opened. **Desired behavior after PR is merged:** This fix ensures that pressing the Tab key will open active live chats first, then the ended chats. It also keeps the focus on the chat window if the live chat has ended. Task-4507082 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the customer selection button visible again when using Point of Sale on mobile devices with only the standard POS app installed. It ensures cashiers can assign customers to orders without needing the restaurant add-on, reducing checkout disruption.
Original PR description
Steps: ========== - Install only the point_of_sale module. - Open the PoS Register in mobile view. - Click on the cart button. Issue: =========== - The partner button is not visible. Cause: =========== - The `currentOrder` getter was defined in `pos_restaurant`, making it unavailable when only `point_of_sale` is installed. Fix: - Moved the `currentOrder` getter from `pos_restaurant` to `point_of_sale`, ensuring availability in all cases.
Commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d introduced a regression that caused `l10n_latam_invoice_document` to lose its header for the striped layout. In addition due to different position of the header img tag in the standard layout template HTML tree, `l10n_hu_edi` also required explicit base standard layout header classes in its attributes. This was caused by the xpath `//img/../..` introduced in f86238d7c872b3f025085831d50f1896168b6274 which thus unintentionally removed these classe
Original PR description
Commit 9d986db17f14c7fcc05ba30df59b07b8c37d0a9d introduced a regression that caused `l10n_latam_invoice_document` to lose its header for the striped layout. In addition due to different position of the header img tag in the standard layout template HTML tree, `l10n_hu_edi` also required explicit base standard layout header classes in its attributes. This was caused by the xpath `//img/../..` introduced in f86238d7c872b3f025085831d50f1896168b6274 which thus unintentionally removed these classes opw-4593505 Forward-Port-Of: odoo/odoo#198744
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at w
Original PR description
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193498
In `account.move.line` views, the `account_id` fields that have a `domain` attribute need to filter for `company_ids` in the domain, since the check_company domain is overriden by the domain in the field. We removed these domains in odoo#171079 thinking that check_company=True would automatically add them. But it doesn't, so we must revert that change. Otherwise, the user can select accounts that don't belong to the current invoice / vendor bill / journal entry's company. task-none For
Original PR description
In `account.move.line` views, the `account_id` fields that have a `domain` attribute need to filter for `company_ids` in the domain, since the check_company domain is overriden by the domain in the field. We removed these domains in odoo#171079 thinking that check_company=True would automatically add them. But it doesn't, so we must revert that change. Otherwise, the user can select accounts that don't belong to the current invoice / vendor bill / journal entry's company. task-none Forward-Port-Of: odoo/odoo#198645
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
Original PR description
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
Before this commit and since [1], when inserting a banner at the top of the editable, a zero-width space (ZWS) was inserted before the banner to circuvent a Chromium bug that prevents fully selecting the banner with the mouse [2]. This led to the undesirable behavior of having a text node (with a ZWS) as the first child of the editable, creating a line above the banner and allowing for text insertion at the editable's root. This commit replaces the ZWS insertion with an empty paragraph, wh
Original PR description
Before this commit and since [1], when inserting a banner at the top of the editable, a zero-width space (ZWS) was inserted before the banner to circuvent a Chromium bug that prevents fully selecting the banner with the mouse [2]. This led to the undesirable behavior of having a text node (with a ZWS) as the first child of the editable, creating a line above the banner and allowing for text insertion at the editable's root. This commit replaces the ZWS insertion with an empty paragraph, which can be later be moved around by the user. [1]: https://github.com/odoo/odoo/commit/a0fcba694a8a23a947ba28d188d6806272627447 [2]: https://issues.chromium.org/issues/40822311 task-4512959 Forward-Port-Of: odoo/odoo#195027
When we show a wizard to the user it is possible to add some warnings and redirects to views. However currently an error message will raise when accessing a view with more than 1 view mode Steps to reproduce: - Have entries already secured with hash - Create unreconciled bank statement - Open Secure Entries wizard (Accounting / Accounting / Secure Entries) - Enter a future date - Warning will raise "There are still unreconciled bank statement lines before the selected date. The entri
Original PR description
When we show a wizard to the user it is possible to add some warnings and redirects to views. However currently an error message will raise when accessing a view with more than 1 view mode Steps to reproduce: - Have entries already secured with hash - Create unreconciled bank statement - Open Secure Entries wizard (Accounting / Accounting / Secure Entries) - Enter a future date - Warning will raise "There are still unreconciled bank statement lines before the selected date. The entries from journal prefixes containing them will not be secured: BNK1/2025 Review" - Click on the Review Link Traceback ``` Uncaught Promise > View types not defined kanban,list found in act_window action 855 ``` This occurs because multiple view_mode are not correctly handled opw-4571921 Forward-Port-Of: odoo/odoo#198159
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an e
Original PR description
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198710 Forward-Port-Of: odoo/odoo#196106
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
Original PR description
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
### Commit 1 In the point of sale environnement we want to be able to edit html field in a minimal way. So only core plugins are added to the html_editor. As we have a special assets environnement for the point_of_sale we can directly patch the main `htmlField` definition without impacting main assets of Odoo. So in Order to make it work we need to remove the preventDefault on backspace key at the initialization of PoS. Enterprise: 79703 ### Commit 2 The html editor should
Original PR description
### Commit 1 In the point of sale environnement we want to be able to edit html field in a minimal way. So only core plugins are added to the html_editor. As we have a special assets environnement…
### Commit 1
In the point of sale environnement we want to be able to edit html field
in a minimal way. So only core plugins are added to the html_editor.
As we have a special assets environnement for the point_of_sale we can
directly patch the main `htmlField` definition without impacting main
assets of Odoo.
So in Order to make it work we need to remove the preventDefault on
backspace key at the initialization of PoS.
Enterprise: 79703
### Commit 2
The html editor should only work with the “CORE_PLUGINS” plugin set.
But when an HTML field is used only with this Set a traceback is raised
because the “MediaPlugin” plugin is missing.
This is due to this piece of code:
```js
async getEditorContent() {
await this.editor.shared.media.savePendingImages();
return this.editor.getElContent();
}
```
Each time an HTML input is unfocused, this method is called and attempts
to save the pending images. The problem is that media.savePendingImages
depends on the “MediaPlugin”.
A quick fix is made in this commit by adding a question mark after media
to avoid traceback if the plugin is missing.
Forward-Port-Of: odoo/odoo#198482## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it
Original PR description
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking. OPW-3919976 Forward-Port-Of: odoo/odoo#198675 Forward-Port-Of: odoo/odoo#196161
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: > Automatic payment failed. No email sent this time. > Error: Worldline: The communication with the API failed. > Details: Cause ----- When a payment gets rejected for any reason like card expiration, Worldline returns the 402 HTTP response code[^2]. This is a nonstandard response indic
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: >…
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card[^1]; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Subscription chatter shows: > Automatic payment failed. No email sent this time. > Error: Worldline: The communication with the API failed. > Details: Cause ----- When a payment gets rejected for any reason like card expiration, Worldline returns the 402 HTTP response code[^2]. This is a nonstandard response indicating "Payment Required"[^3]. Because the 4xx HTTP status code range is reserved for client errors, we currently interpret the 402 response as a communication failure with the API instead of a rejected payment. Solution -------- Don't `raise_for_status` if the response belongs to one of the "expected" responses according to their API: - 200: Successful - 201: Created - 402: Payment rejected opw-4481602 [^1]: Wordline doesn't provide a way to easily test rejected payments. [^2]: https://apireference.connect.worldline-solutions.com/s2sapi/v1/en_US/json/response-codes.html [^3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/402 Forward-Port-Of: odoo/odoo#198652
Steps to reproduce: - Install any industry module; - Uninstall the module; Current behaviour: Some records from the industry module (like a knowledge article) which have a second xmlid from `__cloc_exclude__` remain in the database after the uninstallation. Expected behaviour: After this commit, all records from the industry and their related `__cloc_exclude__` ir_model_data entries are removed. task-4501067 Forward-Port-Of: odoo/odoo#196667
Original PR description
Steps to reproduce: - Install any industry module; - Uninstall the module; Current behaviour: Some records from the industry module (like a knowledge article) which have a second xmlid from `__cloc_exclude__` remain in the database after the uninstallation. Expected behaviour: After this commit, all records from the industry and their related `__cloc_exclude__` ir_model_data entries are removed. task-4501067 Forward-Port-Of: odoo/odoo#196667
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Pr
Original PR description
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Project Stage feature 4. Go to Project > Configuration > Projects 5. Click on new button to create a new project 6. Set the project name and click on the second project stage Current Behavior: ---------------- The project goes back to the default stage instead of staying in the stage selected by the user. Expected Behavior: ----------------- The project should be in the stage selected. Forward-Port-Of: odoo/odoo#198452
Before this commit, it wasn't possible to filter products by category when searching. This functionality was available in previous versions but was removed during refactoring. opw-4439314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193503
Original PR description
Before this commit, it wasn't possible to filter products by category when searching. This functionality was available in previous versions but was removed during refactoring. opw-4439314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193503
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attach
Original PR description
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attachments/assets/df32dbc8-d042-4802-a9b4-2f3d93e97963" /> Forward-Port-Of: odoo/odoo#198320
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close t
Original PR description
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing…
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close the session and check the cost of the products in the order > Observation: The cost for P3 is incorrect, it should be 100 but it is 200. Why the fix: ------------ When selecting the stock moves line to consider for the cost of the PoS order, we need to select the stock moves that are related to the BoM lines of the original product. In the previous code we were only relying on the product id, and this was causing the issue because some products can have the same product id but used in different BoM lines. opw-4201935 Forward-Port-Of: odoo/odoo#198036 Forward-Port-Of: odoo/odoo#193717
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#197235 Forward-Port-Of: odoo/odoo#194985
Original PR description
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#197235 Forward-Port-Of: odoo/odoo#194985
Description of the issue/feature this PR addresses: This PR adds signature of Corporate Contributor License Agreement for PT Layani Solusi Indonesia, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198503
Original PR description
Description of the issue/feature this PR addresses: This PR adds signature of Corporate Contributor License Agreement for PT Layani Solusi Indonesia, including the list of contributors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198503
Before this commit, when using livechat by visitor in mobile, any page reload would remove access to the livechat. Steps to reproduce: - access to website with livechat installed on mobile - click on livechat button (bubble icon in bottom right) - send a message - reload the page => the livechat is not open, not even as a chat bubble. This prevents visitor from access the livechat again, except if user finds a workaround to open the same page in non-mobile mode (e.g. landscape mode
Original PR description
Before this commit, when using livechat by visitor in mobile, any page reload would remove access to the livechat. Steps to reproduce: - access to website with livechat installed on mobile - click on…
Before this commit, when using livechat by visitor in mobile, any page reload would remove access to the livechat. Steps to reproduce: - access to website with livechat installed on mobile - click on livechat button (bubble icon in bottom right) - send a message - reload the page => the livechat is not open, not even as a chat bubble. This prevents visitor from access the livechat again, except if user finds a workaround to open the same page in non-mobile mode (e.g. landscape mode or disabling high-dpi). This happens because livechat relies on discuss chat hub, and there's some code to prevent server-side synchronisation of chat windows and bubbles in mobile. As a reminder, conversation in mobile are shown as fullscreen chat windows. This code was preventing the opening of chat window on livechat for visitor, leading to prevention of continuing to live chat on the device. This commit fixes by adding fold action to chat windows in mobile specifically for livechat visitors, thus allowing to have chat bubbles in mobile. This fixes allow to show chat windows as bubbles to livechat visitors, which is the primary fix of these changes. Due to chat windows being server-synced, we made sure to not sync chat windows in the backend. To do so, we rely on presence of livechat service to determine when the chat bubble feature should work in mobile. opw-4423556 opw-4488830 Forward-Port-Of: odoo/odoo#194363
- Adjusting the 'Request Invoice' button UI. - Adjusting the tooltip description text for point_of_sale_use_ticket_qr_code. - Traceback was resolved in https://github.com/odoo/odoo/commit/ca19b340af49fea845275d737124d5fca79d23a3 task: 4276541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190081
Original PR description
- Adjusting the 'Request Invoice' button UI. - Adjusting the tooltip description text for point_of_sale_use_ticket_qr_code. - Traceback was resolved in https://github.com/odoo/odoo/commit/ca19b340af49fea845275d737124d5fca79d23a3 task: 4276541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190081
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
Original PR description
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
add a function to add discount Forward-Port-Of: odoo/odoo#198588
Original PR description
add a function to add discount Forward-Port-Of: odoo/odoo#198588
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#197794
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: - P1 -> 2 units - P2 -> 2 units - Validate the receipt and create a backorder. Problem: A picking is validated with only 2 units of P2, and a backorder is created with 5 units of P1 and 3 units of P2, instead of correctly validating the picking with: - P1 -> 2 units -
Original PR description
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: -…
Steps to reproduce the issue:
- Create a storable product P1.
- Create a subcontracted product P2.
- Create a receipt with 5 units of P1 and P2.
- Mark it as To Do.
- Set the quantities as follows:
- P1 -> 2 units
- P2 -> 2 units
- Validate the receipt and create a backorder.
Problem:
A picking is validated with only 2 units of P2, and a backorder is
created with 5 units of P1 and 3 units of P2, instead of correctly
validating the picking with:
- P1 -> 2 units
- P2 -> 2 units
And creating a backorder with:
- 3 units of P1
- 3 units of P2
This occurs because, when updating the move for P2 from 5 to 2, a move
line is created and marked as picked. As a result, when computing the
picked value for the move, it is also marked as picked:
https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock/models/stock_move.py#L206-L207
Thus, when validating the picking, since only the move for P2 is marked
as picked, it is the only one that gets validated.
opw-4357997
Forward-Port-Of: odoo/odoo#189481## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send - "What is Peppol" warning no longer appear on already sent invoices. - Remove the warning related to already existing PDF. This will be improved by the following task [1]. - Remove the warning related to bank accounts, this will be improved in the next commit of this PR. - Align warnings related to absence of EAS/Endpoint. - Move the "Test/Demo mode" warning next to the "by Peppol" label. - Remove the new
Original PR description
## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send - "What is Peppol" warning no longer appear on already sent invoices. - Remove the warning related to already existing…
## Commit 1: [IMP] account{,_edi_ubl_cii,_peppol}: Misc imps of the Print & Send
- "What is Peppol" warning no longer appear on already sent invoices.
- Remove the warning related to already existing PDF. This will be improved
by the following task [1].
- Remove the warning related to bank accounts, this will be improved
in the next commit of this PR.
- Align warnings related to absence of EAS/Endpoint.
- Move the "Test/Demo mode" warning next to the "by Peppol" label.
- Remove the new "Print" button from draft invoices.
[1]: https://www.odoo.com/odoo/project/967/tasks/4498564
task-4478365
-----------------------------
## Commit 2: [FIX] account: Add translation for invoice pdf report field in form
task-no
-----------------------------
## Commit 3: [IMP] account_{edi_ubl_cii,peppol}: Stop setting automatically an invoice edi format
In previous refactor[1], we set automatically an invoice EDI format.
This decision was too zealous considering the overall state of e-invoicing
and now cause more frictions than necessary.
We therefore decided to remove the automatic computation of EDI format on
partners.
[1]: https://github.com/odoo/odoo/commit/9e769e1b11f22890e5245859053bc8dd31e42634
task-4478365
-----------------------------
## Commit 4: [FIX] account: remove partner_bank_id from readonly field of posted moves
In previous PR [1], we made the partner_bank_id field editable on
the invoice form as long as the move is not sent.
There was still a security check in place, let's remove it for this
field.
[1]: https://github.com/odoo/odoo/pull/195069
task-4478365
-----------------------------
## Commit 5: [IMP] account_edi_ubl_cii: use code ZZZ instead of 30 if no bank account is set
To generate a valid BIS3 format, if we put 30 - credit transfer as payment means,
we need to have a bank account set. If it's not the case, it will raise an error.
We improve the usability by changing that code to ZZZ - mutually defined if no
bank account is provided to the invoice.
This should improve the onboarding flow when no bank account is set yet.
task-4478365
-----------------------------
## Commit 6: [IMP] account_peppol: expand the countries where we display WhatIsPeppol banner
This list is based on recent usage statistics from OpenPeppol.
task-4478365
Forward-Port-Of: odoo/odoo#196657Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Original PR description
Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. I
Original PR description
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. Instead, while the MO isn't started yet, we can simply compare to the demand to see if there's enough reservation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198593
Steps to reproduce: ------------------- - Create an invoice and set the partner to a portal user. - Set the payment term to any payment term with an early discount option and confirm the invoice. - Log in as the portal user and view my invoices, you will get an error message that you aren't allowed to access "Partial Reconcile" records Cause: ----- Since #182656, access to the payment_terms was added to the _is_eligible_for_early_payment_discount method, to allow applying the early disc
Original PR description
Steps to reproduce: ------------------- - Create an invoice and set the partner to a portal user. - Set the payment term to any payment term with an early discount option and confirm the invoice. - Log in as the portal user and view my invoices, you will get an error message that you aren't allowed to access "Partial Reconcile" records Cause: ----- Since #182656, access to the payment_terms was added to the _is_eligible_for_early_payment_discount method, to allow applying the early discount for in_payment invoices. Fix: --- Add sudo qualifier to the payment_terms access to allow this function to be called by portal users. opw-4535621 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198101
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
Original PR description
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.
Original PR description
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages. * `python3-cryptography` is installed by `python3-openssl` * `python3-idna` and `python3-urllib3` are installed by `python3-requests` * `python3-markupsafe` is installed by `python3-jinja2` Forward-Port-Of: odoo/odoo#198102 Forward-Port-Of: odoo/odoo#197302
Before this commit, if an element was out of the screen on the X axis, the pointer was showing as if it was out of the screen in top. Now, it makes the difference between X and Y axis. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198614
Original PR description
Before this commit, if an element was out of the screen on the X axis, the pointer was showing as if it was out of the screen in top. Now, it makes the difference between X and Y axis. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198614
The message "Transferred by <Wave Nb>" was posted on pickings that are detached before the wave is validated. How to reproduce: - Create Product P, storable, with 2 unit on hand - Create 2 delivery transfer for 1 unit of P each - Add both transfer to new wave - Set Picked to True on 1 of the move, and not on the other. - Validate the wave transfer => 1 transfer only is validated (OK), but both have a message saying that the transfer was "Transferred by <Wave Nb>" Removed `skip_immedi
Original PR description
The message "Transferred by <Wave Nb>" was posted on pickings that are detached before the wave is validated. How to reproduce: - Create Product P, storable, with 2 unit on hand - Create 2 delivery transfer for 1 unit of P each - Add both transfer to new wave - Set Picked to True on 1 of the move, and not on the other. - Validate the wave transfer => 1 transfer only is validated (OK), but both have a message saying that the transfer was "Transferred by <Wave Nb>" Removed `skip_immediate` context as it is obsolete, and allow the function to only have 1 return statement, which is needed for the fix. OPW-4503809 Forward-Port-Of: odoo/odoo#198058 Forward-Port-Of: odoo/odoo#195757
More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
Original PR description
More logging is required to track calls to VIES services to enable tracking databases triggering VIES limitations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176677 Forward-Port-Of: odoo/odoo#176602
In this commit: ========== - Updated the test case for test_customer_all_fields_displayed. The test previously found multiple partners with the same phone number because the ID Company's phone was `+62 812-345-678`, while the test phone was `1234567890`. To resolve this, we have updated the test phone number to `9898989899`. Runbot Error- 116844, 116845 Forward-Port-Of: odoo/odoo#198255
Original PR description
In this commit: ========== - Updated the test case for test_customer_all_fields_displayed. The test previously found multiple partners with the same phone number because the ID Company's phone was `+62 812-345-678`, while the test phone was `1234567890`. To resolve this, we have updated the test phone number to `9898989899`. Runbot Error- 116844, 116845 Forward-Port-Of: odoo/odoo#198255
related - https://github.com/odoo/enterprise/pull/79690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198328
Original PR description
related - https://github.com/odoo/enterprise/pull/79690 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198328
## Issue: In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary. ## Steps to reproduce: 1. Create a new employee 2. Create a new contract for this employee with a hourly wage and Luxembourg: Regular Pay structure 3. Create a new payslip for this employee 4. Check the basic salary: it will be 0 ## Root cause: - The previous implementation did not account
Original PR description
## Issue: In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary.…
## Issue: In Luxembourg companies, when creating an employee contract with an hourly wage, the indexed wage is always displayed as 0, causing the payslip to incorrectly show 0 for the basic salary. ## Steps to reproduce: 1. Create a new employee 2. Create a new contract for this employee with a hourly wage and Luxembourg: Regular Pay structure 3. Create a new payslip for this employee 4. Check the basic salary: it will be 0 ## Root cause: - The previous implementation did not account for hourly wage contracts when computing the indexed wage, leading to incorrect salary calculations. ## Solution: - Added logic to correctly compute the indexed wage for hourly contracts. - Adjusted related salary rules to differentiate between hourly and monthly wage types. - Updated views to reflect the correct unit (per month or per hour) based on the wage type. - Added a test case to validate the correct computation for hourly contracts. OPW-4460735 Forward-Port-Of: odoo/enterprise#78789
This PR will add new reports for the danish localisation. The new reports are a minimal version of what was already there since we received some comments that for a lot of companies the report has too much details. Also when doing the PR, we saw that some name in the old reports where not well formatted and so not consistent with the rest of the reports. This PR will also re-export the translation. Forward-Port-Of: odoo/enterprise#72879
Original PR description
This PR will add new reports for the danish localisation. The new reports are a minimal version of what was already there since we received some comments that for a lot of companies the report has too much details. Also when doing the PR, we saw that some name in the old reports where not well formatted and so not consistent with the rest of the reports. This PR will also re-export the translation. Forward-Port-Of: odoo/enterprise#72879
Instead of sending a confusing customer statement that includes invoices from the last period regardless of their status. Adding a new Partner ledger variant that will be sent as a follow-up report that provides the current year's customer statement including only customer invoices with separating Due and OverDue invoices. task-4454196 Forward-Port-Of: odoo/enterprise#78534
Original PR description
Instead of sending a confusing customer statement that includes invoices from the last period regardless of their status. Adding a new Partner ledger variant that will be sent as a follow-up report that provides the current year's customer statement including only customer invoices with separating Due and OverDue invoices. task-4454196 Forward-Port-Of: odoo/enterprise#78534
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
Original PR description
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158 Forward-Port-Of: odoo/enterprise#79669
Original PR description
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158 Forward-Port-Of: odoo/enterprise#79669
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will
Original PR description
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection. Forward-Port-Of: odoo/enterprise#79797
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273 Forward-Port-Of: odoo/enterprise#78692
Original PR description
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273 Forward-Port-Of: odoo/enterprise#78692
In the point of sale environnement we want to be able to edit html field in a minimal way. So only core plugins are added to the html_editor. As we have a special assets environnement for the point_of_sale we can directly patch the main `htmlField` definition without impacting main assets of Odoo. Community: 198482 Forward-Port-Of: odoo/enterprise#79703
Original PR description
In the point of sale environnement we want to be able to edit html field in a minimal way. So only core plugins are added to the html_editor. As we have a special assets environnement for the point_of_sale we can directly patch the main `htmlField` definition without impacting main assets of Odoo. Community: 198482 Forward-Port-Of: odoo/enterprise#79703
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records. ### Note: This is easily reproducible by hand in localhost and should worsen if you have server delay. In addition, it makes it impossible to write a proper tour involving the catalo
Original PR description
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost),…
### Issue: Since 18.0, the catalog is used in certain actions of the shopfloor However, if you leave the catalog fast enough after your last change (something of the order of ~0.5 sec in localhost), you can trigger a reload of the shopfloor records and call a `web_read` prior to the update of these records. ### Note: This is easily reproducible by hand in localhost and should worsen if you have server delay. In addition, it makes it impossible to write a proper tour involving the catalog in the shopfloor. ### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > wheel > Add component - Add a component to be consumed in that operation - Close the catalog fast (using ESC for instance) #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on the shopfloor. ### Cause of the issue: When a product is added from the catalog it triggers an rpc call to update the data's of the MO (notably creating a new raw move): https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/product/static/src/product_catalog/kanban_record.js#L62-L69 https://github.com/odoo/odoo/blob/193c9a49dfc039ee93fbc8e171819236697b5c50/addons/mrp/models/mrp_production.py#L2898-L2901 On the other hand, closing the product catalog will reload the mrp record that started the action that opened the catalog: https://github.com/odoo/enterprise/blob/c1346dd2279bf3882b47b260b8d03ef9651ffaf1/mrp_workorder/static/src/mrp_display/dialog/mrp_menu_dialog.js#L41-L45 Since this reload is currently not waiting for the update of the record the associated `web_read` might be called prior to the last update of the record and the newly created raw moves might not be displayed. ### Fix: We use the props option of the action opening the catalog to transfer a callback to reload the records when all the record update promisses are resolved. #### To be more precise: The `ProductCatalogKanbanController` component contains a list of promises (initially empty): `catalogKanbanUpdates` aswell as an optional callback props `onCatalogUpdated`. This list is going to be populated each time that a `ProductCatalogKanbanRecord` make a quantity update (used stock moves on the mrp.production). To populate this array of promises a method is defined in the controller: `pushCatalogKanbanUpdate`. This method needs to be called by the `KanbanRecords` an hence is transported using xpath from the `ProductCatalogKanbanController` to the `ProductCatalogKanbanRecord` via the `ProductCatalogKanbanRenderer`. Once the controller is detroyed (and hence each kanban record that had to update a quantity started its call) if a callback was given to the props of the Kanban controller we wait for all the update promises to be resolved and we call that call back. opw-4199156 --- Forward-Port-Of: odoo/enterprise#74151
- Adding DIAN UBL codes for the existing UoM provided in the task description. Code '94' is returned if the UoM for some reason doesn't have a defined code. - Adjusting the relevant method in the DIAN module to match. - Adjusting test XMLs to use correct UBL codes. task: 4396119 Forward-Port-Of: odoo/enterprise#75745
Original PR description
- Adding DIAN UBL codes for the existing UoM provided in the task description. Code '94' is returned if the UoM for some reason doesn't have a defined code. - Adjusting the relevant method in the DIAN module to match. - Adjusting test XMLs to use correct UBL codes. task: 4396119 Forward-Port-Of: odoo/enterprise#75745
See commits :-) Forward-Port-Of: odoo/enterprise#79743 Forward-Port-Of: odoo/enterprise#79264
Original PR description
See commits :-) Forward-Port-Of: odoo/enterprise#79743 Forward-Port-Of: odoo/enterprise#79264
By default, SEPA requires a 5 day notification period prior to collecting a payment, if no payment has ever been collected using the related mandate. However, it could be that the company used another software before and imported their existing mandates (that have no payments yet in Odoo). In this case, the 5 day period does not apply and can be relaxes to the default 2 day period for running mandates. Instead of blocking the user when their required payment date is not at least 5 days fro
Original PR description
By default, SEPA requires a 5 day notification period prior to collecting a payment, if no payment has ever been collected using the related mandate. However, it could be that the company used another software before and imported their existing mandates (that have no payments yet in Odoo). In this case, the 5 day period does not apply and can be relaxes to the default 2 day period for running mandates. Instead of blocking the user when their required payment date is not at least 5 days from today (on first-time mandates), we now only show a warning at the top of the form, with links to the related payments. Blocking the user will only happen if the required payment date is not at least 2 days from today. [task-4472278](https://www.odoo.com/odoo/project.task/4472278) Forward-Port-Of: odoo/enterprise#77134
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
Original PR description
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
- Fix the tags and attributes html to xml replacement to use longest matching - Fix the price calculations when a discount is added to an order line Forward-Port-Of: odoo/enterprise#79827
Original PR description
- Fix the tags and attributes html to xml replacement to use longest matching - Fix the price calculations when a discount is added to an order line Forward-Port-Of: odoo/enterprise#79827
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Original PR description
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Original PR description
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
Original PR description
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efa
Original PR description
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called,…
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efabfed5c1 Before: 3.51s (`_create_checks`) - 17493 queries (total queries of the script, not for the single operation)  After: 2.08s (`_create_checks`) - 16103 queries (total queries of the script, not for the single operation)  Comparison of the time taken by Confirming the MRP Order (using `time.process_time()`) | n_components | before (s) | after (s) | ratio | | --- | --- | --- | --- | | 1 | 0.074 | 0.073 | 0.988 | | 5 | 0.134 | 0.140 | 1.042 | | 10 | 0.216 | 0.187 | 0.862 | | 20 | 0.334 | 0.304 | 0.908 | | 50 | 0.736 | 0.600 | 0.816 | | 100 | 1.378 | 1.172 | 0.851 | | 200 | 2.739 | 2.374 | 0.867 | Forward-Port-Of: odoo/enterprise#77608 Forward-Port-Of: odoo/enterprise#65725
Forward-Port-Of: odoo/enterprise#79660
Original PR description
Forward-Port-Of: odoo/enterprise#79660
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79579 Forward-Port-Of: odoo/enterprise#75552
Original PR description
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79579 Forward-Port-Of: odoo/enterprise#75552
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Original PR description
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create arti
Original PR description
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create article without any errors. Also prevent unnecessary write on empty recordset. Task-4414401 Forward-Port-Of: odoo/enterprise#76349
related - https://github.com/odoo/odoo/pull/198328 Forward-Port-Of: odoo/enterprise#79690
Original PR description
related - https://github.com/odoo/odoo/pull/198328 Forward-Port-Of: odoo/enterprise#79690