Monday, February 3, 2025
33 changes · saas-17.4
Resolved issues and error corrections
Time off allocations no longer create an activity for the employee who entered them when no notified time off officer is selected. This prevents unnecessary reminders and emails from being sent in configurations where no officer should be notified.
Original PR description
steps to reproduce: -Create a new time off type. -Set the approval radio button to either "By Time Off Officer" or "By Employee's Approver and Time Off Officer." -Leave the "Notified Time Off Officer" field empty. -Try to create a new allocation for the newly created time off type. -Notice that an activity is created for the user who created the allocation. cause: When the "Notified Time Off Officer" field is left empty, no activity or email should be created. solution: Remove self.env.user.ids to prevent the creation of an activity for the user. task-4351747
The Payroll work entries Gantt view now keeps the deferred time off warning in place when users scroll horizontally. This makes the warning easier to read and prevents it from moving away from its intended position.
Original PR description
Steps to Reproduce: • Install the Payroll app. • Navigate to the Work Entries Gantt view. • When there is deferred time off, a warning message is displayed. • Scrolling horizontally in the Gantt view causes the warning message to move along, whereas it should remain static. Cause: • The position of the warning message element is not fixed. Fix: • Set the element's position to sticky so that it remains static while scrolling. task-4367336
The database name now remains clearly visible when debug mode and dark mode are both enabled. This improves usability for users and administrators who rely on the database name to confirm they are working in the right environment.
Original PR description
Previously after activating debug mode and then dark mode, the letters of database name are not visible clearly. It is happening because in new bootstrap version we are having an inappropriate color for mark tag in dark mode. After this commit the database name will be clearly visible in dark mode. Task- 4389154
Miscellaneous changes
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
Original PR description
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Original PR description
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represe
Original PR description
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represented correctly in Python (including 7, 3.3 etc.). opw-4485316 Forward-Port-Of: odoo/odoo#195328
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Original PR description
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be
Original PR description
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓…
Since the class `s_searchbar_input` was translated into Dutch by a translator on Transifex. <sub>See screenshot of the Website `nl.po` file </sub>↓ <kbd></kbd> It is no longer possible to drop the searchbar block onto a webpage when Odoo's language is set to Dutch. In this PR, we add `t-translation="off"` in the xpath that adds this class to the list of droppable element selectors, so it won't be translated anymore. We also do the same for other xpath-ed classes that don’t have `t-translation="off"`, to prevent the same issue elsewhere. Since the class is already translated in the existing databases, in stable versions, we add the class a second time to the list of droppable element selectors. This second class won't be translated, which will fix the issue for Dutch users. [opw-4461785](https://www.odoo.com/web#id=4461785&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) ----------- Note: This PR also fix 2 minor bugs: - The text on the button to install a block overflows when translated into certain languages that make it longer. <kbd></kbd> - The `Embed code` block "Click on Edit..." message is not visible on dark background. <kbd></kbd> Forward-Port-Of: odoo/odoo#195854 Forward-Port-Of: odoo/odoo#193819
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. 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#196036 Forward-Port-Of: odoo/odoo#195909
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, securit
Original PR description
Description of the issue/feature this PR addresses: - After an internal user (without Live Chat application access) interacted with chatbot from website, he will not be able to click on the Messages icon on the top-right menu anymore:  - Cause: Internal user without Live Chat application access cannot read on model `chatbot.script.step`, so when system calls `mail_channel.chatbot_current_step_id`, security error occurs. - Solution: Use `sudo` on `mail_channel` variable to avoid security error. 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#185234 Forward-Port-Of: odoo/odoo#174611
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Fo
Original PR description
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Forward-Port-Of: odoo/odoo#193421
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other
Original PR description
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any others field types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195432
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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#179592
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194724
Forward-Port-Of: odoo/odoo#170080### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On…
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477 ### Fix: Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`. opw-4428050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194068
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test
Original PR description
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test by default drops at the middle and top of the drop zones. To avoid this kind of situation, in this commit, we add a step at the beginning of the test to hide the header. [1]: https://github.com/odoo/odoo/commit/e0c16bb9a90dfb378b75e0de059e71f0aebd84fb opw-4494945 Forward-Port-Of: odoo/odoo#195768 Forward-Port-Of: odoo/odoo#195554
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet
Original PR description
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet 1 - Drop text snippet 2 and hide it for desktop - Drop text snippet 3 - Remove text snippet 3 - Bug => text snippet 1 is not activated as expected [1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337 [2]: https://github.com/odoo/odoo/commit/2de0ad7259993f654ca8d826f5430f78090a28c5 task-4531506 Forward-Port-Of: odoo/odoo#195941 Forward-Port-Of: odoo/odoo#195743
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c
Original PR description
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id.…
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd - On TODO picking, do the following steps WITHOUT CLICKING ON SAVE - Operations -> Add a line: (demand 0, quantity 0) - Click on 'Open Move' button (fa-list icon) - Popup 'Open: Stock move': Add a line - Popup 'Add line: <product>': click on 'New' - Popup 'Create Move Line': click on 'Save & Close' - Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close' - Validate picking -> Create backorder => Check picking move_line_ids = EMPTY ## Solution Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list). OPW-3974109 Forward-Port-Of: odoo/odoo#171766
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent
Original PR description
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent crashes. [1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1#diff-b51336c1ad97255bfb3646f013327eca1904ca194078f4ce671e517096233c58 task-4420262 Forward-Port-Of: odoo/odoo#195940 Forward-Port-Of: odoo/odoo#194976
Those tests are sometimes failing since [1]. This commit is essentially a partial backport of [2], from the hoot suite to the qunit one. The other suites changed in [2] were already fixed in this version. [1] odoo/odoo#189147 [2] odoo/odoo#190157 runbot issue-109694 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
Original PR description
Those tests are sometimes failing since [1]. This commit is essentially a partial backport of [2], from the hoot suite to the qunit one. The other suites changed in [2] were already fixed in this version. [1] odoo/odoo#189147 [2] odoo/odoo#190157 runbot issue-109694 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#195197
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when tr
Original PR description
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the…
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when trying to read on it. When exporting a report with sections, `dispatch_report_action` is called on the first section, it detects that this is a section and calls the same method on the parent report. This commit (https://github.com/odoo/enterprise/commit/8213813e68f02d88934285a44a3413505f6ca187) removed the line getting the options for the parent report call to keep the specific options of each section. Specifically, the "report_id" key in the options is the id of the first section, causing the method to be called on the section. ### Solution: Setting the key "report_id" in the options of the parent report. This way the fix of the commit introducing the bug is still active. opw-4501376 Forward-Port-Of: odoo/enterprise#78185
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 F
Original PR description
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 Forward-Port-Of: odoo/enterprise#78074
### 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 - 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#71681
When moving a document from a folder to another, the tags are not removed, this leads to wrong behavior, for example when grouping by tags in the destination folder because we have invisible records linked to the documents. With this commit, we clear the `tag_ids` from the vals if there is no `tag_ids` in the write values, this way we don't interfer with eventual workflow rules that might set tags while moving the document. Steps: - With demo data, select the document mail.png in t
Original PR description
When moving a document from a folder to another, the tags are not removed, this leads to wrong behavior, for example when grouping by tags in the destination folder because we have invisible records linked to the documents. With this commit, we clear the `tag_ids` from the vals if there is no `tag_ids` in the write values, this way we don't interfer with eventual workflow rules that might set tags while moving the document. Steps: - With demo data, select the document mail.png in the 'Internal' folder - Change its folder to 'Finance' via the select input on the right side window - Go to 'Finance' folder, and filter the documents by tag (tag_ids contains 'Inbox') -> The document mail.png appears in the list although there is no tag set on it opw-4347910 Forward-Port-Of: odoo/enterprise#78333 Forward-Port-Of: odoo/enterprise#75001
Steps to reproduce: 1. Preview a document without selecting it. 2. Change the folder in the inspector. 3. The document is still in the current folder. 4. All the selected documents will be gone. This commit fix that UI issue, now only the previewed document if not selected will be moved. The preview will also be closed to emphasize the move. Task-4492621 Forward-Port-Of: odoo/enterprise#77762
Original PR description
Steps to reproduce: 1. Preview a document without selecting it. 2. Change the folder in the inspector. 3. The document is still in the current folder. 4. All the selected documents will be gone. This commit fix that UI issue, now only the previewed document if not selected will be moved. The preview will also be closed to emphasize the move. Task-4492621 Forward-Port-Of: odoo/enterprise#77762
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Original PR description
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
There are currently some elements in views that are not reachable on a deterministic way when those views are inherited. That means, to reach them, positional selectors need to be used (e.g. `last()`). That causes inherited views to get broken when there are small changes in element position. A good example of this is [1]: <div class="digital-stamp"> <span>Extra Info</span> </div> Which can't be filtered by: - Class, because there are several `<div>` elements with the
Original PR description
There are currently some elements in views that are not reachable on a deterministic way when those views are inherited. That means, to reach them, positional selectors need to be used (e.g. `last()`). That causes inherited views to get broken when there are small changes in element position.
A good example of this is [1]:
<div class="digital-stamp">
<span>Extra Info</span>
</div>
Which can't be filtered by:
- Class, because there are several `<div>` elements with the same class
- Text content, because when content is translated, selector will fail
To solve the above, this change provides names for several elements, to make possible/easier to reach them on a safely manner.
[1] https://github.com/odoo/enterprise/blob/d6346ef8/l10n_mx_edi/views/l10n_mx_edi_report_invoice.xml#L123
Forward-Port-Of: odoo/enterprise#76408
Forward-Port-Of: odoo/enterprise#63957Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
Original PR description
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
Original PR description
Before this commit: when triggering a followup reports on parent company, followup levels on both parent company and branches were triggered, meaning duplicated datas could be sent to customers. After this commit: Now only the followup on the current company is triggered, ignoring all the branches. task-4393081 Forward-Port-Of: odoo/enterprise#77954 Forward-Port-Of: odoo/enterprise#75572
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78295 Forward-Port-Of: odoo/enterprise#56896
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Sen
Original PR description
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- *…
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Send the request to terminal * Disconnect ethernet cable from the worldline terminal * Cancel the payment > Observation: After the timeout, two errors appear: 1: underfined:undefined (Bug) 2: Please check if your iot box is still connected. (Normal) Why the fix: ------------ This commit https://github.com/odoo/enterprise/commit/35a392c27e70ffb5f4a5d8ca32bf10c38d7f709c added one more error throwing other than `_onActionFail()` when sending requests. In our case since the error is due to a timeout, it will raise the `_onActionFail()` but also the `Promise.reject(e)`. We consider that the `_onActionFail()` is enough for all potential failure here. opw-4414175 Forward-Port-Of: odoo/enterprise#77606 Forward-Port-Of: odoo/enterprise#77555
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Original PR description
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Create _get_write_off_move_move_line_dict() method to allow extension Related to OCA/account-reconcile#761 @Tecnativa TT51885 --- This PR is actually the FW of: https://github.com/odoo/odoo/pull/188808 . That PR was changing things in community that were moved to enterprise in 17.0 Therefore, a new PR (this one) had to be opened. Forward-Port-Of: odoo/enterprise#77944
Original PR description
Create _get_write_off_move_move_line_dict() method to allow extension Related to OCA/account-reconcile#761 @Tecnativa TT51885 --- This PR is actually the FW of: https://github.com/odoo/odoo/pull/188808 . That PR was changing things in community that were moved to enterprise in 17.0 Therefore, a new PR (this one) had to be opened. Forward-Port-Of: odoo/enterprise#77944