Daily updates from Odoo
Tuesday, October 22, 2024
26 changes · master
Enhancements to existing features
The referral app’s sample reward data and images have been refreshed to reference Odoo instead of external companies. This keeps demonstration content aligned with Odoo branding and avoids showing third-party brand references in demo environments.
Original PR description
The demo data are updated to make reference to odoo and remove external reference to other companies. task-4071950
This update switches many Odoo Enterprise apps to the newer translation system and marks the older approach as deprecated. It helps keep the platform easier to maintain and prepares for future simplification, with little expected day-to-day impact for users.
Original PR description
This commit replaces the use of `core.{_t,_lt}` with its equivalent from `@web/core/l10n/translation`. Calling these functions will now result in a warning.
This paves the way for the unification of `_t` and `_lt` into a single function, and the removal of the legacy `web.translation`.
Community: https://github.com/odoo/odoo/pull/124285The appointment module no longer applies a date-only display option to fields that store both date and time. This prepares the system for stricter checks on unsupported field settings and helps reduce hidden configuration issues.
Original PR description
This commit removes the date widget on datetime fields. The widget is ignored if used on a datetime fields, see the tests : `DatetimeField with date/datetime widget (with day change) does not care about widget` and `DatetimeField with date/datetime widget (without day change) does not care about widget.` This commit is part of a bigger task, that aim to raise an error if a widget is used in an unsupported field type, in this case the widget date, will only support the date type fields. task-id: 4224192
Resolved issues and error corrections
This update corrects several small code issues identified by automated quality checks across accounting, delivery, documents, stock barcode, and data cleaning areas. The changes reduce the risk of hidden bugs and improve maintainability without introducing expected functional changes for users.
The EasyPost delivery setup now shows the correct carrier type options in the selection widget. This helps users configure shipping carriers more reliably and avoids incorrect or missing choices during setup.
Original PR description
This commit fix the supportedTypes of widget `carrier_type_selection`. task-id: 4224192
Miscellaneous changes
Steps to reproduce: - have two companies with different main currencies - have currency rates != 1 for the selected main company - open the trial balance with both companies selected => The amounts displayed in Debit and Credit column from the first company are not converted to the main company currency. Reason of the issue: The general ledger custom code rewrite the options 'date_from' to the fiscal year date from, which results in a Null join with the account_currency_tab
Original PR description
Steps to reproduce: - have two companies with different main currencies - have currency rates != 1 for the selected main company - open the trial balance with both companies selected => The amounts displayed in Debit and Credit column from the first company are not converted to the main company currency. Reason of the issue: The general ledger custom code rewrite the options 'date_from' to the fiscal year date from, which results in a Null join with the account_currency_table Forward-Port-Of: odoo/enterprise#72006
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
Original PR description
Following the changes made in the community side in odoo/odoo#183190, adapts the tests to check that the dropships are properly considered as dropships in inter-company transactions. Forward-Port-Of: odoo/enterprise#72188 Forward-Port-Of: odoo/enterprise#71688
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be conside
Original PR description
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be considered by that line of the BS. Only affectation must also be considered from within the current fiscal year. Forward-Port-Of: odoo/enterprise#72337 Forward-Port-Of: odoo/enterprise#72021
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644 Forward-Port-Of: odoo/enterprise#72054
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Original PR description
If we receive a valid pairing code, block the 'Pair' button, since if it is pressed again it will show an error as the pairing code has already been used. task-4207295 Forward-Port-Of: odoo/enterprise#72416
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72362 Forward-Port-Of: odoo/enterprise#71459
Original PR description
Before this commit, when a user doesn't have any hr right, he can't see employee's picture. With this commit, this issue is fixed and the user can access to the public employee form when he clicks on this picture. And "mark as done" option in three dot menu is invisible if the goal is already done. task-4240631 Forward-Port-Of: odoo/enterprise#72362 Forward-Port-Of: odoo/enterprise#71459
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72278 Forward-Port-Of: odoo/enterprise#72199
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72278 Forward-Port-Of: odoo/enterprise#72199
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amount
Original PR description
The model 349 wasn't working as expected, here are the points that have been changed: - Some keys were missing, in particular the keys R, D, and C. - Changed some wording of the report, such as replacing 'refunds' with 'rectifications'. - The biggest change was changing the way the lines are computed in the report. Before this commit, we used only the domain engine, but now we need to use a custom engine to handle the rectifications part. - Fixed some other bugs, like negative amounts which are not supposed to appear as the report only deals with positive values, and also ensured the discounts on the move lines are computed correctly. task-3992046 Forward-Port-Of: odoo/enterprise#72430 Forward-Port-Of: odoo/enterprise#65074
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` wh
Original PR description
## Steps to reproduce: 1. Create a quality control point for the operation type Manufacturing 2. Create a manufacturing order and plan it 3. Go to the Shop floor 4. Register the production & do the quality checks 5. The Quality Checks button is still there; clicking again displays a traceback because the quality checks are already done. ## Before this commit: Upon reloading the production, the new data is not propagated to `this.record`. ## After this commit: Change `this.record` when props are updated so it always contains the correct reference to the record. opw-4176393 Forward-Port-Of: odoo/enterprise#72425 Forward-Port-Of: odoo/enterprise#70800
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#71811 Forward-Port-Of: odoo/enterprise#70369
Original PR description
This commits add the first test for the fiskaly module. This tests mock all the call made to the api so that we can make sure the module is working correctly. opw-4171641 Forward-Port-Of: odoo/enterprise#71811 Forward-Port-Of: odoo/enterprise#70369
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Original PR description
Forward-Port-Of: odoo/enterprise#72400 Forward-Port-Of: odoo/enterprise#72307
Steps to reproduce the bug: - Create two Storable product: - “P1” -> product category A - “P2” -> product category B - Create a quality point: - picking type: receipt - product category: Cat A & Cat B - Measure: by quantity - Create a second quality point: - picking type: receipt - product category: Cat A - Measure: by quantity - Create a receipt of one unit of P1 and P2 - Confirm Problem: Four quality checks are created instead of three bec
Original PR description
Steps to reproduce the bug:
- Create two Storable product:
- “P1” -> product category A
- “P2” -> product category B
- Create a quality point:
- picking type: receipt
- product category: Cat A & Cat B
- Measure: by quantity
- Create a second quality point:
- picking type: receipt
- product category: Cat A
- Measure: by quantity
- Create a receipt of one unit of P1 and P2
- Confirm
Problem:
Four quality checks are created instead of three because we check if the quality point corresponds to the picking type and if the quality point has no product selected. However, we don't verify if a product category is also not set.
opw-4240859
Forward-Port-Of: odoo/enterprise#71709
Forward-Port-Of: odoo/enterprise#71453If a language is set on the customer when doing the followup, the attached Partner Ledger was always generated in the language of the active user. Instead, if a language is set on the customer, we want to use it. Forward-Port-Of: odoo/enterprise#71529
Original PR description
If a language is set on the customer when doing the followup, the attached Partner Ledger was always generated in the language of the active user. Instead, if a language is set on the customer, we want to use it. Forward-Port-Of: odoo/enterprise#71529
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time wit
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#72224 Forward-Port-Of: odoo/enterprise#63002
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72429 Forward-Port-Of: odoo/enterprise#72343
Original PR description
Recently, this commit is merged: https://github.com/odoo/enterprise/pull/63002/commits/32776c6eb7ce1dafca2f8f4d0f825c19da641b71 the test case is failing in the weekends or non-working days, so I have used freeze_time to run it as if it were a working day. Forward-Port-Of: odoo/enterprise#72429 Forward-Port-Of: odoo/enterprise#72343
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only
Original PR description
Steps to reproduce: ------------------- - Create or rename any journal entry to have an empty name (Number). - Open GL and make sure that this entry is included in the report. - Click XLSX export, will give error: "TypeError: float() argument must be a string or a real number, not 'NoneType'". Cause ----- Since #50004, dynamic column width calculation for xlsx was added without handling the case where a filed can be empty. A typecast to float was done with exception for ValueError only. Fix --- Add condition to check if the field is non empty before casting. Forward-Port-Of: odoo/enterprise#71295
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#72269 Forward-Port-Of: odoo/enterprise#69552
Resolve an issue where the compute method `_compute_is_there_shared_cert` was triggered before the record was saved, causing the domain to be incorrectly constructed with `company.id`. Replacing `company.id` with `company._origin.id` to ensure the correct domain is applied by accessing the original record instance. Forward-Port-Of: odoo/enterprise#72084
Original PR description
Resolve an issue where the compute method `_compute_is_there_shared_cert` was triggered before the record was saved, causing the domain to be incorrectly constructed with `company.id`. Replacing `company.id` with `company._origin.id` to ensure the correct domain is applied by accessing the original record instance. Forward-Port-Of: odoo/enterprise#72084
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496 Forward-Port-Of: odoo/enterprise#71726
Original PR description
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496 Forward-Port-Of: odoo/enterprise#71726
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681 Forward-Port-Of: odoo/enterprise#71627
Improve tooling defined in marketing automation, notably * add more verbose errors; * add parameters for trace check, notably to be less strict in case of duplicate-like traces; * improve tool methods generating activities; * assert some keys to be sure we effectively check what is intended; * add some docstrings while passing by; Task-2667099: [mail] Improve default template values Prepares Task-4224145: [marketing_automation] Improve test coverage Forward-Port-Of: odoo/ente
Original PR description
Improve tooling defined in marketing automation, notably * add more verbose errors; * add parameters for trace check, notably to be less strict in case of duplicate-like traces; * improve tool methods generating activities; * assert some keys to be sure we effectively check what is intended; * add some docstrings while passing by; Task-2667099: [mail] Improve default template values Prepares Task-4224145: [marketing_automation] Improve test coverage Forward-Port-Of: odoo/enterprise#72420