Daily updates from Odoo
Navigate
Branch
Thursday, July 18, 2024
37 changes
12 changes
Resolved issues and error corrections
Point of Sale records now keep linked information when saved or transferred, even if some related data was not loaded in the session. This helps prevent missing customer, order, or other linked details in certain Point of Sale workflows.
Original PR description
Before this commit, serializing a record would omit x2many and many2one fields if their related models were not loaded into the PoS. opw-3998097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. Since the function modified has been updated in 17.2, another PR will be necessary. See https://github.com/odoo/odoo/pull/168634 task-3964942 Forward-Port-Of: odoo/odoo#170741 Forward-Port-Of: odoo/odoo#168638
Original PR description
When printing an invoice including a fixed tax, we don't want the base amount to be displayed after said tax, since the fixed computation doesn't take into account said amount. Added a check to differentiate fixed taxes from other and adapt display accordingly. Since the function modified has been updated in 17.2, another PR will be necessary. See https://github.com/odoo/odoo/pull/168634 task-3964942 Forward-Port-Of: odoo/odoo#170741 Forward-Port-Of: odoo/odoo#168638
### Issue: The `test_backorder_batching_2` is failling on the nightly community build of 17.0 because the order of the final records is not the same. ### Fix: The problematic assert on the product identity was not important and has been removed. Follow up of commit 386b32e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171623 Forward-Port-Of: odoo/odoo#171547
Original PR description
### Issue: The `test_backorder_batching_2` is failling on the nightly community build of 17.0 because the order of the final records is not the same. ### Fix: The problematic assert on the product identity was not important and has been removed. Follow up of commit 386b32e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171623 Forward-Port-Of: odoo/odoo#171547
16.0 update changes the back-end design interpretation, leading to a width display issue with mailing_list_view_form_simplified. I remove some useless <group> tags in order to fix the width of the fields in the form task-4042993 Forward-Port-Of: odoo/odoo#173348
Original PR description
16.0 update changes the back-end design interpretation, leading to a width display issue with mailing_list_view_form_simplified. I remove some useless <group> tags in order to fix the width of the fields in the form task-4042993 Forward-Port-Of: odoo/odoo#173348
Issue ---- Demo data company data contains a phone number of a real person, who receives phone calls from people asking to buy stuff :) note: extension of 05f344b6a0b4cd71b4d0f0abcb4825856fdf4edc after finding the number is in other views as well. Steps ---- Number is available on website footer. Cause ---- A real number is used in demo data. opw-3853066 Forward-Port-Of: odoo/odoo#173235 Forward-Port-Of: odoo/odoo#171192
Original PR description
Issue ---- Demo data company data contains a phone number of a real person, who receives phone calls from people asking to buy stuff :) note: extension of 05f344b6a0b4cd71b4d0f0abcb4825856fdf4edc after finding the number is in other views as well. Steps ---- Number is available on website footer. Cause ---- A real number is used in demo data. opw-3853066 Forward-Port-Of: odoo/odoo#173235 Forward-Port-Of: odoo/odoo#171192
Steps to reproduce: - Install planning and switch to calendar view - try resizing the pill that is already resizable (pills that span for multiple days) Issue: pill resizing is not working as expected. Cause: the end date wasn't being calculated correctly for this. Fix: after this commit, the end date is calculated correctly. task-3326281 Forward-Port-Of: odoo/odoo#139893
Original PR description
Steps to reproduce: - Install planning and switch to calendar view - try resizing the pill that is already resizable (pills that span for multiple days) Issue: pill resizing is not working as expected. Cause: the end date wasn't being calculated correctly for this. Fix: after this commit, the end date is calculated correctly. task-3326281 Forward-Port-Of: odoo/odoo#139893
Currently if there are no IR rules preventing a low right user to write on a record, no error notification will appear when the user tries to add a property field to the child model since no error is raised in the checkDefinitionWriteAccess method. If this user does not have access rights on the model of the parent record an unwanted traceback will appear since nothing prevents him from trying to add a property field to the model Here we're using the canChangeDefinition which is loaded
Original PR description
Currently if there are no IR rules preventing a low right user to write on a record, no error notification will appear when the user tries to add a property field to the child model since no error is raised in the checkDefinitionWriteAccess method. If this user does not have access rights on the model of the parent record an unwanted traceback will appear since nothing prevents him from trying to add a property field to the model Here we're using the canChangeDefinition which is loaded by checkingAccessRight on the user at the start of the component startup Task-3815748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158165
This commit improves the performance of the related_models.js file by using Map instead of Object and Array to keep ordering of records. This commit also improves the performance of the product_screen.js file by filtering product after slicing the product list. Forward-Port-Of: odoo/odoo#172303
Original PR description
This commit improves the performance of the related_models.js file by using Map instead of Object and Array to keep ordering of records. This commit also improves the performance of the product_screen.js file by filtering product after slicing the product list. Forward-Port-Of: odoo/odoo#172303
Currently, invoices cannot be sent to TicketBAI if the invoice sequence does not end with `/<sequence_number>`. ### Steps to Reproduce * Install `l10n_es_edi_tbai`. * Ensure your invoice has a sequence that does not contain a `/`. * Attempt to send the invoice through TicketBAI. A traceback error occurs: `ValueError: not enough values to unpack (expected 2, got 1)` ### Cause When parsing invoice sequence numbers for TicketBAI, the system splits the sequence number by the rightm
Original PR description
Currently, invoices cannot be sent to TicketBAI if the invoice sequence does not end with `/<sequence_number>`. ### Steps to Reproduce * Install `l10n_es_edi_tbai`. * Ensure your invoice has a sequence that does not contain a `/`. * Attempt to send the invoice through TicketBAI. A traceback error occurs: `ValueError: not enough values to unpack (expected 2, got 1)` ### Cause When parsing invoice sequence numbers for TicketBAI, the system splits the sequence number by the rightmost `/`. This fails when the sequence number does not contain a `/`. opw-3959956 Forward-Port-Of: odoo/odoo#168654
Before this commit, translations in data modules were not taken into account as there were not extracted nor loaded. This commit adds the possibility to add a i18n folder that contains the translations for the imported module task-3734243 To-do in master: - Merge `get_po_paths` and `get_po_paths_env` - Add an argument `env` to `_load_module_terms` so that `_import_module` (in base_import_module) calls `_load_module_terms` directly. Forward-Port-Of: odoo/odoo#165449
Original PR description
Before this commit, translations in data modules were not taken into account as there were not extracted nor loaded. This commit adds the possibility to add a i18n folder that contains the translations for the imported module task-3734243 To-do in master: - Merge `get_po_paths` and `get_po_paths_env` - Add an argument `env` to `_load_module_terms` so that `_import_module` (in base_import_module) calls `_load_module_terms` directly. Forward-Port-Of: odoo/odoo#165449
Current behavior: --- On a mobile phone, using Chrome, when scanning a barcode that begins with the FNC1 character, ']C1' will be added to the final code. Expected behavior: --- ']C1' should be removed from the final code Steps to reproduce: --- 1. On a mobile phone, with chrome 2. Go to the barcode module 3. Scan a barcode starting with FNC1 4. Code will begin with ]C1 Cause of the issue: --- https://github.com/odoo/odoo/blob/321d16950ee9dcf4d722ecbfe0a49ca8f7d855a6/addons
Original PR description
Current behavior: --- On a mobile phone, using Chrome, when scanning a barcode that begins with the FNC1 character, ']C1' will be added to the final code. Expected behavior: --- ']C1' should be removed from the final code Steps to reproduce: --- 1. On a mobile phone, with chrome 2. Go to the barcode module 3. Scan a barcode starting with FNC1 4. Code will begin with ]C1 Cause of the issue: --- https://github.com/odoo/odoo/blob/321d16950ee9dcf4d722ecbfe0a49ca8f7d855a6/addons/web/static/lib/zxing-library/zxing-library.js#L6928 zxing-library is adding ']C1' to barcodes starting with a FNC1 character opw-3853913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163404
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includ
Original PR description
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'.…
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includes only button 'Scan' with display utility classes that hide the button in mobile. Similarly for 'Create Report' button in list. In Kanban, the button 'Create Report' has not been added. Fix: In the list view, 'Upload' button was added for desktop view, and the classes of the 'Scan' button were changed to display it in mobile view. The display utility classes for 'Create Report' were removed, so the button is displayed in mobile. In kanban view, button 'Create Report' was added. The main div of web.KanbanView.Buttons is replaced to ensure that the mobile view buttons are also displayed correctly. Without replacing it, the buttons 'New' and 'Scan' do not match the height of 'Create Report'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172442 Forward-Port-Of: odoo/odoo#169396
10 changes
Resolved issues and error corrections
This update adds automated test coverage for a previously fixed POS IoT printer issue. It helps reduce the risk of the same problem returning in future releases, with no direct change to user-facing behavior.
Original PR description
This commit is just adding a test for the fix made here (https://github.com/odoo/odoo/pull/165798) opw-3792576
Code cleanup and technical improvements
Spreadsheet pivot measures now use explicit identifiers to stay aligned with the latest spreadsheet engine changes. This is an internal cleanup that helps keep spreadsheet reports, filters, templates, and collaboration features reliable without changing day-to-day user workflows.
Miscellaneous changes
**Steps to reproduce**: - Create an MO for Stool - In the shop floor, open the "assembly" step of the created WO **Currently**: scanning barcode for back/skip does not do anything. **After this commit**: scanning the barcode executes the expected command. task-4047193 Forward-Port-Of: odoo/enterprise#66617 Forward-Port-Of: odoo/enterprise#66579
Original PR description
**Steps to reproduce**: - Create an MO for Stool - In the shop floor, open the "assembly" step of the created WO **Currently**: scanning barcode for back/skip does not do anything. **After this commit**: scanning the barcode executes the expected command. task-4047193 Forward-Port-Of: odoo/enterprise#66617 Forward-Port-Of: odoo/enterprise#66579
Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#66736 Forward-Port-Of: odoo/enterprise#65609
Original PR description
Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#66736 Forward-Port-Of: odoo/enterprise#65609
With odoo/odoo#138937, making these declarations in enterprise isn't required anymore and everything can be centralized in community The expense/revenue deferred account declarations will be created in community in odoo/odoo#173370 meaning this should now be removed from enterprise task-383985 Forward-Port-Of: odoo/enterprise#66763
Original PR description
With odoo/odoo#138937, making these declarations in enterprise isn't required anymore and everything can be centralized in community The expense/revenue deferred account declarations will be created in community in odoo/odoo#173370 meaning this should now be removed from enterprise task-383985 Forward-Port-Of: odoo/enterprise#66763
- Go to Dashboards > Configuration > Dashboards - Open the Human Resources section - Open the payroll dashboard - Open the Period filter configuration panel - the field matching period offset of pivot 3 and 4 are inverted. In the Data sheet, the column named "current" (pivot 3) is filtering on previous, and the one called "previous" (pivot 4) is not filtering on anything. Note that this fix is only active on new databases or if the dashboard is deleted then the module "spreadsheet_das
Original PR description
- Go to Dashboards > Configuration > Dashboards - Open the Human Resources section - Open the payroll dashboard - Open the Period filter configuration panel - the field matching period offset of pivot 3 and 4 are inverted. In the Data sheet, the column named "current" (pivot 3) is filtering on previous, and the one called "previous" (pivot 4) is not filtering on anything. Note that this fix is only active on new databases or if the dashboard is deleted then the module "spreadsheet_dashboard_hr_payroll" is updated. Task: 4056412 Forward-Port-Of: odoo/enterprise#66760
The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is that the list of IDs can be gigantic, leading to performance issues. Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report. That PR then simply bypassed the issue by passing t
Original PR description
The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is…
The model 347 report is adding a partner exclusion domain in the search call. It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf. The issue is that the list of IDs can be gigantic, leading to performance issues. Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report. That PR then simply bypassed the issue by passing the domain as `forced_domain` so it would not go through the `literal_eval()` call (which is the one crashing when the list is too long). But even after that fix, we still provide the list of IDs into the domain and so ultimately in the SQL request, which can still be an issue if there are too many. This commit improves that by passing the SQL subquery (the one fetching the partners to exclude) directly into the domain, so the SQL query won't contain any list of IDs but just a sub-select. It does have better performance within PostgreSQL for big lists. Note that the `SQL()` query is surrounded by parentheses on purpose, as it doesn't work otherwise. This might be improved at the ORM level in the future with odoo/odoo#163560. Task [link](https://www.odoo.com/web#model=project.task&id=3895983) task-3895983 Forward-Port-Of: odoo/enterprise#66794 Forward-Port-Of: odoo/enterprise#62866
Currently, the external `l10n_nl_reports` test checking the validity of the generated XML file is failing due to some missing user. By adding the `enter_test_mode` method, we make sure that the user will be maintained all throughout the testing process like this is done for the non-external test. Forward-Port-Of: odoo/enterprise#66500
Original PR description
Currently, the external `l10n_nl_reports` test checking the validity of the generated XML file is failing due to some missing user. By adding the `enter_test_mode` method, we make sure that the user will be maintained all throughout the testing process like this is done for the non-external test. Forward-Port-Of: odoo/enterprise#66500
The current code is taking the residual amount instead of the statement line amount. When doing a reco model 'percentage_st_line' on 1000: Line 1 - 74% Line 2 - 24% Line 3 - 2% We get: 1000 * 0.74 = 740 (1000 - 740) * 0.24 = 62.4 (1000 - 740 - 62.4) * 0.02 = 3.95 Instead of: 1000 * 0.74 = 740 1000 * 0.24 = 240 1000 * 0.02 = 20 task_id: 3940370 Forward-Port-Of: odoo/enterprise#66735 Forward-Port-Of: odoo/enterprise#62884
Original PR description
The current code is taking the residual amount instead of the statement line amount. When doing a reco model 'percentage_st_line' on 1000: Line 1 - 74% Line 2 - 24% Line 3 - 2% We get: 1000 * 0.74 = 740 (1000 - 740) * 0.24 = 62.4 (1000 - 740 - 62.4) * 0.02 = 3.95 Instead of: 1000 * 0.74 = 740 1000 * 0.24 = 240 1000 * 0.02 = 20 task_id: 3940370 Forward-Port-Of: odoo/enterprise#66735 Forward-Port-Of: odoo/enterprise#62884
When the document is filled in with the OCR values, we need to use the document's company context, otherwise it can lead to inconsistent values being selected. For example, the payment terms of a supplier are company dependent, so we need the right company context to select the one from the company of the invoice. Related task: [#3902741](https://www.odoo.com/odoo/project.task/3902741?cids=1) Forward-Port-Of: odoo/enterprise#66779 Forward-Port-Of: odoo/enterprise#66168
Original PR description
When the document is filled in with the OCR values, we need to use the document's company context, otherwise it can lead to inconsistent values being selected. For example, the payment terms of a supplier are company dependent, so we need the right company context to select the one from the company of the invoice. Related task: [#3902741](https://www.odoo.com/odoo/project.task/3902741?cids=1) Forward-Port-Of: odoo/enterprise#66779 Forward-Port-Of: odoo/enterprise#66168
15 changes
Enhancements to existing features
This update improves the Brazilian electronic invoice system by standardizing address formatting and adding important details like terms and conditions and delivery dates to invoices. These enhancements make the customer-facing PDF invoices generated by Avatax more complete and easier to understand.
Original PR description
This homogenizes the address format we send for each location and adds the terms and conditions and delivery date. This makes the customer invoice PDF that Avatax generates more complete and less confusing for users and their customers. task-3894745
This update improves the city selection experience when entering customer information in Mexico. Instead of showing all cities across the entire country (which is confusing when many cities share the same name), cities are now filtered to show only those in the selected state. This makes it much faster and easier to find and select the correct city.
Original PR description
When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries.
So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue.
task: 4027290
Forward-Port-Of: odoo/enterprise#66495Resolved issues and error corrections
The Saskatchewan tax report now includes the missing “Total before Sales” line. This helps Canadian businesses produce a more complete and accurate tax report for Saskatchewan filings.
Original PR description
Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926
List views no longer show separator entries as optional fields when configuring displayed columns. This removes confusing choices that have no data value and prevents a related browser console warning.
Original PR description
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`)
information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated.
Also it avoids a warning in the JS console ("Missing widget: separator
for field of type separator").
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prTimesheets now link analytic accounts to the correct custom analytic plan instead of always using the default Projects plan. This helps ensure accounting reports show timesheet costs under the right plan when companies use customized analytic structures.
Original PR description
Steps to reproduce: ------------------- 1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan) 2. Create again a new…
Steps to reproduce:
-------------------
1. Create a new analytic plan and set it as the default analytic plan in Project settings (it must be different from the 'Projects' plan)
2. Create again a new analytic plan and set its parent to the one you have created in step 1.
3. Create a new analytic account linked to the plan you have just created in step 2.
4. Create a new project and a new task
5. Link the analytic account you have created in step 3. to the task
6. Create a new timesheet linked to the task
7. In Accounting > Analytic Items, the analytic account of the timesheet will not be reported in the plan you created in step 2.
Fix:
-------------------
The 'Projects' plan (the default one) represents the 'account_id' field of analytic.account.line, other plans have names with the following format: 'x_plan{plan.id}_id' (they are fields created on the fly).
When creating a timesheet we were always setting its account.analytic.account to the 'account_id' field by default and ignoring the other plans.
The fix we propose is to look at the top-level plan of the account.analytic.account of the timesheet being created or modified, and link it to the plan it belongs to.
Note that we keep the 'account_id' ('Projects' plan) updated even if the account does not belong to this plan because this field is used in other parts of the code.
Linked PR: https://github.com/odoo/odoo/pull/139225
task-3820916
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects a guided tour step for the Field Service Management worksheet feature. Previously, the tour would advance without requiring users to fill in the worksheet name field as intended. The fix ensures the tour properly waits for user input before proceeding to the next step.
Original PR description
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542
This fix corrects how the system determines the acquisition date for fixed assets created from invoices. Previously, the accounting date was incorrectly used instead of the invoice date. Now the system properly uses the invoice date when available, ensuring assets are recorded with the correct acquisition date for financial reporting purposes.
Original PR description
The accounting date is used as acquisition date instead of
bill date.
Steps:
2 flows leads to the bug:
1) - Create and confirm a bill with different accoutning and bill dates
- Open a new asset form and click on "select related purchases"
button
- Select the bill
-> The acquisition is set as the accounting date instead of the bill
date
2) - Set the expense account to create an asset
- Create and confirm a bill with line using the expense account
- An asset should be created, open it
-> Same as before
Cause:
In the `_compute_acquisition_date`, we use the field `date` from
`account.move.line` which is a related field to the `date` field of
`account_move`
Fix:
In the compute, we get the `invoice_date` field from the related move
of each `original_move_line_ids` then fallback to `date` if it is not
set (case of journal entries)
opw-4000259
Forward-Port-Of: odoo/enterprise#66831
Forward-Port-Of: odoo/enterprise#65769POS staff can now settle customer dues directly from the point of sale system without requiring accounting permissions. The system has been updated to show accurate due amounts in real-time, including dues settled in the current session, making it easier for POS users to manage customer payments.
Original PR description
Previously, only users with accounting rights could see the `total_due` from the POS and therefore only they could settle dues from the POS. Basic POS users should be able to settle dues. This commit allows them to do so without granting them unnecessary rights, by creating an exception in the `get_total_due` method for users in `group_pos_user`. opw-[3976254](https://www.odoo.com/odoo/project.task/3976254?cids=1)
This fix resolves an issue where tax report lines were showing zero values when users switched to a translated language. The problem occurred because tax tag names were being translated, but the report formulas that reference these tags were not. The fix ensures that tax tags are always matched using the base English language to maintain consistency between report formulas and tag names.
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#65030
Fixed a critical issue where subscription invoices with negative amounts (credit notes) could incorrectly charge customers instead of refunding them. The system now blocks automatic payments for negative amounts and flags these invoices for manual review, preventing unintended charges while maintaining data integrity.
Original PR description
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe if a bug occurs, we decide to prevent the payment request if the amount is negative. In that case, we keep the draft invoice and keep the "payment_exception" flag to avoid running the subscription invoice cron again on that contract. opw-3874964
This update improves how the balance sheet test handles database operations by reducing the number of temporary savepoints created during testing. Previously, the system created a new savepoint for each test iteration, which could exceed database limits and cause performance issues. Now it creates a single savepoint and reuses it, making tests run more efficiently.
Original PR description
Instead of calling `env.cr.savepoint()` in a loop, which will create a savepoint at every iteration, we should create a single savepoint and rollback to it at the end of every subtest. In Postgres, the number of sub-transactions that may exist in active transactions has a hard limit of 64 before sub-transactions are stored on disk. It's therefore best practice to limit the number of savepoints we create. See also https://github.com/odoo/odoo/pull/167236 Forward-Port-Of: odoo/enterprise#66322
This fix ensures the eTims button only appears on vendor bills when the company is based in Kenya. Previously, the button was showing for all countries, which could confuse users in other regions. This improves the user experience by hiding irrelevant features based on the company's location.
Original PR description
…bill
This fix prevents Web Studio from crashing when opening invoices that have empty group attributes in their configuration. The issue occurred when certain modules set empty group values, which the system couldn't process correctly. The fix adds a simple check to skip empty group values, allowing users to open and edit invoices in Web Studio without errors.
Original PR description
Steps to reproduce ================== - Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale - Go to invoices - Open studio ``` enterprise/web_studio/models/ir_ui_view.py:103 in…
Steps to reproduce
==================
- Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale
- Go to invoices
- Open studio
```
enterprise/web_studio/models/ir_ui_view.py:103 in _postprocess_access_rights
100 │ │ │ for node in tree.xpath('//*[@groups]'):
101 │ │ │ │ node_groups[node] = node.get('groups')
❱ 103 │ │ │ │ if not self.user_has_groups(node.get('groups')):
odoo/odoo/models.py:1550 in user_has_groups
❱ 1550 │ │ │ if group_ext_id[0] == '!':
1551 │ │ │ │ not_has_groups.append(group_ext_id[1:])
IndexError: string index out of range
```
Cause of the issue
==================
The l10n_fr_invoice_addr sets an [empty group] attribute on a node. When opening studio, user_has_groups is called with the groups attribute value. In this case, it's an empty string and it fails.
Solution
========
Since an empty group is [allowed] by the ORM, we simply check that the value is not empty before calling user_has_groups
---
[empty group]: https://github.com/odoo/odoo/blob/00a78373f87c84dfa8ffa97ca255cf01368cd423/addons/l10n_fr_invoice_addr/models/account_move.py#L17
[allowed]: https://github.com/odoo/odoo/blob/a913272136182e6f4b1e28337686dd14616ea0ca/odoo/addons/base/tests/test_views.py#L2791
opw-4046078
Forward-Port-Of: odoo/enterprise#66595Previously, when employees viewed a stock picking in the barcode system, they were automatically assigned as the responsible person, even if they only looked at it without making any changes. This fix ensures users are only assigned as responsible when they actually perform an action like validating or editing a line, not when simply viewing the picking.
Original PR description
Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484
Miscellaneous changes
16.0 update changes the back-end design interpretation, leading to a width display issue with mailing_list_view_form_simplified. I remove some useless <group> tags in order to fix the width of the fields in the form task-4042993 Forward-Port-Of: odoo/odoo#173348
Original PR description
16.0 update changes the back-end design interpretation, leading to a width display issue with mailing_list_view_form_simplified. I remove some useless <group> tags in order to fix the width of the fields in the form task-4042993 Forward-Port-Of: odoo/odoo#173348