Tuesday, July 18, 2023
27 changes · master
New functionality added to Odoo
Knowledge users can now use a new print option to print articles or save them as PDFs through their browser. This gives teams an easier way to share or archive articles, while keeping better article formatting for printed output.
Original PR description
This commit simply adds a shortcut to the browser "print" feature that will allow end users to export their article to PDF (or print it). We are not using "wkhtmltopdf" as it does not support emojis. (And the investigation on that issue showed that adding the support for that would be very complicated). Note that exporting with the browser is not as good as we do not control everything, for example the browser will add the URL of the page to the printed document. It is however possible to customize the export to some extent, if the end user knows the various options. Task-2892055
Restaurants can now let customers reserve tables through the website, with bookings appearing directly in the point of sale. New and updated reservations are shared instantly so staff can see table bookings in real time and manage seating more efficiently.
Original PR description
*:appointment,pos_preparation_display,pos_restaurant_appointment,website_appointment This module adds the possibility to book a table online from the website. The booking is then visible in the POS. When a new table is created in the PoS, a linked resource is created in the appointment application, which allows the user to add these resources to appointment_types, authorising visitors to reserve tables online. In pos_config, you need to choose an appointment_type via which the appointments will be retrieved A websocket has been integrated to retrieve new bookings instantly from the PoS, which are displayed directly on the tables. When an event (appointment) is created, only that new event is sent thru the bus as notification. Some improvements have also been made to the pos_preparation_display module on the websocket part. taskId: 3067577 community: https://github.com/odoo/odoo/pull/124850
Enhancements to existing features
The POS due settlement flow now runs after order validation, so it also applies when customers pay online. This helps ensure settlement actions are consistently completed for all relevant POS orders, regardless of payment method.
Original PR description
Execute the code after afterOrderValidation instead of _finalizeValidation method to have the code be executed even for POS orders that have online payments. task-id: 3276404 related: https://github.com/odoo/odoo/pull/123237
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
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
Odoo can now regularly send available stock quantities to Amazon for seller-fulfilled products when synchronization is enabled. This helps reduce overselling, order cancellations, and delivery delays that can harm seller reputation.
Original PR description
Currently, the stock on Amazon for FBM is not updated when it changes on odoo side. This can lead to overselling, so the user either will have to cancel a lot of orders or he risks having big delay to deliver. It can then have a bad impact on the reputation. From now on, Odoo will regularly send the current available quantity of each offers for account that activated the synchronization feature. This only works for FBM products, as Amazon will not update the quantity for FBA even when we try. task-2864098 See also: - https://github.com/odoo/documentation/pull/4773 - https://github.com/odoo/upgrade/pull/4810
Users can once again preview files directly from the Documents Kanban view, making it easier to review documents without switching views. The preview experience is also smoother, with chatter moved out of the preview area and thumbnail clicks allowing quick switching between previews.
Original PR description
This commit reverts some of the changes from the PR #29807 - The previous changes aimed to show the file preview only in the List view. However, this commit restores the file preview for the Kanban view. - The chatter is removed from the file preview and added with the buttons as in Kanban view. - Now we can switch preview by clicking on the thumbnail without closing the other preview. Task-3358187
Helpdesk ticket forms now show how long each ticket has spent in every stage. This gives teams clearer visibility into ticket progress and helps identify bottlenecks in the support workflow.
Original PR description
Add the `MailTrackingDurationMixin` to helpdesk to compute time spent in each stage and change statusbar widget from `statusbar` to `statusbar_duration` to see time spent in the form view See https://github.com/odoo/odoo/pull/108554 Task-3032773
Updates helpdesk forum and slide-related pages so they stay aligned with the redesigned forum experience. This helps keep customer support and learning content visually consistent and functional after the broader forum redesign.
Original PR description
Necessary changes after redesign. See odoo/odoo#123709
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
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
The Belgian Partner VAT Listing now calculates which partners must appear before applying any user-defined grouping. This prevents incorrect reported amounts when businesses customize the report, and it should also make the report run more efficiently.
Original PR description
The Partner VAT Listing uses a custom engine, meaning that it is possible for the user to customize its line in order to do the grouping differently, and for example have a group by account on top of…
The Partner VAT Listing uses a custom engine, meaning that it is possible for the user to customize its line in order to do the grouping differently, and for example have a group by account on top of the default group by partner. However, due to legal requirements, this report already "injected" a groupby in the SQL ran for its computation, so that we did not report partners not reaching the "turnover" untaxed value of 250 EUR (or another of the special criteria about credit notes). This completely broke custom grouping, as the turnover got computed on the new groups (so, not only "group by partner_id", but "group by account_id,partner_id", for example). The numbers reported in this case were hence completely wrong. With this commit, we rewrite the queries ran by the report so that the partners meeting the appearance criteria (like the turnover) are computed beforehand and the custom groupby can work as usual. Thanks to that, this refactoring also improves the overall performance of the report in the meantime.
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