Wednesday, June 5, 2024
13 changes · saas-17.1
Resolved issues and error corrections
Project updates now avoid tiny currency rounding differences when calculating expenses to bill. This prevents occasional incorrect margin percentages, helping users see more reliable profitability figures for reinvoiced expenses.
Original PR description
Steps to reproduce: ------------- - Install project_sale_expenses and timesheet_grid - Create a new product - Can be Expensed. - Re-Invoice Expenses set to Sales price - Set sales price and cost to…
Steps to reproduce:
-------------
- Install project_sale_expenses and timesheet_grid
- Create a new product
- Can be Expensed.
- Re-Invoice Expenses set to Sales price
- Set sales price and cost to 957
- Create a project(service type)
- Create a sale order with the service type product
and confirm
- Go to the expense App
- Create a expense:
- Choose a category (the product with Expensed).
- Customer to Reinvoice: Select the above sale order.
- Expense posted and approved
- Go to project and open project update
- Check the margin percentage to bill.
Issue:
-------------
Sometimes, the margin percentage of the 'to bill' item becomes unexpectedly
incorrect.
Cause:
-------------
In the _get_expenses_profitability_items function of project_sale_expense,
rounding during currency conversion may lead to minor variations
(e.g., 832.17 to 832.1700000000001)for some values, not all. These differences
accumulate when subtracting untaxed amounts from amount_to_bill, resulting
in a residual value (e.g., 1.1368683772161603e-13) instead of zero, causing
unexpected margin percentages.
Solution :
----------------
The _convert method will not round the value since we passed the round=False in the _convert method.
task-3706741This change adds test coverage to ensure appointment resource time off keeps the end time selected by the user instead of automatically changing it to the end of the day. It supports a related fix that limits that automatic end-of-day behavior to public holidays, reducing scheduling errors in appointments.
Original PR description
# BEWARE: This PR depends on another PR! This is a test that will pass only after https://github.com/odoo/odoo/pull/160665 is merged **In effect this test will fail until the other PR is merged** ##…
# BEWARE: This PR depends on another PR! This is a test that will pass only after https://github.com/odoo/odoo/pull/160665 is merged **In effect this test will fail until the other PR is merged** ## Description [FIX] appointment_hr: TEST Narrow date_to end-time behavior to public holidays This is a test to the related a fix in the community branch. [Preserving original commit message from the fix] Previously, the end-time of 'date_to' for leave requests was consistently set to the end of the day (i.e., 23:59), which was only desirable for public holidays (ref.1). However, this caused undesired behavior in other modules, such as the appointment module. The fix restricts the setting of the end-time of 'date_to' to public holidays, ensuring compatibility and consistency across modules. [ref.1] [IMP] resource: compute date_to for better ux e0f3dd9e01d91896f1c00fb5cb3ce5c821912d03 https://github.com/odoo/odoo/pull/115688 [Reproduce] - Install appointment - Create New Resource Time Off (Appointments/ Configuration/ Resource Leaves) - change time of "End Date" - BUG: time sets itself to 23:59 opw-3841275a
Miscellaneous changes
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install one of the module that use this template Actual result: - Module X installed - Demo data not loaded properly, traceback Expected result - Module X installed - Demo data loaded Initial PR on enterprise: https://github.com/odoo/enterprise/pull/63328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167696
Original PR description
Steps: - Create a database on SaaS - Activate debug mode - Load demo data if not enabled - Install one of the module that use this template Actual result: - Module X installed - Demo data not loaded properly, traceback Expected result - Module X installed - Demo data loaded Initial PR on enterprise: https://github.com/odoo/enterprise/pull/63328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167696
Ensures that the exhibitor level badge is correctly displayed, as it was shown on a separate column for longer sponsor names. Now, it always appears inline, after the name of the sponsor. Task-3874059 Forward-Port-Of: odoo/odoo#162987
Original PR description
Ensures that the exhibitor level badge is correctly displayed, as it was shown on a separate column for longer sponsor names. Now, it always appears inline, after the name of the sponsor. Task-3874059 Forward-Port-Of: odoo/odoo#162987
Current behaviour before commit: When background color is applied on text, the text becomes somewhat invisible in dark mode. Desired behaviour after commit: Now, when background color is applied on text, opacity of 60% is applied to the color. Due to this text becomes somewhat visible. task-3273315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166325 Forward-Port-Of: odoo/odoo#129700
Original PR description
Current behaviour before commit: When background color is applied on text, the text becomes somewhat invisible in dark mode. Desired behaviour after commit: Now, when background color is applied on text, opacity of 60% is applied to the color. Due to this text becomes somewhat visible. task-3273315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166325 Forward-Port-Of: odoo/odoo#129700
Problem: When a quotation is printed for a client in a different language that uses different decimal separators, the discounted price for optional products are not being displayed with the same decimal separators used throughout the quotation. Purpose: The formats of the price should be consistent. Steps to Reproduce on Runbot: 1. Install Sales 2. Enable Discounts in Setting > Sales 3. Create a quotation with a German customer and discounted optional products 4. Print the quotation 5
Original PR description
Problem: When a quotation is printed for a client in a different language that uses different decimal separators, the discounted price for optional products are not being displayed with the same decimal separators used throughout the quotation. Purpose: The formats of the price should be consistent. Steps to Reproduce on Runbot: 1. Install Sales 2. Enable Discounts in Setting > Sales 3. Create a quotation with a German customer and discounted optional products 4. Print the quotation 5. Observe the discounted price has inconsistent formatting (ex. shows 140.00 instead of 140,00 since German uses , as decimal separators) opw-3853464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167677 Forward-Port-Of: odoo/odoo#165888
VAT should be accounted for on gift card rewards (when necessary). To allow that, we will start considering the taxes set on the reward product. As it is enforced that no taxes are set on that product on creation, we are sure that if a tax is set on the product, it can safely be applied on the reward line. opw-3817604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164391
Original PR description
VAT should be accounted for on gift card rewards (when necessary). To allow that, we will start considering the taxes set on the reward product. As it is enforced that no taxes are set on that product on creation, we are sure that if a tax is set on the product, it can safely be applied on the reward line. opw-3817604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164391
- Re-using results for domains duplicated - Ordering by id instead of default heavy unused order Opening a POS sessions our SQL profiler shows the following query executed too many times: - <img width="770" alt="Screenshot 2024-05-07 at 8 41 09 a m" src="https://github.com/odoo/odoo/assets/6644187/80d7ac19-a042-40bc-a525-063b4074ec0e"> Checking the PY profilers the following method is reported as slow: https://github.com/odoo/odoo/blob/42f5e84eeb1d649feed5e032d65ff74d148b49b8/addons/po
Original PR description
- Re-using results for domains duplicated - Ordering by id instead of default heavy unused order Opening a POS sessions our SQL profiler shows the following query executed too many times: - <img…
- Re-using results for domains duplicated
- Ordering by id instead of default heavy unused order
Opening a POS sessions our SQL profiler shows the following query executed too many times:
- <img width="770" alt="Screenshot 2024-05-07 at 8 41 09 a m" src="https://github.com/odoo/odoo/assets/6644187/80d7ac19-a042-40bc-a525-063b4074ec0e">
Checking the PY profilers the following method is reported as slow:
https://github.com/odoo/odoo/blob/42f5e84eeb1d649feed5e032d65ff74d148b49b8/addons/pos_coupon/models/coupon_program.py#L80
- <img width="1508" alt="Screenshot 2024-05-07 at 8 42 17 a m" src="https://github.com/odoo/odoo/assets/6644187/e46b60f0-cac2-480b-b588-d681f0bc5607">
The reason it is executing the same query too many times with the same domain
So, I have created this change to re-use the result if the domain is repeated
Also, the query generated has heavy `order by`
`order by "res_partner"."type", coalesce("res_partner"."is_company", false) desc, "res_partner"."display_name", "res_partner"."id"; `
Replacing by `order by "res_partner"."id"` it is faster
Before `Execution Time: 104.256 ms`
Now `Execution Time: 31.802 ms`
So, it is ~4x faster for each query and it is re-using data for the same query using a LRU-Cache locally in the method
Manual Forward-Port-Of: https://github.com/odoo/odoo/pull/164771 since the module was renamed and the python code refactored so the bot was not able to forward-port it automatically from https://github.com/odoo/odoo/pull/166447
Also, i didn't find the part of the partners in this new version
Forward-Port-Of: odoo/odoo#166608In "Task-3890068 OPW-3787054" the customer is facing the issue regarding the activity. on clicking on activity they are getting all the records instead of the filtered data. Solution: 1) Added the code to enable "late" or "today" activity filter by default. 2) Added the on-click into the XML to get the activity for the appropriate button. Before PR: Not able to get the filtered record Video: https://drive.google.com/file/d/1s2K-1-n9y2hmRJhrxyZXGgGRoZ1KACSv/view?usp=sharing After PR
Original PR description
In "Task-3890068 OPW-3787054" the customer is facing the issue regarding the activity. on clicking on activity they are getting all the records instead of the filtered data. Solution: 1) Added the code to enable "late" or "today" activity filter by default. 2) Added the on-click into the XML to get the activity for the appropriate button. Before PR: Not able to get the filtered record Video: https://drive.google.com/file/d/1s2K-1-n9y2hmRJhrxyZXGgGRoZ1KACSv/view?usp=sharing After PR: Enable the filter (late, today and future activities) Video: https://drive.google.com/file/d/1a2mRHfZeHqvPcDHyIa6PlKyYw1HiImv7/view?usp=sharing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162567
Currently, an error occurs when the user tries to select a selection, boolean, or radio field. Steps to produce an error: 1. Install web_studio 2. Go to Settings > Users & Companies > Users > Select any user 3. Open studio mode by clicking the studio icon. 4. Try to select the Administration field from the access right page Error: ``` TypeError: WebStudioController.get_default_value() missing 1 required positional argument: 'field_name' File "odoo/http.py", line 2139, in __call__
Original PR description
Currently, an error occurs when the user tries to select a selection, boolean, or radio field. Steps to produce an error: 1. Install web_studio 2. Go to Settings > Users & Companies > Users > Select…
Currently, an error occurs when the user tries to select a selection, boolean, or radio field.
Steps to produce an error:
1. Install web_studio
2. Go to Settings > Users & Companies > Users > Select any user
3. Open studio mode by clicking the studio icon.
4. Try to select the Administration field from the access right page
Error:
```
TypeError: WebStudioController.get_default_value() missing 1 required positional argument: 'field_name'
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
```
This is because before the owl refactor of webstudio with https://github.com/odoo/enterprise/pull/37285/commits/e44403193cbfd7893708ff739fd072f8bb1197c6, the code tries
to access the field name from the 'attrs' of the node (see [1]), but after Commit[1],
it tries to access the field name from the 'field' of the node (see [1]), and it works for
normal fields like text, number, etc., but not for grouped fields like selection, boolean, radio, etc.
This commit fixes the above issue by not fetching or changing the
default value of reified fields. Now, after this commit, the default
value box is not showing for the reified fields.
[1]-https://github.com/odoo/enterprise/blob/1fd7b1182146f1d7e6a7cbb9b725cb4d47281e14/web_studio/static/src/legacy/js/views/view_editor_manager.js#L1029 [2]-https://github.com/odoo/enterprise/blob/50b6e04d2e2f47797ec14bf506a030bd1d9bc797/web_studio/static/src/client_action/view_editor/interactive_editor/properties/field_properties/field_properties.js#L117
sentry-4156923959
Forward-Port-Of: odoo/enterprise#63465
Forward-Port-Of: odoo/enterprise#50249Before this change we were always setting document type for the debit note by default, but this should only apply if from Peru LATAM 1198 Forward-Port-Of: odoo/enterprise#63655 Forward-Port-Of: odoo/enterprise#63099
Original PR description
Before this change we were always setting document type for the debit note by default, but this should only apply if from Peru LATAM 1198 Forward-Port-Of: odoo/enterprise#63655 Forward-Port-Of: odoo/enterprise#63099
If we upload a Soda and an account is not mapped, we'll fall back on the Suspense Account. However, when modifying the entry line with the Suspense Account, the general Soda Mapping is not updated. For UX reasons, we should update the general Soda Mapping too so that the user doesn't have to modify it twice. However, we shouldn't do the reverse. I.e. when modifying the general Soda Mapping, we shouldn't modify the existing entries. taks-id: 3954585 Forward-Port-Of: odoo/enterprise#6
Original PR description
If we upload a Soda and an account is not mapped, we'll fall back on the Suspense Account. However, when modifying the entry line with the Suspense Account, the general Soda Mapping is not updated. For UX reasons, we should update the general Soda Mapping too so that the user doesn't have to modify it twice. However, we shouldn't do the reverse. I.e. when modifying the general Soda Mapping, we shouldn't modify the existing entries. taks-id: 3954585 Forward-Port-Of: odoo/enterprise#63356
Create a branch company In the parent company: - Create a [tax] of type "Group of Taxes" and add a child tax - add [tax] to a [product] record In the branch company: - Create an invoice with [product] - Open journal Reports KeyError will raise It occurs because we fetch the tax data by SQL selecting data belonging to the current company only, without considering parent companies opw-3874824 Forward-Port-Of: odoo/enterprise#63004
Original PR description
Create a branch company In the parent company: - Create a [tax] of type "Group of Taxes" and add a child tax - add [tax] to a [product] record In the branch company: - Create an invoice with [product] - Open journal Reports KeyError will raise It occurs because we fetch the tax data by SQL selecting data belonging to the current company only, without considering parent companies opw-3874824 Forward-Port-Of: odoo/enterprise#63004