Odoo Changelog — 2024-02-14

Wednesday, February 14, 2024

13 changes · saas-17.1

Improvements(1)

Enhancements to existing features

[IMP] adapt code to the removal of (JS) _lt

Coresaas-17.1webtoolstest_lint

This update removes remaining references to an obsolete JavaScript translation helper from documentation, translation extraction, and lint tests. It keeps translation tooling aligned with the current codebase and reduces maintenance noise without changing user-facing behavior.

Original PR description

In this PR:

## [IMP] web: remove obsolete comment

"_lt" was removed in https://github.com/odoo/odoo/pull/130179. This commit updates the doc accordingly.

## [IMP] tools: don't try to extract _lt in JS code

"_lt" was removed from the JS code in https://github.com/odoo/odoo/pull/130179, but the source terms
extractor (used to generate .pot files) still looks for its occurrences.

This commit removes "_lt" from the list of the keywords whose content is
extracted in the context of JS files.

## [IMP] test_lint: adapt tests to the removal of (JS) _lt

"_lt" was removed in https://github.com/odoo/odoo/pull/130179, but is still mentioned in linting
tests.

This commit adapts the tests to remove all mentiones of _lt.

(Note: it deliberately ignores the part about lodash, even though this
is also obsolete, as it is outside the scope of this commit).

#translations#maintenance#javascript

Bug Fixes(1)

Resolved issues and error corrections

[FIX] l10n_in: resolve traceback on saving empty sequence number

PR #153829

Coresaas-17.1l10n_in

Saving an Indian invoice with an empty sequence number no longer causes an error. The system now restores the previous sequence number, helping users avoid interruptions while managing invoices.

Original PR description

Before this PR, users receive a traceback whenever they try to save the empty sequence number in the invoice.

After this PR, traceback will not come and the old sequence number will be reassigned.

#india#invoicing#sequence number

Other(11)

Miscellaneous changes

[FW][FIX] web_editor: consider the drag and drop with the mobile order

PR #153957

Coresaas-17.1web_editor

Original PR description

Since commit [1], it is now possible to order the columns in mobile view independently from the desktop view. When moving a column with an arrow, if we are in mobile view, mobile order classes are…

While it works well when using the arrows, this behavior is not the same when moving the columns with the drag and drop. This means that drag and dropping a column
- in the same snippet does not reset the mobile order classes;
- in another snippet does not reset the classes in it and does not fill the gap left in the previous snippet if it was ordered.

This means that in the same snippet, there can be both columns with and without the mobile order classes. This causes some issues:
1) Removing such snippets or their ordered columns causes a traceback. Indeed, the `onRemove` code considers that all columns have the mobile order classes if we remove one, which is why it fails when it is not the case.
2) The arrows on the mobile overlay are not always correct and can also be missing, because they depend on the order classes.
3) In mobile view, changing the order of the columns adds inconsistent mobile classes on them, because of the columns that already have one.

This commit improves the drag and drop by also taking mobile ordered elements into account, as it is the root cause of the mentioned issues:
- When a column is moved, the order classes of all the other columns in the snippet where it was dropped are removed (so it behaves the same way as with the arrows).
- When moving an ordered column in another snippet, the gap it left in its previous snippet is now filled.

This commit also fixes the issues for already dropped blocks in existing DBs, by
- adding a check when removing to avoid the first issue;
- removing the mobile classes at the start if they are inconsistent.

[1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba

opw-3697962

Forward-Port-Of: odoo/odoo#152487

In this PR: ## [IMP] web: remove obsolete comment "_lt" was removed in https://github.com/odoo/odoo/pull/130179. This commit updates the doc accordingly. ## [IMP] tools: don't try to extract _lt in JS code "_lt" was removed from the JS code in https://github.com/odoo/odoo/pull/130179, but the source terms extractor (used to generate .pot files) still looks for its occurrences. This commit removes "_lt" from the list of the keywords whose content is extracted in the context of JS files. ## [IMP] test_lint: adapt tests to the removal of (JS) _lt "_lt" was removed in https://github.com/odoo/odoo/pull/130179, but is still mentioned in linting tests. This commit adapts the tests to remove all mentiones of _lt. (Note: it deliberately ignores the part about lodash, even though this is also obsolete, as it is outside the scope of this commit).

Since commit [1], it is now possible to order the columns in mobile view independently from the desktop view. When moving a column with an arrow, if we are in mobile view, mobile order classes are added on the columns, which only changes the order on mobile without affecting desktop. But if we move on desktop view, then these classes are removed. While it works well when using the arrows, this behavior is not the same when moving the columns with the drag and drop. This means that drag and dropping a column - in the same snippet does not reset the mobile order classes; - in another snippet does not reset the classes in it and does not fill the gap left in the previous snippet if it was ordered. This means that in the same snippet, there can be both columns with and without the mobile order classes. This causes some issues: 1) Removing such snippets or their ordered columns causes a traceback. Indeed, the `onRemove` code considers that all columns have the mobile order classes if we remove one, which is why it fails when it is not the case. 2) The arrows on the mobile overlay are not always correct and can also be missing, because they depend on the order classes. 3) In mobile view, changing the order of the columns adds inconsistent mobile classes on them, because of the columns that already have one. This commit improves the drag and drop by also taking mobile ordered elements into account, as it is the root cause of the mentioned issues: - When a column is moved, the order classes of all the other columns in the snippet where it was dropped are removed (so it behaves the same way as with the arrows). - When moving an ordered column in another snippet, the gap it left in its previous snippet is now filled. This commit also fixes the issues for already dropped blocks in existing DBs, by - adding a check when removing to avoid the first issue; - removing the mobile classes at the start if they are inconsistent. [1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba opw-3697962 Forward-Port-Of: odoo/odoo#152487

[FIX] website: correctly update carousel thumbnails on image insertion Steps to reproduce the bug: - Add an "Image Gallery" on the website. - Add a new image on the snippet. -> Problem: the thumbnail of the first image of the carousel has been replaced by the new added image. To solve the problem, the triggering of the `image_changed` event has been removed on extra image added. It was introduced by [1] to trigger the re-rendering of the thumbnail when adding a new image on the carousel but was actually useless. Indeed, the mechanism was the same as now; when a new image was added on the carousel, the `website.gallery.slideshow` that already handles the thumbnails was re-rendered. An important think to note is that the system was also never intercepting this `image_changed` event as it was triggered on an element that was not in the DOM (as it was removed at the `_replaceContent()` call in the `slideshow()` method). However, since [2], the images rendered by the `website.gallery.slideshow` are replaced by the images (or the wrapped anchored images) returned by `_getImgHolderEls`. Therefore, `$newImageToSelect` is part of the DOM and the `image_changed` event is intercepted by the gallery option. As the active carousel item is always the first one of the carousel after a `website.gallery.slideshow` re-rendering, the system changed the thumbnail of the first item with the new added image. [1]: https://github.com/odoo/odoo/commit/85990768592cbdefbb178b5ffa38c1e29b9eeb87 [2]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481 task-3736301 Forward-Port-Of: odoo/odoo#153717 Forward-Port-Of: odoo/odoo#153409

Consider the case that we attach invoices to the followup. We only attach invoices that have previously been printed / generated. (Except if someone attaches a custom file which could be whatever.) Currently: 1. During the generation of the followup report we basically just regenerate the invoices by calling the invoice template. 2. The PDFs that are added in the manual followup wizzard are not added to the generated PDF. Problem: (Reproduce at the bottom) Point (1.) is a problem in case the template does not reflect the actual printed invoice. This can happen since the PDF output may also be altered during render time (by overwriting '_render_qweb_pdf_prepare_streams'). This is i.e. a problem for l10n_ch. There, a QR code is appended to the invoice PDF only during render time. This QR code does not appear in the followup report since it is not part of the template. Point (2.) may lead to missing invoices in the generated PDF. After this commit: The actual PDF (that was generated previously) is attached to the invoice. Thus i.e. the QR code appears in l10n_ch. In the process Point (2.) was also solved. In case the manually added files are not PDFs they are silently dropped. Reproduce 1. Install l10n_ch 2. Select 'CH Company' 3. Create an Invoice * Due Date: in the past * Customer: Easy Clean Lausanne (A Swiss company) 5. Print the PDF. Check that the QR code is appended to the invoice 6. Go to follow-up reports for Easy Clean Lausanne and follow up with 'Print' option. Ensure 'Attach Invoices' is checked. Add some PDF file manually. Click "Print" 7. The invoice is appended to the follow-up report but w/o QR code. The PDF that was manually added does not appear in the report at all. task-3472962 Forward-Port-Of: odoo/enterprise#56451 Forward-Port-Of: odoo/enterprise#53836

Improvements(1)

[IMP] adapt code to the removal of (JS) _lt

Bug Fixes(1)

[FIX] l10n_in: resolve traceback on saving empty sequence number

Other(11)

[FW][FIX] web_editor: consider the drag and drop with the mobile order

Improvements(1)

[IMP] adapt code to the removal of (JS) _lt

Bug Fixes(1)

[FIX] l10n_in: resolve traceback on saving empty sequence number

Other(11)

[FW][FIX] web_editor: consider the drag and drop with the mobile order

[FW][FIX] event: always set email author as partner

[FW][FIX] website: correctly update carousel thumbnails on image insertion

[FW][FIX] web_editor: dynamicplaceholder at the end positions below the page

[FW][FIX] web, web_editor, website: fix menu auto hide in edit mode

[FW][IMP] l10n_in_edi_ewaybill: don't send ewaybill if all lines are service

[FW][FIX] web_grid: use previously created context when creating new record

[FW][FIX] l10n_mx_edi_stock_extended_30: fix dependencies

[FW][FIX] account_followup: attach the actual invoice PDFs

[FW][FIX] documents: resolve issue when drag & drop document from inspector

[FW][FIX] documents_spreadsheet: open the spreadsheet by pressing the enter key