Daily updates from Odoo
Tuesday, July 9, 2024
41 changes
23 changes
Miscellaneous changes
Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to
Original PR description
Serbian is a rare example of "synchronic digraphia", meaning that it has two writing systems that coexist and are used interchangeably by its speakers: Cyrillic and Latin. To handle this feature of Serbian in Odoo, we use a locale with a special modifier to specify the script to use: sr@latin. Problem: This locale is not recognized by the JavaScript APIs that implement the BCP 47 format, which leads to errors when trying to use them with the sr@latin locale. This PR provides a helper to convert the locales from the Python side for use on the JavaScript side. *: payment_adyen Task-4014022 Forward-Port-Of: odoo/odoo#172001 Forward-Port-Of: odoo/odoo#171176
Steps: - Add "rate" field via Studio in the currency form - Try to create a currency Actual result: - Traceback due to rate computation ```python currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id) TypeError: unsupported operand type(s) for /: 'NoneType' and 'float' ``` Expected result: - Default rate value is 1.0 (cf 16.0) opw-4039324 Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd --- I confirm
Original PR description
Steps: - Add "rate" field via Studio in the currency form - Try to create a currency Actual result: - Traceback due to rate computation ```python currency.rate = (currency_rates.get(currency.id) ) / currency_rates.get(to_currency.id) TypeError: unsupported operand type(s) for /: 'NoneType' and 'float' ``` Expected result: - Default rate value is 1.0 (cf 16.0) opw-4039324 Caused-By: https://github.com/odoo/odoo/commit/9353a6f9ba81926c7002b3ca5b53ac66fed9aebd --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172211
Versions -------- - 17.0+ Steps ----- 1. Go to working schedules; 2. try to modify duration days. Issue ----- Any change gets undone immediately. Cause ----- Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values. Solution
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to working schedules; 2. try to modify duration days. Issue ----- Any change gets undone immediately. Cause ----- Commit https://github.com/odoo/odoo/commit/bbae19cc630cb629adabbc54e7fa96f23a4359d8 added `calendar_id.hours_per_day` to the dependent fields of the `_compute_duration_days` method. Because modifications happen on temporary records, any modification will now trigger a recompute, overwriting the manual values. Solution -------- Remove `calendar_id.hours_per_day` from `api.depends`. Having the fields editable is preferable over triggering recomputes ASAP. opw-3999825 Forward-Port-Of: odoo/odoo#171109
[FIX] l10n_dk: fix some accounts' type Some accounts are set as "Expense" but it should be "Cost of revenue" Change them to 'expense_direct_cost' type task-id#3983710 enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168838
Original PR description
[FIX] l10n_dk: fix some accounts' type Some accounts are set as "Expense" but it should be "Cost of revenue" Change them to 'expense_direct_cost' type task-id#3983710 enterprise-pr#[66202](https://github.com/odoo/enterprise/pull/66202) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168838
Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set,
Original PR description
Purpose ======= Fix the dynamic placeholder popup which wasn't closing when clicking on escape or on the "x" button in the field selection view. Instead of closing, the default value selection was displayed. Specification ============= The dynamic placeholder files have been cleaned recently and a mistake was made as the isPathSelected value was being set to true on popup closing no matter if the path was selected or not. Fixing the issue by checking if the path value is correctly set, if it is, displaying the default value view, else closing the popover. related PR: odoo/odoo#117951 Task-4001976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171697
task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021
Original PR description
task-3744319 Forward-Port-Of: odoo/odoo#171570 Forward-Port-Of: odoo/odoo#171021
-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912
Original PR description
-fix and issue when adding a product to the cart (in debug mode only) an error pops up because freeze and refresh functions are missing from the props and the warning prop is not set as optional. opw-4016928 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171912
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 I
Original PR description
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/…
Steps to reproduce: -Go to analytic plans -> Projects -> Add a new line with a "Purchase Order" Domain and set Applicability to "Mandatory" -> Save -Go to Bills oF Materials -> create a new one w/ any product -> Save Issue: -There will be an error "One or more lines require a 100% analytic distribution." Cause: When saving the BoM, it leads to a constraint check https://github.com/odoo/odoo/blob/0217b88e481dc1d0d244b620ba527dec177edde1/addons/mrp_account/models/mrp_bom.py#L44-L50 In this method, we first try to find the relevant plans: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L103-L107 To do so, we take all existing plans, evaluate them with a score, and take the one with the higher score. Here is the issue: when evaluating *Projects*, since we didn't provide any business domain and since the plan has a company, we assign a 0.5 score to the plan instead of skipping it: https://github.com/odoo/odoo/blob/f17b37b14cad8f353443586cc9c4ecaf86e476da/addons/analytic/models/analytic_plan.py#L310-L319 Which does not make sense as the business domain of *Project* is *Purchase Order* and here the user is dealing with a BoM... As a result, back to `_validate_distribution`, we check the distribution for this plan and realize there isn't any, hence the error: https://github.com/odoo/odoo/blob/d6bdb05771fd29a79f2e8087b92a438fec28afaa/addons/analytic/models/analytic_mixin.py#L115-L117 Solution: BOM: We don't restrict anymore the creation of a BOM. Setting an analytic distribution is only a tool to facilitate the definition of the analytic distribution on the MO but the creation should not be constrained Workcenter: we correct the flowing by specifying the business domain restricting the creation of a workcenter if any relevant rule is present Forward-Port-Of: odoo/odoo#168688
We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355
Original PR description
We were removing the `res_id` in SQL to avoid raising when the audit trail is activated (because we cannot modify an attachment anymore) But it still failed when the value was still in cache. [opw-4040187](https://www.odoo.com/odoo/project/49/tasks/4040187) Forward-Port-Of: odoo/odoo#172355
Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forwar
Original PR description
Version 17.0 steps to produce: - open 'hr_employees_view_kanban' in debug mode by searching in 'open view' - open hr attendance kanban view - click on kanban record - The method 'action_employee_kiosk_confirm' does not exist on the model 'hr.employee' issue: faced with a traceback cause: 'action_employee_kiosk_confirm' action was removed from hr.employee.public solution: remove 'action_employee_kiosk_confirm' action from 'hr_employees_view_kanban' view. task-4022620 Forward-Port-Of: odoo/odoo#171471
To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217
Original PR description
To reproduce the bug: - Go to Accounting app -> Customers -> Invoices - Click on an invoice or create a new one - Click on the Preview button - Chcek due in days. It has number after the decimal point. This was caused to a miss understanding of the toFixed function. The parameter of the function represent the numbers needed after the digit. And by default its value is 0. opw-3957112 Forward-Port-Of: odoo/odoo#169217
Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503
Original PR description
Prior to this commit, the QR code size on some receipts was too small to be scanned effectively. opw-4008280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171503
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Enterprise PR: https://github.com/odoo/enterprise/pull/65952 opw-4004765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171264
Original PR description
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Enterprise PR: https://github.com/odoo/enterprise/pull/65952 opw-4004765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171264
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add any storable product - Delivery date: Tomorrow - Confirm the PO - Go to the Scheduled Actions: Purchase reminder - Run it Manually - Come back to the Dashbord > Emails - Select the email for Azure interior: - Try to click on “YES” **Problem:** A tra
Original PR description
**Steps to reproduce the bug:** - Go to contact and select azure interior: - Sales & purchase tab: - Enable “Receipt Reminder” 1 day - Create a purchase order: - Select azure interior as vendor - add…
**Steps to reproduce the bug:**
- Go to contact and select azure interior:
- Sales & purchase tab:
- Enable “Receipt Reminder” 1 day
- Create a purchase order:
- Select azure interior as vendor
- add any storable product
- Delivery date: Tomorrow
- Confirm the PO
- Go to the Scheduled Actions: Purchase reminder
- Run it Manually
- Come back to the Dashbord > Emails
- Select the email for Azure interior:
- Try to click on “YES”
**Problem:**
A traceback is triggered: `AttributeError: type object 'datetime.datetime' has no attribute 'from_string'`
When the “YES” button is clicked, we retrieve the “confirmed_date” from the arguments as a string and then call the `confirm_reminder_mail` function https://github.com/odoo/odoo/blob/181c7d82e30d0848bbac7f7d0188e81aced0af07/addons/purchase/controllers/portal.py#L117
This date will be localized to the PO timezone using the `get_localized_date_planned` function: https://github.com/odoo/odoo/blob/a0be5ea52aeff3520f8f1a92206a5aad38fdaa82/addons/purchase/models/purchase.py#L823
We then get the timezone and use the `astimezone` function to transform this date, but since it is in string format, an error is triggered.
opw-4028362
Forward-Port-Of: odoo/odoo#172267## Issue: Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet. ## Steps to reproduce: 1. Install website_slide_survey. 2. Create or go to an existing course logged in. 3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect. 4. Go to your profile and check for the attemtps. ## Solution: It will make more
Original PR description
## Issue: Right now we will be showing as Attemtps (under the website profile in attempts tab) any attempt, even whe we didn't even started the certification yet. ## Steps to reproduce: 1. Install website_slide_survey. 2. Create or go to an existing course logged in. 3. Create or use an exsiting certigication and press the 'Begin certification' and don't start the certification after the redirect. 4. Go to your profile and check for the attemtps. ## Solution: It will make more sense that we only show the actual attempts, which means that we shouldn't show here the attempts that are not finished, since how user_inputs works and are always created at the time of the link creation, we could just filter out the user_inputs that are not actually valid to show here and show only the proper ones. opw-3781323 Forward-Port-Of: odoo/odoo#161456
A traceback is occuring in the backend when the `method` is undefined while using the `POS`. Error:- ``` KeyError: 'method' File "odoo/http.py", line 2248, in __call__ response = request._serve_db() File "odoo/http.py", line 1818, in _serve_db ro = ro(self.registry, request) File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly method_name = params['method'] ``` During an `ORM` call with dynamic method and model, at some point somehow, `metho
Original PR description
A traceback is occuring in the backend when the `method` is undefined while using the `POS`.
Error:-
```
KeyError: 'method'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1818, in _serve_db
ro = ro(self.registry, request)
File "addons/web/controllers/dataset.py", line 23, in _call_kw_readonly
method_name = params['method']
```
During an `ORM` call with dynamic method and model, at some point somehow,
`method` value getting undefined with the model as `pos.session`.
This leads to a traceback in the backend side.
After applying this commit it will resolve this issue by handling
the traceback on the `JS` side when the method is undefined.
sentry-5285015466
Forward-Port-Of: odoo/odoo#170676Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania con
Original PR description
Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to…
Romania requires its companies to send all invoices to a specific web service on their E-Factura platform. Now that we can generate the file (CIUS-RO XML), our next obvious step is to send them to their SPV (the ANAF platform). This commit implements 2 big part: - the full OAUTH/authentication process and its token generation - sending/fetching/downloading data to and from the SPV --- The Authentication To be able to generate the token needs a special USB key from Romania connected with an ANAF account. The full process on what needs to be done is explained in the settings view, in the "Romanian E-Factura" block. Once a token is generated, we'll be able to use it in all of our request to send/fetch/download data to/from ANAF. --- The Full Sending E-Factura Flow (requires access token) - Upload invoice/credit note to SPV -> get "loading ID" - The invoice gets processed by ANAF (State: "sending") - After some time, fetch the invoice using the acquired loading ID. - If processed, there will be 2 kind of answer: "OK" or "NOK" (not ok) - Either way, we will get a "download ID", which we can then use to download the answer. - If "NOK" -> "Error". Read the zip file and display the error message - If "OK" -> "Sent". Save the zip file attachment task-id: 3595436 related enterprise PR: https://github.com/odoo/enterprise/pull/65602 Forward-Port-Of: odoo/odoo#144061
In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
In version 16.0, when a change is made to a record in an x2many field, saving it without saving the parent form and then accessing the record again and pressing discard will delete the changes previously made to the record. With these changes, the issue does not occur, and discarding returns the record to the state it was last saved in. Closing #171703 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#172289 Forward-Port-Of: odoo/odoo#172233
Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings. opw-3995279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171962
Original PR description
Before this commit, when a fiscal position was mapped to a tax that is included in the price, the computation did not work correctly. This commit ensures that prices are accurately recalculated when taxes included in the price are affected by fiscal position mappings. opw-3995279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171962
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is
Original PR description
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report,…
### Steps to reproduce the issue: 1. Create a Tax Based On Payment with a Cash Basis Transition Account 2. Create an Expense Paid By Company and add previously created Tax 3. Create the report, submit it, approve it then Post Journal Entries 4. Go to the Journal Entry (until you see the Journal Items) 5. The Journal Item of the Tax is recorded on the Cash Basis Transition Account but no Caba Entry is created ### Explanation: When using the company to pay the expense, the payment is immediate. When the employee took care of the payment, a Bill and a Caba Entry are created because the company still needs to reimburse the employee. ### Suggested fix: Adding a Caba Entry is not necessary since there is no need to record the transaction in a transitional account, sending the transaction in the final Account would also match the use case when using Taxes Based On Invoice. `account_id` is selected between the `cash_basis_transition_account_id` of the tax and the `account_id` of the repartition line depending on the values of `tax_exigibility` and `caba_no_transition_account`. https://github.com/odoo/odoo/blob/0c0f0b58aa49cff1efafcc1d4c5a9091e99f2ff4/addons/account/models/account_tax.py#L640-L642 The latter is a context key and is only used in this check, meaning it is most likely harmless to add it in the context of the method. opw-3946362 Forward-Port-Of: odoo/odoo#172196 Forward-Port-Of: odoo/odoo#169255
Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 For
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” - Create a delivery for P1 - Click on “Detailed operation” smart button - select the move line - click on “put in pack” Problem: Nothing happens because the `put_in_pack` function of the 'stock.move.line' model always returns true after calling the same function of the 'stock.picking' model instead of returning the result. Note that this function cannot handle multiple move lines with different pickings. opw-4029393 Forward-Port-Of: odoo/odoo#172235 Forward-Port-Of: odoo/odoo#172068
When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172317
Original PR description
When calling read_group() with an invalid field name, the error message was misleading, indicating the last aggregated field name instead of the field that was invalid (non-existant on the model) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172317
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270
Original PR description
Following odoo/odoo@82ae5b0769c2, we should reuse the same author name as in the transcript introduction. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172316 Forward-Port-Of: odoo/odoo#172270
17 changes
Enhancements to existing features
The Web Enterprise module’s automated checks were migrated to a newer testing framework. This helps keep quality assurance reliable and easier to maintain without changing how users experience the product.
Original PR description
In this PR: * [IMP] web_enterprise: convert action_manager_mobile tests to HOOT * [IMP] web_enterprise: convert home_menu tests to HOOT * [IMP] web_enterprise: convert list tests to HOOT * [IMP] web_enterprise: convert expiration_panel tests to HOOT task-3705027 task-4028335
The payroll rule setup text was improved to better explain how to enter the output of a salary rule calculation. This helps payroll administrators configure custom rules more accurately and reduces confusion during setup.
Original PR description
In the default value of the amount_python_compute in the model hr.salary.rule, we have a placeholder giving the available variables and also showing where to put the output. It was missing more information to make it really accurate. Task: 4038128
The Chile and Mexico e-invoicing flows in online sales were adjusted to stay compatible with recent platform changes. This helps ensure customers can continue completing website purchases that require local electronic invoicing without disruption.
Original PR description
task-3682746 See also: - https://github.com/odoo/odoo/pull/149020
This update modernizes several enterprise web and mobile interface tests using Odoo's newer HOOT testing framework. It helps ensure key areas like mobile navigation, pivot views, and the home menu continue to work reliably as the product evolves.
Original PR description
In this PR: * [IMP] web_enterprise: add test assets bundle for HOOT * [IMP] web_enterprise: add HOOT clickbot test * [IMP] web_enterprise: convert pivot_view tests to HOOT * [IMP] web_enterprise: convert webclient_mobile tests to HOOT * [IMP] web_enterprise: convert burger_menu tests to HOOT task-3705027 task-4028335
Code cleanup and technical improvements
Brazilian Avalara tax service functionality has been folded into the main Brazil tax modules instead of being kept in separate service-specific modules. This simplifies module structure and maintenance while preserving the same capabilities for goods and service transactions.
Original PR description
The first release of Avatax Brazil focused only on goods transactions. Service transactions were added later in stable, and thus needed new modules. This commit merges these *_services specific modules into the main one. None of the functionality should have been changed.
Miscellaneous changes
Steps: - Install social_demo, crm - Open social marketing app - Open instagram ost - Create a lead from comment Actual result: - issue due to the demo data with invalid date format - demo date is not ISO8601 compliant Expected result - Lead wizard is opened opw-3975423 opw-4019390 Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142 Forward-Port-Of: odoo/enterprise#64204
Original PR description
Steps: - Install social_demo, crm - Open social marketing app - Open instagram ost - Create a lead from comment Actual result: - issue due to the demo data with invalid date format - demo date is not ISO8601 compliant Expected result - Lead wizard is opened opw-3975423 opw-4019390 Caused-by: https://github.com/odoo/enterprise/commit/4fb0f854c57c1669eea8a383a55e16dd52894142 Forward-Port-Of: odoo/enterprise#64204
## Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. ## After this PR The Sample Values will now update according to the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#65198
Original PR description
## Before this PR In WhatsApp Composer, the Sample Values do not update when changing the WhatsApp Template. Instead, it display the sample values from the initially selected template. ## After this PR The Sample Values will now update according to the selected WhatsApp Template. Task-3996935 Forward-Port-Of: odoo/enterprise#65198
With an MX company setup Go to Accounting > Reports > Trial Balance. Click "SAT (XML)" to export the file. Issue: No certificate in the xml In Odoo 15, exporting the SAT XML would include the company's EDI certificate. In Odoo 16 and newer, this is no longer the case. opw-3891205 Forward-Port-Of: odoo/enterprise#66022 Forward-Port-Of: odoo/enterprise#62969
Original PR description
With an MX company setup Go to Accounting > Reports > Trial Balance. Click "SAT (XML)" to export the file. Issue: No certificate in the xml In Odoo 15, exporting the SAT XML would include the company's EDI certificate. In Odoo 16 and newer, this is no longer the case. opw-3891205 Forward-Port-Of: odoo/enterprise#66022 Forward-Port-Of: odoo/enterprise#62969
30% Exemption field shows on all contracts although it should only show on dutch employees contracts. This change restricts the 30% Exemption to only show on dutch contracts. task-3946599 Forward-Port-Of: odoo/enterprise#65790
Original PR description
30% Exemption field shows on all contracts although it should only show on dutch employees contracts. This change restricts the 30% Exemption to only show on dutch contracts. task-3946599 Forward-Port-Of: odoo/enterprise#65790
Forward-Port-Of: odoo/enterprise#65976
Original PR description
Forward-Port-Of: odoo/enterprise#65976
Before this commit, the reserved lot for a line was displayed even if the "Show reserved lots/SN" is not checked. ### How to reproduce: - Ensure "Show reserved lots/SN" is not check for the deliveries; - Create a product tracked by lots and set a barcodes; - Create two lots for this product and add quantity in stock for both; - Create a delivery for this product (enough qty. to reserved both lots); - Open the delivery in the Barcode app. ### Issue: On the barcode line, the first rese
Original PR description
Before this commit, the reserved lot for a line was displayed even if the "Show reserved lots/SN" is not checked. ### How to reproduce: - Ensure "Show reserved lots/SN" is not check for the…
Before this commit, the reserved lot for a line was displayed even if the "Show reserved lots/SN" is not checked. ### How to reproduce: - Ensure "Show reserved lots/SN" is not check for the deliveries; - Create a product tracked by lots and set a barcodes; - Create two lots for this product and add quantity in stock for both; - Create a delivery for this product (enough qty. to reserved both lots); - Open the delivery in the Barcode app. ### Issue: On the barcode line, the first reserved lot is displayed. ### Expected behavior: In this configuration, only scanned lots should be displayed (here, the barcode line lot part should appear empty.) This commit also fixes an issue where not the same move lines is opened when using the edit form view in the Barcode App. To reproduce, follow steps above, then open the display line in the form view (via the edit button) => You can see a lot is displayed. Update the quantity to fulfill the line, save the change and then re-open the form view => You can now see the other lot and 0 qty because it's the other reserved move line who was opened. To avoid this issue, it will always be the first (by ID) move line who will be opened. Forward-Port-Of: odoo/enterprise#64264
### Steps to reproduce: - Install Sale Subscription module - Create a recurrent order and add Optional products and Start date under Other info tab - Click on Preview ### Current behavior before PR: You won't see the optional products in the portal view if for a recurrent order that has start date and in draft. This is happening because in sale_subscription we are checking if the start_date of the order is equal to the next_invoice_date https://github.com/odoo/enterprise/blob/17.0/sal
Original PR description
### Steps to reproduce: - Install Sale Subscription module - Create a recurrent order and add Optional products and Start date under Other info tab - Click on Preview ### Current behavior before PR: You won't see the optional products in the portal view if for a recurrent order that has start date and in draft. This is happening because in sale_subscription we are checking if the start_date of the order is equal to the next_invoice_date https://github.com/odoo/enterprise/blob/17.0/sale_subscription/models/sale_order.py#L1957:1959 and if the order is in draft it won't have a next_invoice date until it is either confirmed or sent. ### Desired behavior after PR is merged: We are now checking if the next_inovice_date is not set we show the optional products. opw-3980405 Forward-Port-Of: odoo/enterprise#66237 Forward-Port-Of: odoo/enterprise#64894
This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order. Task-4037741 Forward-Port-Of: odoo/enterprise#66154
Original PR description
This PR makes the employees always appear in alphabetical order in the planning overlap warning. This fixes a test breaking when the order changes, and prevents potential problems caused by a nondeterministic order. Task-4037741 Forward-Port-Of: odoo/enterprise#66154
Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.com
Original PR description
Before this commit the timesheet_mail_employee_nextdate and timesheet_mail_manager_nextdate Were calculated only when a change was made on timesheet_mail_employee_delay, timesheet_mail_employee_interval or timesheet_mail_manager_delay, timesheet_mail_manager_interval fields, even tho those two have a default value Now the _timesheet_postprocess method will always call _calculate_timesheet_mail_employee_nextdate and _calculate_timesheet_mail_manager_nextdate method when called from the res.company.create method Seems to work even if the delay and interval fields don't have default value Following this PR > https://github.com/odoo/enterprise/pull/48096 15.0 > master Task-3714293 Forward-Port-Of: odoo/enterprise#65564 Forward-Port-Of: odoo/enterprise#55546
Versions -------- - 16.0+ Steps ----- 1. Create an open slot in a planning; 2. publish & send an email to an employee who could fill it; 3. open the planning link sent via email; 4. open the same URL while logged out. Issue ----- The datetimes of the open slot are displayed in UTC. Cause ----- Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Create an open slot in a planning; 2. publish & send an email to an employee who could fill it; 3. open the planning link sent via email; 4. open the same URL while logged out. Issue ----- The datetimes of the open slot are displayed in UTC. Cause ----- Commit cf256e94d333 modified the planning template to use the `datetime` widget to format the dates instead of the `format_datetime` function provided by the `ShiftController`. Doing so, it lost access to the `employee_tz` value, derived from the email recipient, and hence defaulted to UTC. Solution -------- Format the dates using `format_datetime`. opw-3967787 Forward-Port-Of: odoo/enterprise#66231 Forward-Port-Of: odoo/enterprise#66015
Currently the warning of the partner VAT listing is never shown. In 88b449b08e21700e9dd113250125b2c3daa65a0f (17.2) the warnings for custom report handlers were moved from `_custom_line_postprocessor` to a new function called `_customize_warnings`. Currently this is not the case for the partner VAT listing. This commit does the necessary change for the partner VAT listing. (This commit does not belong to any task) Forward-Port-Of: odoo/enterprise#64313
Original PR description
Currently the warning of the partner VAT listing is never shown. In 88b449b08e21700e9dd113250125b2c3daa65a0f (17.2) the warnings for custom report handlers were moved from `_custom_line_postprocessor` to a new function called `_customize_warnings`. Currently this is not the case for the partner VAT listing. This commit does the necessary change for the partner VAT listing. (This commit does not belong to any task) Forward-Port-Of: odoo/enterprise#64313
Adapt history revision tour after the improvements done on the comparison feature. task-3761721 Forward-Port-Of: odoo/enterprise#66069 Forward-Port-Of: odoo/enterprise#60061
Original PR description
Adapt history revision tour after the improvements done on the comparison feature. task-3761721 Forward-Port-Of: odoo/enterprise#66069 Forward-Port-Of: odoo/enterprise#60061
1 change
Resolved issues and error corrections
Updated the accounting module's test procedures to comply with German audit trail requirements, which mandate that financial moves cannot be deleted. The fix ensures that only moves associated with the specific test company are removed during testing, while preserving the audit trail integrity required by law.
Original PR description
Since the audit trail is mandatory in Germany, we cannot remove moves or any documents related. We only need to remove the moves linked to the company of the tour.