Thursday, January 9, 2025
65 changes
10 changes
Resolved issues and error corrections
Material resources now show the expected wrench icon instead of an empty photo placeholder when selected in Planning forms. The update also improves icon and text alignment in resource selection fields, making the interface clearer and more polished for users.
Original PR description
Steps to reproduce: - Open planning app and click on New. - A form is opened and searched for a material resource in the Resource field ex. Crane - An empty photo icon is displayed in the selection bar. Issue: - An empty photo icon is being displayed instead of a wrench. Cause: - Many2XAutocomplete which adds an image in the many2one selection field is not modified to display - the wrench icon in the many2one_avatar_resource_field. Solution: - A similar modification is done in many2many_avatar_resource_field through class which extends Many2XAutocomplete which can be imported and added into components of many2one_avatar_resource_field. fix the alignment between of icon and text in many2many_avatar_resource. task-3801551
Miscellaneous changes
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_
Original PR description
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list…
Steps ----- - Have two companies A and B. - Activate Project Stages, and in the list of stages set the first one of the list as belonging to company A. - Create a project (from 'new' button in list view to be able to set a company at creation) belonging to company B (company B needs to be in the list of selected companies). - Save it: the project's company has changed to company A. Cause ----- If no stage is set on the project at creation, we default to the default stage provided by `_default_stage_id`, which is the first stage in sequence, regardless of its company. We then change the company of the project to match the stage's company, which overrides the stage set at creation. Change ----- If the project has a company set a creation, use the first stage without a company or with the same company as the project. This is done even if the user doesn't have multiple companies selected, since the `search` on `project.project.stage` can return a stage from another company than the one selected. opw-4290711 Forward-Port-Of: odoo/odoo#187635
22 changes
Enhancements to existing features
The signing request view was simplified by removing an unnecessary layout container. This minor cleanup helps keep the Sign interface easier to maintain without changing business workflows.
33 changes
Enhancements to existing features
Subscription invoice payment processing now uses a lighter database lock to avoid blocking related updates unnecessarily. This reduces the risk of deadlocks during automated subscription billing, improving reliability without changing user-facing workflows.
Original PR description
Before this commit, the transaction row was locked when payment was performed in the subscription invoice cron. Using `SELECT FOR UPDATE` locks the entire row, primary key included (id in our case). As a result, it could prevent insertion or update or other table refering to the id too. As it is not necessary and could trigger unnecessary deadlock, it is better to rely on `SELECT FOR NO KEY UPDATE` which allow the update of foreign keys. https://www.postgresql.org/docs/16/explicit-locking.html#LOCKING-ROWS See https://github.com/odoo/enterprise/pull/74078#discussion_r1873729342 taskid: 4391755
Versions -------- - 17.0+ Steps ----- 1. Download a VoIP provider like Skype or Linphone to open tel:* urls; 2. use a browser that supports this (FireFox works for me, but Chrome doesn't); 3. with Studio, edit the Sales Order form to add the customer phone; 4. create a new Sales Order with one order line; 5. save the form; 6. add a second line; 7. click on the phone number to start the VoIP app; 8. save the Sales Order form. Issue ----- The 2nd line is duplicated. Cause --
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Download a VoIP provider like Skype or Linphone to open tel:* urls; 2. use a browser that supports this (FireFox works for me, but Chrome doesn't); 3. with Studio, edit the Sales Order form to add the customer phone; 4. create a new Sales Order with one order line; 5. save the form; 6. add a second line; 7. click on the phone number to start the VoIP app; 8. save the Sales Order form. Issue ----- The 2nd line is duplicated. Cause ----- Starting VoIP initiates an "urgent" web save, saving the first time. Usually this only happens when leaving the page, so it doesn't clear the changes to be saved. In this scenario however, we remain on the page, and the changes are saved again when clicking the save button. Solution -------- Clear the saved changes if the urgent save succeeded. opw-4308954 Forward-Port-Of: odoo/odoo#192517
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the c
Original PR description
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the child company in `allowed_company_ids` from the context. The fix here is to: 1) When accessing the root company in order the get its currency, just access the currency of the child company, as it is the same. 2) Use sudo when accessing other fields from the root company. opw-4352595 Forward-Port-Of: odoo/odoo#192632
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
Original PR description
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
**Behaviour before PR:** In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`. **Behaviour after PR is merged:** Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that
Original PR description
**Behaviour before PR:** In website, in some snippets font-size of paragraph like elements is not displayed correctly in toolbar. This issue happens because in `getFontSizeDisplayValue` method if there is no font-size class applied to element then it will set the value of `--font-size-base` css variable which is `16px`. **Behaviour after PR is merged:** Now, `getFontSizeDisplayValue` method will set font-size using `getComputedStyle` if there is no font related class is applied to that element. task-4420329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191577
Steps to reproduce ================== - Install industry_fsm,web_studio - Go to Field Service - Switch to the calendar view - Open studio - Unset the color => fields[fieldMapping.color] is undefined Cause of the issue ================== We have a field that has the color attribute with a value of color. ```xml <field name="worksheet_template_id" attrs="{'invisible': [('worksheet_template_id', '=', False)]}" filters="1" color="color"/> ``` `shouldFetchColor` checks if th
Original PR description
Steps to reproduce
==================
- Install industry_fsm,web_studio
- Go to Field Service
- Switch to the calendar view
- Open studio
- Unset the color
=> fields[fieldMapping.color] is undefined
Cause of the issue
==================
We have a field that has the color attribute with a value of color.
```xml
<field name="worksheet_template_id" attrs="{'invisible': [('worksheet_template_id', '=', False)]}" filters="1" color="color"/>
```
`shouldFetchColor` checks if the filter color is the same one as the calendar record color.
Solution
========
Since it's possible to have a color filter without a record color, we should fetch the filter colors in that case.
opw-4443497
Forward-Port-Of: odoo/odoo#192841
Forward-Port-Of: odoo/odoo#192334Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#191972
Original PR description
Steps: === - Open a POS shop. - Create an order, select a customer, and validate it. Issue: === - The generated receipt did not include customer name and phone details. Cause: === - Customer details were not being passed correctly to the receipt template. Fix: === - Updated the function for setting customer details to correctly include in the receipt. Task- 4431623 Forward-Port-Of: odoo/odoo#191972
**Current behavior before PR:** prior to this PR fa-plane icon does not displayed after user comes online/offline/away while on leave without any reload. **Desired behavior after PR is merged:** now fa-plane icon is displayed with respective color of im_status without any reload task-4237384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184471
Original PR description
**Current behavior before PR:** prior to this PR fa-plane icon does not displayed after user comes online/offline/away while on leave without any reload. **Desired behavior after PR is merged:** now fa-plane icon is displayed with respective color of im_status without any reload task-4237384 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184471
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
Original PR description
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
Miscellaneous changes
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` i
Original PR description
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the…
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` is properly set during mandate creation, aligning it with the payment link's associated company and preventing unexpected behavior. Steps: 1) Configure two companies with accounting setups. 2) Open the Payment Providers menu. 3) Select SEPA, activate test mode, and ensure it is published. 4) Duplicate the SEPA payment provider, set the company_id to the second company, activate test mode, and ensure it is published. 5) Go to any sales order in the first company, generate a payment link, open it, and select SEPA. Enter any fake IBAN — it will process successfully. 6) Switch to the second company and repeat step 5. You will encounter an error message because the mandate is incorrectly assigned to the first company, preventing payment completion. Forward-Port-Of: odoo/enterprise#76705
Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76780 Forward-Port-Of: odoo/enterprise#76511
Original PR description
Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76780 Forward-Port-Of: odoo/enterprise#76511
partial payments An user may receive several partial payments for invoices/bills. These payments could be grouped in a batch and reconciled with a single statement line. However this flow is currently not working because the bank reconciliation fails Steps to reproduce: - Create 2 invoice and register a partial payment for each one - Select the 2 payments create a batch - Create a new statement with the sum of the payment amounts - Reconcile the statement with the created batch Issue:
Original PR description
partial payments An user may receive several partial payments for invoices/bills. These payments could be grouped in a batch and reconciled with a single statement line. However this flow is…
partial payments An user may receive several partial payments for invoices/bills. These payments could be grouped in a batch and reconciled with a single statement line. However this flow is currently not working because the bank reconciliation fails Steps to reproduce: - Create 2 invoice and register a partial payment for each one - Select the 2 payments create a batch - Create a new statement with the sum of the payment amounts - Reconcile the statement with the created batch Issue: An error will block the validation ``` The move (BNK1/2024/00011) is not balanced. The total of debits equals $ 510.60 and the total of credits equals $ 100.00. You might want to specify a default account on journal "Bank" to automatically balance each move. ``` This occurs because the system is taking the amount to reconcile from the invoice, instead of the payment, so it will try to reconcile the full amount. opw-4379673 Forward-Port-Of: odoo/enterprise#76121
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create an invoice with a Mexican partner and confirm - Create a Payment - In the invoice form view, go to the "CFDI" page - Click "Update CFDI" - The payment appears, click on "Show" - The button "Request Cancel" does nothing ### Cause: the method `button_request_cancel` on move is called from the payment model but does not return anything: ``` def button_request_cancel(self): self.move_id.button_requ
Original PR description
### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create an invoice with a Mexican partner and confirm
- Create a Payment
- In the invoice form view, go to the "CFDI" page
- Click "Update CFDI"
- The payment appears, click on "Show"
- The button "Request Cancel" does nothing
### Cause:
the method `button_request_cancel` on move is called from the payment model but does not return anything:
```
def button_request_cancel(self):
self.move_id.button_request_cancel()
```
But the `button_request_cancel` from `l10n_mx_edi` is returning a wizard that is never caught.
### Solution:
When clicking the "Request cancel" button, the method `action_request_cancel` is called instead of `action_cancel` which will dispatch the request depending on the type of move being cancelled.
opw-4332483
Forward-Port-Of: odoo/enterprise#76027
Forward-Port-Of: odoo/enterprise#75714In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it. In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown: ```javascript _onModalShown: function (ev) { $(ev.target).addClass('modal_shown'); }, ``` This fix add classes in triggers
Original PR description
In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it.
In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown:
```javascript
_onModalShown: function (ev) {
$(ev.target).addClass('modal_shown');
},
```
This fix add classes in triggers to ensure modal is shown before continuing the tour.
Forward-Port-Of: odoo/enterprise#76605When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Original PR description
When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Since the Select owl componenent is used to display the benefits values, the 'options' of the select are displayed alphabetically. It is caused by the default value to 'true' for the autoSort attribute of the component. As we give the data in a specific order to the select in salary cofigurator we don't want the JS to re-order it. e.g.: the cars are sorted by cost and we don't wan't it in the alphabetical order. Forward-Port-Of: odoo/enterprise#76642
Original PR description
Since the Select owl componenent is used to display the benefits values, the 'options' of the select are displayed alphabetically. It is caused by the default value to 'true' for the autoSort attribute of the component. As we give the data in a specific order to the select in salary cofigurator we don't want the JS to re-order it. e.g.: the cars are sorted by cost and we don't wan't it in the alphabetical order. Forward-Port-Of: odoo/enterprise#76642
In GanttModel, we markup html values like it is done in the util function parseServerValue so that is it now possible to use t-out on html field values in the gantt popovers (and possibly elsewhere) and have correct results. Task ID: 4382205 Forward-Port-Of: odoo/enterprise#76665 Forward-Port-Of: odoo/enterprise#76530
Original PR description
In GanttModel, we markup html values like it is done in the util function parseServerValue so that is it now possible to use t-out on html field values in the gantt popovers (and possibly elsewhere) and have correct results. Task ID: 4382205 Forward-Port-Of: odoo/enterprise#76665 Forward-Port-Of: odoo/enterprise#76530
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Original PR description
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Related to https://github.com/odoo/odoo/pull/187430 Forward-Port-Of: odoo/enterprise#74818 Forward-Port-Of: odoo/enterprise#73927
Original PR description
Related to https://github.com/odoo/odoo/pull/187430 Forward-Port-Of: odoo/enterprise#74818 Forward-Port-Of: odoo/enterprise#73927
Before this commit, fields that were always invisible (with an `invisible` attribute equals to True|1) were not listed in the Sidebar's "Existing Fields", and were not available for drag/drop. This was rather impractical as such field may be in the arch just to have their data loaded, not really displayed. Moreover, since odoo/odoo@6f06420e4a9443c52dc0cb427f8f55eb4aecabce, fields may be added in the view automatically based on whether their value will be used in some condition or context else
Original PR description
Before this commit, fields that were always invisible (with an `invisible` attribute equals to True|1) were not listed in the Sidebar's "Existing Fields", and were not available for drag/drop. This was rather impractical as such field may be in the arch just to have their data loaded, not really displayed. Moreover, since odoo/odoo@6f06420e4a9443c52dc0cb427f8f55eb4aecabce, fields may be added in the view automatically based on whether their value will be used in some condition or context elsewhere in the view. After this commit, always invisible fields are always proposed for addition in the view. opw-4450351 Forward-Port-Of: odoo/enterprise#76677 Forward-Port-Of: odoo/enterprise#76608
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76
Original PR description
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76694
Steps: - Have 2 or more companies, select both in company selector - Go to Cash Flow Statement report -> Traceback: `TypeError: '<' not supported between instances of 'str' and 'NoneType'` Cause: https://github.com/odoo/enterprise/blob/0dad52c1371f2daca50775d72571a0eac768ac03/account_reports/models/account_cash_flow_report.py#L228 is equal to `SQL('("account_move_line__account_id"."code_store"->%s->>0)::VARCHAR', '<self.env.company.id>')` therefore the account code for accounts that
Original PR description
Steps:
- Have 2 or more companies, select both in company selector
- Go to Cash Flow Statement report
-> Traceback: `TypeError: '<' not supported between instances of 'str' and 'NoneType'`
Cause:
https://github.com/odoo/enterprise/blob/0dad52c1371f2daca50775d72571a0eac768ac03/account_reports/models/account_cash_flow_report.py#L228
is equal to `SQL('("account_move_line__account_id"."code_store"->%s->>0)::VARCHAR', '<self.env.company.id>')` therefore the account code
for accounts that are not from `self.env.company` are set to None in the data dict
Fix:
Adding a default value set to '' and reversing the order allowing to
keep the accounts from the selected company first.
opw-4367588
Forward-Port-Of: odoo/enterprise#75892Purpose: -------- The comments popover is not displayed when the computed popover top value is "0". This issue arises from incorrectly using this value as a boolean condition, whereas "0" is an acceptable top value (= top of the body). To fix this issue, we now check if the popover's top is undefined instead of using it as a boolean. Task-4461321 Forward-Port-Of: odoo/enterprise#76703
Original PR description
Purpose: -------- The comments popover is not displayed when the computed popover top value is "0". This issue arises from incorrectly using this value as a boolean condition, whereas "0" is an acceptable top value (= top of the body). To fix this issue, we now check if the popover's top is undefined instead of using it as a boolean. Task-4461321 Forward-Port-Of: odoo/enterprise#76703
### Steps to reproduce the issue: - Employee > open your favorite employee > HR Settings tab - Add a Badge Id say: 111 - Go to the shopfloor > extends the employee panel on the left - Scan the badge of your employee #### Expected behavior: The corresponding employee is added to the employee panel on the left and is set as the session owner. If you had clicked on the `+ Add operator` button before the scan, the dialog should be closed. #### Current behavior: TypeError: Cannot re
Original PR description
### Steps to reproduce the issue: - Employee > open your favorite employee > HR Settings tab - Add a Badge Id say: 111 - Go to the shopfloor > extends the employee panel on the left - Scan the badge…
### Steps to reproduce the issue: - Employee > open your favorite employee > HR Settings tab - Add a Badge Id say: 111 - Go to the shopfloor > extends the employee panel on the left - Scan the badge of your employee #### Expected behavior: The corresponding employee is added to the employee panel on the left and is set as the session owner. If you had clicked on the `+ Add operator` button before the scan, the dialog should be closed. #### Current behavior: TypeError: Cannot read properties of undefined (reading 'isShown') at `MrpDisplay._onBarcodeScanned` ### Cause of the issue: Once the scanned barcode is parsed and match a given employee in the `_onBarcodeScanned`, this call checks that a `SelectionPopup` is shown (representing the search dialog) and if so close it: https://github.com/odoo/enterprise/blob/e6bb5d2dcd1042ae6269487056babceca34b8655/mrp_workorder/static/src/mrp_display/mrp_display.js#L170-L177 Then, the session owner is set to the scanned employee. However, the `SelectionPopup` has been removed in saas-17.3 by Commit 209b0840df4d3de184dcba6cbc09539ec191a43a: https://github.com/odoo/enterprise/pull/56927/commits/209b0840df4d3de184dcba6cbc09539ec191a43a#diff-119404910b34efb326dbe84735b8ca63c16391841da9a7a85e5f61f790b25bd6L26-L31 and has been replaced by a regular dialog of the dialogService. It should therefore be closed in a similar way to how its done in the `selectEmployee` of the `useConnectedEmployee`: https://github.com/odoo/enterprise/blob/e6bb5d2dcd1042ae6269487056babceca34b8655/mrp_workorder/static/src/mrp_display/hooks/employee_hooks.js#L76 opw-4405585 --- Forward-Port-Of: odoo/enterprise#76361 Forward-Port-Of: odoo/enterprise#75820
Excluding counbtries on an appointment type should not lead to a 404 page when directly given the appointment link (even wihtout invite). Now the countries excluded are used to not display these appointments when necessary but they can still be reached with the direct link. task-4456488 Forward-Port-Of: odoo/enterprise#76674
Original PR description
Excluding counbtries on an appointment type should not lead to a 404 page when directly given the appointment link (even wihtout invite). Now the countries excluded are used to not display these appointments when necessary but they can still be reached with the direct link. task-4456488 Forward-Port-Of: odoo/enterprise#76674
Versions: ------------- 16.0 Steps to Reproduce: ---------------------------- 1. Open the Sign app. 2. Switch to the kanban view of sign templates. 3. Upload a document without adding any sign items. 4. Switch to the list view and open the template. 5. In the form view, go to the "Fields" notebook tab. 6. Add 2-3 sign items, then go back to the kanban view. 7. Reopen the template. Issue: --------- An error occurs when trying to sign the template. Cause: ---------- When a
Original PR description
Versions: ------------- 16.0 Steps to Reproduce: ---------------------------- 1. Open the Sign app. 2. Switch to the kanban view of sign templates. 3. Upload a document without adding any sign items. 4. Switch to the list view and open the template. 5. In the form view, go to the "Fields" notebook tab. 6. Add 2-3 sign items, then go back to the kanban view. 7. Reopen the template. Issue: --------- An error occurs when trying to sign the template. Cause: ---------- When adding sign items in the form view, other required fields are left empty. These missing values are needed to properly render the items in the PDF iframe. Solution: ------------ Make the sign items in the "Fields" notebook read-only. task-4212762 Forward-Port-Of: odoo/enterprise#71017
An error occurs while preparing monster data because in code mistakenly uses the attribute name 'is_flexible_hours' instead of the correct attribute name 'flexible_hours' to check the flexible hours of the resource calendar. `AttributeError: 'resource.calendar' object has no attribute 'is_flexible_hours'` To resolve this issue, Give a valid attribute name 'flexible_hours' instead of 'is_flexible_hours'. Sentry-6150854320 Forward-Port-Of: odoo/enterprise#75730
Original PR description
An error occurs while preparing monster data because in code mistakenly uses the attribute name 'is_flexible_hours' instead of the correct attribute name 'flexible_hours' to check the flexible hours of the resource calendar. `AttributeError: 'resource.calendar' object has no attribute 'is_flexible_hours'` To resolve this issue, Give a valid attribute name 'flexible_hours' instead of 'is_flexible_hours'. Sentry-6150854320 Forward-Port-Of: odoo/enterprise#75730
Steps to reproduce: 1. Install l10n_uk_reports_cis 2. Open a new bill 3. Set the 20% G tax on a new line. 4. Save without assigning a partner. 5. A traceback is raised. --- Description of the issue this commit addresses: In the l10n_uk_reports_cis module, a tax validation system is implemented that reaches into move.partner_id to check the chosen taxes validity. This causes an issue when the move doesn't have a partner yet, raising a traceback. --- Desired behavior after th
Original PR description
Steps to reproduce: 1. Install l10n_uk_reports_cis 2. Open a new bill 3. Set the 20% G tax on a new line. 4. Save without assigning a partner. 5. A traceback is raised. --- Description of the issue this commit addresses: In the l10n_uk_reports_cis module, a tax validation system is implemented that reaches into move.partner_id to check the chosen taxes validity. This causes an issue when the move doesn't have a partner yet, raising a traceback. --- Desired behavior after this commit is merged: No traceback is raised. --- Note on the fix: An additionnal check verifying the move has a partner is done before reaching into its values. The error happens inside the lambda line 20 and is **not** modified in the PR, the next line is modified to remove the `move.partner_id and ` that became redundant with the ` or not move.partner_id` condition added to the initial `if`. --- opw-4365356 Forward-Port-Of: odoo/enterprise#76527
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551
Original PR description
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551 Forward-Port-Of: odoo/enterprise#76144 Forward-Port-Of: odoo/enterprise#58817
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695
Original PR description
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695
Resolved issues and error corrections
Discuss call notifications are now only sent while a call is active. This prevents stray peer-to-peer notifications after a call has ended, reducing confusing or unnecessary communication behavior for users.
Original PR description
Before this commit, a race condition could allow attempts to send peer notification to go through despite not having a call. This could happen if a `_busNotify()` call follows a promise that is resolved after the end of a call. This commit fixes this issue by ensuring that notifications can only be sent when a call is active.
Fixes a live chat chatbot issue where a visitor's selected answer could briefly fail to appear correctly after being posted. This improves reliability in chatbot conversations and reduces flicker or inconsistent message display for website visitors.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/192076 PR above fixes issues regarding question-answer step of chatbot: to detect which answer was picked, it was comparing item selected text content…
Follow-up of https://github.com/odoo/odoo/pull/192076 PR above fixes issues regarding question-answer step of chatbot: to detect which answer was picked, it was comparing item selected text content with each possible answers. This worked as long as each possible answer had mutually exclusive text content. If one proposition had X and another had no X, one option could be unreachable. To solve the issue, PR above tracks the `select_answer_id`. When the user posts a message, the selected answer is returned in RPC response as store data. The selected answer is put in the question message of chatbot. This means the `message_post` store data contains 2 messages. The implementation of message_post in JS is naive and assumes the data contains only 1 message. Therefore when inserting the store data, it was assuming the 1st inserted message in store was the newly posted message. However in this particular case, the 1st inserted message was the question message of chatbot, not the user answer message. As a result, the test `test_complete_chatbot_flow_ui` had the following non-deterministic issue because of this: ``` Failed to find 1 of ".o-mail-Message" inside a specific target with text "I'd like to buy the software" (as parent). Found 0 instead. ``` This commit fixes the issue by putting the message_post message (the answer of user) before the question message of chatbot. This is the chosen fix as this is minimal. The destruct of store.insert() in message_post is too naive and should be changed by something more robust in the future. Note that this problem was not present in practice: the visitor message was visible but with minimal flicker. This is because the bus notification was adjusting the UI from the erroneous message_post result. runbot-111747
This fixes an error that occurred when multiple stock lot records were created at once through external integrations. Businesses using automated inventory workflows can now create batches of lot records reliably without running into a missing argument failure.
Original PR description
Before this commit: creating stock lot records (multi) via the xml.rpc resulted in a bug: missing argument 'vals_list'. After this commit: It is possible to create multiple stock lot records without this bug --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Self-ordering now sends the assigned stand number to the server when an order is meant to be served at a table. This helps staff identify where to deliver orders and prevents missing location details in the point-of-sale flow.
Original PR description
Before this commit, if the order was set to be served at a table, the assigned stand number was not sent to the server because the draft order was sent to the server before opening the stand number page. opw-4457394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated website editor test that could fail depending on timing when switching languages. The change helps keep quality checks stable, reducing false failures during development and releases.
Original PR description
In this commit, we fix the tour snippet_translation_changing_lang. The problem is that we don't wait for the DOM to be re-rendered before clicking on the dropdown to open the editing dropdown. So, if we click before the DOM is re-rendered, it also re-renders the dropdown menu and it disappears. So depending on the execution speed of the tour, it may fail. This commit fixes this behavior. 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
Starting or resuming a timer in the timesheet grid now correctly shows which row has the active timer, including after refreshing the page. This helps users see their current tracked work at a glance and avoids confusion when recording time.
Original PR description
Before this commit, when the user starts a new timer on the grid view and a timesheet is created, the timer is not marked as running on the row contained the project. Same issue when a timer is running and the user refreshes the page. This commit adds the needed data to make sure the grid view finds which row has the timer running.
The sales external tax test now clears pricelist settings before running so expected prices stay consistent. This prevents false test failures when a pricelist would otherwise change product values during the portal tour.
Original PR description
Since #76586 the tour checks for exact values, if a pricelist happens to apply, then the product value will be altered and not match expectations. Reset pricelists to ensure consistent execution environment.
Documents can no longer be saved after renaming without a valid name. This prevents unnamed documents from displaying as “False” and helps users catch the issue immediately with a clear save warning.
Original PR description
When we rename any doc without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4367684
Fixes an issue where the Trial Balance could not display additional balance-related columns after a performance change in version 18.0. This helps users see the expected financial figures without losing the speed improvements from the earlier update.
Original PR description
Since 18.0[^1], the ending balance is done by summing the values fetched instead of querying the database again. While this is a great performance gain, it also means that we can't get other values like the balance. Note that the Trial Balance has been refactored in 18.1[^2], so a simple fix is enough. opw-4435450 [^1]: e598fcb48b5e4f0126406a4008f175a88528ba85 [^2]: a7e1ec20e07efc39bca44d3ae613a54770175273
Code cleanup and technical improvements
This update reorganizes how default project values are set for field service tasks. It keeps the behavior easier to maintain while reducing the risk of inconsistent task setup in future changes.
Miscellaneous changes
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
Original PR description
We improve the image reliability by: - Improving handlers cleanup (we only removed os-specific handlers but downloaded all), - Forcing Odoo service to restart after checkout, even if an error occurred. Task: 4433461 Forward-Port-Of: odoo/odoo#191928
In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the Taxable Supply Date (for l10n_cz / CZ) or Delivery Date (for l10n_hu_edi / HU). The way this was done conflicts with a change in 17.3: Since then we store and display the currency rate on invoices (See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details). The rate for each line shoul
Original PR description
In modules l10n_cz and l10n_hu_edi the currency rate computation on the invoice lines was changed. Instead of using the standard date (i.e. Invoice Date) for the currency conversion we use the…
In modules l10n_cz and l10n_hu_edi the currency rate computation on
the invoice lines was changed. Instead of using the standard date
(i.e. Invoice Date) for the currency conversion we use the
Taxable Supply Date (for l10n_cz / CZ) or Delivery Date
(for l10n_hu_edi / HU).
The way this was done conflicts with a change in 17.3:
Since then we store and display the currency rate on invoices
(See commit bedffa80beb61c134e8f476ef2ca71f2bd66f554 for more details).
The rate for each line should then just be taken from the rate stored on the move.
Currently the rate on the invoice is still computed with the standard date (invoice date)
in any case.
So e.g. with l10n_cz installed it can happen happen that the lines of a CZ invoice
- compute the currency rate individually "themselves" instead of taking it from the invoice
(which is one of the things the change in 17.3 wanted to prevent)
- use a different different date for the currency rate conversion than the invoice
(in case the Taxable Supply Date is set)
I.e. the rate stored and displayed on the invoice may have nothing to do with the rate
that was actually used for the conversion.
Example that goes wrong currently for l10n_cz on runbot
1. Install l10n_cz
2. Select CZ Company
3. Ensure the USD currency is as follows:
- Starting on 2024-12-01 there is 10 units per CZK rate
- There is no other currency rate defined
4. Create an invoice
- in USD
- with invoice date 2024-11-01
- Taxable Supply Date 2024-12-01
- a single invoice line with price 100 and no taxes
5. The invoice displays:
- "1 CZK = 1.000000 USD" (Since we ignore the Taxable Supply Date)
- total: 100 USD
6. The "Journal Items" tab displays only 10 CZK total.
(Since we use the Taxable Supply Date for the actual conversion)
Related commits: The currency rate computations for move lines were overridden
in commits e3bac6461500d34425697eed5a263c605f6f9de5 (l10n_cz) and
b1e07d27da27aad86049c8eae42e1803cf24bd3f (l10n_hu_edi) respectively.
This commit fixes the currency rate computation for these localizations:
We revert the changes to the currency rate computation on the lines and
adapt the date used for the currency rate computation on the invoice.
The invoice then displays the correct rate and the lines just take the (correct)
rate from the invoice.
Further for l10n_cz the taxable supply date is hidden on non-invoices and
ignored for currency computations on non-invoices.
task-4367605
related upgrade PR: https://github.com/odoo/upgrade/pull/6853
Forward-Port-Of: odoo/odoo#189023* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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
* STEP TO REPRODUCE: install event (only CE code), go to Registration Desk then hit button < to go back -> The system warning there are no gantt view * Solution: using existing action `action_event_view` with `clearBreacrumbs` which will help display the menu correctly 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#191376 Forward-Port-Of: odoo/odoo#191295
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192858 Forward-Port-Of: odoo/odoo#191538
Original PR description
If you create a pricelist rule with a discount that has a valid date range, that discount is only applied if the SO was created in that range. Even if it is confirmed within the valid date range. Fix: For website_sale orders we consider the date to be the current time when computing the price. opw-4375643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192858 Forward-Port-Of: odoo/odoo#191538
Steps to reproduce: -------------------- - Go my account - Click on tasks - Search Issue: ------ The client when searching without selecting a scope cannot search. This is direct incidence of the [changes](https://github.com/odoo/odoo/commit/2a0ff2ae7bd46666) Since the default search_in was set to content that has been removed. Fix: --- Setting the search_in defaulting to name. (Name is the closest to what content did) opw-4396491 --- I confirm I have signed the CLA
Original PR description
Steps to reproduce: -------------------- - Go my account - Click on tasks - Search Issue: ------ The client when searching without selecting a scope cannot search. This is direct incidence of the [changes](https://github.com/odoo/odoo/commit/2a0ff2ae7bd46666) Since the default search_in was set to content that has been removed. Fix: --- Setting the search_in defaulting to name. (Name is the closest to what content did) opw-4396491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191150
The unit tests were having a dependency from account_reports module which is not a dependency of the l10n_jo_edi module nor even a community module. This commit removes this dependency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192893
Original PR description
The unit tests were having a dependency from account_reports module which is not a dependency of the l10n_jo_edi module nor even a community module. This commit removes this dependency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192893
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
Original PR description
As we updated the camera interface's logic, we need to add the new library to the IoT Box image. We also removed the python lib patching part, as it was only used by the old camera detection logic. Enterprise PR: [https://github.com/odoo/enterprise/pull/76511](https://github.com/odoo/enterprise/pull/76511) Task: 4432584 Forward-Port-Of: odoo/odoo#192449
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default C
Original PR description
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines. …
**Issue:** Accountants cannot create products through Customer Invoice or Vendor Bill product lines.  **Expected:** Accountants should be allowed to manage the products database. **Steps to reproduce:** - Activate Invoicing app; - Configure a branch to the company; - Create a user with an accounting `Accountant` role and set the branch company as only entry in Allowed Companies and as Default Company;  - Log in as that new user; - Try create a new product through a Customer Invoice or a Vendor Bill. **Cause:** The `Accountant` role itself has no right on products. **Fix:** Reset a previously removed (february 2023 (saas-16.2) odoo/odoo@512574861691f425ec6a17f20fe4b586bb88a299) access right on `product_template` for group `group_account_manager`.  **Note:** This PR replaces https://github.com/odoo/enterprise/pull/75453 after discussion with reviewer. opw-4293151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192445 Forward-Port-Of: odoo/odoo#190360
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#1
Original PR description
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#191978
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192489
Original PR description
In journal items, when grouping by 'Internal Group', a traceback appears due to referencing a non-existent table `account_account` as it has been joined with `account_move_line`. This commit ensures the referenced table is correctly updated in the case of joins. opw-4405281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192489
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` i
Original PR description
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the…
Behavior Before the Commit: When generating a new payment link, the system creates a new mandate without explicitly setting the `company_id`. As a result, the default company (`company_id` of the public user, `user_id = 4`) is assigned, which may not match the intended company if the payment is being processed for a company other than the default one. This mismatch between the journal's company and the mandate's `company_id` prevents the payment from being completed. Fix: The `company_id` is properly set during mandate creation, aligning it with the payment link's associated company and preventing unexpected behavior. Steps: 1) Configure two companies with accounting setups. 2) Open the Payment Providers menu. 3) Select SEPA, activate test mode, and ensure it is published. 4) Duplicate the SEPA payment provider, set the company_id to the second company, activate test mode, and ensure it is published. 5) Go to any sales order in the first company, generate a payment link, open it, and select SEPA. Enter any fake IBAN — it will process successfully. 6) Switch to the second company and repeat step 5. You will encounter an error message because the mandate is incorrectly assigned to the first company, preventing payment completion. Forward-Port-Of: odoo/enterprise#76705
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transaction
Original PR description
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery…
Currently, the cron method "_create_recurring_invoice" handles the invoices by batch of 30. Each batch is done in its own cron run and each invoice is committed individually. However, the delivery creations handled in _post_invoice_hook are all done at the end of the last batch, without any commit. If the database has a lot of invoices to generate (ex: ~200), it would take a few minutes before the delivery creations to start. This is enough time for the CRON "payment: post-process transactions" to start and handle all the invoices & payments created by "_create_recurring_invoice". The 2 CRON were then likely to create SerializationFailure due to a concurrent update. With this commit, each batch creates its own deliveries before triggering the next batch. If the delivery creations do fail: - The error is caught as to not prevent the next batch from being triggered. - An exception activity is created on the subscription to notify the customer about the error. - A contextual action is available to manually trigger the delivery. OPW-4319019 --- When the delivery creation failed, you can easily spot it on the list view thanks to the activity warning:  --- ## Example log ``` 2024-11-14 07:48:53,757 96554 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (30.353s). 2024-11-14 07:58:26,142 96886 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 07:58:57,145 96886 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (31.003s). 2024-11-14 08:05:51,910 97204 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:06:46,734 97204 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (54.823s). 2024-11-14 08:06:53,143 97262 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:07:46,207 97262 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (53.064s). 2024-11-14 08:07:55,496 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:08:30,928 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:08:44,957 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `Sale Subscription: generate recurring invoices and payments` (49.461s). 2024-11-14 08:08:50,945 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `Sale Subscription: generate recurring invoices and payments`. 2024-11-14 08:09:18,543 97300 ERROR customer-database odoo.addons.base.models.ir_cron: Call from cron Sale Subscription: generate recurring invoices and payments for server action #705 failed in Job #10 2024-11-14 08:15:52,854 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (441.926s). 2024-11-14 08:18:31,161 97300 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. 2024-11-14 08:21:16,823 97300 INFO customer-database odoo.addons.base.models.ir_cron: Job done: `payment: post-process transactions` (165.662s). 2024-11-14 08:28:31,865 99066 INFO customer-database odoo.addons.base.models.ir_cron: Starting job `payment: post-process transactions`. ``` - At the beginning: `payment: post-process transactions` take ~30 secs - Then, `Sale Subscription: generate recurring invoices and payments` runs a few times (as expected). - `payment: post-process transactions` re-runs, and it takes 441.926. During this time, `Sale Subscription: generate recurring invoices and payments` starts and failed. --- ## A few points of information/discussion: - The SerializationFailure is systematic on the customer database, who has ~200 subscriptions invoiced each day. - The added action "Subscription: Generate delivery" is optional, I am amenable to remove it from this PR, but we would just block the customer with undelivered stock. - In master, it would be better to automatically detect the deliveries not done and re-generate each day. However, I was unable to find a proper way to do it without adding a field or changing the behavior of an existing one. - I originally wanted to create to add a button to the form view like "Create Delivery", however, like above I was unable to properly detect undelivered subscriptions. - The exception activity does not directly notify the users via discuss, do you think I should add the option? - I did not (yet) created tests for this error. To properly do so, I would need to reproduce a SerializationFailure which I'm unsure of how to do without doing commits. I could simply fake it by overwriting the `_action_launch_stock_rule` to raise an Error... TBD Forward-Port-Of: odoo/enterprise#75402 Forward-Port-Of: odoo/enterprise#73911
Bug === When posting on Instagram, it will download the image from the URL gave to the API, this process can be sometimes slower than excepted in d2d5ddcdb1613a4f83a2d90e02e2856f87cb5c05, and so we increase the timeout of the requests. Other API calls can also take more times than excepted, so we also increase the other timeouts. Task-3109395 Backport of https://github.com/odoo/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4213307 Forward-Port-Of: odoo/enterprise#
Original PR description
Bug === When posting on Instagram, it will download the image from the URL gave to the API, this process can be sometimes slower than excepted in d2d5ddcdb1613a4f83a2d90e02e2856f87cb5c05, and so we increase the timeout of the requests. Other API calls can also take more times than excepted, so we also increase the other timeouts. Task-3109395 Backport of https://github.com/odoo/enterprise/commit/50762761a59c1dbc41c43540d504b1d3f55626dd opw-4213307 Forward-Port-Of: odoo/enterprise#76325
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551
Original PR description
Steps to reproduce: ------------- - Install Sales, Field Service, and Stock, - Go into Field service and open any task that has products. - Through stat button on the top access the product catalog. - Click on burger menu on any service type product. Issue: - View Availability option should not be shown for service type products Cause: - No condition to make it invisible. Solution: - Added a condition when product type is service to the option invisible. task-3801551 Forward-Port-Of: odoo/enterprise#76144 Forward-Port-Of: odoo/enterprise#58817
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76557
Original PR description
With the changes done to `account.external.tax.mixin` the name of ir.logging is now the module name and not 'Avatax' anymore. So us logs resulted in Avatax US and were not shown by default when opening the window with the window actions. opw-4429151 Forward-Port-Of: odoo/enterprise#76557
When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Original PR description
When [adding this module], the translations were forgotten. We are adding them here. [adding this module]: https://github.com/odoo/enterprise/commit/055ed588dd7558c568373fbaa6d24208d0aeeb87 opw-4425163 Forward-Port-Of: odoo/enterprise#76646 Forward-Port-Of: odoo/enterprise#76612
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Original PR description
Starting from saas-17.4, the default transaction code in settings shows the commidity code instead of transaction codes. This commit applies the domain for showing transaction codes instead. opw-4419718 Forward-Port-Of: odoo/enterprise#76519
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76
Original PR description
Following the "nice urls" [task][1] It may happen that the studio's systray item is re-rendered while the actionService is loading a URL with multiple actions In this case, there may be a crash because the SystrayItem would check if the current action (in this case from the virtual controller) is editable. After this commit, there is no crash. part of task-4391729 [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f Forward-Port-Of: odoo/enterprise#76694
### Steps to reproduce: - Install "l10n_mx" and switch to a Mexican company - Create an invoice with a Mexican partner and confirm - Create a Payment - In the invoice form view, go to the "CFDI" page - Click "Update CFDI" - The payment appears, click on "Show" - The button "Request Cancel" does nothing ### Cause: the method `button_request_cancel` on move is called from the payment model but does not return anything: ``` def button_request_cancel(self): self.move_id.button_requ
Original PR description
### Steps to reproduce:
- Install "l10n_mx" and switch to a Mexican company
- Create an invoice with a Mexican partner and confirm
- Create a Payment
- In the invoice form view, go to the "CFDI" page
- Click "Update CFDI"
- The payment appears, click on "Show"
- The button "Request Cancel" does nothing
### Cause:
the method `button_request_cancel` on move is called from the payment model but does not return anything:
```
def button_request_cancel(self):
self.move_id.button_request_cancel()
```
But the `button_request_cancel` from `l10n_mx_edi` is returning a wizard that is never caught.
### Solution:
When clicking the "Request cancel" button, the method `action_request_cancel` is called instead of `action_cancel` which will dispatch the request depending on the type of move being cancelled.
opw-4332483
Forward-Port-Of: odoo/enterprise#75714Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76511
Original PR description
Camera driver was not working, so we updated the logic to detect camera devices, and improved the one to take pictures. We also caught the opportunity to move IoT Handlers corresponding to `quality` modules to `quality_iot`. Community PR: [https://github.com/odoo/odoo/pull/192449](https://github.com/odoo/odoo/pull/192449) Task: 4432584 Forward-Port-Of: odoo/enterprise#76511
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have
Original PR description
[FIX] account_reports: sections tour The sections' tour was breaking with the change of year. We use the generic tax report for doing the testing. The generic tax report has a periodicity of 1 month and opens at the previous period. Our tests where based on the current date year. It works fine except on the change of year. Indeed, we will be on January of year XXXX but the report will open on December of year YYYY. Now, we correctly remove 1 month to our dates to make sure we have the correct year. We also took the time to replace the usage of Date of plain javascript with DateTime of the luxon library. Forward-Port-Of: odoo/enterprise#76606
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695
Original PR description
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305 Forward-Port-Of: odoo/enterprise#72695