Tuesday, February 4, 2025
15 changes
10 changes
Enhancements to existing features
Tickets created from chatbot conversations now show the chat history in a clearer format and include a direct shortcut back to the original discussion. This helps support teams understand customer requests faster and continue the conversation with less manual searching.
Original PR description
*: website_helpdesk_livechat. This PR aims to improve live chat consultations for tickets created by a chatbot. Specifically, it enhances the formatting of the ticket description to make the conversation easier to read, introduces a smart button to redirect users to the discussion channel where the ticket originated and set the ticket name according to the user request. task-4432728 community: https://github.com/odoo/odoo/pull/191813
Recruiters can now post job listings to job boards more smoothly, including jobs that have not yet been published. The update reduces interruptions during posting by requiring key information upfront and makes related recruitment modules easier to understand, while also fixing a missing job post icon in Firefox.
Contract template management is moved into the core employee contract area so templates are available where users expect them. The update also improves related hiring and payroll salary screens, making contract setup more consistent and easier to navigate.
Original PR description
Contract template should already exist in hr_contract and some other UX improvements. Task: 4320233
The disallowed expenses reporting now supports cases where businesses can deduct more than 100% of an expense, such as Belgium's enhanced deduction for eInvoicing costs. Reports and fleet-related expense settings now show both the disallowed and actually deductible amounts, helping finance teams apply the correct tax treatment.
Original PR description
Our Disallowed Expense module does not allow for deductibility of >100%. We have cases where it's needed, for example in Belgium you are allowed to deduct 120% of your amounts expensed for eInvoicing. For this we need to inverse the percentage to the part that is allowed in the expenses, so that we can take it into account in the report, and add another column showing the amounts that can actually be deduced. task-id 4421297 Upgrade PR: https://github.com/odoo/upgrade/pull/6971, https://github.com/odoo/upgrade/pull/7807 Documentation PR: https://github.com/odoo/documentation/pull/11634
Appraisal goals can now be linked to more than one employee, making shared objectives easier to track in performance reviews. The appraisal screens and demo data were updated to display these multi-employee goals clearly, including small visual fixes to status ribbons.
Original PR description
- change the field to Many2Many - edit the view and demo data to match the new type Task: 4391198
The appraisal survey experience now includes better demo data and an easier way to request 360 Feedback directly from the survey list. This helps users find and launch feedback requests more reliably, while ensuring employee matching works even if email details have changed.
Original PR description
- Add demo data to make 360 Feedback entry to be shown - fix email field in the demo data to match the context matching - Add button to ask feedback in the surveys list view Task: 4373438
The Planning employee avatar card layout has been improved to better present details such as skills and roles. Clearer spacing and content separation make the card easier to read and less visually crowded for users reviewing staff information.
Original PR description
This PR reviews the layout of the avatar card in order to match all the use cases. - requires https://github.com/odoo/odoo/pull/188068 The employee avatar card recently received an update aiming to display skills and roles within its content. While this added extra information and value to the component, its layout wasn't really meant to contain that much information, which led to a crowded visual result. With this PR, we review the hierarchy of the card by adding clear separations to its content and reviewing the use of white space. | Master | This PR | |--------|--------| |  | <img width="402" alt="image" src="https://github.com/user-attachments/assets/6f4f7d6b-6e72-4cf6-b88f-e8e2e977e8b9"> | task-3810438
Payroll users can now see each employee's reference number directly in employee, contract, payslip, attendance, leave, and salary report lists. The label has also been standardized as "Employee Reference," making it easier to identify employees consistently across payroll screens.
Original PR description
- add the `registration_number` field to the employee, contract, and payslip list views - change the field label to `Employee Reference` to be consistant Task: 4491186
Payroll work entry type records are now protected from being overwritten during system migrations or upgrades, helping keep configured payroll behavior stable. The payroll setup data was also reorganized into smaller files to make future maintenance safer and clearer.
Original PR description
Work entry type data should not be updatable as it shoud not be erased at each migration/upgrade. This commits fixes this by changing all work entry type data to noupdate true. The hr_payroll data file has also been split into multiple files to follow the coding guidelines. task-4479965
Resolved issues and error corrections
The helpdesk stock ticket list no longer loads an unused product suitability field. This removes unnecessary background processing and should make ticket lists faster, especially when many tickets are shown.
Original PR description
Following odoo/enterprise@07954ea8b5bccd185dc4639c5e75d5dbab8b5499, `product_id` was removed from the list view. Therefor there is no more reason to have `suitable_product_ids` in the list view also, as the only reason it was present was because `product_id` had a domain that was depending on the `suitable_product_ids`. This should also lead to a significant performance improvement of the list view, as `suitable_product_ids` doesn't scale well with a larger collection of tickets than `1` which was the expected usage in the form view.
5 changes
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