Tuesday, February 4, 2025
5 changes · 18.0
Enhancements to existing features
The HTML editor now treats eligible div blocks more like paragraphs, making line breaks, formatting, signatures, and report fields behave more predictably. This gives users cleaner editing results by default and reduces cases where formatting unintentionally affects multiple lines or protected content.
Original PR description
This PR's purpose is to allow certain `div` elements to be handled by the editor with the features commonly used inside `p` elements. It is also comprised of a series of fixes and improvements…
This PR's purpose is to allow certain `div` elements to be handled by the editor with the features commonly used inside `p` elements. It is also comprised of a series of fixes and improvements related to that change, see each commit for more details. Notable changes: - Fix some behaviors of the DomPlugin `insert` function - Update how Signature is handled in mail html fields - Update how qweb fields are handled in the Report editor - Introduce usage of `div` elements (baseContainer) Eligible `div` elements will automatically inherit these features as soon as they met the requirements during the `normalization` phase. For the user, this means that there are now 2 options for the "base container", the `div` which does not have a margin-bottom and the `p` which does have one. `div` will be used as the default in most cases, and `p` will be used as the default for `knowledge` (and probably `website` when it starts using the html_editor). The features around paragraphs are some of the most well defined in the editor, and with this commit, there are now more ways to fall back on the "right track" (meaning that user interactions will more likely result in something they want, rather than not). Most notably, prior to this commit, adding new lines with `enter` starting from a `div` with one line, then applying an editor command, would result in the command applying on every line. Now, since the `div` behaves like a paragraph, adding new lines will create a new editor context for each line (another `div`), meaning that any command will only apply to that context. Technically, this commit introduces a generalization of the concept for `baseContainer`, meaning that it will be easier to introduce new forms that will inherit the related editor features. There are still some limitations: Some `div` elements will keep their `unsplittable` properties if they contain HTML elements that are not compatible with a `p` (non-phrasing content), because any `baseContainer` should be convertible between all equivalent forms. To avoid such limitations, one solution could be to only work with `div` elements (and never use paragraph related elements like `p`, `h1`, etc.), which would be less explicit, but would allow more flexibility. task-4260398 and task-4294440
The editor now handles certain structured content blocks more like regular paragraphs, making editing behavior more consistent. This improves authoring in Knowledge, manufacturing work orders, and Studio report editing while reducing layout issues during editor operations.
Original PR description
This is the counterpart to the community PR allowing certain `div` elements (baseContainer) to be handled by the editor with the features commonly used inside `p` elements. See community PR for a more detailed explanation. task-4260398 and task-4294440
Resolved issues and error corrections
This fix stops website visitors from being repeatedly redirected when a chatbot ends with a link. Once the chatbot has completed its steps, live chat is marked inactive so the bot does not restart unnecessarily on page reload.
Original PR description
Before this PR, if a chatbot's last step is redirecting to a URL, a visitor could be trapped in an infinite loop of redirection. This is because the chatbot always replays the last step of the script when the page loads. This PR updated the livechat_active status when all the steps were done and ensured that the chatbot service doesn't start if livechat_active is false. Task-4518285
The HTML editor now converts invalid self-closing tags into standard open-and-close tags when loading content. This prevents browser misinterpretation that could break email templates such as sales order confirmations.
Original PR description
**Problem**: When content comes from the config containing self-closing tags, the browser misinterprets them as they are not valid HTML, leading to a broken template when displayed. **Solution**: Convert self-closing tags to explicitly opened and closed tags when content is added to the editor. **Steps to Reproduce**: 1. Open Email Templates > "Sales: Order Confirmation". 2. Inspect and observe that self-closing tags are not rendered correctly. opw-4531812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kenya payroll now calculates the Social Health Insurance Fund contribution from gross pay instead of basic pay, aligning payslips with the required basis. The update also removes the SHIF relief rule because that relief does not apply, improving payroll accuracy and compliance.
Original PR description
Problem ---------- The SHIF is based on the gross and not the basic. There is no SHIF Relief Objective ---------- Correct the SHIF implementation Solution ---------- Get GROSS in SHIF computation rather than BASIC Remove SHIF Relief Rule task-4414345