Monday, September 7, 2026
59 changes · master
Enhancements to existing features
Employees and payroll users now see a warning on time off records that points them to the payslip needing correction. This helps payroll teams resolve time off adjustments more directly, while removing an unnecessary payslip status field from the time off view.
Original PR description
-Warning has been introduced on the timeoff form view, to redirect to the payslip to be corrected. -"payslip_state" has been removed from the timeoff view.
Payroll users now see a clearer warning on time off records when a related payslip needs correction, with a direct path to the payslip to update. The payroll dashboard and correction process have also been streamlined so teams can resolve time off and payslip issues more easily.
Original PR description
-Warning has been introduced on the timeoff form view, to redirect to the payslip to be corrected. -"payslip_state" has been removed from the timeoff view. -UX changes in the payroll dashboard.
The activity popover now adapts its layout depending on whether activities are scheduled. This makes the empty state clearer with a stronger call to action, while keeping lists of activities easier to read and visually polished.
Original PR description
Give the popover two distinct states instead of one rigid layout. With no activity scheduled, it shrinks to its help text and offers a primary CTA. With activities listed, it keeps its 350px width and a secondary button. Also stops the section headers' background from overflowing the popover's rounded top corners, and tints the handle to match the header it points at. task-6528195 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders are now easier to use because the Unbuild action has been moved away from the main buttons, reducing confusion with resetting an order to draft. Stock transfers are also easier to find because the quick search now includes vendor names.
Original PR description
This improvement enhances the manufacturing and stock user experience by: - Moving the Unbuild button to the cog menu of the MO form view to avoid confusion with the Reset to Draft action. - Updating the Transfer quick search filter in stock.picking to also consider the vendor name, making it easier to find transfers related to a specific vendor. Task iD- 6460372 Enterprise PR: https://github.com/odoo/enterprise/pull/128087
Manufacturing users get a clearer experience in ECO approvals, planning schedules, and work order lists. The approvals section now has more room, planning opens with fewer visual distractions, and work order action buttons are sized more consistently.
Original PR description
*: quality_mrp_workorder This improvement enhances the UX by: - Extending the Approvals view in ECO stages to full width for better form visibility. - Setting Show Dependencies to false by default in the Planning Gantt view for a cleaner and less cluttered view. - Fixing the Finish button size in the work order list view to ensure consistent sizing across the list view. Task Id - 6460372 Community PR: https://github.com/odoo/odoo/pull/282715
Manufacturing order overviews now include a To Replenish toggle that shows only components still needing to be ordered. This helps users quickly focus on missing supplies by hiding unrelated operations, byproducts, and already-covered components while the filter is active.
Original PR description
Users could not quickly identify components that still needed to be ordered because the MO overview displayed them alongside all other components. Add a To Replenish toggle to the top-right control panel so users can limit the overview to components whose status is To Order. This commit's changes: - Add the To Replenish toggle to ongoing manufacturing orders - Show only components whose status is To Order when enabled - Hide operations and byproducts while the filter is enabled task-5946139 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces a light user access level that automatically keeps permissions limited to lightweight groups where available. It reduces manual permission setup and helps organizations manage lower-privilege users more consistently across multiple business apps.
Original PR description
**[IMP] base: light user access rights management** Introduce the "light user" concept to optimize group assignment and privilege management. ### Technical Details * **Light vs. Regular Groups**: Groups listed by `_get_light_group_xmlids` are classified as light groups; all other groups are treated as regular groups. * **Implied Groups Automation**: `base.group_user_regular` is automatically appended to the `implied_ids` of groups (specifically those without privileges, without existing `implied_ids`, or representing the lowest privilege level within a privilege set). This logic is internal and cannot be modified or accessed by users. * **Light Group Reduction**: Selecting the light user access level triggers `_reduce_to_light_groups`, which revokes all regular groups from the user and replaces them with their corresponding light versions (when available). https://github.com/odoo/odoo/pull/285702
Odoo introduces a light user access level that automatically keeps users limited to lower-privilege groups when selected. This helps businesses manage basic user permissions more consistently and reduces the risk of assigning unnecessary access across apps.
Original PR description
**[IMP] base: light user access rights management** Introduce the "light user" concept to optimize group assignment and privilege management. ### Technical Details * **Light vs. Regular Groups**: Groups listed by `_get_light_group_xmlids` are classified as light groups; all other groups are treated as regular groups. * **Implied Groups Automation**: `base.group_user_regular` is automatically appended to the `implied_ids` of groups (specifically those without privileges, without existing `implied_ids`, or representing the lowest privilege level within a privilege set). This logic is internal and cannot be modified or accessed by users. * **Light Group Reduction**: Selecting the light user access level triggers `_reduce_to_light_groups`, which revokes all regular groups from the user and replaces them with their corresponding light versions (when available). OPW-5323371
Belgian payroll wording has been standardized so salary classifications are now consistently called salary scales across employee records, salary offers, reports, warnings, and demo data. This reduces confusion for HR users and makes payroll configuration easier to understand.
Original PR description
Harmonize the terminology used for Belgian salary scale classifications across
UI labels, views, models, salary offers, reports, data records, and test suites.
Previously, different terms ("Job Categories", "Professional Categories", and
"Category") were used inconsistently throughout the payroll configuration,
contract options, and employee views.
- Rename model `l10n_be.job.category` to `l10n_be.salary.scale`
- Rename relational field to `l10n_be_salary_scale_id` across employees, versions, and contract offers
- Rename record names in CSV data (e.g., "Category A" -> "Salary Scale A")
- Update payroll warnings, PDF reports (individual account, social balance), JS patches, and salary configurator
- Rename data, view, model, and test files to match the new nomenclature
- Update demo data and tests in dependent module `test_l10n_be_hr_payroll_account`
Task: 6475636HR documentation now uses “salary scale” instead of “job category” to match Belgian payroll terminology. This helps keep internal wording consistent and clearer for teams working with Belgian payroll processes.
Original PR description
Update method docstring and parameter examples to reference 'salary scale' instead of 'job category' to align with the Belgian payroll terminology. Task: 6475636
Odoo Discuss can now use a custom call client bundle for testing alternative video call infrastructure or server updates. If no custom bundle is active, the standard built-in client continues to be used, reducing disruption while making experimentation easier.
Original PR description
Testing alternative SFU implementations (or updating the SFU with a breaking client-server API change) currently requires replacing the bundled client in the source tree. Add a config setting to provide a custom SFU JS client bundle. The bundle is stored as an attachment and replaces the default client through an `ir.asset`. When deactivated or empty, it is the built-in static bundle that is used.
The messaging menu can now combine filters from multiple features, so users see more accurate and relevant conversations without pagination issues. It also supports context-specific tabs that stay out of the global menu and counters while still loading and counting their own content correctly.
Original PR description
See individual commits for rationale. enterprise: https://github.com/odoo/enterprise/pull/130289
Project users can now open a Time by Stage report to see how long tasks spend in each stage. This helps teams spot workflow bottlenecks and better understand where project work is slowing down.
Original PR description
- added `Time by Stage` option to open the report page - create `project.task.stage.report` for the stage time calculation --- task-5139455
Serial numbers now show their delivery date in stock and field service planning screens, making it easier for teams to see when equipment was delivered. When all delivered items are returned, the delivery date is cleared so records stay accurate.
Original PR description
- show the `delivery_date` of the serial number in the `stock.lot` form, list, and kanban views - show the `delivery_date` in `planning.slot` equipment notebook - product returns make delivery date to false if the returned quantity = the delivered one --- task-5184420
Helpdesk search screens have been reorganized and simplified to make tickets and SLA reports easier to filter and analyze. This improves day-to-day navigation for support teams without changing the underlying ticket data or workflow.
Original PR description
In this commit, we refactor and clean the search view of Helpdesk. task-6512923
The Project options menu now places “Timesheets and Planning Analysis” in a revised order. This makes the menu organization more consistent and easier for users to navigate.
Original PR description
Change the order of `Timesheets and Planning Analysis` in the project option menu --- task-5139455
This update improves how character field size limits are handled in the user interface, helping users enter data that fits expected limits. It reduces the chance of input errors or rejected exports, with a small impact focused on German reporting tests.
Original PR description
https://github.com/odoo/odoo/pull/284290
The HR app menu order has been adjusted so Fleet and Payroll appear directly after Time Off. This creates a more logical onboarding flow and helps users find related HR tools more easily.
Original PR description
Reorder menu sequence values to position Fleet and Payroll directly after Time Off while maintaining increments of 5 between bounds 185-230. Sequence changes: - Appraisals: 200 -> 190 - Attendances: 205 -> 200 - Recruitment: 210 -> 205 - Referrals: 215 -> 210 - Time off: 225 -> 215 - Fleet: 220 (unchanged, now following Time Off) - Payroll: 190 -> 225 task-6482852 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The online shop now shows out-of-stock status more accurately, only marking products as unavailable when all variants are sold out. Customers are guided to available variants when possible, and unavailable products show clearer notification and wishlist actions instead of a misleading add-to-cart option.
Original PR description
**Purpose:** Out of stock was not completely managed in eCommerce. The out of stock ribbon was not reflecting correctly the status of the partially out of stock products. The notification and…
**Purpose:** Out of stock was not completely managed in eCommerce. The out of stock ribbon was not reflecting correctly the status of the partially out of stock products. The notification and wishlists buttons were inconsistents with the rest of the features. **Specification:** Shop page: - Make the out of stock ribbon appear only if all variants are out of stock. - If a product if completely out of stock, hide the add to cart button. - If a variant is still available, select the first available variant in the configurator or when clicking on the tile to open the product page. Product page: - Make the notification button replace the Add to cart button. - Rationalise the wishlist button of out of stock products. - When clicking notify me, show form to enter email if not logged in, subscribe directly if logged in Task-6026756 See also: - https://github.com/odoo/enterprise/pull/130684 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several internal improvements across Odoo's core framework, including faster access checks, better handling of cached model data, and clearer debugging information for access errors. These changes should help developers diagnose issues more easily while improving performance and reliability for users behind the scenes.
Original PR description
(see commits) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings Odoo's spreadsheet engine up to its latest version, including improvements that help calculations run more efficiently by limiting evaluation to valid sheet areas. It also includes internal compatibility updates that support ongoing spreadsheet reliability and maintainability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/54a0597b26 [REL] 19.5.0-alpha.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/54a0597b26 [REL] 19.5.0-alpha.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4f0daee34e [IMP] index: export `owlPlugins` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/532243ce63 [REL] 19.5.0-alpha.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7907b8e368 [PERF] evaluation: clip range to sheet [Task: 6483083](https://www.odoo.com/odoo/2328/tasks/6483083) https://github.com/odoo/o-spreadsheet/commit/1fe87f3046 [IMP] owl3: remove `env.getPopoverContainerRect` [Task: 6510584](https://www.odoo.com/odoo/2328/tasks/6510584) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Swiss QR invoices can now be generated even when a company or customer address is missing street or building number details, since those fields are not required in Switzerland. Users are informed with a banner in the Send & Print flow and batch processing continues for other invoices if one invoice has a QR issue.
Original PR description
In Switzerland, the street and building number is not required to generate a valid QR invoice. To minimize friction, errors are no longer raised if they are missing from the address of the company or the customer during the creation of the QR Code. Instead, an info banner is now displayed in the Send & Print popup indicating to the user that the addresses of some of the customers are missing and allow the user to browse through those customers. task-4349496 opw-4317153 Forward-Port-Of: odoo/odoo#271534
The HR app menu order has been adjusted so new companies see related onboarding areas in a more logical sequence, with Fleet and Payroll placed directly after Time Off. This makes navigation clearer during setup and supports a smoother onboarding experience for business users.
Original PR description
Reorder menu sequence values to position Fleet and Payroll directly after Time Off while maintaining increments of 5 between bounds 185-230. Sequence changes: - Appraisals: 200 -> 190 - Attendances: 205 -> 200 - Recruitment: 210 -> 205 - Referrals: 215 -> 210 - Time off: 225 -> 215 - Fleet: 220 (unchanged, now following Time Off) - Payroll: 190 -> 225 task-6482852
The AI feature now records a warning when a required markdown component is missing. This helps administrators identify configuration issues faster and reduces time spent diagnosing why AI-generated content may not render as expected.
Accounting reports now once again let users filter for unreconciled items while keeping the existing reconciliation date logic. This makes it easier for finance teams to review open partner balances accurately for a selected reporting date.
Original PR description
Restore the unreconciled filter while continuing to use the recon_date mechanism, applying the date to date_to. task-none
Belgian payroll now handles worker terminations with updated termination fee calculations and no employer holiday pay. It also generates the dedicated holiday attestation report for workers, helping payroll teams produce the correct departure documents and amounts.
Original PR description
1. No holiday pay from the employer. 2. Generate the delicated holiday attest report for wokers. 3. Update termination fees. Task-6006190
Odoo now stops silently shortening text that is longer than an allowed field size and instead relies on database validation to reject it clearly. This improves data accuracy and makes configuration or import issues easier to detect, with country codes now explicitly limited to the standard two-letter format.
Original PR description
The gift card design has been refreshed to use space more effectively and stay readable in dark mode. The related PDF layout is also adjusted, and mail previews in the chatter get more room for a clearer customer-facing presentation.
Original PR description
This PR redesigns the gift card template by improving the space utilization and adding a white background to enhance readability on dark mode. It also - slightly modifies the layout of the related…
This PR redesigns the gift card template by improving the space utilization and adding a white background to enhance readability on dark mode. It also - slightly modifies the layout of the related PDF - increases the minimum width to provide more space for the mail preview in the chatter. task-6246180 | Before | After | |--------|--------| | <img width="616" height="779" alt="Screenshot 2026-06-25 at 10 53 22" src="https://github.com/user-attachments/assets/b7f05c43-aaaa-4f4f-ba5b-fa93f4aaaad2" /> | <img width="504" height="595" alt="Screenshot 2026-06-25 at 10 25 22" src="https://github.com/user-attachments/assets/19bca54b-923a-44d7-9c08-3901ff08a532" /> | |--------|--------| | <img width="448" height="720" alt="Screenshot 2026-06-02 at 10 43 53" src="https://github.com/user-attachments/assets/d5fed6d0-1d05-44a2-9bc8-090259a10291" /> | <img width="555" height="721" alt="Screenshot 2026-06-25 at 10 26 34" src="https://github.com/user-attachments/assets/8e26db94-d654-4d18-8e34-8bee277a9f44" /> | |--------|--------| | <img width="798" height="884" alt="Screenshot 2026-06-25 at 10 54 39" src="https://github.com/user-attachments/assets/54bf2940-988c-4754-8677-19bc980a6684" /> | <img width="790" height="856" alt="Screenshot 2026-06-25 at 10 26 52" src="https://github.com/user-attachments/assets/f2ca78d5-97f8-456d-9416-fbd2f680b013" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Visitors who sign in during an active live chat can now keep the same conversation instead of starting over. This improves the customer support experience by preserving ongoing and previous chat access after login, including cases where extra authentication is required.
Original PR description
*=base, mail, portal, website_livechat Before this commit, when a visitor logged in while an active livechat session was ongoing, the session was lost and the user had to start a new one. Once logged in, access is checked on `partner_id` and no longer on `guest_id`. Add a post-session-login hook that runs only after authentication is fully finalized, including MFA. im_livechat uses this hook to replace the guest members of pinned livechat sessions with the logged-in partner. This allows visitors to continue active sessions and access previous ones. When a guest is present in the user context, both the user and guest are sent to the client so that guest messages continue to be recognized as self-authored after login. task-[3957100](https://www.odoo.com/odoo/project/1519/tasks/3957100)
Belgian payroll calculations now reduce payslip amounts based on time credit, parental time off, and partial incapacity while keeping the employee's contractual wage unchanged. This improves accuracy for regular pay, holiday-related calculations, and reporting by reflecting actual working time across fixed and variable schedules.
Original PR description
**Time Credit Work Entries :-** . LEAVE300 (Credit Time) . LEAVE301 (Parental Time Off) . LEAVE281 (Partial Incapacity) ### Regular Pay :- **1. Wage proration for time credit** The `wage proration`…
**Time Credit Work Entries :-**
. LEAVE300 (Credit Time)
. LEAVE301 (Parental Time Off)
. LEAVE281 (Partial Incapacity)
### Regular Pay :-
**1. Wage proration for time credit**
The `wage proration` applies only to the payslip calculation, not to the employee's contractual wage, the employee's full-time contractual wage remains unchanged. The wage displayed on the employee's version remains the original amount agreed in the contract, where **The proration is applied only when calculating the worked days and corresponding amounts on the payslip**. This ensures that the payslip reflects the employee's actual working time while preserving the contractual wage as the reference amount.
The used range to calculate the proration ratio depends on the schedule type :-
_. Fixed Calendars:_ The proration ratio is computed using a standard 1-week period (Monday to Sunday) from the attendance schedule, as fixed schedules repeat weekly.
> Fixed Calendar Example (1-Week):
> Schedule: 4 working days (30.4h) + 1 time credit day (7.6h) = 38h total schedule
> Calculation range: 1 week
> Proration ratio: $\frac{30.4\text{ actual working hours}}{38.0\text{ total schedule hours}} = 0.80$.
> Contractual Wage: €5,000 (Unchanged).
> Prorated Payslip Amount: $€5,000 \times 0.80 = €4,000$.
_. Variable Calendars:_ The proration ratio is computed over the entire target evaluation period to accurately capture work entries, taking the full month for a monthly payslip or the full 3-quarter/3-month period for DMFA reporting.
> Schedule: Alternating shifts across a monthly payslip period totaling 152 total scheduled calendar hours, of which 38 hours are marked as time credit and 114 hours are actual working hours.
> Calculation range: Full calendar month (e.g., 1st to 30th/31st).
> Proration ratio: $\frac{114\text{ actual working hours}}{152\text{ total schedule hours}} = 0.75$.
> Contractual Wage: €5,000 (Unchanged).
> Prorated Payslip Amount: $€5,000 \times 0.75 = €3,750$.
Ex: If an employee has a contractual wage of €5,000 and their schedule includes time credit:
Employee/contract wage: €5,000 → remains unchanged
Basic wage used as the contractual reference: €5,000 → remains unchanged
Payslip worked-days amount: prorated according to the actual working time
This distinction is important because time credit changes the amount paid for the payroll period, but it does not change the employee's underlying contractual full-time wage.
**2. Version Work Time Rate**
The `work_time_rate` is computed at the employee version level, where the time-credit situation belongs to the employee's version.
The existing behavior for flexible/variable calendars is preserved, **where currently the work_time_rate not computed for variable calendars and the user is expected to enter the appropriate work_time_rate manually for the variable calendars, So the overidden work_rime_rate computation deals with the `credit_time_fixed_calendars`**
For fixed calendars with time credit, the computation is handled specifically for the employee version:
. Only versions flagged with l10n_be_time_credit and using a fixed calendar are handled by the custom computation.
. The employee's reference calendar is used to determine the full-time weekly hours.
. The calculation considers both, regular working attendances & attendances marked as time credit.
The time-credit hours are therefore included when determining the employee's work_time_rate, **But Importantly, the actual working hours of the resource calendar are not changed.**, where The time-credit attendances are included only for the purpose of calculating work_time_rate. They are not treated as actual working hours, and hours_per_week continues to represent the employee's effective working hours without the time-credit period.
Ex: For a full-time reference calendar of 38 hours:
Actual working hours: 30.4h/week
Time-credit hours: 7.6h/week
Hours considered for work_time_rate: 30.4 + 7.6 = 38h
work_time_rate: 100%
Actual working hours remain: 30.4h/week
-----
### Double Holiday :-
The Double Holiday Pay calculation requires special handling for time-credit periods because two different rates need to be considered:
. The **computed work_time_rate** that used to normalize the wage "include credit_entries"
. The **effective/real work_time_rate** used to determine the assimilated months "not include credit_entries""
The used wage is the version wage itself that's not prorated. The calculation first uses the full contractual wage **(so no need to change the wage on the tests)** and divides it by the version's current computed work_time_rate. This is important for time-credit versions because their computed work_time_rate can include the time-credit attendances.
However, when calculating the _double_holiday_assimilated_months, the time-credit periods are treated differently. The calculation uses the effective working-time rate, where regular time-credit entries are not considered as working time. The exception is `LEAVE281 (Partial Incapacity),` which is considered in the assimilated-month calculation and therefore contributes with its corresponding rate.
Ex: An Employee works with wage €2,500
. January → June with Normal Schedule
. July → September with 4/5 Partial Incapacity (LEAVE281)
. October → December with 4/5 Credit Time (LEAVE300)
The employee's version wage remains €2,500 throughout the calculation and the used work_time_rate for the wage will be the current computed work_time_rate which will be 1.0
The Double Holiday Pay calculation can therefore be represented as:
€2,500 / 1.00 × [(6 × 1.0 / 12) + (3 × 1.0 / 12) + (3 × 0.8 / 12)]
. For the wage normalization: the computed work_time_rate of the relevant version is used. This rate can include time-credit attendances.
. For _double_holiday_assimilated_months: the calculation uses the effective/real working-time rate for each period. Regular time-credit (LEAVE300) is therefore reflected as 80%, while LEAVE281 (Partial Incapacity) is treated as an assimilated period and remains at 100% in this example.
check:-
```
def _l10n_be_get_paid_double_holiday()
def _compute_double_holiday_assimilated_months()
```
-----
### Eco Voucher :-
The Eco-voucher calculation depends directly on the employee version's work_time_rate.
The voucher amount is therefore automatically updated when the work_time_rate changes. This is particularly important for time-credit versions, because the work_time_rate now correctly represents the employee's contractual occupation rate, including the relevant time-credit periods.
This means that a time-credit version does not necessarily result in a reduced Eco-voucher entitlement. In particular, when the employee is on a reduced working schedule but the reduction is entirely due to time credit, the computed work_time_rate can remain at 100%, because the time-credit periods are included when calculating the rate.
Ex: An employee is entitled to a maximum of €250 in Eco-vouchers and has the following situation during the reference period:
01/06/2020 → 31/10/2020: Full-time schedule → work_time_rate = 100%
01/11/2020 → 31/05/2021: 3/5 schedule with Tuesday and Wednesday represented as credit-time entries.
Although the employee only has 22.8 actual working hours per week, the two non-working days are explicitly represented as time credit. Therefore, for the purpose of the employee version's work_time_rate, the time-credit hours are included and the rate remains 100%.
The Eco-voucher calculation consequently uses: €250 × 100% = €250
110 valid working days during the full-time period, out of 261 scheduled days.
82 valid working days during the 3/5 time-credit period, out of 157 scheduled days, after excluding 9 unpaid-time-off days.
Therefore: €250 × 110 / 261 + €250 × 82 / 157 = €235.94
This confirms that time credit does not incorrectly reduce the Eco-voucher amount simply because the resource calendar contains fewer actual working hours. The employee's work_time_rate correctly remains 100% when the missing hours are accounted for as time credit.
check:-
`def _get_eco_vouchers_amount(self, get_explanation=False):
`
-----
### Representation Fees :-
The REP.FEES calculation depends directly on the employee version's work_time_rate. Therefore, for time-credit versions, the newly computed work_time_rate is automatically taken into account when determining the amount.
For time-credit versions, the computed rate includes the time-credit hours. Therefore, a 4/5 schedule with one full day of time credit has a work_time_rate of 100% (the 4/5 worked hours + the 1/5 time-credit hours represent the full reference schedule). As a result, the existing representation-fee proration logic is not triggered, and the full representation-fee amount is maintained.
check :-
`def _get_representation_fees(self, localdict):
`
-----
### DMFA :-
The DMFA declaration requires two separate considerations for time credit:
**. Working days,** where the employee's days_per_week is preserved and the time-credit attendances are not considered as actual working days.
This is important because the time-credit hours may be included when determining the employee's work_time_rate, but they must not be reported as worked days in the DMFA declaration, So the time credit can affect work_time_rate, but it does not create additional working days for DMFA.
**. Termination contribution type,** The contribution type is determined based on the employee's yearly salary, which is accumulated from the amounts reported on the payslip worked-days lines, The resulting yearly salary is compared against the configured salary thresholds to determine the appropriate contribution type.
Because the yearly salary is based on the actual amounts coming from the payslip worked-days lines, a time-credit period can reduce the yearly salary used for this calculation.
As a result, the employee's contribution type can legitimately move to a lower category.
check:-
```
DMFAWorkerContribution() __init__ class
yearly_salary = payslips[0]._l10n_be_get_termination_yearly_salary()
```
-----
task-5126195Field Service planning now supports an additional Urgent priority for shifts, giving teams a clearer way to flag work that needs immediate attention. The website request form also adds a Minor Impact option, helping businesses capture issue severity with more precision from the start.
Original PR description
This PR adds a new "Urgent" priority level in Field Service shifts, and a new "Minor Impact" level in the website form, to allow more granularity. Task-6486321
Subscription users can now add recurring lines using only a description, without first creating a dedicated product. These lines are included in invoicing, renewals, upsells, plan counts, and recurring revenue metrics, while existing product-based subscription lines keep their current behavior.
Original PR description
Before this commit: Subscription lines needed a product. Lines with no product were not treated as recurring, so invoicing, renew, upsell, plan counts, and MRR ignored them. After this commit: A line…
Before this commit: Subscription lines needed a product. Lines with no product were not treated as recurring, so invoicing, renew, upsell, plan counts, and MRR ignored them. After this commit: A line with only a description on a subscription with a plan is recurring. It can be invoiced, renewed, upsold (with prorata when prepaid), counted on the plan, and included in MRR. Impact: Users can build subscriptions without creating a product for every line. Product lines keep the same behavior as before. Performance: Profiler on Subscription Report (list), product only dataset on master vs this branch (2000 subscriptions) Main report query (sale_subscription_report ... LIMIT 80): - master: 58.97 ms - this branch: 59.52 ms No meaningful difference on that path. Flame graphs: Current master- <img width="1920" height="1002" alt="image" src="https://github.com/user-attachments/assets/c81fd63a-c9b7-4506-a4a8-8f04b1427549" /> PR Branch- <img width="1920" height="1002" alt="image" src="https://github.com/user-attachments/assets/9b750b14-739f-4b1c-b661-e915dac60c5c" /> Task id: 6410240
Belgian payroll reporting now includes employer-owned pool vehicles in quarterly ONSS/DMFA CO2 contribution declarations when they were used during the period. This helps companies report company car contributions more accurately and avoid double-counting vehicles already handled through employee payslips.
Original PR description
**Description :-** This PR adds support for declaring ONSS/DMFA quarterly CO₂ contributions for pool vehicles (vehicles owned by the employer that are not assigned to am employee on a contract, but…
**Description :-** This PR adds support for declaring ONSS/DMFA quarterly CO₂ contributions for pool vehicles (vehicles owned by the employer that are not assigned to am employee on a contract, but are used during the period). According to Belgian social security (ONSS) regulations, CO₂ fees must be paid for all company vehicles used during the quarter: . Assigned Company Cars: CO₂ fees are calculated and declared directly via employee monthly payslips. . Pool Cars: Must be declared at the employer level for any month in which they had active assignment/driver logs (fleet.vehicle.assignation.log) and were not already declared on an employee payslip. **Implementation :-** . Vehicles declaration on the DMFA (_compute_vehicle_ids) Retains all active vehicles with valid license plates that have driver assignment logs during the DMFA quarter. Ensures eco-friendly and pool vehicles appear under the XML <CompanyVehicle> declaration block. . Month-by-Month Vehicles Contribution (_get_vehicles_contribution) Evaluates the DMFA quarter on a per-month basis rather than applying a static quarterly multiplier. Prevents double-counting by excluding vehicles already charged via an employee payslip for a specific month (covered_vehicle_ids). Dynamically checks driver log date overlaps (date_start and date_end) per month to properly handle mid-quarter acquisitions or transitions. Evaluates CO₂ indexation parameters historically per month by passing co2_fee_date in the context (vehicle.with_context(co2_fee_date=current_month)._get_co2_fee(...)). **Example :-** > CAR-001 (Diesel, CO₂=120): ((120 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 175.42 > CAR-002 (Gasoline, CO₂=100): ((100 * 9 - 768) / 12) * (181.93 / 114.08) * 2.75 = 48.24 > CAR-003 (Diesel, CO₂=110): ((110 * 9 - 600) / 12) * (181.93 / 114.08) * 2.75 = 142.53 > TEST (Class Default Car): = 33.22 > Payslips CO₂ Fees: > CAR-002 on Employee Payslips (Jan & Feb): 48.24 * 2 = 96.48 > Pool Cars Monthly CO₂ Fees (Iterating Jan, Feb, Mar): > > January: > CAR-001: 175.42 > TEST: 33.22 > Subtotal Jan: 208.64 > > February: > CAR-003: 142.53 > CAR-001: 175.42 > TEST: 33.22 > Subtotal Feb: 351.17 (Cumulative pool fees: 559.82) > > March: > CAR-003: 142.53 > CAR-001: 175.42 > CAR-002: 48.24 > TEST: 33.22 > Subtotal Mar: 399.41 (Cumulative pool fees: 959.23) > > Therefore, Total Vehicles Contribution: 96.48 (payslips) + 959.23 (pool) = 1055.71 task-6147532
Belgian payroll declarations now calculate withholding-tax exemptions for eligible overtime hours and include them in the 274.XX report. This helps companies apply annual hour caps correctly across the year and gives payroll teams clearer XLS and PDF reporting, including sector-specific rules and white-cash-register settings.
Original PR description
Compute the withholding-tax exemption for overtime hours (natures 44–59) within the Belgian 274.XX declaration. Overtime worked-day lines are collected from validated payslips, bucketed by rate and sector (CP124/CP302/immovable work), and allocated to the appropriate nature codes while respecting each employee's annual hour cap. Hours already declared in earlier months of the same year are carried forward so the cap is enforced cumulatively. The exemption rate is stored as an updatable rule parameter. A white-cash-register flag on the company controls the higher cap for CP302 employees. New work-entry types, an XLS extra-hours sheet, a PDF section, and extended tests are included. Task Id: 5430988
Belgian payroll now includes the foundation for DRS declarations and supports exports for the WECH009 and WECH010 declaration types. This helps businesses prepare required social risk declarations more directly from Odoo, reducing manual reporting work and improving payroll compliance workflows.
Original PR description
Implements the base for all DRS declarations And already implements the exports for WECH009 and WECH010 task-5915160
Spanish accounting users can now choose the abbreviated accounting plan template in Odoo. This makes the appropriate reports available for companies that use this lighter version of the standard Spanish chart of accounts.
Original PR description
Description of the issue/feature this PR addresses: Add abbreviated accounting plan There is an accounting plan called abbreviated that was not there. This is very similar to full that is why it has this template as parent. Now this template can be selected and access to its reports. task-6065347
Financial reports now use the new retained earnings account category when calculating cumulative translation adjustments. This improves the accuracy and consistency of balance sheets, general ledger, trial balance, and SAF-T reporting across affected localizations.
Original PR description
This commit uses the new Equity Retained account type with average CTA. It also adds the account type in the balance sheet and in SAFT. task-6374563
This update adds an equity retained earnings account and adjusts currency translation handling in accounting reports. It helps businesses produce more accurate financial reporting, especially when consolidating or translating balances across currencies.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents server connection errors when many background requests happen at the same time. It helps Odoo stay responsive during busy periods, especially for live messaging and websocket-related activity.
Original PR description
make gevent connection pool non-blocking to avoid 'The Connection Pool Is Full' error when too many coroutines are borrowing connections in gevent server. https://github.com/odoo/iap-apps/pull/1827 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285423
Odoo now supports Turkish workflows where an e-Archive invoice is legally used as the dispatch document, avoiding a separate e-Dispatch submission. This reduces duplicate paperwork for e-commerce, marketplace fulfillment, and third-party logistics while keeping the standard e-Dispatch process available when needed.
Original PR description
Purpose: Turkish regulations allow an e-Archive invoice to serve directly as the dispatch document, eliminating the need to send a separate e-Dispatch XML. This is commonly used in e-commerce…
Purpose:
Turkish regulations allow an e-Archive invoice to serve directly as the
dispatch document, eliminating the need to send a separate e-Dispatch XML.
This is commonly used in e-commerce marketplace fulfillment or third-party
logistics scenarios.
This commit adds support for the "Invoice Serves as e-Dispatch" workflow:
- Extend `l10n_tr_nilvera_dispatch_type` on `stock.picking` with the new
option `IS_DESPATCH` ("Invoice Serves as e-Dispatch") and update its label
to "Dispatch Handling".
- When `IS_DESPATCH` is selected on linked pickings for e-Archive invoice, skip
sending separate e-Dispatch and instead inject '<cac:AdditionalDocumentReference>'
node with `<cbc:DocumentTypeCode>IS_DESPATCH</cbc:DocumentTypeCode>`
into e-Invoice XML.
- Hide the "Send GİB e-Dispatch (XML)" and "Update From GİB e-Dispatch (XML)"
buttons when Dispatch Handling is set to `IS_DESPATCH`.
- Vehicle and carrier information is not required when Dispatch Handling is
set to `IS_DESPATCH`.
- Replace the blocking warning for invoices with linked pickings but no
e-Dispatch orders with an info message, allowing the XML to be sent without
e-Dispatch information.
- Keep the existing flow when both linked delivery and e-Dispatch orders are
provided.
task-6369988Polls in Odoo Discuss now use the updated visual style, including refreshed panel colors and rounder corners. This creates a more consistent and polished experience for users when viewing or interacting with polls in conversations.
Original PR description
Since [1], discuss styling was adapted to frost. Action panel have a different color and more radius. This commit adapts the poll components to match this new styling. [1]: https://github.com/odoo/odoo/pull/285383 |Before|After| |-|-| |<img width="500" alt="image" src="https://github.com/user-attachments/assets/88b7dcce-ca30-4fb1-bc1c-7252a70b524f" />|<img width="500" alt="image" src="https://github.com/user-attachments/assets/34cae1e1-8bb7-4920-980b-45d236433e3e" />|
Belgian payroll now recalculates company car benefit-in-kind at year-end or when a contract ends, so employees are not overtaxed when their car changes during the year. If too much benefit was already taxed because of monthly minimums, the system automatically applies a regularization to correct it.
Original PR description
**Description :-** The payroll system currently applies a minimum legal yearly BIK/ATN for company cars. So even if the employee’s theoretical calculated car benefit is lower than the legal minimum,…
**Description :-**
The payroll system currently applies a minimum legal yearly BIK/ATN for company cars.
So even if the employee’s theoretical calculated car benefit is lower than the legal minimum, payroll still taxes the employee on the legal minimum.
That is correct as long as the employee keeps that same car all year,
But if later in the same year the employee changes to a another car, with a lower or a bigger BIK, In that case, the employee may already have paid too much earlier in the year because the minimum was applied month-by-month indirectly.
So, in December, or in the Month that the contract ends, must:
1. recompute the true yearly ATN
2. compare it with what was already paid
3. refund/deduct the excess if too much ATN was charged.
. Add a salary rule to calculate the regularization amount in case of employee have paid too much for the car bik, which applied in December, or in the Month that the contract ends,
**Implementation :-**
. Min legal car ATN: this's minimum yearly ATN that need to be paid.
. Yearly Theoretical ATN: This's the sum of the real BIK calculated from the car formula without applying the min legal car atn per month
. Yearly ATN paid: this's the sum of ATN paid on the payslips during the year
∴ Yearly ATN to pay = MAX( Min legal car ATN, Yearly Theoretical ATN)
∴ Regularization amount = Yearly ATN to pay - Yearly ATN paid
If +ve ,then employee paid less and owes more ATN **(not our case)**
If -ve ,then employee paid too much and need to refund
**Example :-**
min_car_atn = 1,690€ / year _(in 2026)_
car1 (Volkswagen/Golf 8) from January to June:
car_value = 38,000 €
yearly_theoretical_atn = 1,938 €/year
yearly_paid_atn = 1,938 €/year
car2 (Nissan) July to December::
car_value = 20,000 €
yearly_theoretical_atn = 1,371.43 €/year
yearly_paid_atn = 1,690 €/year
Calculations:
∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days
∵ car1 covered_days = 181 days
∵ car2 covered_days = 184 days
∴ Yearly Theoretical ATN = 1,938 * (181 / 365) + 1,371.43 * (184 / 365)
= 1,652.39 €
∴ Yearly ATN to pay = Max(min_legal_car_atn, yearly_theoretical_atn)
, where it's the final ATN that should have been paid after applying the legal minimum.
= Max(1,690, 1,652.37) = 1,690 €
∵ Yearly ATN paid _(payslips)_ =
car1 -> (1,938/365) * (31 + 28 + 31 + 30 + 31 + 30) = 961.035616438 €
car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 31) = 851.945205479 €
= 1,812.98 €
∴ Regularization amount = yearly_atn_to_pay - yearly_atn_paid
= 1,690 - 1,812.97
= -122.97 €
**∴ Need to refund 122.97 € to the employee**
**Example :-**
min_car_atn = 1,690€ / year _(in 2026)_
Car 1 (Corolla) Jan-Jun:
Yearly Theoretical ATN = 1,748.57€
Yearly Paid ATN = 1,748.57€
Car 2 (Clio) Jul-Nov:
Yearly Theoretical ATN = 1,371.43€
Yearly Paid ATN = 1,690€
>>The contract end at 30th November
Calculations:
∵ monthly_car_atn is calculated based on the month calendar days so need to get the car covered assignment on days
∵ car1 covered_days = 181 days
∵ car2 covered_days = 152 days
∴ Yearly Theoretical ATN = 1,748.57 * (181 / 365) + 1,371.43 * (152 / 365)
= 1,438.215 €
∵ The regularization will be applied till the contract end not the full year, so the min_legal_car_atn will be prorated
∴ min_atn_prorated = 1,690 * ((181 + 152) / 365)
= 1,541.8356 €
∴ Yearly ATN to pay = Max(1,541.8356, 1,438.215) = 1,541.8356 €
∵ Yearly ATN paid (payslips) =
car1 -> (1,748.57/365) * (31 + 28 + 31 + 30 + 31 + 30) = 867.11 €
car2 -> (1,690/365) * (31 + 31 + 30 + 31 + 30 + 29) = 571.12 €
= 1,570.87 €
∴ Regularization amount = 1,541.8356 - 1,570.87
= -29.03 €
∴ Need to refund 29.03 € back to the employee
**Tests :-**
. Payslip Simulation for December & Termination Tests:
Updated all test cases covering December payslip computations and mid-year contract terminations
(e.g., test_274_declaration_december, test_end_of_contract, test_simple_n_holiday_pay_recovery_higher_salary)
to ensure that fully validated payslips exist for all preceding months of the active fiscal year, where The `ATNCARREGUL` salary rule computes regularization by inspecting historical payslips (_get_line_values / cumulative paid BIK from January up to the current month), so December or exit payslips in isolation without prior validated payslips skews the total paid BIK (atn_paid_before_current_payslip), which does not accurately reflect a real-world payroll state.
check:-
`def _get_holiday_pay_recovery()
`
. Updated Assertions (M.ONSS):
Adjusted expectations for year-to-date-dependent lines, for special ONSS contributions (M.ONSS) across these specific tests. **Because previous months' payslips are now added, processed and validated sequentially, which reflect exact real-life behavior.**
check:-
`def _l10n_be_get_special_social_contribution()
`
. Updated 274_xx december declarations
Make sure that the payslips are computed and validated **sequentially**, where all payslips from January through November is computed first then December payslips,
Before M.ONSS computed for December first which leads to Zero values, that makes taxable_amount_10 & pp_amount_10 not correct, **But now payslips are now processed and validated sequentially, which reflect exact real-life behavior.**
check:-
`def _compute_line_ids(self): "l10n_be_274.xx"
`
`def _l10n_be_get_special_social_contribution()
`
-----
task-6197625The salary configurator now prevents employees or candidates from selecting both a company car rental option and reimbursement for using a private car. When one option is selected, the other is reset and disabled, helping avoid incompatible benefit combinations and payroll mistakes.
Original PR description
In order to safe gaurd from employees (or candidates) from selecting both options for renting a company car and getting reimbursed for their private cars, the salary configurator now resets and disables one of the benefits if the other is selected. Task: 6515172
Payroll screens and reports now use the clearer term "Payslip Adjustment" consistently instead of "Salary Adjustment". The related forms and list views have also been simplified, making payroll adjustments easier for users to understand and manage.
Original PR description
- Updated all instances of "Salary Adjustment" to "Payslip Adjustment" across models, views, and reports for consistency. - simplify UI/UX across all form, list views Task: 6416223
Odoo no longer uses database-level text length limits for character fields, avoiding cases where values could be silently shortened and later produce confusing search or filter results. Length limits can still guide the user interface, while important business rules such as two-letter country codes are enforced explicitly with clearer validation messages.
Original PR description
Having a size of varchar is leading to subtle inconsistencies: silently truncating the value. For example, if size=2, you could insert "ABC" and a search with "ABF" would match that record, but filtering would match nothing. The property was already marked as deprecated. This change removes it. In terms of storage, this has no impact. https://github.com/odoo/enterprise/pull/129766 https://github.com/odoo/upgrade/pull/11134 https://github.com/odoo/upgrade-util/pull/505 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings Odoo's spreadsheet component up to the latest version. It improves spreadsheet calculation performance by limiting evaluations to relevant sheet ranges and includes internal compatibility updates that help keep the feature reliable.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/532243ce63 [REL] 19.5.0-alpha.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/532243ce63 [REL] 19.5.0-alpha.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7907b8e368 [PERF] evaluation: clip range to sheet [Task: 6483083](https://www.odoo.com/odoo/2328/tasks/6483083) https://github.com/odoo/o-spreadsheet/commit/1fe87f3046 [IMP] owl3: remove `env.getPopoverContainerRect` [Task: 6510584](https://www.odoo.com/odoo/2328/tasks/6510584) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Copying existing attachments is now faster because the system reuses known file information instead of recalculating it. This reduces waiting time when duplicating large files and improves performance for workflows that copy attachments often.
Original PR description
Do not recompute the checksum and lookup indexed content if we copy an already known file.
Creation of an attachment of 100Mo takes approximately 3s. This reduces the copy less than 1s is the indexed content is huge and to a few milliseconds if it's small.
```py
att = env['ir.attachment'].create({'name': 'a.csv', 'raw': BinaryBytes(b'a,b,c,d,e,f,g\n' * 2000000)}) # 1.25s
att.copy() # before: 1.25s; after: 0.25s
```
task-2630381
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSaudi companies will now keep global tax rounding enabled automatically, reducing the risk of accidental configuration changes. This helps maintain compliant and consistent tax calculations for Saudi localization users.
Original PR description
- Force "Round Globally" on Saudi companies to prevent accidental changes. task-6377776 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Pricelists now include a Daily Rates calendar that lets users select days and create the matching daily pricing rules in one action. This makes seasonal or date-specific pricing easier to manage, while related pricing forms are simplified and reused across connected sales channels.
Original PR description
Seasonal prices are set through pricelist rules with validity dates. This commit adds a "Daily Rates" button on the pricelist that opens a calendar where selecting days creates the matching rules at once, each covering a full day. The pricelist button box is moved to the base form so it can be shared, and partnership is updated to reuse it. task-4968689 See : - https://github.com/odoo/enterprise/pull/126319 - https://github.com/odoo/upgrade/pull/10797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers now see more accurate pickup and shipping information during checkout, including first available pickup dates, store closure notices, and expected shipping dates when available. The checkout also remembers the customer's selected delivery method and pickup store, making the buying experience smoother and reducing confusion.
Original PR description
Improve the pickup and shipping widgets to provide more accurate delivery information and keep track of the customer's choices. - Compute and display the first available pickup date based on opening hours, closures and estimated delivery time. - Display upcoming exceptional store closures in the pickup map. - Select the most relevant shipping method based on the customer's country and estimated delivery time. - Display the expected shipping date when available. - Remember the selected delivery method and pickup store during checkout. task-6485106 , design-task-6514854
Pricing rules that previously used percentage-based discounts now use the newer formula-based approach while keeping the same discount values. This keeps product, rental, subscription, point of sale, and website pricing behavior consistent after the old method was removed.
Original PR description
Follows the removal of the percentage price method. Rules defined with 'percentage' and a `percent_price` are redefined as 'formula' with the same value in `price_discount`, and the checks deciding whether a price can be shown as a discount now call `_is_plain_discount_rule`. See: - https://github.com/odoo/odoo/pull/273685
Belgian payroll worker code names have been simplified so users can find and select the right option more easily. The full official wording is still kept separately for reference, reducing clutter in daily payroll workflows without losing important details.
Original PR description
DMFA worker code names were overly long and detailed, making selection cumbersome for users in payroll workflows. Move the long official descriptions to a new `description` field on `l10n.be.worker.code` and update `name` with concise short names. Task: 6514465
The rental stock module now reuses an existing shared rule for checking rented product quantities. This makes it easier for future customizations or add-on modules to adjust rental availability logic consistently without changing the core process.
Original PR description
There is already an existing hook on product.product ([sale_renting.models.product_product.ProductProduct._get_qty_in_rent_domain](https://github.com/acsone/enterprise/blob/2cd105c93bb7199a5ecea67a919a7ab5d9251cbf/sale_renting/models/product_product.py#L24)), use it to get the domain, so it can be inherited by other modules.
While the upstream method uses `('product_id', 'in', self.ids)` instead of this one's `('product_id', '=', self.id)`, this isn't an issue since there's a `self.ensure_one()` just above.
Forward-Port-Of: odoo/enterprise#130090
Forward-Port-Of: odoo/enterprise#129191The website import form now directs users to official documentation instead of older links. This helps users find clearer guidance on creating API keys, reducing setup confusion when using the website import tool.
Original PR description
Update the import form links to use the documentation instead. This is important as it gives better info about creating API keys to use the tool correctly. Forward-Port-Of: odoo/enterprise#130457
Users can now connect WhatsApp Business accounts through Meta Embedded Signup directly in Odoo. This automates authorization, account setup, phone registration, and webhook configuration, reducing manual setup work and lowering onboarding friction.
Original PR description
Allow users to onboard WhatsApp Business accounts through Meta Embedded Signup using the application as their Tech provider. The onboarding flow guides users through the Meta authorization process, retrieves the required account information, configures the WhatsApp account automatically, registers the required webhook, and completes the setup without requiring manual Meta application configuration. Documentation: https://developers.facebook.com/documentation/business-messaging/whatsapp/embedded-signup/overview Related IAP PR: https://github.com/odoo/iap-apps/pull/1606 Task-5237447
Large Italian electronic invoices now import much faster by processing invoice lines more efficiently and reducing repeated checks. This can significantly shorten waiting times for businesses handling invoices with many lines, especially in accounting workflows.
Original PR description
### Description: When importing a large invoice, the process can take a lot of time. This is caused by how `l10n_it_edi` handles the creation and writing of each line of the bill. To improve performance, most of the process is now performed in memory and record creation is deferred to a single batch at the end. Additionally, the check related to `account_accountant` is cached to avoid superfluous calls. ### Benchmark: **For `history.limit`[^1] of 50 (= 21002 `account.move.line`):** | Invoice lines | Before | After | Speedup | |---------------|----------|---------|---------| | 33 | 4.75s | 2.23s | 2.1× | | 172 | 2.3min | 45.1s | 3.1× | | 1,934 | 44.4min | 6.8min | 6.6× | [^1]: System parameter `account.bill.predict.history.limit` ### Reference: opw-5937519 Forward-Port-Of: odoo/odoo#286357 Forward-Port-Of: odoo/odoo#282880
Belgian payroll officers now change an employee’s working schedule through one guided flow directly from the employee form. The process helps ensure leave balances, wages, and employee records are updated consistently, reducing confusion and avoiding missed payroll adjustments.
Original PR description
Before: Belgian employees had two different ways to change their working schedule: Directly updating the Working Schedule field on the employee. Using the "Working Schedule Change" action. Only the…
Before: Belgian employees had two different ways to change their working schedule: Directly updating the Working Schedule field on the employee. Using the "Working Schedule Change" action. Only the dedicated action correctly handled related payroll operations such as leave allocation adjustments and employee version creation. The action was not easily discoverable and created confusion about which workflow should be used. After: The "Working Schedule Change" action has been removed. Changing the Working Schedule directly from the employee form now opens a dedicated wizard. The wizard allows payroll officers to review and adapt the related leave allocation and wage before applying the change. Employee versions are automatically created when required. Existing allocation recomputation, wage update and version creation logic is preserved. To support this workflow: Added a custom widget on the employee Working Schedule field to trigger the wizard when the schedule changes. Reworked the wizard to focus on the Belgian paid time off use case. Added user notifications to clearly communicate the actions performed after validation. Impact: Provides a single and more intuitive workflow for working schedule changes. Prevents users from bypassing payroll-specific recomputations. Improves usability while preserving existing business behavior. Task: 6247606
Bill field suggestions now run more efficiently on databases with many accounting entries. This improves responsiveness when processing supplier bills, especially in Peppol workflows where product, account, and tax matching is used frequently.
Original PR description
### Description: Predicting fields can be slow when the database has a large amount of move lines (AML). This is caused by the fact that `_predicted_field` will search on all these AMLs to find the…
### Description: Predicting fields can be slow when the database has a large amount of move lines (AML). This is caused by the fact that `_predicted_field` will search on all these AMLs to find the ones related to the searched fields. It can be an issue when using Peppol since it is used a lot in most localizations to match each line to its product/account/tax. To speed up the queries, the move IDs have been inlined in `_build_predictive_query` to avoid suboptimal execution plans caused by LIMIT and ORDER BY clauses. Additionally, materialization of the `account_move_line` CTE has been removed so the planner can inline filters and stream rows directly, which improves performance in most use cases. ### Benchmark: **For a `history.limit`[^1] of 100:** | Nb of invoice line | Before | After | AMLs scanned | |--------------------|-----------|---------|--------------| | 33 | 7s | 4s | 232 | | 172 | 11.39min | 5min | 99859 | | 1934 | 3h+ [^2] | 1h40min | 102503 | **For a `history.limit`[^1] of 50:** | Nb of invoice line | Before | After | AMLs scanned | |--------------------|---------|---------|--------------| | 33 | 6s | 4s | 187 | | 172 | 2.52min | 1.27min | 21002 | | 1934 | 40min | 20min | 21002 | [^1]: System parameter `account.bill.predict.history.limit` [^2]: Stopped manually after 3h; full runtime not measured ### Reference: opw-5937519 Forward-Port-Of: odoo/enterprise#130242 Forward-Port-Of: odoo/enterprise#128172
Marketing Automation now includes a Templates area for saving, finding, and reusing favorite marketing emails. Users can create email activities from scratch or start from an existing template, making campaign setup faster and more consistent.
Original PR description
This commit includes the `mass_mailing`'s mailing **templates** in the `marketing_automation` app.
Do not trim the value silently when storing the value in cache. postgres already enforces the size when writing values, let it enforce that constraint. This avoids silently truncating the value. The size attribute is not deprecated as it is used for UI. https://github.com/odoo/enterprise/pull/130315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr