Daily updates from Odoo
Navigate
Branch
Thursday, May 2, 2024
45 changes
16 changes
Enhancements to existing features
Facebook social posts and comments now display users' different reaction types, not just likes, making engagement easier to understand at a glance. Users can also like or unlike Facebook posts directly from the comments window, improving day-to-day interaction workflows.
Original PR description
Purpose ======= Currently, we only show the likes of the users. But they can also react with something else than a like. This commit shows the emojis of the most used reactions. Other commits contain: Remove duplicated code about comment. Allow users to like posts in comments modal See underlying commits for details. Task-3595484
Documents attached through bridge modules are now moved to the trash instead of being permanently deleted when the related business record is removed. This preserves traceability and helps users recover or audit documents after associated records are deleted.
Original PR description
Purpose: Currently when a record with a document attached is deleted, the document attached is deleted as well which makes the document untraceable. Specification: Implemented a new functionality to handle document deletion in modules bridged with the documents. Instead of directly unlinking the document from the bridge module, a new function `send_to_trash()` has been created. This function changes the document's `res_model` to 'documents.document' and archives it, ensuring that the document is sent to the trash even if the associated record in the bridge module is deleted. This approach enhances document management and ensures data integrity across modules and helps in documents traceability. Task-3777950
Features or functions removed from Odoo
The Documents spreadsheet app no longer includes predefined spreadsheet templates that were unused and hard to maintain. Users creating a new spreadsheet will now go directly to a blank spreadsheet when no templates are available, reducing unnecessary choices and simplifying the workflow.
Original PR description
Task: 3761476
An unused action for opening subscriptions was removed from the Sales Subscription area. This is a small cleanup that reduces maintenance overhead without changing expected user workflows.
Original PR description
In this commit, the "action_open_subscriptions" function is no longer utilized, hence it has been removed. task-3860359
Miscellaneous changes
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
Original PR description
- Adds missing section D and E to the tax report. - Change line 43 to editable instead of aggregation. Forward-Port-Of: odoo/enterprise#61557 Forward-Port-Of: odoo/enterprise#57367
… variables To be able to render a human-readable qweb, we need to evaluate some arbitrary python expressions. Thos can produce bad sql queries because at this point, we are not, by construction in the conditions that produce correct queries (missing records etc....) Before this commit, when an query error occured at that step, the whole transaction was corrupted, and crashed the whole thing. After this commit, we do our partial evaluation things in a separate cursor, to avoid polluting
Original PR description
… variables To be able to render a human-readable qweb, we need to evaluate some arbitrary python expressions. Thos can produce bad sql queries because at this point, we are not, by construction in the conditions that produce correct queries (missing records etc....) Before this commit, when an query error occured at that step, the whole transaction was corrupted, and crashed the whole thing. After this commit, we do our partial evaluation things in a separate cursor, to avoid polluting the main one. opw-3815284 Forward-Port-Of: odoo/enterprise#60754
This commit moves the call for the Banxico currency update to the IAP server, where we can create a daily cache of currency rates. Part of: task-3749574 Forward-Port-Of: odoo/enterprise#61726 Forward-Port-Of: odoo/enterprise#58685
Original PR description
This commit moves the call for the Banxico currency update to the IAP server, where we can create a daily cache of currency rates. Part of: task-3749574 Forward-Port-Of: odoo/enterprise#61726 Forward-Port-Of: odoo/enterprise#58685
`Net profit/Loss for the Year` report.line has now an aggregation expression[1] which cannot have a groupby. But as the groupby field was removed instead of set to `eval=False`. The groupby is still there and blocking upgrades to 16.0 and 17.0 [1] https://github.com/odoo/enterprise/pull/52157 ``` File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
Original PR description
`Net profit/Loss for the Year` report.line has now an aggregation expression[1] which cannot have a groupby. But as the groupby field was removed instead of set to `eval=False`. The groupby is still there and blocking upgrades to 16.0 and 17.0
[1] https://github.com/odoo/enterprise/pull/52157
```
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_no_reports/data/profit_loss.xml:3
Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'Net profit/Loss for the Year'
View error context:
'-no context-'
```
Forward-Port-Of: odoo/enterprise#61445[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61701 Forward-Port-Of: odoo/enterprise#60107
Original PR description
[IMP] l10n_mx : Update master data with new Exento tax and fix the XML reader issues Add a new tax, Exento, to the master data of the module l10n_mx, change the fiscal position 'Foreign Customer' and add a new tax group for Exento. Add the Exento tax recognition for the XML reader for vendor bills. task id: 3774996 Forward-Port-Of: odoo/enterprise#61701 Forward-Port-Of: odoo/enterprise#60107
The `send as message` macro for the template/clipboard block is only supposed to open and edit the message composer on the target form view, then discard it. The form view does not become dirty because of that. However it has been observed that on some Odoo versions, the form view sometimes becomes dirty (indeterministic factor), which is unrelated to the successful macro operation. Therefore it has been decided to always attempt to discard the form so that the test does not fail no matter
Original PR description
The `send as message` macro for the template/clipboard block is only supposed to open and edit the message composer on the target form view, then discard it. The form view does not become dirty because of that. However it has been observed that on some Odoo versions, the form view sometimes becomes dirty (indeterministic factor), which is unrelated to the successful macro operation. Therefore it has been decided to always attempt to discard the form so that the test does not fail no matter if the view is dirty or not during the test. runbot error 62459 Forward-Port-Of: odoo/enterprise#61705 Forward-Port-Of: odoo/enterprise#61682
Added bold formatting to the header text in the template preview to help users distinguish it from the body text. A new line is added between the header and body text in the template preview for the same reason. Task - 3605612 Forward-Port-Of: odoo/enterprise#59143
Original PR description
Added bold formatting to the header text in the template preview to help users distinguish it from the body text. A new line is added between the header and body text in the template preview for the same reason. Task - 3605612 Forward-Port-Of: odoo/enterprise#59143
As seen in support tickets, other errors can be raised by PyPDF2 when trying to compute pages count on corrupted files. As we are not going to do any kind of handling and must not crash because of this, we'll simply log and discard any non-exit exception raised. Task-3614532 Forward-Port-Of: odoo/enterprise#59026
Original PR description
As seen in support tickets, other errors can be raised by PyPDF2 when trying to compute pages count on corrupted files. As we are not going to do any kind of handling and must not crash because of this, we'll simply log and discard any non-exit exception raised. Task-3614532 Forward-Port-Of: odoo/enterprise#59026
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#61610 Forward-Port-Of: odoo/enterprise#56121
Steps to reproduce ================== - Open studio on a form view - Edit something - Click on "Restore default view" => Nothing visually happens and the changes stays Forward-Port-Of: odoo/enterprise#61236 Forward-Port-Of: odoo/enterprise#60009
Original PR description
Steps to reproduce ================== - Open studio on a form view - Edit something - Click on "Restore default view" => Nothing visually happens and the changes stays Forward-Port-Of: odoo/enterprise#61236 Forward-Port-Of: odoo/enterprise#60009
Currently, it's not possible to create a form on `event.event` because website_studio doesn't check whether `/event` already exists. Steps: - Install `website_studio` and `website_event` - Open `Events` - Open `Studio` - Click on `Website` tab - Try to add a new form by clicking on `New Form` - Studio doesn't create a new form because it points to /event which already exists (created by `website_event`). This commit verifies that the route doesn't exist before creating it.
Original PR description
Currently, it's not possible to create a form on `event.event` because website_studio doesn't check whether `/event` already exists. Steps: - Install `website_studio` and `website_event` - Open `Events` - Open `Studio` - Click on `Website` tab - Try to add a new form by clicking on `New Form` - Studio doesn't create a new form because it points to /event which already exists (created by `website_event`). This commit verifies that the route doesn't exist before creating it. Pages are served as a fallback when Python routing (`@route`) doesn't match and there is no attachment matching that url. For simplicity and performance, we only check that our new page doesn't collide with an `@route` controller, because we assume that attachments url won't collide. see `website/models/ir_http.py` `Http::_serve_fallback` opw-3778543 Forward-Port-Of: odoo/enterprise#60752 Forward-Port-Of: odoo/enterprise#58504
This is a backport of odoo/enterprise#58479 This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. task-id: 3747828 Community PR: odoo/odoo#161342 Forward-Port-Of: odoo/enterprise#60561 Forward-Port-Of: odoo/enterprise#60451
Original PR description
This is a backport of odoo/enterprise#58479 This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. task-id: 3747828 Community PR: odoo/odoo#161342 Forward-Port-Of: odoo/enterprise#60561 Forward-Port-Of: odoo/enterprise#60451
29 changes
Resolved issues and error corrections
The check report summary line had misaligned columns where the partner name, date, and check number were compressed at the start of the line. This fix properly spaces these columns across the line with the partner name at the beginning, date in the middle, and check number at the end, improving the readability and professional appearance of printed checks.
Original PR description
Check Report Summary line columns were not aligned correctly, fixing it to have partner_name at the beginning, date at the middle, and check sequence number at the end of the line. task id: 3708433
This fix corrects an accounting issue where deleted time records from manufacturing work orders were not properly reflected in the analytic account's gross margin calculations. Previously, when employees' time entries were removed, the system would still count their labor costs, resulting in inaccurate profitability reports. The fix ensures that deleting time records now automatically adjusts the analytic account to reflect the actual time worked and provide accurate financial reporting.
Original PR description
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work…
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:00 or open the work order and delete a line from the Time Tracking tab. Note: decreasing the Real Duration on the Manufacturing Order page will not lead to an issue as long as no time record is deleted on the work order (typically, when decreasing the time by a small amount). Issue ----- The gross margin still takes into account the employee's cost for the deleted time. Note that the workcenter's cost is removed from the gross margin as expected. Either by _create_or_update_analytic_entry in case the time of the work order is modified, or unlink if the work order is deleted. https://github.com/odoo/odoo/blob/16.0/addons/mrp_account/models/mrp_workorder.py Fix ----- When deleting a time record, modify the analytic account accordingly. We create an analytic entry with a previous_duration equal to the double of the time that is deleted. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L16 That way, we create an analytic entry with a duration equal to the negative of the deleted time. This will add a positive amount to the analytic account. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L21-L22 This makes the analytic account's gross margin consistent with the time worked. **opw-3759144** Forward-Port-Of: odoo/enterprise#58760
This update corrects how rounding precision is applied in the Field Service Sales module. The system was using incorrect parameters when calculating rounded values, which could lead to inaccurate pricing or amount calculations. This fix ensures rounding is performed correctly according to your company's precision settings.
Original PR description
Versions -------- - 17.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Community branch: https://github.com/odoo/odoo/pull/163182
This update improves the reliability of automated tests for the helpdesk knowledge template feature. The test now consistently discards forms after sending messages, preventing occasional test failures that occurred unpredictably on certain Odoo versions. This ensures the test runs reliably without being affected by unexpected form state changes.
Original PR description
The `send as message` macro for the template/clipboard block is only supposed to open and edit the message composer on the target form view, then discard it. The form view does not become dirty because of that. However it has been observed that on some Odoo versions, the form view sometimes becomes dirty (indeterministic factor), which is unrelated to the successful macro operation. Therefore it has been decided to always attempt to discard the form so that the test does not fail no matter if the view is dirty or not during the test. runbot error 62459 Forward-Port-Of: odoo/enterprise#61705 Forward-Port-Of: odoo/enterprise#61682
The WhatsApp template preview has been enhanced to make it easier for users to distinguish between the header and body text. Bold formatting is now applied to the header text, and a line break separates the two sections, improving the overall clarity and usability of the template preview interface.
Original PR description
Added bold formatting to the header text in the template preview to help users distinguish it from the body text. A new line is added between the header and body text in the template preview for the same reason. Task - 3605612 Forward-Port-Of: odoo/enterprise#59143
Fixed an issue where the Documents module would crash when encountering corrupted PDF files while trying to count pages. The system now gracefully handles these errors by logging them and continuing operation instead of stopping the entire process.
Original PR description
As seen in support tickets, other errors can be raised by PyPDF2 when trying to compute pages count on corrupted files. As we are not going to do any kind of handling and must not crash because of this, we'll simply log and discard any non-exit exception raised. Task-3614532 Forward-Port-Of: odoo/enterprise#59026
Fixed a bug in Studio where clicking "Restore default view" on a form view did not visually update the interface, leaving edited changes visible. The fix ensures that Studio properly reloads after restoring a view to its default state, providing users with immediate visual confirmation that their customizations have been reverted.
Original PR description
Steps to reproduce ================== - Open studio on a form view - Edit something - Click on "Restore default view" => Nothing visually happens and the changes stays Forward-Port-Of: odoo/enterprise#61236 Forward-Port-Of: odoo/enterprise#60009
The Duplicate action was appearing twice in the Payroll app's Salary Structures menu due to the action being defined in two places. This fix removes the duplicate definition, ensuring users see the action only once when selecting salary structure entries. This improves the user experience by eliminating confusion from redundant menu options.
Original PR description
**Steps:** Go to Payroll App > Configuration > Salary > Structures Select checkbox for any entry Now click on the Action Button **Issue:** "Duplicate" action menu is displayed 2 times…
**Steps:** Go to Payroll App > Configuration > Salary > Structures Select checkbox for any entry Now click on the Action Button **Issue:** "Duplicate" action menu is displayed 2 times  **Cause:** Prior to this update, the 'list_controller.js' file in version saas~16.4 did not included the "Duplicate" menu action within the [getActionMenuItems](https://github.com/odoo/odoo/blob/saas-16.4/addons/web/static/src/views/list/list_controller.js#L287-L325) function. However, in the same version, the 'hr.payroll' model defined this action in the [hr_payroll_structure_views.xml](https://github.com/odoo/enterprise/blob/saas-16.4/hr_payroll/views/hr_payroll_structure_views.xml#L132-L143) file, utilized within the 'Salary Structures' in the Payroll app. In version 17.0, the "Duplicate" menu action was added to the [getStaticActionMenuItems](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/list/list_controller.js/#L304-L349) function of 'list_controller.js'. Following the update, despite the addition of the "Duplicate" menu action in the 'list_controller.js' file for version 17.0, it still remained present in the [hr_payroll_structure_views.xml](https://github.com/odoo/enterprise/blob/17.0/hr_payroll/views/hr_payroll_structure_views.xml#L134-L145) file. **Fix:** Removed the 'ir_actions_server_duplicate_structure' from hr_payroll_structure_views.xml, to ensure the same menu action "Duplicate" do not exist twice, in the 'Salary Structures'. Affected Version: 17.0 ~ master Task ID: [3854557](https://www.odoo.com/web#id=3854557&cids=2&menu_id=4720&action=4043&model=project.task&view_type=form)
A bug in the bank reconciliation widget was causing it to receive the wrong type of data for the journal identifier, leading to errors when processing bank transactions. This fix ensures the correct journal ID format is passed through the system, allowing the bank reconciliation feature to work properly.
Original PR description
The context key default_journal_id is being given the record and not the id when opening the bank rec widget. In the bank rec widget, updateJournalState is called, which in some [cases](https://github.com/odoo/enterprise/blob/17.0/account_accountant/static/src/components/bank_reconciliation/kanban.js#L553) will use that context key as journal id to send to [collect_global_info_data](https://github.com/odoo/enterprise/blob/17.0/account_accountant/models/bank_rec_widget.py#L1576). In collect_global_info_data, the journal id is used to browse, which create a recordset with id 'account.journal(x,)' which will trigger an error when exists is called. This change will simply fix the context key to properly take the id as you would expect. opw-3885030
This update fixes Colombian electronic invoice validation issues that arose from DIAN's Anexo 1.9 regulatory changes effective May 1st. The system now correctly handles currency-specific sections and adds required tags for credit and debit notes without referenced invoices, ensuring your Colombian invoices pass all regulatory validations.
Original PR description
Issue: DIAN activated the changes of Anexo 1.9 on May 1st. Currently our documents fail some (new) validations: * The TDC section should only be exported when the invoice is not in COP (since it is used for exchange rate information) * New tags ENC_11 and ENC_12 are needed in case there is no referenced invoice on a debit or credit note. (example discounts for early payments or discounts for rebates) Fix: This commit fixes these issues s.t. the validation passed again. * The TDC section is only displayed if invoice is not in company currency (assumed to be 'COP' anyway in more places) * The new ENC_11 and ENC_12 tags are added (conditionally) **manual forward port** of https://github.com/odoo/enterprise/pull/61841
This fix ensures that when users expand (unfold) lines in financial reports while the "hide at 0" option is enabled, zero-value lines remain hidden as expected. Previously, zero-value child lines would incorrectly reappear after expanding and collapsing a parent line. The fix applies the same visibility logic to both newly loaded and already-loaded lines when expanding.
Original PR description
[FIX] account_reports: hide lines at 0 when unfold Problem: There are two way to see the issue :- 1- Whenever you go to the balance sheet and check on the hide at 0 option Then you go and…
[FIX] account_reports: hide lines at 0 when unfold
Problem: There are two way to see the issue :-
1- Whenever you go to the balance sheet and check on the hide at 0 option Then you go and
unfold-fold-unfold a line with one zero child and non zero child.
The line will with zero will keep showing up.
2- Mentioned in the task-3898147
Issue: when we check the option 'hide at 0' then we fold and unfold.
The flow of func 'unfold Loaded Line' (the already loaded lines) has no clue about the 'hide at 0' option
but on the other hand the func 'unfoldNewLine' (the new added lines) know about the 'hide at 0' option
Solution: Send the lines that we want to unfold to the 'assignLinesVisibility' logic that handle 'hide at 0'
as we do with 'unfoldNewLine'
Minor renames: setLineVisibility >> hideZeroLines, assignLinesVisibility >> setLineVisibility
Task-3898147Fixed an issue where Shiprocket shipping requests were not using the correct phone number when the delivery address was in India but the invoice address was in another country. The system now properly captures and uses the phone number from the actual delivery address, ensuring accurate shipment processing regardless of invoice location.
Original PR description
Before this commit: ============== When the delivery address is in India but the invoice address is outside India, Shiprocket will not consider the shipping address and mobile number from a different country. After this commit: ============== The correct phone/mobile number is provided for the delivery address. opw - 3841506 Forward-Port-Of: odoo/enterprise#61234
The Report Editor in Web Studio was crashing when it encountered database query errors while trying to display report variables. This fix isolates the variable evaluation process to prevent these errors from corrupting the main transaction. Users will now experience more stable report editing without unexpected crashes.
Original PR description
… variables To be able to render a human-readable qweb, we need to evaluate some arbitrary python expressions. Thos can produce bad sql queries because at this point, we are not, by construction in the conditions that produce correct queries (missing records etc....) Before this commit, when an query error occured at that step, the whole transaction was corrupted, and crashed the whole thing. After this commit, we do our partial evaluation things in a separate cursor, to avoid polluting the main one. opw-3815284 Forward-Port-Of: odoo/enterprise#60754
This fix resolves a critical issue preventing upgrades to versions 16.0 and 17.0 in the Norwegian localization module. The "Net profit/Loss for the Year" report had conflicting settings that were causing system errors during installation. The fix removes the incompatible grouping setting to allow the system to process the report correctly.
Original PR description
`Net profit/Loss for the Year` report.line has now an aggregation expression[1] which cannot have a groupby. But as the groupby field was removed instead of set to `eval=False`. The groupby is still there and blocking upgrades to 16.0 and 17.0
[1] https://github.com/odoo/enterprise/pull/52157
```
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 567, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/17.0/l10n_no_reports/data/profit_loss.xml:3
Groupby feature isn't supported by aggregation engine. Please remove the groupby value on 'Net profit/Loss for the Year'
View error context:
'-no context-'
```
Forward-Port-Of: odoo/enterprise#61445This fix corrects an incorrect visibility condition on a report field in the WhatsApp template interface. The issue occurred during a code merge and has been resolved to ensure the field displays properly for users. This ensures the WhatsApp messaging feature works as intended without display errors.
Original PR description
Wrong conflict resolution when forward porting https://github.com/odoo/enterprise/commit/b81c50278a8d55a733c6f1579dc764c19b92e08d Task-3901993
This fix corrects a display issue in the Manufacturing Shop Floor view where production quantities were showing incorrect decimal values (e.g., 1000 displayed as 1000.0000000000001). The solution properly formats quantity values to eliminate floating-point rounding errors, ensuring users see clean, accurate numbers when managing work orders.
Original PR description
Versions -------- - saas-16.4+ Steps ----- 1. Set decimal accuracy of Product Unit of Measure to 5 digits; 2. create a Manufacturing Order for any product; 3. set quantity to 1000 Units; 4. add Work Order and confirm; 5. go to Overview and click on the chosen Work Center. Issue ----- `1000` gets displayed as `1000.0000000000001`. Cause ----- Our float utils introduce tiny rounding errors, especially at higher precisions, which need to be eliminated for display. Solution -------- Use `formatFloat` w/ the precision digits of the `qty_producing` field. opw-3684166 Forward-Port-Of: odoo/enterprise#58880
This update resolves a crash that occurred when users clicked on "Early Discount" while creating new payment terms in the Invoicing module. The fix ensures the company information is properly included when setting up early discount options, preventing the system from encountering missing currency data.
Original PR description
This error arises when the someone clicks on ``Early Discount`` in Payment Terms while creating a new one. Steps to reproduce - Install ``account`` module - Invoicing -> Configuration -> Invoicing ->…
This error arises when the someone clicks on ``Early Discount`` in Payment Terms while creating a new one.
Steps to reproduce
- Install ``account`` module
- Invoicing -> Configuration -> Invoicing -> Payment Terms
- Click on ``New`` -> click on ``Early Discount``
Traceback :
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5848, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.currency()
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1011, in onchange
todo = [
File "addons/web/models/models.py", line 1014, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1127, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6576, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1261, in __get__
self.compute_value(recs)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4931, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/account/models/account_payment_term.py", line 95, in _compute_example_preview
discount_amount = record._get_amount_due_after_discount(record.example_amount, 0.0)
File "addons/account/models/account_payment_term.py", line 67, in _get_amount_due_after_discount
discount_amount_currency = self.currency_id.round(total_amount - (total_amount * (1 - (percentage))))
File "odoo/addons/base/models/res_currency.py", line 217, in round
self.ensure_one()
File "odoo/models.py", line 5851, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
This error occurs from line[1] where the currency ID is getting false within the self, leading to a value error being raised. This happens because of this PR https://github.com/odoo/odoo/pull/161044, where they have removed the default currency from currency ID field.
This commit will fix the above error by adding ``company_id`` field in the payment term from view.
[1] : https://github.com/odoo/odoo/blob/5673ea9d8c6993575bd9ce9c2a931a8738e77e76/addons/account/models/account_payment_term.py#L67
sentry - 5209971284
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects how the inventory system calculates product quantities by fixing an internal parameter error. The system was using incorrect rounding settings, which could lead to inaccurate inventory counts. This fix ensures quantities are rounded correctly according to company standards.
Original PR description
Versions -------- - 17.0+ Issue ----- `precision_rounding` values were being passed incorrectly as `precision_digits` parameters. Solution -------- Pass them as named `precision_rounding` parameters instead. Enterprise branch: https://github.com/odoo/enterprise/pull/61387
This fix resolves an issue where customers couldn't properly remove coupons from orders containing products with different tax rates. When a coupon is applied to such orders, it creates separate discount lines for each tax scenario. The fix ensures the correct coupon line is deleted when removing the coupon, preventing errors and ensuring accurate order totals.
Original PR description
Resolves a problem when removing a coupon from an order containing different tax applications. If an order is composed of products with varying tax rates, the coupon applied generates separate lines for each unique tax situation. This includes non-taxed products, products with individual taxes, and combinations thereof. The purpose of this commit is to fix the management of coupon deletion in cases where the coupon generates multiple lines for different tax scenarios. Adjusting the recovery process to select the first coupon line identifier, ensuring that the correct line is targeted for deletion in scenarios with multiple tax-related coupon lines. Example: - Product A (non-taxed) - Product B (Tax A) - Product C (Tax B) - Product D (Tax A and B) The coupon would generate four separate lines for non-taxed, Tax A, Tax B, and Tax A & B scenarios, respectively. opw-3693319 Forward-Port-Of: odoo/odoo#163333 Forward-Port-Of: odoo/odoo#161817
This update resolves a critical bug that prevented new users from logging in through LDAP authentication when the system was configured to automatically create user accounts. Previously, the system would crash with an error when an LDAP user without an existing account attempted to log in. This fix ensures that the automatic user creation process works smoothly, allowing organizations using LDAP authentication to onboard new users without manual intervention.
Original PR description
Steps: - Set up LDAP authentication with Create User enabled and a Template User set - Log in with an LDAP identity that doesn't have an account yet Get odoo.exceptions.MissingError: Record does not exist or has been deleted See https://github.com/odoo/odoo/issues/41060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162456
This fix resolves an issue where users were unable to remove phone numbers from the SMS blacklist when clicking the unblock button in their contact records. The problem was in how the system searched for blacklisted numbers when using certain search filters. Users can now successfully unblacklist phone numbers directly from their contacts.
Original PR description
Current behavior: --- When trying to un-blacklist a phone number from the contacts, it doesn't do anything. Steps to reproduce: --- 1. Install mass_mailing_sms 2. Go to Contacts 3. Create a new contact 4. Add a mobile phone number (ie: +917896525894) 5. Go to SMS Marketing 6. Go to Configuration > Blacklisted phone numbers 7. Click on new and input the same number then confirm 8. Click on Blacklist 9. Go back to the contact 10. Before the field, a block icon has appeared 11. Click on it then confirm 12. Nothing happens Cause of the issue: --- The search override was always checking for a string, but when the keyword 'in' is used in the domain, the last element is a list. opw-3757193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162915 Forward-Port-Of: odoo/odoo#155457
This fix corrects a tax reporting issue in the Point of Sale module where QR code-generated invoices were incorrectly doubling VAT amounts instead of properly reversing them. The problem occurred when closing POS sessions with Belgian tax settings, causing the tax report to show inflated figures. The fix ensures that reversed accounting entries are properly marked so tax amounts are correctly accounted for in financial reports.
Original PR description
With BE localization Enable 'Use QR code on ticket' in Settings Open POS Session Add a Product with 21% Tax Pay > Save QR link for later Close Pos session Access QR link, generate invoice Check Accounting>Reporting>Tax Report Issue: Line '03 - Operations subject to 21% VAT' will account twice the product amount instead of canceling it This occurs because when reverting the POS closing entry we create an entry having amounts with inverted signs and same tax tags. We also need to set the flag `tax_tag_invert` to ensure the amount correctly accounted as reverse opw-3815770 opw-3821017 Forward-Port-Of: odoo/odoo#163685 Forward-Port-Of: odoo/odoo#161531
This update corrects the styling of payment information popups in the accounting module. A deprecated custom style class was replaced with the standard Bootstrap styling class, ensuring the payment field displays correctly and consistently with the rest of the application.
Original PR description
o_popover_header was removed on [1], so the bootstrap class popover-header could be used instead. References: - [1] https://github.com/odoo/odoo/commit/777eb767 **16.0:**  **17.0 previous this commit:**  **17.0 after this commit:**  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that website styling input fields with fake units or step controls properly validate numeric values. Previously, these fields accepted invalid entries like comma-separated decimals, which caused styling errors. Now they correctly parse and validate numeric inputs, preventing compilation errors and ensuring form fields work as intended.
Original PR description
Since commit [1], a fake unit can be specified on `InputUserValueWidget` widgets, thanks to the `data-fake-unit` attribute. It allows to display a unit whose purpose is only to show a dummy unit and…
Since commit [1], a fake unit can be specified on `InputUserValueWidget` widgets, thanks to the `data-fake-unit` attribute. It allows to display a unit whose purpose is only to show a dummy unit and which does not need to be converted to other ones. However, it is still a unit, so the value written in the input should still be considered as numeric and should therefore be processed as such (e.g. checking if it has the correct format or if it is well a number). This is currently not the case, since only values with real units (i.e. with `data-unit`) allows to go through these checks. This means that fake unit inputs can accept any values, which can cause errors if only numeric ones were expected (e.g. for numeric CSS properties). The same goes for inputs without unit but still having a step specified. Indeed, the `data-step` attribute allows to increase/decrease the value by using the keyboard arrows, which implies that the value should be considered as numeric. Note that no option is really broken by that, as they generally either parsed the value themselves or accepted the value without any traceback assuming that the user should write logical values and should not be surprised if it does not work. But the comma use case makes it worth being fixed. This commit adds the fake unit and step cases to the checks, so the input values are considered as numeric and can properly be parsed to numbers. Steps to reproduce: For the fake unit case: - In website edit mode, go to the "Theme" tab in the right panel. - In the "Paragraph" section, set the "Line Height" option to a decimal number but with a comma instead of a period. - Save. => There is a style compilation error, because the value was used as is in the CSS file, which is not correct. If it was a real unit, the value would have been cut before the comma by the `parseFloat` function. For the step case: - In edit mode, drop the "Form" snippet. - Add a new field and set its "Type" option to "File Upload". - Set the "Max # Of Files" option to a decimal number but with a comma. => If we wrote a number bigger than 1 to allow uploading multiple files, the field will stay as a single file input. [1]: https://github.com/odoo/odoo/commit/388e4bb2bfcaebdd4ff30277fb49a034592d7086 opw-3635886 Forward-Port-Of: odoo/odoo#163160
When users restore a default view in Studio after customizing it, the old view was incorrectly displayed instead of the new one. This fix ensures that the system properly clears its internal cache when views are removed, so users always see the correct view after making changes.
Original PR description
Steps to reproduce ================== - Enable debug mode - Go to studio - Add a new field - Switch to the view tab - Restore the default view => The old view is displayed Cause of the issue ================== The studio view is unlinked [0] but the template cache is not cleared --- [0]: https://github.com/odoo/enterprise/blob/b97f4c440d020141940a3d9e05aa25c9847ae5b9/web_studio/controllers/main.py#L448 Forward-Port-Of: odoo/odoo#162953
This fix prevents the translation of the udt:Indicator field in EDI documents, ensuring it only contains "true" or "false" values instead of translated text like "faux". This resolves compatibility issues with the Chorus Pro platform that would otherwise reject these documents with an exception.
Original PR description
The tag `udt:Indicator` should either be "true" or "false" but not "faux", which will raise an exception on the Chorus Pro platform. opw-3859249 Forward-Port-Of: odoo/odoo#163990
Two missing account translations have been added to the Italian localization module. This ensures that Italian users will see properly translated account names in the system, improving the user experience for businesses operating in Italy.
Original PR description
Two account translations were missing in the Italian localization. We're adding them here. Forward-Port-Of: odoo/odoo#163999
This fix ensures that styled text elements in the web editor are properly preserved during content cleanup. Previously, the system was incorrectly removing formatting tags that had special styling effects, even though they were important for the visual appearance. Now the system correctly recognizes and keeps these styled elements intact.
Original PR description
Commit [1] made sure `span`s without attributes are removed, as they're useless. However, it did not take pseudo-elements into account. This commit ensures that if there is no attribute but a pseudo-element can be detected, the tag is not removed. [1]: https://github.com/odoo/odoo/commit/a26e27c85e6a0685b6cf4d2dbab90453899df34c opw-3881401 Forward-Port-Of: odoo/odoo#163627 Forward-Port-Of: odoo/odoo#163392
A test in the web module was using hardcoded dates that caused automated build processes to fail. This fix skips that problematic test to restore normal build operations. This is a quick maintenance fix to keep development workflows running smoothly.
Original PR description
Quick fix to unlock runbot and mergebot builds. Forward-Port-Of: odoo/odoo#164141