Daily updates from Odoo
Friday, December 13, 2024
42 changes
8 changes
Miscellaneous changes
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Original PR description
We need to first check if active_ids exist and get usererror if there are no active_ids present. [Link to Runbot Error builds](https://runbot.odoo.com/web#id=74407&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190324
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Original PR description
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190494 Forward-Port-Of: odoo/odoo#190308
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues 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
Original PR description
In this commit we fix to two things: 1. For SEZ(intra state) with payment of `IGST`, the `IGST` on Intra used to be sent `False` for E-Invoice 2. For Overseas export, refund claimable is also used to be sent as `False` with same situation payable of `IGST` in case of export In this commit resolve the above issues 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#190151
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190212
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#190495 Forward-Port-Of: odoo/odoo#187838
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView 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#189811 Forward-Port-Of: odoo/odoo#188380
11 changes
Enhancements to existing features
The editor’s signature option is now available only in the Knowledge app instead of appearing across all editor-based areas. This keeps other apps cleaner and ensures the signature feature is shown only where it is intended to be used.
Original PR description
### Description of the issue/feature this PR addresses: - The signature command was categorized under `BASIC_BLOC` and accessible in all modules using the editor. ### Desired behavior after PR is merged: - The signature command is now categorized under `PERSONALIZATION`. - It is accessible only in the `Knowledge` module. ### Approach: - Removed `SignaturePlugin` from `MAIN_PLUGINS` and added it as extra plugin. - In `html_field`, the `signatureCommand` prop determines whether the signature command is displayed. - Passed `signatureCommand` as `true` from the Knowledge module to enable the signature command. community: https://github.com/odoo/odoo/pull/189554 task-4224624
Miscellaneous changes
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Problem --------- When launching the accounting tours, the don't actually run. This is because, when account_accountant is available, the App menu item name is different than when only Invoicing is available. Furthermore, the last steps of the tours where failing because the buttons had be renamed. Solution --------- When account_accountant is available, the app menu name should be `accountant.menu_accounting`, this is done using a patch of the `goToAccountMenu`. Furthemore, the button na
Original PR description
Problem --------- When launching the accounting tours, the don't actually run. This is because, when account_accountant is available, the App menu item name is different than when only Invoicing is available. Furthermore, the last steps of the tours where failing because the buttons had be renamed. Solution --------- When account_accountant is available, the app menu name should be `accountant.menu_accounting`, this is done using a patch of the `goToAccountMenu`. Furthemore, the button names for the last steps have been updated accordingly and a few extra steps have been added to generate a transaction. task-4309716 odoo/odoo/pull/188073 Forward-Port-Of: odoo/enterprise#74092
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forw
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#75561 Forward-Port-Of: odoo/enterprise#74912
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a
Original PR description
Steps to reproduce 1. Install account_followup and contacts 2. Have a branch company 3. Have a user with only the branch in its allowed companies (setting in the "Access rights" tab) 4. With this user, go to Contacts and click on any contact. ** Access Error: Access to unauthorized or invalid companies. ** Cause Commit https://github.com/odoo/enterprise/commit/fb59524a95b0f78112002d1e4d5ad3d6c301de7e modified the way company dependent fields work, which reveals an access error issue: a user may not have access to the root company of the currently selected company. Change Currently `.with_company(self.env.company.root_id.id)` has no effect, remove it to fix access error. opw-4368736 Forward-Port-Of: odoo/enterprise#75044
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are
Original PR description
Steps to Produce: - Configure Urban Piper in your POS. - Open the particular session. - Configure preparation display. - Place test order and accept in through POS. - Order gets placed in Kitchen display. - Done the order from Kitchen Display. - Order status does not get updated in POS without reloading it. Issue: - Order status was not updated when the order was done from the Kitchen display. Fix: - Initially, only draft orders were fetched from the server but now all orders are been fetched from server that belongs to urbanPiper. task- 4320193 Forward-Port-Of: odoo/enterprise#73884
In this commit: === - Added `pos_urban_piper.is_production_mode` parameter to toggle between production and integration environments. Forward-Port-Of: odoo/enterprise#75375
Original PR description
In this commit: === - Added `pos_urban_piper.is_production_mode` parameter to toggle between production and integration environments. Forward-Port-Of: odoo/enterprise#75375
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in. Current rate currency translation is still applied like before when CTA is not enabled on the report. task-4270102 ========================================================================== [IMP] account_reports: currency table: add te
Original PR description
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at…
The way we initially implemented CTA, it was using the current rate for all the balance sheet accounts. Instead, we actually want to consider the closing rate ; that is, the rate of each currency at the end of the fiscal year the operation was made in. Current rate currency translation is still applied like before when CTA is not enabled on the report. task-4270102 ========================================================================== [IMP] account_reports: currency table: add test case If a period containing some res.currency.rate object starts by some sub-period without any range, the average rate computation considered this sub-period as having a rate of 0. It's wrong; it should be 1. The fix itself is in the corresponding community commit ; this one adds a check ensuring this doesn't break again in the future. Fixing this also revealed an issue in the Trial Balance, where the initial balance column group was computed with different rates than the rest of the report, which is not what we want for this instance. We fix that by properly setting the period_key on all of its column groups and ensuring the initial balance dates have no impact on the currency table. Forward-Port-Of: odoo/enterprise#75140
### Steps to reproduce: - Install 'account_iso20022' - Accounting > Vendors > Payments - Create a new payment with "SEPA Credit Transfer" as the payment method, confirm - Duplicate it and confirm - Back to the payment list view, select the two and click "Create Batch Payment" - Validate and check the generated XML - `Ctry` is missing in the `PstlAdr` ### Cause: The ´_get_PstlAdr´ method in `account_journal_sepa_ct.py` is returning the whole `PstlAdr` element but the country code is mi
Original PR description
### Steps to reproduce: - Install 'account_iso20022' - Accounting > Vendors > Payments - Create a new payment with "SEPA Credit Transfer" as the payment method, confirm - Duplicate it and confirm - Back to the payment list view, select the two and click "Create Batch Payment" - Validate and check the generated XML - `Ctry` is missing in the `PstlAdr` ### Cause: The ´_get_PstlAdr´ method in `account_journal_sepa_ct.py` is returning the whole `PstlAdr` element but the country code is missing. Previously the country code was always added (https://github.com/odoo/enterprise/blob/saas-17.4/account_sepa/models/account_journal.py#L322-L329), this is no longer the case in this situation. ### Solution: Add the country to the list of fields to add. opw-4287100 Forward-Port-Of: odoo/enterprise#74596
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send
Original PR description
First we replaced the 'send' activity by the 'pay' activity. Since the 'pay' activity was inadequate for the FIDU /my/databases view (it's only created when there is tax to pay), we brought the 'send' activity back. But in order to see the 'pay' activity, the 'send' activity had to be marked as done & nobody knows how to do that. And what if the user wants to pay before sending? (to avoid fines) So in this PR, we create the 'send' and 'pay' acitivities at the same time. Those who want to send, send. And those who want to pay, pay. Task - TSB/BIB/CHKL/AYH discussion Forward-Port-Of: odoo/enterprise#75317 Forward-Port-Of: odoo/enterprise#74915
20 changes
Resolved issues and error corrections
The Discuss sidebar now visually de-emphasizes inactive conversations so the active chat remains easier to focus on. Unread conversations still stand out enough to be noticed, improving usability without changing functionality.
Original PR description
Discuss sidebar items are too catchy, which is distracting when the core part of Discuss app is the conversation itself. As much as possible, conversation should be very visible while other elements are slightly less visible. This problem is even more pronunced when the sidebar is compact, because the avatars in sidebar are next to avatars of conversation, which is even more distracting. This commit fixes the issue by reducing opacity slightly on non-active sidebar items. Conversation that are unread and unactive have an in-between opacity so they are more visible than other read and non-active conversations but still have reduced opacity so that this is less distracting than the conversation itself. Backport of https://github.com/odoo/odoo/pull/190071
The HTML editor now correctly enables the remove formatting button when any selected content includes formatting, even if other selected text is plain. This makes editing formatted content more predictable and prevents users from being blocked from clearing styles in mixed selections.
Original PR description
When the selection contains formatted nodes among unformatted nodes, the remove format toolbar button should be available. This is not the case currently because the `hasAnyFormat` method, which is used to determine whether the button should be disabled, checks if **every** node in the selection is formatted. This commit fixes the issue by checking if **any** node in the selection is formatted instead. task-4385246
Fixes an error that occurred when users clicked the “Same payment” link after duplicating a confirmed payment. The payment screen now opens the related business document correctly, preventing an unexpected interruption in accounting workflows.
Original PR description
In the payment view, he `x2many_buttons` widget on `duplicate_payment_ids` calls the `action_open_business_doc`, but this method is not implemented on `account.payment`. This was not not a problem before 01b87f1230beac0568f4e3b1b76e547909506892 since a payment was always linked to a move, therefore we were calling the method from `account.move`. With this commit, we implement the `action_open_business_doc` in `account.payment`. Step: - Create a payment and confirm - Duplicate it - Click on the 'Same payment' hyperlink -> Error: "The method 'action_open_business_doc' does not exist on the model 'account.payment'" opw-4363907
Fleet contract status changes now use the same internal actions whether they are triggered automatically or by date updates. This makes custom behavior for opening or closing contracts easier to maintain and reduces the risk of inconsistent contract handling.
Original PR description
Since there are two mechanism that changes the status of a contract (a cron and the write of a date), we have to override 2 different places when we want to add a behavior on closing or opening of contracts. As there are already functions (action_expire, ...) that exist and are use in the write part, we also use them in the cron, so we'll have only one place where we need to override it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Documents where opening a folder could fail after previewing a file, closing the preview, and switching views. Users can now continue navigating folders normally without encountering an error.
Original PR description
Steps to reproduce the traceback: - preview a file from the kanban view - close the preview - switch to list view - open a folder To Be: The folder should open correctly. Technical: The traceback happens because the 'getSelectedDocumentsElements' calls a querySelectorAll on the component root element without checking if it exists. Fixing the issue by making sure the component effectively have a root element before calling the method. Task-4373626
Miscellaneous changes
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Before this commit: We didn't allow passing of `IGST` tax rate while sending E-waybill json to government on an intra state invoice After this commit we allow sending `IGST` tax rate in E-waybill json because there few specific scenario where `IGST` is applicable on intra state transaction e.g. SEZ partner within the company state in this case `IGST` will be applicable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190557 Forward-Port-Of: odoo/odoo#190212
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
* STEP TO REPRODUCE: try to _message_log on a channel contain record link (an a tag with data-oe-model and data-oe-link) then click on it -> nothing happen * REASON: when _message_log in mail.channel, it will consider that message as a NotificationMessageView model and we do not have onClick for it unlike MessageView model * SOLUTION: implement onClick for NotificationMessageView just like MessageView 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#189811 Forward-Port-Of: odoo/odoo#188380
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190547 Forward-Port-Of: odoo/odoo#190308
Original PR description
Before this commit: In case an E-waybill is already generated we post a help message as log note on the invoice with URL that user can check that on the government portal, But whenever user links on the URL it give a error code of 404 In this commit we post the correct URL, and the user is re-directed on the correct page --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190547 Forward-Port-Of: odoo/odoo#190308
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write" behavior that commits the rating encoded in `<int:rate>`. So the record is already updated with the new value. Only then renders the feedback submit Form, where the user can change their preselected rating and leave a commentary before submitting it via a POST request. Over the last years email prov
Original PR description
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write"…
### Context: In its current form, the HTTP route using `/rate/<string:token>/<int:rate>`, that is used in URL links generated by emails asking for customer feedback, will have a "one-click write" behavior that commits the rating encoded in `<int:rate>`. So the record is already updated with the new value. Only then renders the feedback submit Form, where the user can change their preselected rating and leave a commentary before submitting it via a POST request. Over the last years email providers and third party services will preemptively crawl URL in emails to verify if they are "dangerous" (e.g. Microsoft's Safe link and Defender fatures). By doing so, the rating for the records will be set to the last clicked URL using the above HTTP route, without any input from a human user. It will be creating a number of false positive or negative ratings that do not represent the real satisfaction of the surveyed customer. ### Proposed solution: We are removing the implicit "one-click write" behavior of the route and favoring the Form submission expecting human input. This will increase the likelihood a given rating was the result of the customer clicking on the link and taking the time to leave a feedback, versus random inputs from URL bots. ### Future outlook: With the ever-changing landscape of URL crawler bots, trying to develop counter measures to identify and flag bot behavior is possible, but would add immense overhead and maintenance cost of the code for an arguably minor feature, i.e. the customer can rate the ticket by just clicking the picture in the email. Other methods to make these routes more resilient to URL crawlers might be revisited in the future, but for the short-term this seems like a sufficient solution to the unwanted behavior. OPW-3411799 OPW-4292166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190400 Forward-Port-Of: odoo/odoo#187373
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply
Original PR description
Steps to reproduce the issue: - go to currencies; - search for a rate with something else than a date; - it crashes. This happens because the currency rate model is searched with two fields, a date field (`name`) and a float field (`rate`). This crashes when converting the value to match against, because the value cannot be serialized in SQL both as a date and a float. What we do in such a case is to explicitly convert the value to the field's type. If the conversion fails, we simply ignore that part of the domain. opw-4278234 Forward-Port-Of: odoo/odoo#190495 Forward-Port-Of: odoo/odoo#187838
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
Original PR description
Add the support for the STORE_SLICE opcode in safe_eval, It looks like an oversight when support for python 3.12 was added. Some code that previously worked in python 3.11 doesn't work anymore on python 3.12 example : foo[:3] = [bar,bar,bar] Forward-Port-Of: odoo/odoo#187867
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from th
Original PR description
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string >…
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer. ### Fix: The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else. ### Note: This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue: 903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805 opw-4290818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189904 Forward-Port-Of: odoo/odoo#187413
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Original PR description
body_content is a better representation of what the email will actually look like when sent. task-4333657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190447 Forward-Port-Of: odoo/odoo#188803
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would not come through. This specifically happens when a lengthy operation is performed in the calls behind the "order" button, such as calling preparation printers. Example steps to reproduce 1. set up a clean DB with pos_restaurant installed 2. configure an epson printer as preparation printer 3.
Original PR description
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would…
Before this commit, when a user returns back, e.g. to the floor screen after clicking "order" but before the call to sendOrderInPreparationUpdateLastChange completed, the update to the order would not come through. This specifically happens when a lengthy operation is performed in the calls behind the "order" button, such as calling preparation printers. Example steps to reproduce 1. set up a clean DB with pos_restaurant installed 2. configure an epson printer as preparation printer 3. open the POS session 4. select a table and add some products 5. click on "order" and immediately click on "back" The order status is still in the "to be sent" state, while the printer effectively printed the order. You now have to get back to the table view and send the order changes again if you ever want to complete any payment for that order. It will then send it again to the preparation printer. The end result is inconsistencies between the pos session and the database in terms of data. In terms of business flows and operations, it results in multiple sends of the same order, which in turn could lead to losses e.g. due to wrong preparations/unneeded preparations. opw-4367939 opw-4246953 Forward-Port-Of: odoo/odoo#189749
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a fi
Original PR description
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input…
When preparing final outgoing email, partner email is normalized. We take their formatted email, which is their name and their normalized email. However email_to and email_cc are taken from input using 'email_split(_and_format)', which finds emails but do not format them. This leads to incoherent behavior as most emails are normalized as we generally always use partners, but not all. In this commit we now split, normalize and format email_to and email_cc in outgoing emails. This fixes a first issue where name are lost if a formatted email was entered in email_cc field. Only address was kept, now the name is correctly found and put back. This also fixes an issue for validated email detection, in order to compare normalized emails. This was introduced at odoo/odoo#185793 and may skip valid emails entered in email_to or email_cc. This commit backports a tool introduced at odoo/odoo@dd4709e579841672b0c2a57d5f2941f3ce770801 which aims at allowing a quick convert from a string holding emails to a list of nicely formatted emails, using normalize version of email addresses. This is the standard we use in most flows. Task-4376876 Followup of task-3704658 Forward-Port-Of: odoo/odoo#190531 Forward-Port-Of: odoo/odoo#189409
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Original PR description
Issue: Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated. Fix: Do nothing when click in this situation, only generate input when clicking on buttons. Forward-Port-Of: odoo/enterprise#75444
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what i
Original PR description
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default…
Steps to reproduce: - Install the planning module. - Open Gantt view in day scale. - Create a planning slot from 11am to 12pm for an employee whose working hours are 8-12 and 13-17 - The default hours will be shown as 13 to 12 Issue: - When an employee works two shifts for example 8-12 and 13-17, and we are creating a slot from 11-12, the slot timing will show as 13-12 instead of 8-12. Cause: - here is an example of how the planning slot will be calculated and what is miscalculation - When click on cell 9-10 the calculated hours <table><thead><tr><th>Cell</th><th>shift start time </th><th>shift end time </th></tr></thead><tbody><tr><td>9-10</td><td>|8 - 9| = 1<br>|13 - 9| = 4<br></td><td>|12 - 10| = 2<br>|17 - 10| = 5<br></td></tr><tr><td>minimum</td><td>8</td><td>12</td></tr></tbody></table> so that slot timining will be 8 - 12 - When click on cell 11-12 <table><tbody><tr><td>Cell</td><td>shift start time </td><td>shift end time </td></tr><tr><td>11-12</td><td>|8 - 11| = 3<br>|13 - 11| = 2<br></td><td>|12 - 12| = 0<br>|17 - 12| = 5<br></td></tr><tr><td>minimum</td><td>13</td><td>12</td></tr></tbody></table> So that the slot timining will be 13-12 which should not be possible Fix: - We previously relied on the ```_adjust_to_calendar``` method to calculate the resource's working hours. However since the working hour intervals are already computed using ```_work_intervals_batch```, we are removing the method call to reduce code duplication. Calculate the working hours using ```_work_intervals_batch``` and return the appropriate work intervals based on the resource's working calendar. task-3916687 Forward-Port-Of: odoo/enterprise#75594 Forward-Port-Of: odoo/enterprise#64961
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from th
Original PR description
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string >…
### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Warehouses - Create a second warehouse - Go to Inventory > Products > Products - In the search bar type `foo` string > Search Warehouse for `foo` - Click on any product Kandan record - Click on the Forecast smart button of the product #### > Traceback ### Cause of the issue: Thanks to the dummy `warehouse_id` field of the `product.template` model a `warehouse` context key can be set in the context from the search bar: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L685 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/views/product_views.xml#L78 This trick is notably used in order to take the warehouse into account in the computation of the various quantity fields associated to products by generating custom location domains: https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L136-L137 https://github.com/odoo/odoo/blob/a72763acfc4d83ae2aadad2e807547c5b1819002/addons/stock/models/product.py#L250-L255 However, since that context key was added via the search bar, it type might be: a string, an integerId or a list of either/both other types. (E.g. to create a list of a string and integer type and select a string and then type a string allowing you to find a real warehouse id that you can select after clicking on the dropdown arrow). Therefore, in order to be properly used, this context key needs to be parsed to be used properly as done in the `_get_domain_locations` for instance. However, the `warehouse` context key is used at many other places in the code, each time expecting a single integer id, and since the warehouse context key is not cleaned from one action to an other you are technically able to provide a string where the code is expecting a an integer. ### Fix: The proper fix of this use case would be to change the context key name used by the search view to only match flows expecting such a context. However, this change is not stable as it requires to modify a view and hence can't be applied before master (18.1). As such, in prior versions, we add a context parser for to extract a single integer id from the `warehouse` context key where it is used but unexpected to match something else. ### Note: This patch will improve other fixes and hopefully prevent yet unoticed error raised by this issue: 903d8beeea5d332e556ef81e231a3b8b4c51cd45 and afa7c6bf25c9de5fc0c878faa29e1cc35bc11805 Community: https://github.com/odoo/odoo/pull/187808 opw-4290818 X-original-commit: 856409a1fb35c6c49fe4c404931587a95d99d370 Forward-Port-Of: odoo/enterprise#75300 Forward-Port-Of: odoo/enterprise#74188
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forw
Original PR description
When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields. Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise). Forward-Port-Of: odoo/enterprise#75561 Forward-Port-Of: odoo/enterprise#74912
3 changes
Resolved issues and error corrections
This update fixes an issue where bank statement imports were not accurately capturing debited charges. Now, the system correctly includes these charges in the imported transaction amounts, ensuring more precise financial reporting. This improves the reliability of bank statement data within the Enterprise system.
Original PR description
Before this commit: Import a statement having transactions including debited charges in their total credited amount. In that case, the retrieved amount is incorrect, it does not include the charges. After this commit: The debited charges are retrieved and included in the amount. opw-3208721 Forward-Port-Of: odoo/enterprise#74962
This update resolves a stability issue in the consolidated balance report. Previously, an empty totals list could cause a crash. The fix ensures that the report only attempts to modify data when totals are present, preventing errors and improving reliability.
Original PR description
**[FIX] account_consolidation: handle empty totals when formatting account lines** When processing account lines, the totals list might be empty resulting in an IndexError when trying to set auditable to false on the last column, which leads to consolidated balance to crash. This fix just makes sure that modifying the column on this line is only done when the cols actually contains some data. opw-4205722
This update resolves an issue where the system incorrectly attempted to raise an error message when a bank account lacked a client code. The fix corrects a coding error that was passing multiple arguments to the `append` function, ensuring proper error handling and preventing the system from crashing.
Original PR description
An error occurs when the system try to raise an error message when a bank account has not client code. ```TypeError: list.append() takes no keyword arguments``` Currently in code [1] mistakenly provides multiple values via keyword arguments to the `append` method. which is incorrect. So instead of it, we need to change the formatting to pass a single argument as a string to resolve the error. Link [1]: https://github.com/odoo/enterprise/blob/07fae63e381dfa7a8035f67837f19d619600d434/l10n_jp_zengin/models/account_batch_payment.py#L77 Sentry-6128197646