Daily updates from Odoo
Navigate
Branch
Thursday, December 8, 2022
29 changes
Enhancements to existing features
The task form now shows planned start and end dates closer to key customer or sales order information. This makes scheduling details easier to find when reviewing or updating tasks, especially for field service workflows.
Original PR description
- project.task form view: the fields 'planned_date_begin' and 'planned_date_end' are displayed after the customer field (or after the SOL field if it exists) Task-3046210 related PR-https://github.com/odoo/odoo/pull/107502
Subscription health rules and renewal timing are now managed through subscription alerts instead of templates or a fixed scheduled job. This gives businesses clearer, more flexible control over how contract health is assessed and when subscriptions are marked for renewal, including subscriptions without templates.
Original PR description
Before this commit, the health value of an order was determined by the template health domains. It would prevent subscription without template to have "bad" or "good" health value. Moreover it was not logical to keep these definition there. A cron job was setting the subscriptions to renew one month before their end date. This logic has been moved to subscription alerts to bring more control to the users. taskid: 2831415
The Data menu in spreadsheets has been reorganized so pivot and list options appear after filter and sort actions. This makes common data actions easier to find in a more logical order.
Original PR description
PURPOSE To re organize the menu items in "Data" on top bar in spreadsheet. SPECIFICATION Re arrange the items displayed on top menu, here the sequence of menu items in data are changed to have pivot and list items displayed after Create filter and Sort range. Task - 3040923
This update adds automated test coverage to ensure a prefilled value of "0" is handled correctly during signing. It helps prevent a previously fixed issue from returning, reducing the risk of incorrect behavior in payroll-related signing workflows.
Original PR description
PR https://github.com/odoo/enterprise/pull/31227 fixed an issue where the sign frontend would treat a prefilled '0' as falsy. This commit changes the test_ui test so that this case is also tested. task-2980394
The Data Cleaning module was tidied up by removing an unused background method. This has no expected impact on daily workflows, but helps keep the system easier to maintain and less prone to future issues.
Original PR description
remove unused inherited create function from data_cleaning module
Spreadsheet-related views have been updated to work with the latest spreadsheet engine and support inserting images. This improves spreadsheet editing in Documents and Dashboards by enabling richer visual content directly inside sheets.
Original PR description
adapt code for o-spreadsheet latest version. See community PR https://github.com/odoo/odoo/pull/107372
Resolved issues and error corrections
When a subscription is closed, any remaining billable items are now included in the final invoice. This helps businesses collect the full amount owed and reduces missed revenue at the end of a subscription.
Original PR description
Pay what is left at the end of a subscription
The project task view now hides the planning overlap button when planning overlap checks are disabled. This removes unnecessary blank space beside leave warnings, making the screen cleaner and less confusing for users.
Original PR description
[FIX] project_enterprise: Hide planning_overlap bar **Before this commit:** When planning_overlap = False and leave_warning = True, An alert bar is displayed to show the leave warning but and additional empty space is shown. It's because we inherit the view and we add the leave_warning before the button that redirect to planning_overlap. The button doesn't have an invisible condition when planning_overlap = False. **In this commit:** The button should be invisible when planning_overlap = False task-3092925
The Dutch profit and loss report now lists sub-expense categories directly instead of grouping them under an uncommon parent category. This makes the report better aligned with local business expectations and easier for Dutch users to read.
Original PR description
Description of the issue/feature this PR addresses: Improvement of Dutch Localization, Remove NL_GCOST and show the subs directly. This parent is not common used like this Current behavior before PR: There is a parent grouping on 'Algemene beheerkosten' with all the sub expenses. This parent is not common used like this Desired behavior after PR is merged: Remove NL_GCOST and show the sub expenses directly. -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
The subscription MRR stat button now always shows the monthly recurring revenue the subscription would have when active, even after it is closed. Closing events are still logged for reporting and analysis, preserving business insight while making the displayed value easier to understand.
Original PR description
This commit change the behaviour of the MRR stat button. The value shown on the stat button always represent the MRR of the subscription if it was active. Nonetheless, we still create MRR log for the closing of the subs for analytical purposes. task-id : 3095564
Code cleanup and technical improvements
The separate Sales Enterprise module is being folded into the main Sales module because its remaining reporting fields no longer need to be maintained separately. This simplifies the app structure and should have little visible impact for business users.
Miscellaneous changes
Setting a domain on a marketing campaign did not properly set the domain on the activities created inside of it. The domain is computed properly on creation, or when the activity domain is set. But this is confusing in case the activity doesn't have a domain as the user will see no domain applied until they leave the modal. task-3084676 Forward-Port-Of: odoo/enterprise#34721
Original PR description
Setting a domain on a marketing campaign did not properly set the domain on the activities created inside of it. The domain is computed properly on creation, or when the activity domain is set. But this is confusing in case the activity doesn't have a domain as the user will see no domain applied until they leave the modal. task-3084676 Forward-Port-Of: odoo/enterprise#34721
Steps to reproduce the bug: - Let's consider a Helpdesk Team HT that allows to return picking - Let's consider a partner P with a delivery address DA - Create a SO for P with a storable product SP - Confirm the SO and process the delivery order DO - Archive DA - Create a ticket in HT for P with product = SP - Click on return button and erase the suggested SO (if one is suggested) - In the field Delivery to return, search for DO Bug: DO was not foundable anymore if DA was archived
Original PR description
Steps to reproduce the bug: - Let's consider a Helpdesk Team HT that allows to return picking - Let's consider a partner P with a delivery address DA - Create a SO for P with a storable product SP - Confirm the SO and process the delivery order DO - Archive DA - Create a ticket in HT for P with product = SP - Click on return button and erase the suggested SO (if one is suggested) - In the field Delivery to return, search for DO Bug: DO was not foundable anymore if DA was archived opw:3021148 Forward-Port-Of: odoo/enterprise#34543 Forward-Port-Of: odoo/enterprise#33820
FIX depends duplication made in df01f007fd5c282462ea58ddf3e1b92837fdb2ae Forward-Port-Of: odoo/enterprise#34789
Original PR description
FIX depends duplication made in df01f007fd5c282462ea58ddf3e1b92837fdb2ae Forward-Port-Of: odoo/enterprise#34789
In Odoo 15, when you activate the option to "Centralize files attached to projects and tasks" and then make some attachments to tasks, they will appear in the workspace specified in the documents module. But then, when upgrading to 16, a post_init script tries to delete the workspace without taking care of all linked documents. This PR change the condition for fsm folders to be deleted depending on more precise conditions. The error traceback: ``` 2022-11-22 08:57:49,372 30 CRITICAL db_
Original PR description
In Odoo 15, when you activate the option to "Centralize files attached to projects and tasks" and then make some attachments to tasks, they will appear in the workspace specified in the documents…
In Odoo 15, when you activate the option to
"Centralize files attached to projects and tasks" and then make some attachments to tasks, they will appear in the workspace specified in the documents module. But then, when upgrading to 16, a post_init script tries to delete the workspace without taking care of all linked documents.
This PR change the condition for fsm folders to be deleted depending on more precise conditions.
The error traceback:
```
2022-11-22 08:57:49,372 30 CRITICAL db_44 odoo.service.server: Failed to initialize database `db_44`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/16.0/odoo/service/server.py", line 1289, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-14>", line 2, in new
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/16.0/odoo/modules/registry.py", line 91, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 482, in load_modules
processed_modules += load_marked_modules(cr, graph,
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 371, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/16.0/odoo/modules/loading.py", line 248, in load_module_graph
getattr(py_module, post_init)(cr, registry)
File "/home/odoo/src/enterprise/16.0/documents_fsm/__init__.py", line 12, in _documents_fsm_post_init
fsm_projects.documents_folder_id.unlink()
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3543, in unlink
cr.execute(query, (sub_ids,))
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 315, in execute
res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "documents_folder" violates foreign key constraint "documents_document_folder_id_fkey" on table "documents_document"
DETAIL: Key (id)=(1) is still referenced from table "documents_document".
```
Forward-Port-Of: odoo/enterprise#34484Before this commit, the journal items opened in the aged partner reports will not be filtered by account types. We want the journal items of the aged payable to be filtered on payable account type and the aged receivable to be filtered on receivable account type. Forward-Port-Of: odoo/enterprise#34492
Original PR description
Before this commit, the journal items opened in the aged partner reports will not be filtered by account types. We want the journal items of the aged payable to be filtered on payable account type and the aged receivable to be filtered on receivable account type. Forward-Port-Of: odoo/enterprise#34492
Before, when resetting a tax closing move to draft, we kept the previously created carryover values. When reposting the move, we never regenerated the carryover. It meant that if the amounts in the tax report changed before reposting the closing (to fix an error, for example), the carryover values were not consistent with it anymore. Furthermore, when unlinking a closing move previously posted then re-doing the closing on the report, a brand new move got created, generating new carryover valu
Original PR description
Before, when resetting a tax closing move to draft, we kept the previously created carryover values. When reposting the move, we never regenerated the carryover. It meant that if the amounts in the tax report changed before reposting the closing (to fix an error, for example), the carryover values were not consistent with it anymore. Furthermore, when unlinking a closing move previously posted then re-doing the closing on the report, a brand new move got created, generating new carryover values at posting, hence duplicating the carryover amounts. We fix that by always unlinking the related carryover values when resetting a closing move to draft, raising an error if this would impact a locked report. OPW 3066409 Forward-Port-Of: odoo/enterprise#34742
Tax handlers get dynamic lines generated from the generic tax report. These additional lines appear in tax reports for l10n_es, l10n_lu, l10n_uk. The current workaround is to override `_dynamic_lines_generator` to return an empty list. Before this commit: - Additional lines from the generic tax report appear in custom tax reports. After this commit: - Custom tax reports only contain relevant report lines. Forward-Port-Of: odoo/enterprise#34666
Original PR description
Tax handlers get dynamic lines generated from the generic tax report. These additional lines appear in tax reports for l10n_es, l10n_lu, l10n_uk. The current workaround is to override `_dynamic_lines_generator` to return an empty list. Before this commit: - Additional lines from the generic tax report appear in custom tax reports. After this commit: - Custom tax reports only contain relevant report lines. Forward-Port-Of: odoo/enterprise#34666
Before this commit, when calling extract, we were setting the phone number received as a `phone` field, wether it was a landline or a mobile number. This commit takes advantage of the newly implemented MobileFeature on the OCR server. task-2972937 Forward-Port-Of: odoo/enterprise#34221
Original PR description
Before this commit, when calling extract, we were setting the phone number received as a `phone` field, wether it was a landline or a mobile number. This commit takes advantage of the newly implemented MobileFeature on the OCR server. task-2972937 Forward-Port-Of: odoo/enterprise#34221
**Steps to reproduce the bug:** - Create a storable product “P1” - Update the quantity to 10 - Create a control point: - Product: “P1” - Operations: “Delivery orders” - Type: “Measure” - Norm: 10 mm - Control per: “product” - Create a Transfer: - Product: “P1” - Operation type: “Delivery orders” - select any delivery address - Mark as Todo - The quantity should be reserved automatically - Click on “Quality Check” button - Try to validate the
Original PR description
**Steps to reproduce the bug:**
- Create a storable product “P1”
- Update the quantity to 10
- Create a control point:
- Product: “P1”
- Operations: “Delivery orders”
- Type: “Measure”
- Norm: 10 mm
- Control per: “product”
- Create a Transfer:
- Product: “P1”
- Operation type: “Delivery orders”
- select any delivery address
- Mark as Todo
- The quantity should be reserved automatically
- Click on “Quality Check” button
- Try to validate the check
**Problem:**
Traceback is triggered: `ValueError: Expected singleton: mrp.workorder()`
The `_change_quality_check` function is called with an empty record, so the `self.ensure_one()` triggers a traceback
**Solution:**
Call the function only if there is a work order
opw-3089049
Forward-Port-Of: odoo/enterprise#34653Forward-Port-Of: odoo/enterprise#34749
Original PR description
Forward-Port-Of: odoo/enterprise#34749
TaskID: 3091043 Forward-Port-Of: odoo/enterprise#34662
Original PR description
TaskID: 3091043 Forward-Port-Of: odoo/enterprise#34662
Ideally, we develop in English any localization (then translate to the domestic language, in this case Serbian) All the module has been translated in english and then a .po file has been create to translate back in Serbian Task-id: 3086250 Forward-Port-Of: odoo/enterprise#34781
Original PR description
Ideally, we develop in English any localization (then translate to the domestic language, in this case Serbian) All the module has been translated in english and then a .po file has been create to translate back in Serbian Task-id: 3086250 Forward-Port-Of: odoo/enterprise#34781
Forward-Port-Of: odoo/enterprise#34697
Original PR description
Forward-Port-Of: odoo/enterprise#34697
Changing the bank account on the bank journal led to a traceback (expected singleton on currency_id) when trying to open the reconciliation widget. This is because we are trying to open a blank line as the origin line was linked to the origin Bank account, therefore there is no currency_id. It has been decided to filter the statement line that match the bank account. Steps to reproduce: - Create a bank statement line - In Bank journal, change the Bank Account - From Accounting Dashboard, clic
Original PR description
Changing the bank account on the bank journal led to a traceback (expected singleton on currency_id) when trying to open the reconciliation widget. This is because we are trying to open a blank line as the origin line was linked to the origin Bank account, therefore there is no currency_id. It has been decided to filter the statement line that match the bank account. Steps to reproduce: - Create a bank statement line - In Bank journal, change the Bank Account - From Accounting Dashboard, click on "Reconcile X items" or just open the Bank Journal -> Traceback (expected singleton) opw-3085670 Forward-Port-Of: odoo/enterprise#34702
Before this commit, there was an issue with certain builds using a more recent version of the `zeep` library. The following traceback occured: ``` odoo.addons.delivery_dhl.tests.test_delivery_dhl:245 ERROR: TestMockedDeliveryDHL.test_01_dhl_basic_be_domestic_flow Traceback (most recent call last): File "/data/build/enterprise/delivery_dhl/tests/test_delivery_dhl.py", line 245, in test_01_dhl_basic_be_domestic_flow super().test_01_dhl_basic_be_domestic_flow() File "/data/build/e
Original PR description
Before this commit, there was an issue with certain builds using a more recent version of the `zeep` library. The following traceback occured: ``` odoo.addons.delivery_dhl.tests.test_delivery_dhl:245…
Before this commit, there was an issue with certain builds using a more recent version of the `zeep` library.
The following traceback occured:
```
odoo.addons.delivery_dhl.tests.test_delivery_dhl:245
ERROR: TestMockedDeliveryDHL.test_01_dhl_basic_be_domestic_flow
Traceback (most recent call last):
File "/data/build/enterprise/delivery_dhl/tests/test_delivery_dhl.py", line 245, in test_01_dhl_basic_be_domestic_flow
super().test_01_dhl_basic_be_domestic_flow()
File "/data/build/enterprise/delivery_dhl/tests/test_delivery_dhl.py", line 73, in test_01_dhl_basic_be_domestic_flow
choose_delivery_carrier.update_price()
File "/data/build/odoo/addons/delivery/wizard/choose_delivery_carrier.py", line 76, in update_price
vals = self._get_shipment_rate()
File "/data/build/odoo/addons/delivery/wizard/choose_delivery_carrier.py", line 67, in _get_shipment_rate
vals = self.carrier_id.rate_shipment(self.order_id)
File "/data/build/odoo/addons/delivery/models/delivery_carrier.py", line 176, in rate_shipment
res = getattr(self, '%s_rate_shipment' % self.delivery_type)(order)
File "/data/build/enterprise/delivery_dhl/models/delivery_dhl.py", line 120, in dhl_rate_shipment
res = self._rate_shipment_vals(order=order)
File "/data/build/enterprise/delivery_dhl/models/delivery_dhl.py", line 136, in _rate_shipment_vals
srm = DHLProvider(self.log_xml, request_type="rate", prod_environment=self.prod_environment)
File "/data/build/enterprise/delivery_dhl/models/dhl_request.py", line 27, in __init__
self.client = self._set_client('rate.wsdl', 'Rate')
File "/data/build/enterprise/delivery_dhl/models/dhl_request.py", line 35, in _set_client
client = Client('file:///%s' % wsdl_path.lstrip('/'))
File "/usr/lib/python3/dist-packages/zeep/client.py", line 71, in __init__
transport if transport is not None else self._default_transport()
File "/usr/lib/python3/dist-packages/zeep/transports.py", line 41, in __init__
self.session.mount("file://", FileAdapter())
AttributeError: 'MockedSession' object has no attribute 'mount'
```
This commit ensures that the `mount`, as well as the `close` methods are callable in zeep.transport.requests.Session for the versions using it.
The path for the init of the zeep.Client was changed from a `file://` to a relative path to avoid calling Session.get from the zeep.Transport, aswell.
---
**[FIX] delivery_fedex: convert amount from unknown company**
Before this commit, if no company was associated to the sale order, the fedex delivery module was crashing when the currency had to be converted.
Traceback:
```
FAIL: TestMockDeliveryFedex.test_04_fedex_international_delivery_from_delivery_order
Traceback (most recent call last):
File "/data/build/enterprise/delivery_fedex/tests/test_delivery_fedex.py", line 299, in test_04_fedex_international_delivery_from_delivery_order
super().test_04_fedex_international_delivery_from_delivery_order()
File "/data/build/enterprise/delivery_fedex/tests/test_delivery_fedex.py", line 246, in test_04_fedex_international_delivery_from_delivery_order
delivery_order.button_validate()
File "/data/build/odoo/addons/stock/models/stock_picking.py", line 1072, in button_validate
pickings_to_backorder.with_context(cancel_backorder=False)._action_done()
File "/data/build/odoo/addons/sale_stock/models/stock.py", line 84, in _action_done
res = super()._action_done()
File "/data/build/odoo/addons/stock/models/stock_picking.py", line 884, in _action_done
self._send_confirmation_email()
File "/data/build/odoo/addons/delivery/models/stock_picking.py", line 139, in _send_confirmation_email
pick.sudo().send_to_shipper()
File "/data/build/odoo/addons/delivery/models/stock_picking.py", line 181, in send_to_shipper
res = self.carrier_id.send_shipping(self)[0]
File "/data/build/odoo/addons/delivery/models/delivery_carrier.py", line 211, in send_shipping
return getattr(self, '%s_send_shipping' % self.delivery_type)(pickings)
File "/data/build/enterprise/delivery_fedex/models/delivery_fedex.py", line 333, in fedex_send_shipping
carrier_price = self._get_request_price(response['price'], order, order_currency)
File "/data/build/enterprise/delivery_fedex/models/delivery_fedex.py", line 474, in _get_request_price
return currency_by_name[fdx_currency]._convert(
File "/data/build/odoo/odoo/addons/base/models/res_currency.py", line 244, in _convert
assert company, "convert amount from unknown company"
AssertionError: convert amount from unknown company
```
Forward-Port-Of: odoo/enterprise#34701*: industry_fsm_report, worksheet First Issue =========== To Reproduce ------------ - Enable Analytic tags on Accounting settings - open a sale order - open studio - select edit list view on sale order lines - show hiden elements and select Analytic Tags - check *Disable Creation* A Validation Error is raised Problem ------- The argument `model` in the overrides of the method `edit_view` in `industry_fsm_report` and `worksheet` is missing, When the `edit_view` is called in
Original PR description
*: industry_fsm_report, worksheet First Issue =========== To Reproduce ------------ - Enable Analytic tags on Accounting settings - open a sale order - open studio - select edit list view on sale…
*: industry_fsm_report, worksheet First Issue =========== To Reproduce ------------ - Enable Analytic tags on Accounting settings - open a sale order - open studio - select edit list view on sale order lines - show hiden elements and select Analytic Tags - check *Disable Creation* A Validation Error is raised Problem ------- The argument `model` in the overrides of the method `edit_view` in `industry_fsm_report` and `worksheet` is missing, When the `edit_view` is called in `web_studio` the argument will be `None` then will be replaced by `view.model` https://github.com/odoo/enterprise/blob/203eafdf2cdaab034c83c628d5e81d0265b66860/web_studio/controllers/main.py#L566 which is `sale.order` in this case. then at this line : https://github.com/odoo/enterprise/blob/203eafdf2cdaab034c83c628d5e81d0265b66860/web_studio/controllers/main.py#L1036 we will look for `analytic_tag_ids` in the model `sale.order` which can't be there and that what leads to the error. Solution -------- To solve the issue we add the argument `model` to the overrides of `edit_view` Second Issue ============ To Reproduce ------------ Having the first issue fixed, when we check *Disable creation* on Analytic Tags, it's automatically unchecked and it doesn't modify anything. Problem ------- the form view of `sale.order` has a `form` and a `tree`, the filed `analytic_tag_ids` is present in both views, so when we apply the changes on `analytic_tag_ids` in the `tree` view, because of not precising the correct xpath we take the first field `analytic_tag_ids` which is the one of the `form`, and that explains this behavior. Solution -------- the problem comes from this weird/extraordinary condition :slightly_smiling_face: : https://github.com/odoo/enterprise/blob/203eafdf2cdaab034c83c628d5e81d0265b66860/web_studio/controllers/main.py#L821 where I think the writer of it wanted to simply do : ```py if expr not in xpath: expr = xpath + expr ``` opw-2978291 Forward-Port-Of: odoo/enterprise#34699 Forward-Port-Of: odoo/enterprise#31360
This commit purpose is to hide rating for the user when the user's active companies are different than the company of the rating's associated employee. This commit : - change the domain of the view so that the rating with the wrong companies are not showed task-3044723 Forward-Port-Of: odoo/enterprise#33315
Original PR description
This commit purpose is to hide rating for the user when the user's active companies are different than the company of the rating's associated employee. This commit : - change the domain of the view so that the rating with the wrong companies are not showed task-3044723 Forward-Port-Of: odoo/enterprise#33315
Steps to reproduce: - with an user, start a timer; - with an other user which can validate timesheet of the first user, validate timesheet. Issue: It is possible to validate timesheet even if someone has started the timer on it. If timesheet is validated, you can`t stop the timer. If you stop the timer, the error message appears. Then timer stops, but if you refresh the page, time continues to go. Solution: Force the stop of current timers for the timeshe
Original PR description
Steps to reproduce:
- with an user, start a timer;
- with an other user which can validate timesheet of the first user, validate timesheet.
Issue:
It is possible to validate timesheet even if someone has started the timer on it.
If timesheet is validated, you can`t stop the timer.
If you stop the timer, the error message appears.
Then timer stops, but if you refresh the page, time continues to go.
Solution:
Force the stop of current timers for the timesheet to be validated regardless of the user.
Remark:
The `action_timer_stop` function only acts on the current user's timer only.
We will still have to refresh the page to see the timer stopped.
opw-3073120
Forward-Port-Of: odoo/enterprise#34733
Forward-Port-Of: odoo/enterprise#34483