Daily updates from Odoo
Navigate
Branch
Wednesday, August 7, 2024
46 changes
11 changes
Miscellaneous changes
`install` alias could not mount `/proc` as it was performed using 'sudo', which is unavailable as root is `/root_bypass_ramdisks` at this time. Forward-Port-Of: odoo/odoo#175297
Original PR description
`install` alias could not mount `/proc` as it was performed using 'sudo', which is unavailable as root is `/root_bypass_ramdisks` at this time. Forward-Port-Of: odoo/odoo#175297
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale. Steps to reproduce: 1. Enable packaging configuration. 2. Create a sales order and confirm it; this will generate a delivery. 3. Find that delivery in the ‘Barcode’ app. 4. Add/scan the product. 5. Scan the package type. Current behavior before PR: Following the above
Original PR description
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight…
… when the package type is scanned using the barcode Description of the issue this PR addresses: This PR aims to resolve the issue where the IoT scale is connected but unable to retrieve the weight from the scale. Steps to reproduce: 1. Enable packaging configuration. 2. Create a sales order and confirm it; this will generate a delivery. 3. Find that delivery in the ‘Barcode’ app. 4. Add/scan the product. 5. Scan the package type. Current behavior before PR: Following the above steps, when the package type is scanned using the barcode, the scanned package type is not populated in the opened package wizard. Consequently, the shipping weight field is not visible, preventing the retrieval of the weight from the IoT scale. Please refer to the screen recording before the PR: https://github.com/user-attachments/assets/e4764005-6758-4f80-a189-e27e8897f853 Desired behavior after PR is merged: After merging this PR, when the package type is scanned using the barcode, the scanned package type will be correctly populated in the opened wizard. As a result, the shipping weight will be visible, and it will be able to retrieve the scale weight from IoT. Please refer to the screen recording after the PR: https://github.com/user-attachments/assets/f408ee60-2495-48a5-96ea-3ced502c85dc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173949
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This co
Original PR description
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures…
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This commit partially reverts commit [2] and provides an alternative solution to the original issue. - Inserting a horizontal rule was only possible on paragraph related elements. This PR makes sure horizontal rule can be inserted directly to block elements such as div. task-3850023 [1]: https://github.com/odoo/odoo/commit/ddc8587f8a712fdddaa714bee2931cb149c03a38 [2]: https://github.com/odoo/odoo/commit/530f102720458e5e1c224bf38073cd763309bf0a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173729 Forward-Port-Of: odoo/odoo#164345
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller
Original PR description
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally…
In Luxembourg, the "Société national des chemins de Fer Luxembourgeois" expects the `PartyLegalEntity/CompanyID` to be filled with the "Registre de Commerce et des Sociétés" (RCS), which is normally filled on the `company_registry` of the supplier company. Before this commit, we filled this tag with the VAT (which is also filled in the `PartyTaxScheme/CompanyID`). The peppol official documentation states: 1. `PartyTaxScheme/CompanyID`: "The Seller's VAT identifier (also known as Seller VAT identification number) or the local identification (defined by the Seller’s address) of the Seller for tax purposes or a reference that enables the Seller to state his registered tax status." [1] 2. `PartyLegalEntity/CompanyID`: "An identifier issued by an official registrar that identifies the Seller as a legal entity or person." [2] Consequently, it is not certain whether the company_registry should always be used to fill the element `PartyLegalEntity/CompanyID` or not, hence we only use it in Luxembourg for now. [1] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyTaxScheme/cbc-CompanyID/ [2] https://docs.peppol.eu/poacc/billing/3.0/syntax/ubl-invoice/cac-AccountingSupplierParty/cac-Party/cac-PartyLegalEntity/cbc-CompanyID/ opw-4075457 Forward-Port-Of: odoo/odoo#175379
Steps ----- 1. Have a product of type "Service" with "Subcontract Service" activated on the Purchase page and with at least a vendor. 2. Create a Sales Order with this product. When confirming it, a PO will be automatically created. 3. Create another Sales Order with the product. 4. The PO now has 2 lines, but the "Source Document" in "Other Information" of the PO only contains the name of the first SO. Cause ----- Refactor e54b57ee74893170134438a9b5873db4dfd03ddc changed the logic. If
Original PR description
Steps ----- 1. Have a product of type "Service" with "Subcontract Service" activated on the Purchase page and with at least a vendor. 2. Create a Sales Order with this product. When confirming it, a PO will be automatically created. 3. Create another Sales Order with the product. 4. The PO now has 2 lines, but the "Source Document" in "Other Information" of the PO only contains the name of the first SO. Cause ----- Refactor e54b57ee74893170134438a9b5873db4dfd03ddc changed the logic. If a PO is found by _purchase_service_match_purchase_order, it should have its origin modified to include the new SO (not the case currently). opw-4049834 Forward-Port-Of: odoo/odoo#174051
Before this commit, when a reward eligible for multiple products was claimed, only one product was added to the order regardless of the reward's configuration. opw-4066760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175259 Forward-Port-Of: odoo/odoo#174176
Original PR description
Before this commit, when a reward eligible for multiple products was claimed, only one product was added to the order regardless of the reward's configuration. opw-4066760 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175259 Forward-Port-Of: odoo/odoo#174176
When creating an expense to be paid to the employee, if the employee's contact had a parent_id, then when trying to register a payment for that expense, the bank account of the parent company was used instead. In https://github.com/odoo/odoo/commit/1ed71ba1fa176de9b0100b96f5af7d76c224e1a2 a fix was made to use the employee's bank account. That fix is now being reverted and being replaced with this commit instead. If we're creating an expense to be paid to the employee, we show a warning ban
Original PR description
When creating an expense to be paid to the employee, if the employee's contact had a parent_id, then when trying to register a payment for that expense, the bank account of the parent company was used instead. In https://github.com/odoo/odoo/commit/1ed71ba1fa176de9b0100b96f5af7d76c224e1a2 a fix was made to use the employee's bank account. That fix is now being reverted and being replaced with this commit instead. If we're creating an expense to be paid to the employee, we show a warning banner on the vendor bill and the expense sheet that they're invoicing their own company. task-3955593 Forward-Port-Of: odoo/odoo#175416 Forward-Port-Of: odoo/odoo#167816
Before this commit, it was possible to delete an accrual plan while it was referenced by an allocation. This commit introduces an error message if the user tries to delete an accrual plan in those conditions. task-4023187 Also updates the `hr_holidays.pot` file Forward-Port-Of: odoo/odoo#175553 Forward-Port-Of: odoo/odoo#171403
Original PR description
Before this commit, it was possible to delete an accrual plan while it was referenced by an allocation. This commit introduces an error message if the user tries to delete an accrual plan in those conditions. task-4023187 Also updates the `hr_holidays.pot` file Forward-Port-Of: odoo/odoo#175553 Forward-Port-Of: odoo/odoo#171403
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Fo
Original PR description
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Forward-Port-Of: odoo/odoo#124300
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale will be updated. **Error Description** - If you have a digital scale that is connected and selected for use in POS. - The status of IoT devices is updated via the router `/hw_proxy/status_json` and the function `get_status()` - However, the status of the digital scale is not updat
Original PR description
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale…
**Before commit** - When the electronic scale is disconnected, its connection status is not updated. **After commit** - When the electronic scale is disconnected, the status of the electronic scale will be updated. **Error Description** - If you have a digital scale that is connected and selected for use in POS. - The status of IoT devices is updated via the router `/hw_proxy/status_json` and the function `get_status()` - However, the status of the digital scale is not updated when it is disconnected. This leads to the scale still reporting that it is connected when calling the `get_status()` function. The scale status is updated via `self._status` https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialScaleDriver.py#L110-L114 However `self._status` is not updated when disconnected. https://github.com/odoo/odoo/blob/8ff2381901e4920434eaee73f8c265fc67271c99/addons/hw_drivers/iot_handlers/drivers/SerialBaseDriver.py#L129-L144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175063
**Steps to reproduce the bug:** - Create a storable product "A1" and "A2". - Update their available quantity to 5. - Create a picking with 5 units of "A1" and another picking with 5 units of "A2". - Confirm both pickings. - Create a new wave transfer and add both pickings. - Update the quantity of "A1" to 0 units. - Try to validate the wave. **Problem:** A user error is triggered: "You cannot validate a transfer if no quantities are reserved. To force the transfer, encode quantities."
Original PR description
**Steps to reproduce the bug:** - Create a storable product "A1" and "A2". - Update their available quantity to 5. - Create a picking with 5 units of "A1" and another picking with 5 units of "A2". - Confirm both pickings. - Create a new wave transfer and add both pickings. - Update the quantity of "A1" to 0 units. - Try to validate the wave. **Problem:** A user error is triggered: "You cannot validate a transfer if no quantities are reserved. To force the transfer, encode quantities." **Solution:** When the quantity of "A1" is updated to 0, the state of the picking becomes "confirmed" instead of "assigned" and as all the moves in this picking have a 0 quantity, we can exclude it from the wave and allow the wave validation. opw-4016209 Forward-Port-Of: odoo/odoo#175888
30 changes
Enhancements to existing features
This update adjusts spreadsheet-related tests and supporting code to stay compatible with a newer spreadsheet library. It helps maintain reliability in document spreadsheets, pivot views, list details, and comments without introducing major user-facing changes.
The Point of Sale configuration screen has been updated to provide a clearer and more user-friendly layout. This should make it easier for teams to find and adjust settings, especially around connected POS devices.
Original PR description
Task ID: 4066917 Related: https://github.com/odoo/odoo/pull/174827
The SEPA Direct Debit payment provider screens were updated to use newer, simpler layout building blocks. This should make the interface easier to maintain while keeping the user experience effectively unchanged.
Original PR description
In this commit we have simplified the kanban arch for the payment_sepa_direct_debit module. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name=... widget=image/>` instead Task-3992107
The barcode lookup scanner has been moved into a shared product module so it can be reused beyond Point of Sale, including website sales. Stock barcode views were also standardized, giving users a more consistent product lookup experience across workflows.
Original PR description
*: pos_barcodelookup, stock_barcode_barcodelookup product_barcodelookup : - We have shifted the barcodeScanner widget in product_barcodelookup as now we don't need to show just in pos but also in website_sale module. pos_barcodelookup : - barcodeScanner widget is removed and shifted to product_barcodelookup module. stock_barcode_barcodelookup : - here we don't need the widget in the normalized form view so just removed that for the stock_barcode module. - made the normalized form view similar to what in pos module to make it standard in all modules task: 3977931 Related PR (Community) : https://github.com/odoo/odoo/pull/172217
Accounting lock dates are now handled through an updated wizard that supports separate sales and purchase locks, temporary exceptions, and a stricter hard lock date. This helps businesses protect closed periods while still allowing controlled corrections when needed, and fixes related lock date behavior for Employment Hero integrations.
Original PR description
### changes #### [FIX] l10n_employment_hero: fix lock date Currently there is an `@api.onchange` function on 'res.company'. It is supposed to ensure that the `employment_hero_lock_date` is not after…
### changes
#### [FIX] l10n_employment_hero: fix lock date
Currently there is an `@api.onchange` function on 'res.company'.
It is supposed to ensure that the `employment_hero_lock_date` is not after the `fiscalyear_lock_date`.
But this does not work at all since both lock dates are changed in different views / wizards.
In this commit:
- The broken onchange is removed.
- A constraint on `employment_hero_lock_date` is added
- A function is added to compute the needed date from the `employment_hero_lock_date` and the other relevant fiscal lock dates.
On the `employment_hero_lock_date` constraint:
It ensure that we do not set a Employment Hero Lock Date before the relevant fiscal Lock Dates.
This avoids unexpected behavior / user frustration; since we only start fetching from the maximum of both of these dates.
We accept that the Employment Hero Lock Date can get outdated in case we change the relevant fiscal Lock Dates:
The field is assumed to be mostly used when setting up the DB to fetch historical data.
#### [FIX] account_accountant: remove unused fields from settings
Currently the lock date fields are also on 'res.config.settings'.
They are not used or needed. They were removed from the view in commit 0bd56c92e4b776de6b460da56da2807cc7bc778c .
This commit removes these fields.
#### [IMP] account: rework lock dates and their wizard
In the associated community PR the lock dates were reworked.
I.e.
- The `period_lock_date` was replaced by `sale_lock_date` and `purchase_lock_date`.
- (Temporary) Lock Date Exceptions were added (new model)
They can be used to make changes to a locked period
- A `hard_lock_date` was added.
- It locks everything (like all the lock dates were set to that date).
- It does not allow exceptions.
- It cannot be decreased or removed.
See the community PR for details.
In this commit we adapt the enterprise code to the changes in community.
I.e. we change the lock date wizard:
- All the lock dates can be seen and set in the wizard.
- Exceptions are created when decreasing a lock date
- No exceptions are possible for the `hard_lock_date`
- When a lock date value is decreased in the wizard a line on the button appears.
There it can be selected
- who the exception applies to: me or everyone
- how long the exception is valid: 5 min, 15 min, 1 h, 24 h or forever
- (optional) reason
- In case an exception for everyone and forever is selected we change the lock date instead of creating an exception.
- In case there are active exceptions for a lock date there is a revoke button on the right side of the lock date.
It can be used to revoke the most permissive (minimal date) active exception for that lock date.
- In case there are draft entries in the period the user wants to lock a warning is displayed.
It is only blocking for the `hard_lock_date`.
### related PRs
community: https://github.com/odoo/odoo/pull/174004
upgrade: https://github.com/odoo/upgrade/pull/6295
### task
task-3891414The Bill of Materials overview now takes work center availability into account when simulating production planning. This helps manufacturing teams get a more realistic view of when products can be made and where capacity constraints may affect schedules.
Original PR description
Consider workcenters availability in BoM Overview. task: 3935589
Users can now switch the Discuss sidebar into a more compact view using a new arrow button next to Start a meeting. The preference is saved on the device, helping users keep their workspace organized between sessions.
Original PR description
This commit adds a new "arrow" button in discuss sidebar panel, next to "Start a meeting". Clicking on this button enables a more compact version of discuss sidebar. The toggling of this mode is persistent on the device, thanks to local storage. https://github.com/odoo/odoo/pull/174985
The Documents link on portal task pages has been moved from the navigation area to the related links area. This makes the page layout clearer by separating page navigation from links to associated documents.
Original PR description
Currently, in the portal task's view, the "Documents" link is in the navigation section. This PR will move it in the links section as it isn't a shortcut to navigate the current page like the others links in this section. task-3973629
The project side panel has been visually improved to align with related project updates, making project budget information easier to review. The Timesheet Grid header now highlights shortcut text in bold, improving readability for users entering or managing timesheets.
Original PR description
* = project_account_budget, timesheet_grid This PR is linked to changes made in community PR. Made visual changes in time sheets header helper. task-3747204
Asset-related screens now support keyboard shortcuts for common actions such as confirming, computing depreciation, reconciling, and viewing posted entries. This makes frequent asset management tasks faster and easier for users who prefer keyboard navigation.
Original PR description
Make the asset form view easier to use by mapping its action buttons to hotkeys: - Confirm -> ALT + Q - Compute Depreciation -> ALT + D - Save as Model -> ALT + M - Cancel Asset -> ALT + X - Reconcile -> ALT + R - Create Asset -> ALT + C - Posted Entries -> ALT + P related community PR: https://github.com/odoo/odoo/pull/175424 **task**-4079684
The Default Accounts settings now use clearer and updated labels in Accounting and French reporting. This makes the configuration screen easier to understand for users managing accounting setup, without changing underlying accounting behavior.
Original PR description
Improve/update some of the labels in the Default Accounts setting from `account_accountant` and `l10n_fr_reports` task-id: 4063678
Resolved issues and error corrections
The Barcode app header now shows the option to install it as a PWA again after it was lost during a redesign. Users running the Barcode app as a PWA also get a visible logout button, making access and session management clearer.
Original PR description
This commit fixes the missing button from the UI. This happened since the app was entirely redesigned in commit (1), and this part of the template was not copied when rewriting the template. Now, the button is displayed once again, and a logout button is displayed as well when being run inside the Barcode PWA. 1) 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f Before this commit:  After this commit:  In the app (logout button): 
Miscellaneous changes
Create Branch Set up Avatax on main company Try to compute taxes using Avatax on Branch company Issue: Receive error asking to add Avatax Credentials When working with branches, Avatax should only be configured on the main company and not from the branches, since the tax report will be done from the parent. opw-3962212 Forward-Port-Of: odoo/enterprise#66681
Original PR description
Create Branch Set up Avatax on main company Try to compute taxes using Avatax on Branch company Issue: Receive error asking to add Avatax Credentials When working with branches, Avatax should only be configured on the main company and not from the branches, since the tax report will be done from the parent. opw-3962212 Forward-Port-Of: odoo/enterprise#66681
Introduces e-invoicing and stock reporting via the new eTIMS service. Community PR: https://github.com/odoo/odoo/pull/162196 taskid: 3603762 Forward-Port-Of: odoo/enterprise#66532 Forward-Port-Of: odoo/enterprise#61967
Original PR description
Introduces e-invoicing and stock reporting via the new eTIMS service. Community PR: https://github.com/odoo/odoo/pull/162196 taskid: 3603762 Forward-Port-Of: odoo/enterprise#66532 Forward-Port-Of: odoo/enterprise#61967
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new ticket without any team attached, rendering it useless. step to reproduce: - install helpdesk application - open helpdesk - open confifuration menu, select helpdesk team - select 'customer care' - activate the livechat option and saves - leave helpdesk - change from the current active company
Original PR description
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new…
This commit's purpose is to disable the helpdesk ticket creation command when there are no teams available for the current connected user. Currently, using this command this way will create a new ticket without any team attached, rendering it useless. step to reproduce: - install helpdesk application - open helpdesk - open confifuration menu, select helpdesk team - select 'customer care' - activate the livechat option and saves - leave helpdesk - change from the current active company to any other company that doesn't have any helpdesk team with the livechat feature enabled - open the discuss app and select the 'general' discussion - type /helpdesk your_ticket a new ticket will be created without any team linked to it. source of the issue: when a team has the livechat option enable, the command is added to the livechat regardless of the connected user's access right to the team. solution: Only add the command to the list of livechat command if the user has access to at least one team with the livechat feature enable. affected version : 15.0 - master task - 3631682 https://www.odoo.com/web#id=3631682&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=form Forward-Port-Of: odoo/enterprise#67939 Forward-Port-Of: odoo/enterprise#53510
Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link. task-4070526 Forward-Port-Of: odoo/enterprise#67823 Forward-Port-Of: odoo/enterprise#67612
Original PR description
Fixed `test_industry_fsm_at_install` by activating the pricelist before creating the sale order to ensure a proper link. task-4070526 Forward-Port-Of: odoo/enterprise#67823 Forward-Port-Of: odoo/enterprise#67612
Currently, a traceback may occur when we get the token as false Error:- ``` TypeError: can only concatenate str (not "bool") to str File "odoo/tools/safe_eval.py", line 390, in safe_eval return unsafe_eval(c, globals_dict, locals_dict) File "ir.actions.server(348,)", line 1, in <module> File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi_stock/models/account_move.py", line 14, in cron_run_sii_workflow super(AccountMove, self).cron_run_sii_workflow() File "home/odoo/sr
Original PR description
Currently, a traceback may occur when we get the token as false Error:- ``` TypeError: can only concatenate str (not "bool") to str File "odoo/tools/safe_eval.py", line 390, in safe_eval return…
Currently, a traceback may occur when we get the token as false
Error:-
```
TypeError: can only concatenate str (not "bool") to str
File "odoo/tools/safe_eval.py", line 390, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(348,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi_stock/models/account_move.py", line 14, in cron_run_sii_workflow
super(AccountMove, self).cron_run_sii_workflow()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 806, in cron_run_sii_workflow
self_skip._l10n_cl_ask_claim_status()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 780, in _l10n_cl_ask_claim_status
move.l10n_cl_verify_claim_status()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 288, in l10n_cl_verify_claim_status
response = self._get_dte_claim(
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/l10n_cl_edi_util.py", line 408, in _get_dte_claim
settings = Settings(strict=False, extra_http_headers={'Cookie': 'TOKEN=' + token})
ValueError: <class 'TypeError'>: "can only concatenate str (not "bool") to str" while evaluating
'model.cron_run_sii_workflow()'
File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 971, in run
res = runner(run_self, eval_context=eval_context)
File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
res = super(ServerAction, self)._run_action_code_multi(eval_context)
File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 404, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
But here in the code, only the None case was handled. https://github.com/odoo/enterprise/blob/5dae45bea35b55e88e1d7199a555f9cc5375c899/l10n_cl_edi/models/l10n_cl_edi_util.py#L407-L410
After applying this commit it will resolve this issue by handling all the falsy cases for the token.
sentry-5539925394
Forward-Port-Of: odoo/enterprise#66232Forward-Port-Of: odoo/enterprise#67805
Original PR description
Forward-Port-Of: odoo/enterprise#67805
The hoot helpers make the time advance more quickly. In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the pills can have different ending columns. Here we remove a useless call to selectGanttRange, so that less time passes and we are sure we stay between 18h and 19h and not after 19h, so that "Attendance 6" ends at 6pm 02 November 2018 (included). Build 66529031 Forward-Port-Of: odoo/enterprise#68033
Original PR description
The hoot helpers make the time advance more quickly. In AttendanceGanttModel, open ended records have their dateStopField set to the current moment. So, depending on the way time passes, the pills can have different ending columns. Here we remove a useless call to selectGanttRange, so that less time passes and we are sure we stay between 18h and 19h and not after 19h, so that "Attendance 6" ends at 6pm 02 November 2018 (included). Build 66529031 Forward-Port-Of: odoo/enterprise#68033
Redirect the user to reauthorize their consent directly from Odoo in a seamless manner if we receive a consent-expired error using the reauthorization endpoint (https://documentation.ibanity.com/ponto-connect/2/api/curl#reauthorization-request). Task: 3208460 Odoofin PR: https://github.com/odoo/odoofin/pull/255 Forward-Port-Of: odoo/enterprise#67976 Forward-Port-Of: odoo/enterprise#56901
Original PR description
Redirect the user to reauthorize their consent directly from Odoo in a seamless manner if we receive a consent-expired error using the reauthorization endpoint (https://documentation.ibanity.com/ponto-connect/2/api/curl#reauthorization-request). Task: 3208460 Odoofin PR: https://github.com/odoo/odoofin/pull/255 Forward-Port-Of: odoo/enterprise#67976 Forward-Port-Of: odoo/enterprise#56901
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account (e.g. Test Account) - Go to "Accounting / Accounting / Miscellaneous / Journal Entries" - Create a journal entry: * Journal Items: ------------ Account | Debit | Credit -------------------------------------------- Test Account | $0.00 | $410.34 [any] | $410.34 | $0.00 - Post the journal e
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account (e.g. Test Account) - Go to "Accounting / Accounting /…
**Steps to reproduce:**
- Install Accounting
- Go to "Accounting / Configuration / Accounting / Chart of Accounts"
- Create an account (e.g. Test Account)
- Go to "Accounting / Accounting / Miscellaneous / Journal Entries"
- Create a journal entry:
* Journal Items:
------------
Account | Debit | Credit
--------------------------------------------
Test Account | $0.00 | $410.34
[any] | $410.34 | $0.00
- Post the journal entry
- Go to "Accounting / Accounting / Management / Automatic Transfers"
- Create an automatic transfer:
* Origin Accounts: Test Account
* Automated Transfer:
-----------
Percent (%) | Destination Account
-----------------------------------------------
15.00 | [any]
42.50 | [any, but a different one]
42.50 | [any, but a different one]
- Activate the automatic transfer
- Compute transfer
**Issue:**
A UserError is raised while trying to create a journal entry because of a $0.01 difference between the total credit and the total debit.
**Cause:**
When the amounts of each line are computed from the percentage, they are not rounded.
These amounts are used to create the journal entries generated by the automatic transfer.
However, each created journal entry line is rounded, which can generate a rounding difference.
**Solution:**
Directly round the amounts when they are computed from the percentage to be sure that the amounts used for the computation and the ones that will be set in the journal entries are the same.
opw-3998808
Forward-Port-Of: odoo/enterprise#67956
Forward-Port-Of: odoo/enterprise#67644### Main Issue: When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house number from the 'street' field of the partner. ### Main change: Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats. ### Before: - Regex Pattern: `([1-9]+\w*)` - Explanation: This pattern captures one or more d
Original PR description
### Main Issue: When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house…
### Main Issue:
When creating a sales order that triggers a delivery via Sendcloud, the delivery address on the label may be incorrect. It is due to a limited regex when trying to extract the house number from the 'street' field of the partner.
### Main change:
Updated the regex pattern used to extract house numbers from postal address lines to increase accuracy and cover more address formats.
### Before:
- Regex Pattern: `([1-9]+\w*)`
- Explanation: This pattern captures one or more digits (not starting with zero) followed by any number of word characters (letters, digits, or underscores).
### After:
- Regex Pattern: `(\d+[-\/]?\d* ?[a-zA-Z]?\d*)(?![a-zA-Z])`
- Explanation: This improved pattern captures a broader range of house number formats, including those with dashes, slashes, spaces, and letters.
### Examples of the Differences:
"Friedrichstr. 13/1"
Before: '13'
After: '13/1'
"Rue du pont 11 A"
Before: '11'
After: '11 A'
"Place Albert 1er 15B"
Before: '1er'
After: '15B'
"123-456 Main Street"
Before: '123'
After: '123-456'
"789 C Oak Avenue"
Before: '789'
After: '789 C'
[opw-4042552](https://www.odoo.com/odoo/project/49/tasks/4042552)
Forward-Port-Of: odoo/enterprise#67344
Forward-Port-Of: odoo/enterprise#67286Steps: 1) Install hr_payroll_account module 2) In the batch click on the create payment report Cause: - in the join method, we are trying to call the map method Fix: - the map method is now called within the join method Task - 4079932 Forward-Port-Of: odoo/enterprise#67523
Original PR description
Steps: 1) Install hr_payroll_account module 2) In the batch click on the create payment report Cause: - in the join method, we are trying to call the map method Fix: - the map method is now called within the join method Task - 4079932 Forward-Port-Of: odoo/enterprise#67523
Before this commit, the test checking the reload_context is called only when the user enables for the first time a feature in helpdesk team. The test `reload the page when the feature use_timesheet is enabled in all teams` fails indeterminately because we don't wait enough to reload the page once the user clicks on the arrow right of the pager to get the second record. Moreover, it is not really possible to reproduce a hard reload in HOOT test (unmount and mount a view) and so this test has to b
Original PR description
Before this commit, the test checking the reload_context is called only when the user enables for the first time a feature in helpdesk team. The test `reload the page when the feature use_timesheet is enabled in all teams` fails indeterminately because we don't wait enough to reload the page once the user clicks on the arrow right of the pager to get the second record. Moreover, it is not really possible to reproduce a hard reload in HOOT test (unmount and mount a view) and so this test has to be reviewed. This commit changes some conditions to call `check_modules_to_install` only when a feature is enabled on helpdesk team and it also reviews the test failed and updates the tests but also alter some tests to use hooks developed in web module. runbot-70509 Forward-Port-Of: odoo/enterprise#66989
Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix. Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured': ``` File ".../l10n_br_avatax/models/res_config_
Original PR description
Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And…
Errors returned by Avatax when creating an account are not consistent. Sometimes the 'message' key contains a string with JSON. Other times it's a human-readable string with an error message. And other times it's a non-descript error that we replace with a more user-friendly error to guide users towards the most common fix.
Before this fix a traceback appeared when a human-readable error string was returned without 'unhandled error occured':
```
File ".../l10n_br_avatax/models/res_config_settings.py", line 85, in create_account
result = json.loads(result['message'])
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
This makes the error handling more robust by first attempting to decode the string as JSON. If that fails we fall back on the other two scenarios.
A new test class is included that provides examples of each type of response.
opw-4067842
Forward-Port-Of: odoo/enterprise#67673
Forward-Port-Of: odoo/enterprise#67477This commit add a csrf verification to the public /document/upload route This is change remains stable compliant due to not modifying the template. No module update is require for this change to work. This commit will break some custom implementation that call directly to the route. Forward-Port-Of: odoo/enterprise#67651 Forward-Port-Of: odoo/enterprise#67119
Original PR description
This commit add a csrf verification to the public /document/upload route This is change remains stable compliant due to not modifying the template. No module update is require for this change to work. This commit will break some custom implementation that call directly to the route. Forward-Port-Of: odoo/enterprise#67651 Forward-Port-Of: odoo/enterprise#67119
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946 Forward-Port-Of: odoo/enterprise#62197
Original PR description
Add the modelo 130 report for spain localization task-3866238 Linked PR : https://github.com/odoo/odoo/pull/164946 Forward-Port-Of: odoo/enterprise#62197
In this commit we make the "manage bookings" gantt view appear as an entire screen, instead of a dialog. This makes the gantt view more clear and also changes the undesirable behavior of the form view for editing events that would close the gantt view behind it on save. Forward-Port-Of: odoo/enterprise#67810
Original PR description
In this commit we make the "manage bookings" gantt view appear as an entire screen, instead of a dialog. This makes the gantt view more clear and also changes the undesirable behavior of the form view for editing events that would close the gantt view behind it on save. Forward-Port-Of: odoo/enterprise#67810
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language
Original PR description
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language, to make sure the formula of the report expression matches the tag name (since that expression's formula is not translatable). community: https://github.com/odoo/odoo/pull/170041 Forward-Port-Of: odoo/enterprise#66946 Forward-Port-Of: odoo/enterprise#65030
In https://github.com/odoo/enterprise/pull/56927, the popup.scss file has been deleted and removed important classes still in use. Example, the pin code popup of the shop floor :  instead of  Forward-Port-Of: odoo/enterprise#67442
Original PR description
In https://github.com/odoo/enterprise/pull/56927, the popup.scss file has been deleted and removed important classes still in use. Example, the pin code popup of the shop floor :  instead of  Forward-Port-Of: odoo/enterprise#67442
5 changes
Resolved issues and error corrections
Fixed a bug that prevented users with Hebrew language settings from opening documents in the Documents app. The issue was caused by automatic translation of a technical field name, which has been corrected by disabling translation for that specific field.
Original PR description
Current behaviour: --- When settings the user's language as hebrew, the user cannot open any documents Steps to reproduce: --- 1. My profile > Language > Hebrew 2. Go to Documents 3. Open any documents 4. Traceback Cause of the issue: --- file_extension would be literally translated Fix: --- Setting t-translation as off opw-3938083
This fix corrects a bug in the payroll test system where incorrect payslip data was being generated for Belgium payroll structures. The test utility was mistakenly using the wrong structure type parameter, causing tests to fail with incorrect data. This fix ensures payroll tests run correctly across different regional configurations.
Original PR description
The default _generate_payslip method is using structure type instead of structure. Therefore it generates wrong payslip under BE structure.
This fix corrects a configuration mismatch in the Australian payroll module that was causing installation failures. The module was using inconsistent terminology ("yearly" vs "anually") when defining pay period settings, which prevented the system from properly recognizing annual wage entries. This fix ensures the payroll module works correctly with annual salary configurations.
Original PR description
PERIODS_PER_YEAR is using "yearly" but hr_contract uses "anually" and since this model uses the hr_contract, we need to keep the same dictionary keys. In customer database the installation of the module is failing because cannot find key "anually". The issue would also happen if you just set a yearly wage opw-4083058
This fix resolves a system crash that occurred when the Chilean EDI authentication token was invalid or missing. The system was only checking for one type of invalid token (None) but not handling other invalid cases, causing automated workflows to fail. This update ensures the system properly handles all invalid token scenarios and prevents the crash.
Original PR description
Currently, a traceback may occur when we get the token as false Error:- ``` TypeError: can only concatenate str (not "bool") to str File "odoo/tools/safe_eval.py", line 390, in safe_eval return…
Currently, a traceback may occur when we get the token as false
Error:-
```
TypeError: can only concatenate str (not "bool") to str
File "odoo/tools/safe_eval.py", line 390, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(348,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi_stock/models/account_move.py", line 14, in cron_run_sii_workflow
super(AccountMove, self).cron_run_sii_workflow()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 806, in cron_run_sii_workflow
self_skip._l10n_cl_ask_claim_status()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 780, in _l10n_cl_ask_claim_status
move.l10n_cl_verify_claim_status()
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/account_move.py", line 288, in l10n_cl_verify_claim_status
response = self._get_dte_claim(
File "home/odoo/src/enterprise/saas-17.2/l10n_cl_edi/models/l10n_cl_edi_util.py", line 408, in _get_dte_claim
settings = Settings(strict=False, extra_http_headers={'Cookie': 'TOKEN=' + token})
ValueError: <class 'TypeError'>: "can only concatenate str (not "bool") to str" while evaluating
'model.cron_run_sii_workflow()'
File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 971, in run
res = runner(run_self, eval_context=eval_context)
File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
res = super(ServerAction, self)._run_action_code_multi(eval_context)
File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 404, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
But here in the code, only the None case was handled. https://github.com/odoo/enterprise/blob/5dae45bea35b55e88e1d7199a555f9cc5375c899/l10n_cl_edi/models/l10n_cl_edi_util.py#L407-L410
After applying this commit it will resolve this issue by handling all the falsy cases for the token.
sentry-5539925394
Forward-Port-Of: odoo/enterprise#66232This fix resolves an issue in the Profit & Loss report that occurred when using negative analytical account percentages. When grouping by analytical accounts in the P&L report, the system was incorrectly validating amounts and causing errors. The fix removes an overly strict validation constraint from the temporary reporting table to allow proper handling of negative analytical distributions.
Original PR description
Problem: An issue arises due to a negative analytical distribution. If the analytical percentage is negative, its sign will match the sign of the amount_currency of its move line. However, in the…
Problem: An issue arises due to a negative analytical distribution. If the analytical percentage is negative, its sign will match the sign of the amount_currency of its move line. However, in the query that groups by the analytical account for P&L, the amount value is inverted. This does not cause a problem when the analytic percentage is positive because the amount_currency sign is opposite to the sign of the analytic line amount. But, in cases where the sign is the same, there will be a balance with a different sign than the amount, which will not comply with the constraint of the account.move.line table: "account_move_line_check_amount_currency_balance_sign". Steps to reproduce: 1. Activate "Analytic Accounting" in the settings 2. In an invoice, set an analytic distribution with a negative percentage 3. Validate the invoice 4. Go to P&L report an try to group by an analytic account 5. A validation error will occur. Proposed solution: Remove the constraint in the temporary table. opw-4092475 opw-4092232 opw-4086515 opw-4084850 opw-4083077 Forward-Port-Of: odoo/enterprise#67953