Monday, July 8, 2024
39 changes · saas-17.1
Resolved issues and error corrections
This fix prevents Point of Sale from sending incomplete background requests after an offline barcode scan fails. It avoids backend error logs when the same unknown barcode is scanned again online, making POS operation more stable for users.
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-5285015466Product searches in Point of Sale now avoid creating duplicate product entries behind the scenes. This helps keep product lookup results reliable and prevents possible confusion or performance issues during checkout.
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
Searching for products by name in the restaurant appointment point-of-sale flow no longer creates duplicate product records. This helps keep product search results and order data accurate for staff using the system.
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. Community PR: https://github.com/odoo/odoo/pull/171264 opw-4004765
Planning overlap warnings now show employee names in alphabetical order. This makes the warning easier to read and prevents inconsistent ordering from causing unreliable test results or unexpected behavior.
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
Miscellaneous changes
[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
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
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
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All
Original PR description
When mail totp is enforced, users are required to perform the MFA step after signup, before signin. The authentication is partial and the user is set to None. This causes the signup request to fail at the mail template rendering step with an access right error even though the registration is actually successful. Steps to reproduce: - Install apps `auth_totp_mail_enforce` and `website` - Login with admin user - In Settings: - Enable "Enforce two-factor authentication", set it to "All users" - Set "Customer Account" to "Free sign up" - In a clean session (private browsing), try to sign up an account Old behavior: 403 error New behavior: 2FA page opw-3968129 Forward-Port-Of: odoo/odoo#169594
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utiliz
Original PR description
Issue --> When editing the account code for an `account.account` record with a large number of related `account.move.lines`, the method `_compute_always_tax_exigible` get called down the compute tree on all related `account.move` records. This leads to a MemoryError as the underlying field_cache expands beyond the allocated memory limit. Solution --> Disable the prefetcher in the loop to reduce the number of allocations made to the field_cache. Benchmarks --> Memory utilization before PR -->  Reference flamegraph --> https://drive.google.com/file/d/1ptI8mOfvaACFmuwIEiN5f0rFRueu9h46/view?usp=drive_link After PR -->  Reference flamgraph --> https://drive.google.com/file/d/1dcaLz3jrDmkX96WagAylkL1V--dz9jNQ/view?usp=drive_link opw-3957975 Forward-Port-Of: odoo/odoo#171122
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001
Original PR description
Purpose ======= Considering that the user isn't admin, has enough karma to delete a post comment but not enough karma to delete a post. When the user deletes a comment, fix the warning alert saying that he doesn't have enough karma even though he has. Specification ============= Changing the condition to display the warning in the xml to use the comment unlink required karma instead of the post one. There is no comment can_unlink field so rebuilding the can_unlink condition. Task-4001283 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172167 Forward-Port-Of: odoo/odoo#170130
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased produ
Original PR description
Problem: When you click on the On Hand smart button from a product variant, it will show the on hand quantity for all of the product's variants. Purpose: Clicking on the On Hand smart button from a product variant should show only the on hand quantity for that specific product variant. Steps to Reproduce on Runbot: 1. Create a storable product with an attribute that has two values to create two product variants 2. Purchase stock for both product variants 3. Receive the purchased products 4. Enable Storage Locations in Settings > Inventory 5. Navigate to one of the product variants and click on the On Hand smart button 6. Observe that it shows the on hand quantity for both product variants opw-3988374 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171306
task-3744319 Forward-Port-Of: odoo/odoo#171021
Original PR description
task-3744319 Forward-Port-Of: odoo/odoo#171021
## 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
Forward-Port-Of: odoo/odoo#172203
Original PR description
Forward-Port-Of: odoo/odoo#172203
Steps to reproduce the bug: - Create a storable product “P1”: - Create a reorder rule: - Min qty: 5 - Route: Buy - Click the “To order” button Problem: The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time. opw-3994600 Forward-Port-Of: odoo/odoo#171968
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Create a reorder rule:
- Min qty: 5
- Route: Buy
- Click the “To order” button
Problem:
The button does not become invisible; the page must be refreshed to see the update. This can lead to user error if the user clicks the “order once” button a second time.
opw-3994600
Forward-Port-Of: odoo/odoo#171968Since 17.0 activity view now has a pager, which is not working at all. Actually there are two problems fixed in this commit - Frontend problem fixed in activity_controller.js - Backend problem fixed in mail_activity.py # First problem: Steps: - Install a module with activity view (`sale_management` for example) - Open activity view Let's say we have 4 records, at the loading of the view a request to `get_activity_data` with the following domain in the payload ``
Original PR description
Since 17.0 activity view now has a pager, which is not working at all. Actually there are two problems fixed in this commit - Frontend problem fixed in activity_controller.js - Backend problem fixed…
Since 17.0 activity view now has a pager, which is not working at all.
Actually there are two problems fixed in this commit
- Frontend problem fixed in activity_controller.js
- Backend problem fixed in mail_activity.py
# First problem:
Steps:
- Install a module with activity view (`sale_management` for example)
- Open activity view
Let's say we have 4 records, at the loading of the view a request to
`get_activity_data` with the following domain in the payload
```json
{
"domain": [
["user_id", "=", 2],
["activity_ids.active", "in", [true, false]]
]
}
```
the response contains for example
```json
{
"activity_res_ids": [
3,
19,
4,
7
]
}
```
This is correct, the problem comes if we try to "refresh" the view
with the pager, by clicking in the pager's input and press enter
(without changing anything).
Normally it will be exactly the same request as the one above.
But the domain is not the same this time
```json
{
"domain": [["user_id", "=", 2]]
}
```
Because of this `get_activity_data` returns incorrect data.
To fix this issue we have to do the same thing as here in the pager onUpdate()
https://github.com/odoo/odoo/blob/e11e3ca447fa2997b51a39cefc3457ae411ccb3c/addons/mail/static/src/views/web/activity/activity_model.js#L12
# Second problem:
When the model contains a different order than 'id' `get_activity_data`
can returns incorrect data since we don't specify `order` in `_search`
opw-[3862389](https://www.odoo.com/web#id=3862389&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#164713Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 0
Original PR description
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces…
Currently `_run_fifo_vacuum` can be a performance bottleneck when confirming a large IN transfer. This is especially true for anglo_saxon accounting companies. To fix that, this commit introduces batch versions of `_run_fifo_vacuum` and `_create_fifo_vacuum_anglo_saxon_expense_entry`. The idea of these batch versions is to batch records creation, moves posting, search, etc. Stuff that cannot be batched/don't need to be batched are left as is. #### Speedup 15.0 customer database with 476 000 account.moves, 1M account.move.lines, 8400 products, 700 000 stock.moves, 650 000 stock.move.lines, 500 000 svls All categories have Inventory Valuation set to real_time. Benchmark validation of IN transfers, changing the number of products + total number of svls | Number of products | Total number of svls | Before PR | After PR | |:----------------:|:-------------------:|:-----------:|:-----------:| | 1 | 112 | 3.88s | 3.78s | | 2 | 607 | 548ms | 524ms | | 5 | 2561 | 2.27s | 1.10s | | 3 | 8956 | 15min | 2min | | 32 | 43310 | 7min | 50s | Some pickings are not directly impacted by the PR, most probably because these pickings don't have candidates svls/svls to vacuum to begin with. Still for the fourth and fith picking, the batch version performs way better than the iterative one. Validating an IN transfer with stock_account and real-time inventory valuation is a complex process so it's a bit difficult to pinpoint tables cardinalities that correlate with the validation time. Here it's the Before vs After time that is relevant, more than the validation time growth. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169876 Forward-Port-Of: odoo/odoo#157558
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Original PR description
Unecessary info is fetched with the route hr_attendance/attendance_user_data such as employee avatar and other kiosk related data which is not necessary for the systray. task-4036988 Forward-Port-Of: odoo/odoo#172069
Forward-Port-Of: odoo/odoo#172070
Original PR description
Forward-Port-Of: odoo/odoo#172070
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#171837 Forward-Port-Of: odoo/odoo#171176
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
Original PR description
Replace Sales Analysis By Customers with Sales Analysis Per Customers opw-3999628 Forward-Port-Of: odoo/odoo#171286
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by upd
Original PR description
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP…
For some phone numbers, our SMS provider fails to send messages. In this case, manual verification can become necessary. This verification would be performed by support staff, and a change on the IAP side would allow for it (see https://github.com/odoo/iap-apps/pull/836). Considering this change, the client-side needs to be updated such that the participant state of unverified users is also checked and updated, by calling the participant status endpoint on the IAP. This is performed by updating the _cron_peppol_get_participant_status cron to include EDI users that are not yet verified. When the user has been verified on the IAP side, the state 'verified' will be returned when making a call to the participant status endpoint, for which the most accurate mapping to a client state is 'pending'. Note that when managing users from versions 17.0 to 17.2 (inclusive) the support staff responsible for verifying the user should also take the steps to ensure that they are registered on the SMP too (since users of these versions will otherwise remain in the 'pending' state indefinitely until they are manually registered on the SMP). Forward-Port-Of: odoo/odoo#171823
### 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#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#171547
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0 where it should be 1 day or 8 hours/ressource callendar of the employee 2.b -> if you have selected an allocation where the unit is "half_day" or the number of days and the title doesn't corresponds to each other First introduction: ------------------- task: 3084
Original PR description
### To merge in 17.0 to master -.1 Bugs: ----- 1. both: -go to time off and click on "New Allocation Request" -change the allocation type to any other 2.a -> the number of days or hours is set to 0…
### To merge in 17.0 to master -.1
Bugs:
-----
1.
both: -go to time off and click on "New Allocation Request"
-change the allocation type to any other
2.a
-> the number of days or hours is set to 0 where it should be 1 day
or 8 hours/ressource callendar of the employee
2.b
-> if you have selected an allocation where the unit is "half_day" or
the number of days and the title doesn't corresponds to each other
First introduction:
-------------------
task: 3084232
PR: https://github.com/odoo/odoo/pull/116472
Reasons:
--------
a. We where using the fields where were made for the front-end only
and where not computed properly and thus resetting the value to 0
when changing the allocation type
b. The title was using the unit of the allocation type in db and not
Labels or the unit of the allocation duration
Fixes:
------
Not use the display fields for the computation of the title and make labels corresponding to the actual unit of the allocation duration
task-3852940
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#161035When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commi
Original PR description
When filling a relational field, suggestions are displayed using the AutoComplete component. Problem is, when choosing any suggestion, some ARIA attributes are missing for assistive technologies to know what is the currently-selected suggestion. That because the actual focus is always on the field's input, while the actually-selected suggestion is highlighted by toggling classes, which makes not possible anymore to know what is the selected suggestion for e.g. screen reader users. This commit adds such attributes. This is similar to what was done on 9764e6f7 for the command palette to handle search results on the home screen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170291 Forward-Port-Of: odoo/odoo#165903
Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all the lines. - `CTRL+X` then `CTRL+V` of all the lines - Press `CTRL+A` to select all the lines again. - Press `CTRL+B` to make all the lines bold - The last line doesn't get formatted. Origin of the issue: ==================== The issue is originating from the fact that paste add `br`
Original PR description
Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all…
Issue: ====== Applying bold after copy paste doesn't cover all the selection. Steps to reproduce the issue: ============================= - Go to notes - Add 3 lines - Press `CTRL+A` to select all the lines. - `CTRL+X` then `CTRL+V` of all the lines - Press `CTRL+A` to select all the lines again. - Press `CTRL+B` to make all the lines bold - The last line doesn't get formatted. Origin of the issue: ==================== The issue is originating from the fact that paste add `br` in the last `p` element so actually the issue can be reproduced by just adding couple of lines and at the end of the last line press `SHIFT+enter` (to add br element). In the function `getTraversedNodes` we stop as soon as we reach the `endContainer` which is the last `p` elemnt because we can't have the `br` as endContainer so we don't include its desendants. In the case when we don't do copy paste (without the extra br) the `endContainer` is the node element so it will be included and it works correctly. Solution: ======== - `<p>ab<br>[</p>...]`, `<p>ab<br>[<br>cd</p>..`: startContainer is p element, we need to go to the node at the startOffset. - `<p>ab[<br></p>...`: start container is ab we need to skip it and start from the br element - `[...<p>ab<br>]cd</p>`: endContainer is cd we shouldn't include it - `[...<p>ab><br>]</p>`, `[...<p>ab<br>]<br>cd</p>`: encContainer is p element, we loop over descendants and include only the ones before endOffset. task-3874926 Forward-Port-Of: odoo/odoo#171607 Forward-Port-Of: odoo/odoo#162370
An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the cal
Original PR description
An indeterministic error was present in the pos_loyalty module. This was due to the fact that when the user changed the partner a request to retrieve the loyaltyCards already existing for this partner was made by a different series of function calls. In fine, the call was not awaited, so when another method wanted to retrieve the loyaltyCards for the same partner, a new card was created and then overridden to null by the result of the call to the server. To correct this error, the call to the server to retrieve the cards is made when the partner is changed. At this point the request is awaited. Runbot Error: [57047](https://runbot.odoo.com/web/#id=57047&view_type=form&model=runbot.build.error&menu_id=405&cids=1) Forward-Port-Of: odoo/odoo#171226
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#171244
Original PR description
Multiple fixes related to Audit Trail: * track more fields: * <account.move.line>.balance * <account.move.line>.tax_tag_ids * <account.tax>.l10n_de_datev_code * <res.company>.l10n_de_widnr * Track newly created lines once the move has been posted * Prevent deleting tracking messages/values linked to the audit trail [task-4018800](https://www.odoo.com/odoo/project.task/4018800?cids=1) Forward-Port-Of: odoo/odoo#171244
[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838) Forward-Port-Of: odoo/enterprise#66202
Original PR description
[FIX] l10n_dk_reports: fix account type of DK report tests By fixing the type of the account "Purchase of goods" from expense to expense_direct_cost the test now takes the new first expense account which is now "Freight costs" and not "Purchase of goods" anymore task-id#3983710 odoo-pr#[168838](https://github.com/odoo/odoo/pull/168838) Forward-Port-Of: odoo/enterprise#66202
**Version:** - saas-16.3 **Step to reproduce:** - In the sign app, open the sign template iframe view. - When zooming in, the 'Sign Now' button breaks the text and creates extra space in the breadcrumb. **Issue:** Currently, the sign now button text creates extra spacing. **Solution:** Add the CSS class so that it will not create additional spacing task-3977792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - In the sign app, open the sign template iframe view. - When zooming in, the 'Sign Now' button breaks the text and creates extra space in the breadcrumb. **Issue:** Currently, the sign now button text creates extra spacing. **Solution:** Add the CSS class so that it will not create additional spacing task-3977792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#64648
### 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#64894
### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a Project 3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created 4. Create a Task for the Project 5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour 6. Click on "Mark as done", then "Sales Order" 7. The Delivered Quantiti
Original PR description
### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a…
### Steps to reproduce the issue: 1. Create a Product with "Service" as Product Type and "Based on Timesheets" as Invoicing Policy 2. Go to _Field Service > Configuration > Projects_ and choose a Project 3. In the _Invoicing_ section, add a line with an Employee and the Service Product you created 4. Create a Task for the Project 5. Add in the _Timesheets_ section a line with the Employee and a duration of one hour 6. Click on "Mark as done", then "Sales Order" 7. The Delivered Quantities have a correct value but the Ordered Quantities do not ### Explanation: An uom conversion is performed in `_get_delivered_quantity_by_analytic` to compute `qty_delivered` but is missing in `_fsm_create_sale_order_line` for `product_uom_qty`. https://github.com/odoo/odoo/blob/18e03c73691d9efa82cbf82b5e084172fe74665e/addons/sale/models/sale_order_line.py#L386-L392 ### Suggested Fix: To prevent unintended behaviours, any product that is currently used in a Field Service Project will have `invoice_policy`, `service_type` and `detailed_type` locked to match the domain of `timesheet_product_id` for every model using it. opw-3858530 Forward-Port-Of: odoo/enterprise#66079 Forward-Port-Of: odoo/enterprise#63337
### Steps to reproduce: - Install mrp_quality and uninstall mrp_workrder - Create products A, B, and C - Product A: Storable, Manufacturing: - BOM: - 1 x product B - Product B: Storable, tracked by Lot, Manufacturing route with: - BOM: - 1 x Product C - Quality check: Op manufacturing and Control Per Quantity - Product C: Storable, On hand quantity of 10 - Create MO for product B and complete it with a Lot id - Create MO for product A > confirm #### > Trace
Original PR description
### Steps to reproduce: - Install mrp_quality and uninstall mrp_workrder - Create products A, B, and C - Product A: Storable, Manufacturing: - BOM: - 1 x product B - Product B: Storable, tracked by…
### Steps to reproduce:
- Install mrp_quality and uninstall mrp_workrder
- Create products A, B, and C
- Product A: Storable, Manufacturing:
- BOM: - 1 x product B
- Product B: Storable, tracked by Lot, Manufacturing route with:
- BOM: - 1 x Product C
- Quality check: Op manufacturing and Control Per Quantity
- Product C: Storable, On hand quantity of 10
- Create MO for product B and complete it with a Lot id
- Create MO for product A > confirm
#### > Traceback error
### Cause of the issue:
The `move_id` field of the `quality.check` model is used in the `_update_lot_from_lot_line` method of that same model. However, the method is defined in the `quality_mrp` module while the `move_id` field is defined in the `mrp_workorder` module.
Since `quality_mrp` depends on `mrp` and since `mrp_workorder` is auto installed when `mrp` is installed, this should not be an issue. However, since `mrp_workorder` is not a strict dependency of the `quality_mrp` module, the later in not uninstalled when `mrp_workorder` is. As such, it is possible to not have a `move_id` field on the `quality.check` model while the filed is used in the call of the `_update_lot_from_lot_line` mdethod defined in `quality_mrp`.
### For the posterity:
The method was introduced by commit 8ab6c56 in saas-16.4 for a fix and was later an later updated by commit 801ff42 for an other fix.
opw-3994004
---
Forward-Port-Of: odoo/enterprise#66063Serbian 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. Task-4014022 Community: https://github.com/odoo/odoo/pull/171837 Forward-Port-Of: odoo/enterprise#66061
Steps to reproduce: - set a customer with Belgian VAT and check one with German VAT - Create sales: * one for the Belgian company using the 0% EU sale taxe * another for the German company using the 0% tax for construction (provider §13b) - Go To Statement Reports > EC Sales List Issue: Only the invoice for the Belgian company should appear in the report EC Sales 60 tag should not be present only tags in (41, 42, 21) source: https://apps.datev.de/help-center/documents/1017530 op
Original PR description
Steps to reproduce: - set a customer with Belgian VAT and check one with German VAT - Create sales: * one for the Belgian company using the 0% EU sale taxe * another for the German company using the 0% tax for construction (provider §13b) - Go To Statement Reports > EC Sales List Issue: Only the invoice for the Belgian company should appear in the report EC Sales 60 tag should not be present only tags in (41, 42, 21) source: https://apps.datev.de/help-center/documents/1017530 opw-3923031 Forward-Port-Of: odoo/enterprise#65958 Forward-Port-Of: odoo/enterprise#65098
Steps to reproduce: ------------------- 1. Set the user with 'project > user' access rights level and nothing else. Remove every rights that are related to account/analytic accounting from the user (see record rules, access rights, groups, ...). 2. When opening the Project app, an Access Error occurs (related to 'account.analytic.line'). Fix: ------------------- The progress bar that appears when grouping tasks by project in the gantt view should be able to display the sum of the timeshe
Original PR description
Steps to reproduce: ------------------- 1. Set the user with 'project > user' access rights level and nothing else. Remove every rights that are related to account/analytic accounting from the user (see record rules, access rights, groups, ...). 2. When opening the Project app, an Access Error occurs (related to 'account.analytic.line'). Fix: ------------------- The progress bar that appears when grouping tasks by project in the gantt view should be able to display the sum of the timesheets amount per project even if the user has no access to 'account.analytic.line'. task-3973256 Forward-Port-Of: odoo/enterprise#65873 Forward-Port-Of: odoo/enterprise#63922
Before this commit, avatax used the longitude and latitude in priority even if the partner has an address. The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money. So now it will be the opposite, we will use the address in priority but if the customer has a delivery address wit
Original PR description
Before this commit, avatax used the longitude and latitude in priority even if the partner has an address. The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money. So now it will be the opposite, we will use the address in priority but if the customer has a delivery address with no address information we will use the latitude and longitude of the delivery address partner. Task: 4011481 Forward-Port-Of: odoo/enterprise#66106 Forward-Port-Of: odoo/enterprise#65726
Forward-Port-Of: odoo/enterprise#65976
Original PR description
Forward-Port-Of: odoo/enterprise#65976
The week starts (index 0) on Monday python side, and on Sunday Javascript side. To be able to have both function, the part where we add 7 days to `daysToLastWeekWed` or `days_to_last_weekWed` needs to be done the same way on both sides: from Wednesday to Sunday: * index 2 (WE) to 6 (SU) in Python * index 3 (WE) to 6 (SA) and 0 (SU) in Javascript. Forward-Port-Of: odoo/enterprise#66203
Original PR description
The week starts (index 0) on Monday python side, and on Sunday Javascript side. To be able to have both function, the part where we add 7 days to `daysToLastWeekWed` or `days_to_last_weekWed` needs to be done the same way on both sides: from Wednesday to Sunday: * index 2 (WE) to 6 (SU) in Python * index 3 (WE) to 6 (SA) and 0 (SU) in Javascript. Forward-Port-Of: odoo/enterprise#66203