Tuesday, July 18, 2023
19 changes
Enhancements to existing features
The Knowledge editor now hides formatting commands that are not appropriate in specific areas such as banners, tables, and behavior sections. This helps users avoid applying actions that could disrupt page layout or create inconsistent content.
Original PR description
This commit applies the filter method from editor utils to filter out some commands from given selectors, notably banners, table and behaviours. Task-2782426
This update adapts Enterprise modules to support improved caching behavior introduced in the core platform. It helps keep related business features reliable and consistent after backend cache changes, including a correction for follow-up accounting data handling.
Original PR description
Complement of odoo/odoo#119813
Resolved issues and error corrections
The Peruvian reporting tests now include a required partner identification type. This prevents test failures when assigning invoice document types and helps keep local compliance checks reliable.
Original PR description
The identification type field is required in the view, and now is send in the test. With this avoid error on document type assignation on the tests, because only if the document type in the partner id 6 (RUC) could be used the invoice document type.
Miscellaneous changes
In Knowledge, the record and its latest changes should always be saved before leaving the form view. Summary of the changes in this commit: - Add the `askChanges` call in `beforeLeave` of the Knowledge controller (this change is not done for every controller, because the `HtmlField` currently reports itself as dirty too often and that feature should be reworked. In Knowledge, loosing content of the article body is a greater concern than doing too many `save` calls, so we will
Original PR description
In Knowledge, the record and its latest changes should always be saved before leaving the form view. Summary of the changes in this commit: - Add the `askChanges` call in `beforeLeave` of the…
In Knowledge, the record and its latest changes should always be saved before leaving the form view. Summary of the changes in this commit: - Add the `askChanges` call in `beforeLeave` of the Knowledge controller (this change is not done for every controller, because the `HtmlField` currently reports itself as dirty too often and that feature should be reworked. In Knowledge, loosing content of the article body is a greater concern than doing too many `save` calls, so we will enforce saving until the `dirty` process is reworked). This will allow to clean `askChanges` calls in the Knowledge module that were progressively added as monkey patches to try and make things work. - Ensure that the functions called during the `beforeunload` callback for the htmlField are quasi-synchronous (see community PR too). - Introduce tests that verify those use cases Technical explanation: Normally, the htmlField.commitChanges is done when the blur event triggers on the editable element, but in Knowledge, it is possible to call doAction through a Behavior by clicking on an element inside the editable. This means that the blur event is not triggered, and the record will not have been made aware that the htmlField has pending changes, therefore the beforeLeave callbacks of the Form view will not save these changes. The issue lies with the current model implementation and more precisely the `isDirty` method, which should ask fields for changes `askChanges` during the `beforeLeave` call. In case of `beforeUnload`, the callback provided will be called with a specific `urgent` parameter and in those conditions, we should ensure that it is quasi-synchronous, as the browser allocates a specific (short) amount of time for the callback execution, and it is not enough to wait for an async rpc roundtrip. Therefore we should not wait for `Behaviors` to be fully mounted during the execution of the callback. A consequence of that change is that we now have to change the way we remove `Behavior` `anchor` children when we let Owl mount node inside it: we can remove them synchronously when `Owl` finished its `mount` process instead of doing it before the mounting starts (because the "after" occurs in the same microtask as the node insertion by OWL, but the "before" does not). This means registering those nodes before the mounting, and passing them as props to the `Behavior` which will remove them when it is mounted (in `AbstractBehavior`). COMMUNITY PR: https://github.com/odoo/odoo/pull/127903 task-3372343 Forward-Port-Of: odoo/enterprise#44284 Forward-Port-Of: odoo/enterprise#42644
This fixes automated checks after a related change altered the order in which price lists are handled. It helps ensure subscription and rental sales flows continue to be validated correctly without changing customer-facing behavior.
Original PR description
Fixes tests invalidated by: https://github.com/odoo/odoo/pull/121441 PR changes the pricelists order opw-3282880
This update improves the performance of document signing workflows by making status-based searches faster. Users should see smoother filtering and signature request handling, especially when many signing records exist.
Original PR description
Add missing index on `state` of `sign.request` and `state` of `sign.request.item` used in: - `_compute_is_sharing` - search view filters - `_search_need_my_signature` - `get_document_qweb_context` task-3420528
When multiple OCR IAP accounts of different companies were available, it would always select the one with the highest ID, without taking into account the company to which the document belonged. This happens because the upload of the documents is now done in a cron, where the `company_id` of the environment doesn't necessarily match the `company_id` of the document. Ticket #3369422 Forward-Port-Of: odoo/enterprise#44270 Forward-Port-Of: odoo/enterprise#43780
Original PR description
When multiple OCR IAP accounts of different companies were available, it would always select the one with the highest ID, without taking into account the company to which the document belonged. This happens because the upload of the documents is now done in a cron, where the `company_id` of the environment doesn't necessarily match the `company_id` of the document. Ticket #3369422 Forward-Port-Of: odoo/enterprise#44270 Forward-Port-Of: odoo/enterprise#43780
6b1d61b2df4037fad7dbc7a0401f9bee0d0647fb removed some `div`s that were no longer useful, but neglected to update some part of the JavaScript code accordingly, resulting in the tabs not being displayed after a call. Task-3430368. Forward-Port-Of: odoo/enterprise#44262
Original PR description
6b1d61b2df4037fad7dbc7a0401f9bee0d0647fb removed some `div`s that were no longer useful, but neglected to update some part of the JavaScript code accordingly, resulting in the tabs not being displayed after a call. Task-3430368. Forward-Port-Of: odoo/enterprise#44262
If we have a move whose accounting date is 4 April, and a line whose deferred dates are 1 Jan → 31 May. Then, when this move shouldn't appear in the report of March as the move is not accounted yet. However, it will be displayed in April report. [opw-3425182](https://www.odoo.com/web#id=3425182&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44111
Original PR description
If we have a move whose accounting date is 4 April, and a line whose deferred dates are 1 Jan → 31 May. Then, when this move shouldn't appear in the report of March as the move is not accounted yet. However, it will be displayed in April report. [opw-3425182](https://www.odoo.com/web#id=3425182&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44111
…tally deferred (in manual mode) Steps to reproduce: - Create invoice with a line whose deferred dates are 1/1 -> 31/05 - Go to the deferred report and select May - Generate entries - Error: "You need to add a line before posting." This is because at this point, in May, the line is totally deferred and no deferred lines are created. Therefore an empty move is created and posted. In this case, we should warn the user that no entry has to be generated. [opw-3425165](https://www.odoo.c
Original PR description
…tally deferred (in manual mode) Steps to reproduce: - Create invoice with a line whose deferred dates are 1/1 -> 31/05 - Go to the deferred report and select May - Generate entries - Error: "You need to add a line before posting." This is because at this point, in May, the line is totally deferred and no deferred lines are created. Therefore an empty move is created and posted. In this case, we should warn the user that no entry has to be generated. [opw-3425165](https://www.odoo.com/web#id=3425165&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#44105
**Steps to reproduce:** - Have an account in the CoA set up with a default tax. - Create a customer invoice or vendor bill using that account and fill out a start and end date causing deferred entries to be created. - Post the move. **Observed behavior:** - The taxes set on the account are applied on the deferred moves. This impacts the tax report. **Expected behavior:** - The taxes on the account are ignored for deferred entries, since we don't want to defer the tax and impact
Original PR description
**Steps to reproduce:** - Have an account in the CoA set up with a default tax. - Create a customer invoice or vendor bill using that account and fill out a start and end date causing deferred entries to be created. - Post the move. **Observed behavior:** - The taxes set on the account are applied on the deferred moves. This impacts the tax report. **Expected behavior:** - The taxes on the account are ignored for deferred entries, since we don't want to defer the tax and impact the tax report in deferred moves. This fix makes sure that when we have a deferred move, we don't calculate any new taxes. [task-3419068](https://www.odoo.com/web#id=3419068&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#43912
Ignore the write on clipboard in tour because we don't have the permissions and this leads to a traceback. task-3373590 Forward-Port-Of: odoo/enterprise#41826
Original PR description
Ignore the write on clipboard in tour because we don't have the permissions and this leads to a traceback. task-3373590 Forward-Port-Of: odoo/enterprise#41826
The extraction feature is only meant to be available on invoices, not miscellaneous entries. Ticket #3420370 Forward-Port-Of: odoo/enterprise#44212 Forward-Port-Of: odoo/enterprise#44155
Original PR description
The extraction feature is only meant to be available on invoices, not miscellaneous entries. Ticket #3420370 Forward-Port-Of: odoo/enterprise#44212 Forward-Port-Of: odoo/enterprise#44155
… date In our own production database it appears that an entry had an end date set before its start date, causing a `ZeroDivisionError` later on in a calculation. Normally dates like this shouldn't happen, but to prevent any stacktrace when there is abnormal data, we check whether the end date is before the start date of a deferral, and if so, we set both dates to the start date to not make the reports crash (we don't know what is correct). It is the user's responsibility to change the dat
Original PR description
… date In our own production database it appears that an entry had an end date set before its start date, causing a `ZeroDivisionError` later on in a calculation. Normally dates like this shouldn't happen, but to prevent any stacktrace when there is abnormal data, we check whether the end date is before the start date of a deferral, and if so, we set both dates to the start date to not make the reports crash (we don't know what is correct). It is the user's responsibility to change the dates in the database. [task-3418566](https://www.odoo.com/web#id=3418566&menu_id=4720&cids=1&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#43855
When a user attempts to get the return label using the `sendcloud_get_return_label` method, they will face the ValueError: Posting a message should receive attachments records as a list of IDs. The `_prepare_track_message_docs` method returns the doc_ids as a recordset. However, the `message_post_with_source` method expects the parameter attachment_ids to be provided as a list of IDs rather than a recordset. To resolve this issue, the parameter should be passed as a list of attachment IDs
Original PR description
When a user attempts to get the return label using the `sendcloud_get_return_label` method, they will face the ValueError: Posting a message should receive attachments records as a list of IDs. The…
When a user attempts to get the return label using the `sendcloud_get_return_label` method, they will face the ValueError: Posting a message should receive attachments records as a list of IDs.
The `_prepare_track_message_docs` method returns the doc_ids as a recordset. However, the `message_post_with_source` method expects the parameter attachment_ids to be provided as a list of IDs rather than a recordset.
To resolve this issue, the parameter should be passed as a list of attachment IDs instead.
Traceback:
```
ValueError: Posting a message should receive attachments records as a list of IDs (received ir.attachment(328,))
File "odoo/http.py", line 2123, in __call__
response = request._serve_db()
File "odoo/http.py", line 1699, 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 1726, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1927, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 234, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 716, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 34, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/stock/wizard/stock_immediate_transfer.py", line 63, in process
return pickings_to_validate.with_context(skip_immediate=True).button_validate()
File "addons/stock/models/stock_picking.py", line 1104, in button_validate
pickings_to_backorder.with_context(cancel_backorder=False)._action_done()
File "addons/sale_stock/models/stock.py", line 85, in _action_done
res = super()._action_done()
File "addons/stock/models/stock_picking.py", line 911, in _action_done
self._send_confirmation_email()
File "addons/stock_delivery/models/stock_picking.py", line 125, in _send_confirmation_email
pick.sudo().send_to_shipper()
File "addons/stock_delivery/models/stock_picking.py", line 167, in send_to_shipper
res = self.carrier_id.send_shipping(self)[0]
File "addons/stock_delivery/models/delivery_carrier.py", line 44, in send_shipping
return getattr(self, '%s_send_shipping' % self.delivery_type)(pickings)
File "home/odoo/src/enterprise/saas-16.3/delivery_sendcloud/models/delivery_carrier.py", line 98, in sendcloud_send_shipping
self.get_return_label(pick)
File "addons/stock_delivery/models/delivery_carrier.py", line 49, in get_return_label
return getattr(self, '%s_get_return_label' % self.delivery_type)(
File "home/odoo/src/enterprise/saas-16.3/delivery_sendcloud/models/delivery_carrier.py", line 141, in sendcloud_get_return_label
picking.message_post_with_source(
File "addons/mail/models/mail_thread.py", line 2414, in message_post_with_source
messages_all += record.message_post(
File "addons/rating/models/mail_thread.py", line 178, in message_post
message = super(MailThread, self).message_post(**kwargs)
File "addons/mail/models/mail_thread.py", line 2006, in message_post
raise ValueError(
```
Reference:
https://github.com/odoo/enterprise/blob/f94dc6a951929d4c0d8fe300a4fde632614aa7f8/delivery_sendcloud/models/delivery_carrier.py#L91
Sentry-4295276140
Forward-Port-Of: odoo/enterprise#43725This is a backport of https://github.com/odoo/enterprise/commit/53db496465c559fee94191f859e7c2a40976e1f6#diff-c36fd7952cc2bef40716419a668de41963d49e1aa4177d9319d503fc260da588R734 When 2 subscriptions were started for the same customer by error, it is not possible to cancel one of them, you can only close it but it creates a churn event when it was not a churn as the customer is still there. This PR allow cancelation of subscription that have not been invoiced yet. task-id
Original PR description
This is a backport of https://github.com/odoo/enterprise/commit/53db496465c559fee94191f859e7c2a40976e1f6#diff-c36fd7952cc2bef40716419a668de41963d49e1aa4177d9319d503fc260da588R734
When 2 subscriptions were started for the same customer by error,
it is not possible to cancel one of them, you can only close it but it
creates a churn event when it was not a churn as the customer is still there.
This PR allow cancelation of subscription that have not been invoiced
yet.
task-id : 3245825
Forward-Port-Of: odoo/enterprise#44207Create an Automatic transfer entry > Approve > Compute transfer Entries will have the correct dates Example: 2023-02-01 --> 2023-02-28 2023-03-01 --> 2023-03-31 2023-04-01 --> 2023-04-30 Post the first entry, delete the rest Compute transfer again Open created entries Issue: Entries following the posted one will start from the wrong day Example: 2023-02-28 --> 2023-03-27 2023-03-28 --> 2023-04-27 opw-3414406 Forward-Port-Of: odoo/enterprise#44202
Original PR description
Create an Automatic transfer entry > Approve > Compute transfer Entries will have the correct dates Example: 2023-02-01 --> 2023-02-28 2023-03-01 --> 2023-03-31 2023-04-01 --> 2023-04-30 Post the first entry, delete the rest Compute transfer again Open created entries Issue: Entries following the posted one will start from the wrong day Example: 2023-02-28 --> 2023-03-27 2023-03-28 --> 2023-04-27 opw-3414406 Forward-Port-Of: odoo/enterprise#44202
A t tag in the PartnerDetailsEdit template was not closing properly. In this commit we remove the extra closing tag to make the template works as wanted. Forward-Port-Of: odoo/enterprise#44189
Original PR description
A t tag in the PartnerDetailsEdit template was not closing properly. In this commit we remove the extra closing tag to make the template works as wanted. Forward-Port-Of: odoo/enterprise#44189
Currently when unlinking draft depreciation moves, we check whether the dates of these moves are not before a lock date. If so, we show an error to the user. However, if the move is not posted, we have no reason to show an error, since unlinking an unposted move, even before a lock date, is a valid operation. The related change in community fixes this issue. Here we test whether we can successfully change depreciation methods and thus unlink draft moves before a lock date. [opw-3305506](ht
Original PR description
Currently when unlinking draft depreciation moves, we check whether the dates of these moves are not before a lock date. If so, we show an error to the user. However, if the move is not posted, we have no reason to show an error, since unlinking an unposted move, even before a lock date, is a valid operation. The related change in community fixes this issue. Here we test whether we can successfully change depreciation methods and thus unlink draft moves before a lock date. [opw-3305506](https://www.odoo.com/web#id=3305506&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/127211 Forward-Port-Of: odoo/enterprise#43962 Forward-Port-Of: odoo/enterprise#43586