Thursday, October 31, 2024
21 changes · 17.0
Enhancements to existing features
This change lets related customizations define their own rules for which sales order lines should create projects or tasks. It helps businesses adapt the sales-to-delivery workflow to their specific processes without changing the core behavior for standard users.
Original PR description
Description of the issue/feature this PR addresses: - allow inheriting modules to define own logic about how sale lines should create projects/tasks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The Malaysia e-invoicing settings no longer show an import journal option for supplier bills because the related government API support is not available for that purpose. This prevents users from configuring a feature that cannot currently work and includes small reliability fixes in the same area.
Original PR description
Importing bills was a planned feature that got scrapped due to limitation of the government api. The endpoints that should allow that have a warning asking to not use them for that purpose at the moment. By mistake, the field stayed when the feature was removed. We will remove it from the view for now, and evaluate later on if we should simply remove it, or if the feature may be added later on. This also iron out some small issues that went through with the original pr. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When viewing more than 1 viewable file in the FileViewer, the navigation buttons `<` and `>` are barely visible. This commit fixes it by putting white icon on dark rounded background for the buttons. Task-4056907 <img width="2559" alt="Screenshot 2024-10-30 at 17 34 03" src="https://github.com/user-attachments/assets/b26cc55c-d2e0-47f4-8c60-99fd55a46bf2"> Backport of https://github.com/odoo/odoo/pull/185909 Forward-Port-Of: odoo/odoo#185910
Original PR description
When viewing more than 1 viewable file in the FileViewer, the navigation buttons `<` and `>` are barely visible. This commit fixes it by putting white icon on dark rounded background for the buttons. Task-4056907 <img width="2559" alt="Screenshot 2024-10-30 at 17 34 03" src="https://github.com/user-attachments/assets/b26cc55c-d2e0-47f4-8c60-99fd55a46bf2"> Backport of https://github.com/odoo/odoo/pull/185909 Forward-Port-Of: odoo/odoo#185910
The Fleet app attachment screen now shows the correct upload action on mobile and removes the confusing New button that did not work. This makes it easier for users to add driver history attachments without encountering inaccessible or non-functional controls.
Original PR description
Steps to reproduce: - Fleet app > Any vehicle > Drivers History > Attachments - In mobile view > Primary button 'Upload' is not accessible - Primary button 'New' does not do anything This happens because the controller cannot find a form view for ir.attachment in fleet, which is the default view type for record creation (barring quickcreate stuff). Also d-none class hides the display of the 'Upload' button but the dropdown menu arrow is still there which is rather confusing. Seeing how both buttons serve the same purpose, there is no need to keep 'New' which has no corresponding view. opw-4229756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new lot number from a receipt now works directly from the quick-create option instead of opening an extra edit window. This keeps warehouse users in the intended flow and reduces unnecessary steps when receiving tracked products.
Original PR description
Steps: - enable lots & serials - enable 'Use Existing ones' in operation type 'Receipts' - create a product A tracked by lot - create a receipt operation, add product A, add quantity, mark as todo - open burger menu, add a new lot number, select 'Create' (not 'Create and edit...') Issue: `default_product_id` missing in the context because of `getFieldContext` in utils.js filtering it out. Due to that, Odoo will open a new popup as if we selected 'Create and edit...'. Fix: Remove the lot line in pick_from.js, it is not needed and there's another lot_id in the xml to use. opw-4064895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Time off requests based on extra hours no longer create a negative overtime entry while they are still in draft. This prevents employees' extra hour balances from being reduced before a request is confirmed or approved.
Original PR description
Before this commit, when a time off request based on extra hours was set to draft, a new overtime record with negative duration was created. This commit makes sure that the record is only created when the time off request is in the state `confirm` or `validate`. task-4096548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the timer button on timesheet rows was hidden when users scrolled horizontally within the 'My Timesheets' grid view. Now, the timer button remains visible regardless of horizontal scrolling, ensuring consistent functionality for users managing their timesheets.
Original PR description
Before this commit, when the user horizontally scrolls in the grid view of `My Timesheets` menu, the grid timer button on each row is hidden, only the row title is kept. This commit keeps the grid timer button is kept when the user horizontally scroll in the grid view of `My Timesheets` menu as it is the case for the row title. task-3378510
This update corrects a technical issue related to how sales order item data is processed within the Odoo Enterprise system. By using a lambda function, the system now correctly handles inheritance and returns the expected data format (a list), ensuring accurate sales order item calculations. This improves the reliability of sales reporting.
Original PR description
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model. This issue is fixed by using a lambda function to call the domain method. Forward-Port-Of: odoo/enterprise#72931
This update fixes a bug in the recruitment test that prevented accurate skill detection from OCR results. The changes ensure the test runs correctly after all modules are installed and improve the accuracy of skill matching by refining the search pattern. This enhances the reliability of candidate skill identification.
Original PR description
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`.
This update resolves a bug where certain fields in web studio reports weren't translating correctly when editing invoices. The issue stemmed from how the system handled indentation in the report XML, leading to a mismatch between the edited content and the translation keys. This ensures all reports, regardless of language, display accurate translations.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to an invoice - Set the partner's language to French - Print the Invoice without Paiement PDF - Open studio - Edit that report - Add a new text below the invoice header - Save the report and exit studio - Print the same report => Some fields aren't translated Cause of the issue ================== When editing the report, ```xml <strong>Due Date:</strong><br/> ``` is converted to ```xml <strong>Due Date:</strong> <br/> ``` This no longer matches the translation key. opw-3730267
This update resolves a bug where the mass depreciation action incorrectly recalculated posted assets. The fix restricts the action to only draft assets, aligning with existing functionality and preventing unnecessary calculations. This ensures accurate depreciation reporting.
Original PR description
As of today, the action_account_asset_compute_depreciations server action allows to recompute the board on posted assets by calling compute_depreciation_board.
There is two issues with that:
- compute_depreciation_board shouldn't be called on assets that could already have moves without providing a date
- This action should reflect what can be done on the form view (only applies to draft)
The easy fix is to update the action to only affect draft entries.
Task id # 4297606This update resolves an issue where timesheet grids weren't correctly displaying times due to time zone discrepancies. This fix ensures accurate time representation for timesheet entries, improving data reliability. It's a follow-up to a previous bug fix.
Original PR description
small fix related to following bugfix: https://github.com/odoo/enterprise/pull/72526
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185419
Original PR description
Since domain methods of fields are set using the actual class method instead of a lambda, it is not possible to inherit those methods when inheriting the model. This issue is fixed by using a lambda function to call the domain method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185419
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next con
Original PR description
…creating accrued revenue entries Problem: When using the generate accrued revenue entries action on a sale/purchase order where the first order line is a section or note leads to an invalid account move being created. The move contains a line with not account set. Purpose of this PR: To make sure only product lines are taken into account when generating these entries How to reproduce: 1) Create and confirm a sale order where the first order line is a section or note and the next contains a product 2) Run the Accrued Revenue Entry contextual action 3) Fill the Accrual Account and Amount fields with arbitrary data and hit Create Entry 4) Error appears, a move line is generated with no account --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183230
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdo
Original PR description
Currently, sending a Bis 3 xml on Peppol raises errors if an early payment discount is set on the invoice (the Belgian one: "Always (upon invoice)", for instance: "2/7 Net 30"). An example xml can be found in the attachments. It raises the error: ``` [BR-E-01]-An Invoice that contains an Invoice line (BG-25), a Document level allowance (BG-20) or a Document level charge (BG-21) where the VAT category code (BT-151, BT-95 or BT-102) is "Exempt from VAT" shall contain exactly one VAT breakdown (BG-23) with the VAT category code (BT-118) equal to "Exempt from VAT" ``` Looking at the documentation on [1], we realize we lack an additional VAT breakdown in the xml. [1] https://einvoice.belgium.be/en/article/business-expert-group-overview task-4283933 Forward-Port-Of: odoo/odoo#185138
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.4.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185965
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice l
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: `abs(self.balance) / self.price_subtotal` However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked enterprise PR: https://github.com/odoo/enterprise/pull/73035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185230
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart ico
Original PR description
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0+ _(website_sale_product_configurator)_ Steps ----- 1. Enable Dutch language; 2. go to eCommerce; 3. switch to mobile view; 4. go to a product which has optional products; 5. add to cart. Issue ----- There's not enough space in the configurator to properly display the "Toevoegen aan winkelmandje" button. Cause ----- The view isn't mobile-responsive. Solution -------- Replace the button with a simple cart icon to ensure consistency between localisations while keeping things simple. opw-4198786 Forward-Port-Of: odoo/odoo#185133
* Before this commit, if you have .. image in manifest description like .. image:: image.png (image.png stay in static/description) , it will only work on odoo app store but in module info it isn't * After this commit, make it work in module info of Apps (base module) by replace 'src' (image.png) with static/description resource (/module_name/static/description/image.png) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged
Original PR description
* Before this commit, if you have .. image in manifest description like .. image:: image.png (image.png stay in static/description) , it will only work on odoo app store but in module info it isn't * After this commit, make it work in module info of Apps (base module) by replace 'src' (image.png) with static/description resource (/module_name/static/description/image.png) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182875
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language. Steps to reproduce: 1. On a cleanly initialized DB (only `b
Original PR description
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this…
When guessing the language at install (or upgrade) we cannot trigger a pre-fetch of all fields of `res.company` because some of its columns may be not initialized yet. One way to trigger this behaviour is to add a stored field whose default value uses translations, while at the same time adding any other stored field. If the translation is fetched in a sudo environment we can get an error when the System partner has `NULL` language.
Steps to reproduce:
1. On a cleanly initialized DB (only `base`) add any extra language (en_GB would do).
2. Open Users & Companies (show inactive users) open System user.
3. Open Related Partner.
3. In the form view of the System partner set the language to None.
4. Try to install via the command line a module with the fields as described above (see below for a code example).
We get an error like:
```
2024-10-30 08:48:40,831 41180 INFO test_16 odoo.modules.registry: module mymodule: creating or updating database tables
2024-10-30 08:48:40,839 41180 ERROR test_16 odoo.sql_db: bad query: SELECT "res_company"."id" AS "id", "res_company"."name" AS "name"
... <many more fields, redacted> ... "res_company"."bar" AS "bar", "res_company"."foo" AS "foo" FROM "res_company" WHERE "res_company".id IN (1)
ERROR: column res_company.foo does not exist
LINE 1: ...e" AS "write_date", "res_company"."bar" AS "bar", "res_compa...
```
The solution we propose is to skip the prefetch of `res.company` fields when we are in the process of guessing the language. In this case the language is correctly picked from the System partner's company.
This issue has been observed in many upgrades to 18, but it's present in older Odoo versions as well. The language field in `res.partner` is not required, thus it is also possible to set the language to `NULL` via code.
Example data observed in upgrades:
```
> select id,name,active,lang from res_partner where lang is null
+----+-----------------------+--------+--------+
| id | name | active | lang |
|----+-----------------------+--------+--------|
| 4 | Public user | False | <null> |
| 5 | Default User Template | False | <null> |
| 6 | Portal User Template | False | <null> |
| 2 | System | False | <null> |
+----+-----------------------+--------+--------+
```
There may be other standard flows that lead to such setup where System partner has no language set.
Example inherit of `res.company` that triggers the issue:
```py
class A(models.Model):
_inherit = "res.company"
bar = fields.Many2one(
comodel_name="ir.sequence",
default=lambda self: self.env["ir.sequence"].sudo().create({"name": _("Dummy")}),
required=True,
)
foo = fields.Integer()
```
Standard example of this code pattern that triggers the issue during upgrades to 18:
https://github.com/odoo/odoo/blob/dd71d998/addons/account/models/company.py#L140-L152
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#185810There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659
Original PR description
There was a typo in the test, which was breaking tests when they ran without demo data. This commit fixes it. [broken test builds](https://runbot.odoo.com/web#id=56563&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185659