Monday, February 27, 2023
15 changes · master
New functionality added to Odoo
A new wizard helps Luxembourg payroll users generate the required monthly salary declaration (DECSAL) for social security reporting. This reduces manual preparation work and supports compliance with Luxembourg reporting requirements.
Original PR description
Add a wizard to generate the monthly salary declaration (DECSAL) for Luxembourg. - https://ccss.public.lu/content/dam/ccss/seculine/traces/ccss-seculine-trace-DECSAL.pdf - https://ccss.public.lu/fr/seculine/paiement-salaires-maladie/decsal.html TaskID: 2801710
Enhancements to existing features
The Payroll working schedule field for full-time hours now has clearer wording and help text. This makes it easier for HR users to understand the field's purpose and enter payroll-related working time information consistently.
Original PR description
https://www.odoo.com/web#id=3131542&menu_id=4720&cids=1&action=333&active_id=1251&model=project.task&view_type=form
Resolved issues and error corrections
The Knowledge top bar now correctly opens the dialog needed to move articles from the More Options menu. This fixes a missed connection in the new top bar and adds test coverage to ensure users can move private articles under root articles reliably.
Original PR description
We are adding the dialog service to the new TopBar Component which was forgotten when creating it. We are also adding a new test for the Move To Dialog, this test ensures that we can move an article with the Move To button present inside of the more options panel. task-3208255
Code cleanup and technical improvements
This internal cleanup makes dialog handling available in the control panel setup registry, helping Odoo screens use pop-up interactions more consistently. The change should make future interface work easier while having little direct impact on day-to-day users.
Miscellaneous changes
If an invoice doesn't have an invoice line (but a payable/receivable of 0), we still want to import that. The issue is that `_compute_needed_terms` tells the invoice sync that it should remove the payment term line[^1]. In order to avoid that, we are adding an empty invoice line (value 0). [^1]: https://github.com/odoo/odoo/commit/de328c2f7c6f06e3978ffcee462e2dcb2e12f564 Forward-Port-Of: odoo/enterprise#37544
Original PR description
If an invoice doesn't have an invoice line (but a payable/receivable of 0), we still want to import that. The issue is that `_compute_needed_terms` tells the invoice sync that it should remove the payment term line[^1]. In order to avoid that, we are adding an empty invoice line (value 0). [^1]: https://github.com/odoo/odoo/commit/de328c2f7c6f06e3978ffcee462e2dcb2e12f564 Forward-Port-Of: odoo/enterprise#37544
The website links shown for the Belgian reports post wizard and website appointment modules have been updated to their current destinations. This avoids sending users through outdated redirect links and keeps module information accurate.
Original PR description
* l10n_be_reports_post_wizard, website_appointment before this commit, the website url of both module set as old url after this commit, the url will updated with the latest url to which the old url is getting redirected. reference to: https://github.com/odoo/enterprise/commit/d5fb6191e5cac544d1d7340fd181b559970d1c45
The Mexican localization now sets the correct fiscal regime based on whether a partner is Mexican or foreign. This prevents foreign customers from being assigned an invalid default and lets users review or adjust the value directly.
Original PR description
The Mexican localization has a custom field for the fiscal regime. Currently this field is only shown for Mexican partners and defaulting to `601` (General de Ley Personas Morales). Foreign partners can legally only have the regime `616` (Sin obligaciones fiscales). Since we default to `601` and the field is not shown for foreign partners, the field is always incorrect. This fix computes the field depending on whether the partner is Mexican or not and also allows the user to change it manually. The field is shown for all partners now, so foreign partners can get the correct fiscal regime. An upgrade script has also been added to automatically set all foreign customers to regime `616`. task-3143841 Related: https://github.com/odoo/odoo/pull/111230 Related: https://github.com/odoo/upgrade/pull/4277
The share panel for Knowledge articles now includes a missing visual separator between the publish button and permission settings. This makes the panel easier to scan and reduces confusion when managing article visibility and access.
Original PR description
This commit adds a missing separator between the button to publish an article and all the permission options for the said article. task-3207781
This change removes older dialog-closing behavior in Gantt, Grid, and Studio views because related records now open automatically in their own dialog. Users get a cleaner navigation experience with fewer redundant dialog changes.
Original PR description
This reverts commit ba0e95fe42696dcf44b8feddeb302f04876fcbdc. Because of odoo/odoo#112956, we no longer need this commit as the related record now automatically opens in another dialog.
This update replaces an older internal event-handling approach in German POS certification and IoT POS areas with patterns better suited to the newer interface framework. It should make point of sale behavior more reliable, especially in edge cases like loading or switching browser tabs, without changing business workflows.
Original PR description
*:l10n_de_pos_cert,pos_iot Previously, the point of sale and related modules made heavy usage of `useListener`. This is because the pos was converted early to owl, and in owl 1, using events to…
*:l10n_de_pos_cert,pos_iot Previously, the point of sale and related modules made heavy usage of `useListener`. This is because the pos was converted early to owl, and in owl 1, using events to communicate between components was encouraged. In owl 2, the decision was made to stop encouraging this way of communicating between components, because it encourages communication accross many layers of components, and is also hard to debug. In addition, in owl 2, because components can have 0 or more than node, including non HTMLElement nodes like text or comment nodes, owl removed the implementation of useListener, as useListener relies on the presence and unicity of a root HTMLElement per component on which we can attach event listeners. Another problem is that events rely on the fact that the components are in the DOM so that the event can propagate, which can lead to issues in some cases and in particular, in the PoS, if you load the point of sale and switch tabs, some things will be broken because we are triggering events, but there have not been any animation frame fired in the tab because it's not focussed, and so owl has not mounted the component yet. When migrating odoo to owl 2, we introduced a shim for this.el and useListener in LegacyComponent, with the hope to remove it as soon as possible. This commit removes all usage of useListener from the pos modules for those reasons. In some cases, useListener was incorrectly used intstead of t-on, and the event was triggered and handled by the same component, in other cases, a simple callback could be passed to a child component. In a few cases, a method had to be implemented on the store as we wanted this method to be available everywhere. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
An error is thrown when trying to edit fields in the address of a partner when an `address_view_id` is set on the company country Steps to reproduce: 1. Install Studio and Peru - Accounting (l10n_pe) 2. Open any contact in the Contacts app 3. Toggle Studio 4. Click on any field in the address 5. An error is thrown Solution: Render the original view (without the `address_view_id` modification) by using the `no_adress_format` context key Problem: The view is edited with the `addres
Original PR description
An error is thrown when trying to edit fields in the address of a partner when an `address_view_id` is set on the company country Steps to reproduce: 1. Install Studio and Peru - Accounting (l10n_pe) 2. Open any contact in the Contacts app 3. Toggle Studio 4. Click on any field in the address 5. An error is thrown Solution: Render the original view (without the `address_view_id` modification) by using the `no_adress_format` context key Problem: The view is edited with the `address_view_id` set on the company country. Thus we cannot find the fields of pe_partner_address_form in the original view when we try to edit them. opw-3136618 Forward-Port-Of: odoo/enterprise#36928
Before this commit, as published shared article are technically accessible for everyone, the articles were displayed in the shared section for internal users. After this commit, published shared articles are filtered out when the current user is not member of the article. Also, since user_can_read has been reworked to include website_published when website is installed, user_has_access need to be used for the shared articles to be hidden for every share users if they are not member. Tas
Original PR description
Before this commit, as published shared article are technically accessible for everyone, the articles were displayed in the shared section for internal users. After this commit, published shared articles are filtered out when the current user is not member of the article. Also, since user_can_read has been reworked to include website_published when website is installed, user_has_access need to be used for the shared articles to be hidden for every share users if they are not member. Task-3202849 Forward-Port-Of: odoo/enterprise#37457
In this commit, account_reports_export_wizard violates the foreign key in the account reports. Before this commit: When trying to delete the records of 'account_reports.export.wizard' by cron named 'Base: Auto-vacuum internal data', It will raise an error because the model 'account_reports.export.wizard.format' is linked with it using the field 'export_wizard_id'. After this commit: When running the cron it is allowed to delete the records because the ondelete='cascade' attribute is a
Original PR description
In this commit, account_reports_export_wizard violates the foreign key in the account reports. Before this commit: When trying to delete the records of 'account_reports.export.wizard' by cron named 'Base: Auto-vacuum internal data', It will raise an error because the model 'account_reports.export.wizard.format' is linked with it using the field 'export_wizard_id'. After this commit: When running the cron it is allowed to delete the records because the ondelete='cascade' attribute is added in the field 'export_wizard_id'. so when deleting the records of 'account_reports.export.wizard' will also delete the records of 'account_reports.export.wizard.format'. see - https://tinyurl.com/2nv9a3e8 sentry - 3758596811 Forward-Port-Of: odoo/enterprise#37534 Forward-Port-Of: odoo/enterprise#37279
This commit improves the copy of articles by taking into account the full_width field of an article. Before when creating a private copy of an article, we would set the full_width to False no matter what. Now we are also copying this value. task-3162666 Forward-Port-Of: odoo/enterprise#36517
Original PR description
This commit improves the copy of articles by taking into account the full_width field of an article. Before when creating a private copy of an article, we would set the full_width to False no matter what. Now we are also copying this value. task-3162666 Forward-Port-Of: odoo/enterprise#36517
When printing a PDF of any report, the header was incomplete. Indeed the name of the report itself was missing since version 16.0 of Odoo. This PR solves that by adding the report title when the HTML of the pdf is created. Other bug seen was that since the dark mode, all the separators between lines of the report were missing when printing the report in PDF because wkhtmltopdf doesn't allow the use of VAR in the css file. Task-id: 3135679 Forward-Port-Of: odoo/enterprise#36163
Original PR description
When printing a PDF of any report, the header was incomplete. Indeed the name of the report itself was missing since version 16.0 of Odoo. This PR solves that by adding the report title when the HTML of the pdf is created. Other bug seen was that since the dark mode, all the separators between lines of the report were missing when printing the report in PDF because wkhtmltopdf doesn't allow the use of VAR in the css file. Task-id: 3135679 Forward-Port-Of: odoo/enterprise#36163