Monday, July 10, 2023
12 changes · master
Enhancements to existing features
This change updates sales invoicing configuration and advance invoice flows. It appears intended to improve how sales teams manage invoice-related settings and customer billing preparation.
Original PR description
Task: 3254314
Invoice labels used by accounting taxes are now marked as translatable and translations were added for multiple country localizations. This helps businesses keep invoice wording consistent and appropriate for each customer’s language and country setup.
Original PR description
Knowledge articles can now be edited collaboratively by portal users, making it easier for external participants to contribute. The editor also better reflects changes made by collaborators and closes collaboration connections more reliably.
Original PR description
Enable the collaborative mode in Knowledge and allow portal users to use it. In Knowledge, there is a custom `KnowledgeHtmlField` which adds a menu placeholder if the `HtmlField` value is empty. It evaluates if it is empty after each `historyStep`. This commit introduces a new `historyExternalSteps` event so that the `KnowledgeHtmlField` is able to properly hide/show that menu even after a collaborator made the value empty. Encapsulate the `mail` ICE servers availability check in an overridable function, since the hack does not work in a portal context, but Knowledge portal users should be allowed to use the collaborative feature. Knowledge will override the session check by always returning true, since mail is a dependency of Knowledge and is therefore always installed with it. Allow access to the edition channel for portal users. task-3378266
Select menu search fields now use Odoo's standard focus behavior when the menu opens. This keeps the user experience the same while simplifying maintenance and reducing the chance of future inconsistencies.
Original PR description
This commit makes use of the useAutoFocus hook to focus the input when the SelectMenu opens. This usage of the hook can replace the manual focus that was applied when the dropdown opened. The feature can hardly be tested with newer tests, since the behavior is identical, and the focus on the input was already tested.
Invoices now include a delivery date that can be shown consistently and populated from sales delivery commitments where available. Hungary receives improved default tax rounding, Saudi and Hungary invoice layouts are aligned with local needs, and a demo data installation issue for some localizations is fixed.
Original PR description
In this pr, we have improved the l10n_hu localization by adding a Tax rounding (global) by default. Also, a lot of localization will need a delivery date on invoices. We added a field in account that can be overridden if needed. In this pr, we did an override on l10n_sa and l10n_hu. When creating a sale order and that the commitment date is fill, we take this value for the delivery date. The delivery date field will always be displayed in the other info tab, and if there is a delivery data, the field is also display in the header of the form view. task-id: 3191530 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Company settings now let teams manage email colors separately from document and report colors, so changing email headers or buttons no longer unexpectedly affects business documents. When document colors are updated, email colors are aligned automatically to keep setup simple, while still allowing emails to be fine-tuned independently.
Original PR description
PURPOSE Settings allow to change colors used in emails (primary and secondary colors). Those are used for headers and buttons. They are currently shared with colors used for documents and reporting: changing email colors change documents colors, which is not expected nor clearly indicated. SPECIFICATIONS Split configuration: colors used in documents may differ from colors used in emails. Duplicate color fields (primary and secondary). To ease setup when updating documents colors, update mail colors accordingly. Inverse is not true as we consider documents being the main configuration, and emails a more fine-grain configuration. Task-3346388
This update adds missing internal type information in the mail module. It helps developers maintain the messaging code more reliably without changing what users see.
Customers can now change quantities for optional products in the portal even when the same product is already part of the order. This makes online quote and order adjustments smoother and reduces friction during customer self-service.
Original PR description
Before: if the product was both in the order and in optional products the user could not edit the quantity. Now the user can edit the quantity for all optional products. task-3290530
Users can now open a custom appointment invite directly from the calendar dropdown, making it easier to share appointment options without preset choices. The invite form keeps relevant context from related opportunity or applicant records, so teams can connect scheduling to the right business record more easily.
Original PR description
In order to easily share any appointment from the calendar view, add a simple CUSTOM LINK option that opens an appointment invite form view with no preset options. Therefore, the user could choose between appointment types / users / resources linked to an opportunity, for instance. The context is propagated, in order to use default opportunity_id and default applicant_id when coming from "meeting" stat buttons on their respective form views. Task-3383226
The Knowledge app now restores standard validation checks for its form views after previously incompatible directives were removed. This helps catch invalid view definitions earlier, reducing the risk of future display or stability issues for users.
Original PR description
Now that the forbidden `t-` owl directives have been removed from the arch of the form view of Knowledge, we will re-enable the default arch view validator. That way, we will be able to detect usage of forbidden directives, attributes, etc and prevent potential issues. Follow up of task: 3094058 task-3385229
Knowledge articles now handle template insertion more safely during live collaboration, reducing the risk of lost edits or document conflicts. Portal users can also use collaborative editing more reliably when working in Knowledge.
Original PR description
Ensure that the `WysiwygHelper` is correctly displayed even after applying a bunch of steps coming from the collaboration (`historyExternalSteps`). Ensure that the backend does not write on the body…
Ensure that the `WysiwygHelper` is correctly displayed even after applying a bunch of steps coming from the collaboration (`historyExternalSteps`). Ensure that the backend does not write on the body of an existing article, since this will either be non-effective if a collaborator is editing the article currently and succeeds to save after the write, or it risks breaking the collaboration in case the user which initiated the write was in the collaboration, and succeeds in reloading the view with the new body value after the write, since in that case the editor does not have the time to write collaborative steps id in the first node resulting in a `stale` situation where the editor thinks the new body is a stale version of the document that is still being edited with its old value by the other collaborators. The solution is to allow `apply_template_on_article` to do all non-collaborative write, and return the body value without writing it. The client which applied the template will then create a collaborative step with that new value to share it with collaborators, using `wysiwyg.setValue`. ICE servers are a mail feature, and the `editor` uses a hack to check if it is installed by checking `getSession().notification_type`. The issue is that this value is not present for portal users that should be able to use the collaborative feature for Knowledge. Since `mail` is a dependency of Knowledge, we can override the hack to let the editor know that the ICE servers are available as long as Knowledge is installed. task-3378266
The signing flow updates the wording shown for recipients when sending signature requests. This makes the message clearer for users preparing documents and helps reduce confusion for recipients.
Original PR description
task-id: 3284359
Before this PR, the field "invoice_label" was not translatable and since we wanted to have all localisation in english and then translated back in the desired language, the "invoice_label" field was not consistent for most of them. In previous pr (https://github.com/odoo/odoo/pull/124520) i've translated back the invoice label in the country language to keep the consistency that we lost but in master, i've made the field translatable and added translation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr