Odoo Changelog — 2024-04-10

Wednesday, April 10, 2024

32 changes · saas-17.2

Bug Fixes(5)

Resolved issues and error corrections

[FIX] mrp_workorder: tours build errors

Enterprisesaas-17.2mrp_workorder

This fix makes manufacturing shop floor tests run reliably even when demo data is not installed. It ensures the required permissions and employee records are available during testing, reducing false build failures and improving release confidence.

Original PR description

Before this commit, the test tour `test_generate_serials_in_shopfloor` failed when runned without the demo data.
The issue was the admin user was not part of the
`mrp.group_mrp_routings` group so workcenters were displayed.

Before this commit, tour `test_shop_floor` was failing for the same reason but would also fail because it uses an employee created in demo data. Some employees are now created in the test to avoid that.

Runbot build errors [59833](https://runbot.odoo.com/web/#id=59833&view_type=form&model=runbot.build.error&menu_id=405&cids=1) and [60709](https://runbot.odoo.com/web/#id=60709&view_type=form&model=runbot.build.error&menu_id=405&cids=1)

#manufacturing#shop floor#testing

[FIX] point_of_sale: inverted backspace and plus/minus buttons in numpad

PR #160931

Coresaas-17.2point_of_sale

The point of sale numpad now shows the backspace and plus/minus buttons in their expected positions. This prevents cashier confusion and helps keep checkout input faster and more accurate.

Original PR description

Before this Commit:
==========
- In the Numpad, the plus/minus, decimal point, and backspace buttons were 
displaced from their correct positions.

After this Commit:
==========
- The plus/minus, decimal point, and backspace buttons were correctly placed in 
the Numpad.

task-3856515

#point of sale#numpad#checkout

[FIX] mail: prevent most side-effect RPCs in discuss HOOT tests

PR #161114

Coresaas-17.2mailim_livechat

This fix improves the reliability of automated tests for Odoo's mail, Discuss, and live chat features by preventing delayed background calls from one test affecting another. It is an internal quality fix that helps reduce false test failures without changing user-facing behavior.

Original PR description

HOOT keeps identity of mock server but resets it in-between tests. Tests could have some ongoing code that could trigger RPC, e.g.: - When typing in composer there's a 5 second timeout for sending…

HOOT keeps identity of mock server but resets it in-between tests.

Tests could have some ongoing code that could trigger RPC, e.g.:
- When typing in composer there's a 5 second timeout for sending "not typing" notification.
- When observing a thread with new message, should notify server of new last message seen.

Such RPCs of old tests could affect current test and make it fail. HOOT currently lacks proper test isolation with RPCs, so while this is being fixed discuss code implemented a workaround: use an env-bounded version of `rpc()`, so that envs of a given test are tracked and considered elligible during running of the test in question.

The rough idea of this workaround works, but using a global `let rpc` was problematic, because it was overridden by new tests, which actually allowed old tests to invoke `rpcWithEnv` of the newer test.

A solution is to save this env-bounded rpc on test-specific assets like `this` of service/component/record. This commit solves it by turning it into a `mail.rpc` service that internally contains `rpcWithEnv`. Services are designed to be env-aware, and their uses force developers to use `this`, therefore it feels natural to use a service to solve this issue.

[FIX] mail:tests: remove rpcWithEnv HOOT workaround

PR #160331

Coresaas-17.2mailim_livechat

This fixes an internal testing issue in the mail and live chat areas by ensuring requests from finished tests are blocked. It helps keep automated test results reliable and reduces the risk of false failures during development.

Original PR description

This utility function was used to bind an env to rpc, so that HOOT tests prevent handling RPCs of prior tests, i.e. tests that finished could still trigger RPCs that were intercepted in some other…

This utility function was used to bind an env to rpc, so that HOOT tests prevent handling RPCs of prior tests, i.e. tests that finished could still trigger RPCs that were intercepted in some other tests.

At the time, we were not aware of HOOT feature of scopped param context for each test (suite). Thanks to this feature and RPC internal being easily globally patchable in test environment, we can slightly change its internal in HOOT to use scopped params in order to use same behaviour as `rpcWithEnv` but it's on whether the contextual start is allowed to make rpc or not.

With this commit, tests that use mail `start` now have a patched version of RPC which blocks RPCs at end of test.

Some technical notes on the implementation:
1. global variable `rpcPatched` is per HOOT test file, similarly to `rpc` function. Although it looks like the code only patches `rpc` once, it actually patches rpc once per test file being run. This is because global scope is "refreshed" for each file, so `rpc` function needs to be re-patched.

2. On the other hand, `defineParams()` used in start defines `MAIL_START.allowRpc` once per test. This allow to block RPC specifically to a test that has finished.

[FIX] *: template inheritance: check missing parents (2)

PR #161290

Coresaas-17.2webbase

This fix avoids showing misleading browser console errors when valid screen templates are loaded later as part of a lazy-loaded bundle. It keeps stricter checks where needed so template issues are still caught without disrupting legitimate delayed loading.

Original PR description

With https://github.com/odoo/odoo/pull/160643, it is now easier to detect template extensions for which t-inherit attributes do not match any template name. Nevertheless the implementation should be improved.
Consider the following situation. Have a template A be defined in a bundle 1 and a primary extension B defined in a bundle 2 that is lazy loaded. In that case an error is logged in the console while the template B can be effectively build browser side. The solution to that problem is to check if A is available only when the bundle 2 has been loaded and that all templates in 1 and 2 are known.

Note that we don't delay the check for the other type of extensions (t-inherit-mode="extension") since we think it is a  bad idea. Take the same situation as before but with B an extension with t-inherit-mode="extension". If OWL has already mounted a component with template A, we wouldn't know what to do with the extension. Keeping things simple, we still enforce (as before) that such an extension should be in the bundle of its parent.

Other(27)

Miscellaneous changes

[FW][FIX] sale: fix translated 'and' keyword in Russian

PR #161339

Coresaas-17.2sale

In commit 9b6e1b992923872d45e5edc1857966932f33b9fa Russian translations were bootstrapped using an automated tool. This commit fixes an instance of `and` keyword wrongly translated to `и`, that caused errors during the automatic validation of paid invoices in Russian language: ``` File "addons/sale/models/payment_transaction.py", line 116, in _reconcile_after_done confirmed_orders._send_order_confirmation_mail() ``` Forward-Port-Of: odoo/odoo#161264

Original PR description

In commit 9b6e1b992923872d45e5edc1857966932f33b9fa Russian translations were bootstrapped using an automated tool.  This commit fixes an instance of `and` keyword wrongly translated to `и`, that caused errors during the automatic validation of paid invoices in Russian language:
```
File "addons/sale/models/payment_transaction.py", line 116, in _reconcile_after_done
  confirmed_orders._send_order_confirmation_mail()
```

Forward-Port-Of: odoo/odoo#161264

Before this commit, the test tour `test_generate_serials_in_shopfloor` failed when runned without the demo data. The issue was the admin user was not part of the `mrp.group_mrp_routings` group so workcenters were displayed. Before this commit, tour `test_shop_floor` was failing for the same reason but would also fail because it uses an employee created in demo data. Some employees are now created in the test to avoid that. Runbot build errors [59833](https://runbot.odoo.com/web/#id=59833&view_type=form&model=runbot.build.error&menu_id=405&cids=1) and [60709](https://runbot.odoo.com/web/#id=60709&view_type=form&model=runbot.build.error&menu_id=405&cids=1)

Before this Commit: ========== - In the Numpad, the plus/minus, decimal point, and backspace buttons were displaced from their correct positions. After this Commit: ========== - The plus/minus, decimal point, and backspace buttons were correctly placed in the Numpad. task-3856515

HOOT keeps identity of mock server but resets it in-between tests. Tests could have some ongoing code that could trigger RPC, e.g.: - When typing in composer there's a 5 second timeout for sending "not typing" notification. - When observing a thread with new message, should notify server of new last message seen. Such RPCs of old tests could affect current test and make it fail. HOOT currently lacks proper test isolation with RPCs, so while this is being fixed discuss code implemented a workaround: use an env-bounded version of `rpc()`, so that envs of a given test are tracked and considered elligible during running of the test in question. The rough idea of this workaround works, but using a global `let rpc` was problematic, because it was overridden by new tests, which actually allowed old tests to invoke `rpcWithEnv` of the newer test. A solution is to save this env-bounded rpc on test-specific assets like `this` of service/component/record. This commit solves it by turning it into a `mail.rpc` service that internally contains `rpcWithEnv`. Services are designed to be env-aware, and their uses force developers to use `this`, therefore it feels natural to use a service to solve this issue.

This utility function was used to bind an env to rpc, so that HOOT tests prevent handling RPCs of prior tests, i.e. tests that finished could still trigger RPCs that were intercepted in some other tests. At the time, we were not aware of HOOT feature of scopped param context for each test (suite). Thanks to this feature and RPC internal being easily globally patchable in test environment, we can slightly change its internal in HOOT to use scopped params in order to use same behaviour as `rpcWithEnv` but it's on whether the contextual start is allowed to make rpc or not. With this commit, tests that use mail `start` now have a patched version of RPC which blocks RPCs at end of test. Some technical notes on the implementation: 1. global variable `rpcPatched` is per HOOT test file, similarly to `rpc` function. Although it looks like the code only patches `rpc` once, it actually patches rpc once per test file being run. This is because global scope is "refreshed" for each file, so `rpc` function needs to be re-patched. 2. On the other hand, `defineParams()` used in start defines `MAIL_START.allowRpc` once per test. This allow to block RPC specifically to a test that has finished.

With https://github.com/odoo/odoo/pull/160643, it is now easier to detect template extensions for which t-inherit attributes do not match any template name. Nevertheless the implementation should be improved. Consider the following situation. Have a template A be defined in a bundle 1 and a primary extension B defined in a bundle 2 that is lazy loaded. In that case an error is logged in the console while the template B can be effectively build browser side. The solution to that problem is to check if A is available only when the bundle 2 has been loaded and that all templates in 1 and 2 are known. Note that we don't delay the check for the other type of extensions (t-inherit-mode="extension") since we think it is a bad idea. Take the same situation as before but with B an extension with t-inherit-mode="extension". If OWL has already mounted a component with template A, we wouldn't know what to do with the extension. Keeping things simple, we still enforce (as before) that such an extension should be in the bundle of its parent.

When user tries to empty start date or end date in website using editor, a traceback will appear. Steps to reproduce the error: - Install "website_event" - Go to Website > Events > Open any Event > Register > Edit - Now try to empty start date or end date > Save Traceback: ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo/http.py", line 1847, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 134, in retrying result = func() File "odoo/http.py", line 1824, in _serve_ir_http return self._serve_ir_http(rule, args) File "odoo/http.py", line 1832, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2057, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 740, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 34, in call_kw return self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 30, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 458, in call_kw result = getattr(recs, name)(*args, **kwargs) File "addons/website/models/ir_ui_view.py", line 487, in save super(View, self).save(value, xpath=xpath) File "addons/web_editor/models/ir_ui_view.py", line 257, in save self.save_embedded_field(arch_section) File "addons/web_editor/models/ir_ui_view.py", line 56, in save_embedded_field record.write({field: value}) File "addons/website_event/models/event_event.py", line 261, in write res = super(Event, self).write(vals) File "addons/event/models/event_event.py", line 590, in write res = super(EventEvent, self).write(vals) File "addons/mail/models/mail_thread.py", line 319, in write result = super(MailThread, self).write(values) File "addons/mail/models/mail_activity_mixin.py", line 248, in write return super(MailActivityMixin, self).write(vals) File "addons/website/models/mixins.py", line 217, in write return super(WebsitePublishedMixin, self).write(values) File "addons/website/models/mixins.py", line 136, in write return super().write(vals) File "odoo/models.py", line 4536, in write real_recs._validate_fields(vals, inverse_fields) File "odoo/models.py", line 1483, in _validate_fields check(self) File "addons/event/models/event_event.py", line 570, in _check_closing_date if event.date_end < event.date_begin: ``` https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507 Here, When user tries to empty start date or end date, start date or end date will become "False", So it will lead to the above traceback. solution: A try-catch is used to catch typeerror at write of qweb fields. sentry-5038057541 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160744 Forward-Port-Of: odoo/odoo#156707

### Steps to reproduce: - Create a vendor bill for a partner with a super long name. - Go to Accounting > Reporting > Partner reports > Aged Payable - Generate the pdf #### > If the partner's name is long enough the last columns will not appear ### Cause of the issue: Pdf are generated in Odoo using wkhtmltopdf. This one takes an html file renders it in Qtweb (shrinking its content to fit a single screen) and making a screenshot to generate a pdf. However, there is a limit to the shrinking applied to the html body. Therefore, if the content is too wide part of it will not appear on the pdf (this can easily been observed using Qtweb (but not with chrome)). Between 16.4 and 17.0 there was a refactoring of the way account reports are handled in Odoo see commit 2d77434 and commit b8209e2. Because of this refactoring, there is currently no width limit for cells of the table used in the body of account reports. As such, if the content of the first column is too wide, every other column will be pushed out of the screen before the pdf is generated. This is exactly what happens here. ### Fix: We added a max width to cells and a wordbreak option on the css file used for the html in the pdf export of every account reports. This ensures that the content of any cell will not push the other cells outside of the screen before the screen shot. ### Second Issue: Even with this issue out of the way, it is still possible for the content of the aged partner balance reports to be too wide after the shrink of the hmtl if you use a currency whose symbol is too long. The reason is the same as before coupled with the fact that these reports contain too many columns displaying the currency symbol of the company. ### Second part of the fix: To fix this second issue, we use a custom css class for the export of the two problematic reports (aged payable and aged receivable) when the currency symbol is too wide. opw-3749625 --- Forward-Port-Of: odoo/enterprise#58528

To reproduce the issue: 1. Switch to the `Activity` view for the Documents module. 2. Click `+ Schedule Activity`. 3. The dialog box opens up with the list of documents. 4. Try to DRAG & DROP any document list item. 5. We get a TRACEBACK. Issue: - The `onRecordClick` and the `onDragStart` events bound on the record rows are executed when we DRAG & DROP or click the records from the list of documents. - When the method(`onDragStart`) is called from inside the `Dialog` scope, the `foldersById` in the line of code below returns a singleton object(`{false: {…}}`) with `false` being the folder_id of the `All` workspace. - However, when the same method is called from the list/kanban view (i.e. outside of the `Dialog` scope) then the `foldersById` would return an object with all of the folderIds present as keys. - In our case `foldersById[record.data.folder_id[0]].has_write_access` throws a traceback because the value of every `record.data.folder_id[0]` is a `Number` (as no document can be present inside the `All` workspace), but the `foldersById` object only contains the `false` key. Fix: - The schedule activity dialog box renders the JS of the list view of the related module. In our case, it renders the base list view from the documents and renders the JS of it. - We cannot change this in stable so we fix the issue in JS. After this commit: - The records are no longer selected. - We no longer get the traceback. Task-3727009 Forward-Port-Of: odoo/enterprise#56356

**Current behavior:** The `rental.schedule` model/view does not have serial number data for order lines which are constructed while the `Rental Transfers` config option is active. This prevents the view from accurately grouping by serial number. **Expected behavior:** The schedule view will correctly group the records in this gantt view. **Steps to reproduce:** 1. Create a new rental product, ensure it has the 'By Unique Serial Number' tracking option 2. Create an on hand instance of this product with a serial number 3. In Rental settings, enable the `Rental Transfers` option 3. Create a new rental order for this product, go to the `Schedule` view in the Rental app, select Group By Serial Number, observe that the new order is listed as having an undefined serial number **Cause of the issue:** When the Rental Transfers option is enabled, the wizard which normally tracks rental pickups/returns gets circumvented to instead get organized via stock. The SQL view for the schedule model only looks in the tables managed by this wizard to find lot_ids of products included in rental orders. So when we don't use the wizard, that information never makes it to the proper place. **Fix:** Union the current view's table result with another query which will select the data for the excluded records. opw-3754422 Forward-Port-Of: odoo/enterprise#58986

**Steps to reproduce:** (requires a real certificate and a real CAF) - Install Accounting and l10n_cl_edi_boletas - Switch to a Chilean company - Configure the localization settings with a real certificate and a real CAF - Create an invoice: * Customer: [a Chilean customer] (e.g. Blanco Martin & Asociados) * Document Type: (39) Boleta Electrónica * Product: [any] - Confirm the invoice - Click on "Send Now to SII" - "SII DTE status" will be "Ask For Status" and "Send Now to SII" will change to "Verify on SII" - As soon as it changes to "Verify on SII", click on it - Repeat clicking on "Verify on SII" as soon as it becomes clickable **Issue:** At some point, "SII DTE status" will switch from "Ask For Status" to "Rejected", even if the invoice has not been officially rejected. And as "Verify on SII" link will not be available anymore, it will not be possible to correct the SII DTE status. **Cause:** While checking the SII result after clicking on "Verify on SII", we could receive a response with "estado: SOK" and "estadistica: []". This combination doesn't allow to determine a specific status for the SII DTE and therefore falls back on the default status that is "Rejected". **Solution:** If the SII DTE status cannot be determined, we should use "Ask For Status" as a fallback status to allow verifying it again. opw-3781373 Forward-Port-Of: odoo/enterprise#60284 Forward-Port-Of: odoo/enterprise#59523

7bbec42 removes the 'pos_done' state without providing a substitute. A discrepancy arises between the states defined in pos.order and sale.report. While pos.order can have a 'done' state, this state is not defined in sale.report. Consequently, it is possible to encounter a situation where a state exists in 'sale.report' without being defined in its state field. This inconsistency leads to an error in the web client when attempting to display the state 'done' from 'pos.order', as the system cannot locate a corresponding label for it. Since we can't add a new state in stable, we'll re-use the sale.order 'sale' state which is the sale.order counterpart of pos.order 'done'. **steps to reproduce:** - sales / reporting / sales and go to pivot view - remove all filters - on the pivot view, select 'product category' - click on a cell corresponding to POS (ex: all/saleable/pos) - click on a line in the list view **before this commit:** ``` Caused by: TypeError: Cannot read properties of undefined (reading '1') at get string (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:8393:281) at SelectionField.template (eval at compile (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1500:374), <anonymous>:15:21) at Fiber._render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:940:96) at Fiber.render (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:939:6) at ComponentNode.initiateRender (https://60795873-17-0-all.runbot129.odoo.com/web/assets/af70128/web.assets_web.min.js:1007:47) ``` **after this commit:** the form view is rendered opw-3816652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160432

due to the absence of IR model data entries for certain account taxes, but with identical tax names, tax types, and scopes, attempts to create standard taxes with the same names alongside IR model data result in a constraint violation, specifically, "tax name must be unique." To address this constraint, we append "old" to the tax name for existing taxes lacking IR model data entries. see: https://github.com/odoo/odoo/blob/740fb9ac8c8e121820feeac0e1f25a304e47da9d/addons/account/models/account_tax.py#L202 ``` File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4864, in _create records._validate_fields(name for data in data_list for name in data['stored']) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1456, in _validate_fields check(self) File "/home/odoo/src/odoo/17.0/addons/account/models/account_tax.py", line 201, in _constrains_name raise ValidationError( odoo.exceptions.ValidationError: Tax names must be unique! ``` 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#161054

Steps to reproduce: - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts and create a contact from San Marino: * Name: SM customer * Country: San Marino * Street, City, ZIP: [any] * Destination Code: [any] - Create an invoice: * Customer: [the created contact from San Marino] * Product: [any] - Confirm the invoice - Generate E-invoice XML via "Send & Print" button Issue: In the XML, the destination code (i.e. CodiceDestinatario) is the default one for non-Italian customer (i.e. XXXXXXX). Also, the VAT number (i.e. IdFiscaleIVA) is the default value for countries that are not in the European Union (i.e. OO99999999999). However, since October 2021, San Marino should be handled differently for Italian electronic invoices. A specific destination code (i.e. 2R4GTO8) should be used for all customers from San Marino. Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/ Solution: For customers from San Marino: - Keep VAT number - Set "2R4GTO8" as destination code opw-3819054 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160494

**Steps to reproduce:** - Install mrp and purchase - Go to "Inventory / Configuration / Settings" - Activate "Storage Locations" - Go to "Inventory / Configuration / Warehouse Management / Operations Types" - Edit "Receipts" type by activating "Show Detailed Operations" - Go to "Manufactoring / Configuration / Settings" - Activate "Subcontracting" - Create product: (e.g. Product XYZ) * Product Type: Storable Product - Create a BoM for Product XYZ: * BoM Type: Subcontracting * Subcontractors: [any] (e.g. Azure Interior) - Create a PO: * Vendor: Azure Interior * Products: 2 x Product XYZ - Confirm the PO - Open the picking from PO via the Receipt smart button - In "Operations" tab, set done to 1 - On the picking form, change the destination location (e.g. WH/Stock/Shelf1) - Save - In "Detailed Operations" tab, a line should have appeared - Select the same destination location on that line (i.e. WH/Stock/Shelf1) - Validate the picking and create a backorder for the remaining quantity to produce - Go to "Inventory / Reporting / Locations" - Check the locations of Product XYZ (Search Product: XYZ - Group by: Location) => The "On Hand Quantity" for Product XYZ is as followed: * Virtual Locations/Production: -1.00 (correct) * WH/Stock/Shelf1: 1.00 (correct) - Open the backorder picking from PO via the Receipt smart button - Record the production of the remaining unit - Validate the picking - Go to "Inventory / Reporting / Locations" - Check the locations of Product XYZ **Issue:** No more issue in version saas-17.2 and further. This is just forward-porting the test. opw-3777379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161011 Forward-Port-Of: odoo/odoo#158442

Bug Fixes(5)

[FIX] mrp_workorder: tours build errors

[FIX] point_of_sale: inverted backspace and plus/minus buttons in numpad

[FIX] mail: prevent most side-effect RPCs in discuss HOOT tests

[FIX] mail:tests: remove rpcWithEnv HOOT workaround

[FIX] *: template inheritance: check missing parents (2)

Other(27)

[FW][FIX] sale: fix translated 'and' keyword in Russian

Bug Fixes(5)

[FIX] mrp_workorder: tours build errors

[FIX] point_of_sale: inverted backspace and plus/minus buttons in numpad

[FIX] mail: prevent most side-effect RPCs in discuss HOOT tests

[FIX] mail:tests: remove rpcWithEnv HOOT workaround

[FIX] *: template inheritance: check missing parents (2)

Other(27)

[FW][FIX] sale: fix translated 'and' keyword in Russian

[FW][FIX] hr_recruitment: update the description of interviewer's rigths

[FW][FIX] account: add index

[FW][FIX] web_editor: prevent typeerror at write of qweb fields

[FW][FIX] account_reports: add date to journal report's PDF header

[FW][FIX] account_report: shrink the aged balance reports for pdf export

[FW][FIX] delivery_fedex: added TaxID and email address to fedex request

[FW][IMP] l10n_uk: HMRC connection improvement

[FW][FIX] documents: fix schedule activity view dialog D&D

[FW][FIX] l10n_be_reports: remove group_by on BE_PL_14P report line

[FW][FIX] sale_stock_renting: select all SNs in view

[FW][FIX] account_reports: handle empty column dicts in format_column_values

[FW][FIX] l10n_cl_edi_boletas: fix fallback status of SII result analysis

[FW][FIX] website_sale_renting: fixed traceback when removing a date from…

[FW][FIX] mail: improve public page error wording

[FW][FIX] hr_holidays: ensure consistency with cap accrued time

[FW][FIX] *: remove unnecessary t-key

[FW][FIX] pos_sale: open sale.report form view

[FW][FIX] sale_crm: avoid displaying archived records in quotation

[FW][FIX] website_blog: display the total number of filtered elements

[FW][FIX] sale_pdf_quote_builder: ensure only pdf inside quote

[FW][FIX] account: fixed tax name unique constraint error

[FW][FIX] l10n_it_edi: fix support of customers from San Marino

[FW][FIX] core: add support for windows-874 encoding

[FW][FIX] website: make 'edit_menus' tour work without website_sale

[FW][FIX] mrp_subcontracting_purchase: fix subcontract location after destination update

[FW][17.0][FIX] mail: call rpc before remove attachment or message