Wednesday, July 16, 2025
7 changes · master
Resolved issues and error corrections
Fixed an issue where editing a reusable Sign template could replace field labels with previously entered signer values. This prevents template corruption and ensures future documents show the correct field names.
Original PR description
## Steps to reproduce: - Create a document using a sign template. - Add a new field or modify the placeholder of an existing one. - Save the template. - Refresh the page. - Notice field labels are…
## Steps to reproduce: - Create a document using a sign template. - Add a new field or modify the placeholder of an existing one. - Save the template. - Refresh the page. - Notice field labels are replaced with previously entered values. ## Issue: After editing a template that has already been used in a signed document, the `name` of each sign item is unexpectedly replaced with the last value stored in the database for that item. This corrupts the template and results in incorrect names being shown when the template is reused. ## Cause: The issue occurs because the field name was being updated with the value last stored in the database for that particular sign item. As a result, the popover title was also showing that value instead of the original label. ## Solution: Updated the header_title variable to use type_id[1] (the item’s label) if available; otherwise, it falls back to the sign item's name. Initially, type_id[1] is not set, so the header shows the name. After refreshing the document, type_id[1] becomes available, and the header updates accordingly. --- task-4872963
Fixed an issue where Odoo could move on before a user had time to choose a printer for IoT-connected reception documents. This ensures reception reports and labels are sent to the selected printer reliably during warehouse receiving.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Validate the Reception of the order -> Result: Odoo will prompt the customer to select a printer, however we are not able to choose a printer in time as the process continues without selecting one. This in return does not send the report to the printer via IoT. The root cause of this bug is that the IoT report handler JS function returns too early, it resolves once the printer selection popup has appeared, instead of resolving once the printer has actually been selected and is starting to print. Therefore the multi-report printing code assumes the print is done and triggers the next print, which causes the popup to close before the user can select a printer. To solve this bug, we listen for a 'printer-selected' event in the handler, and resolve only once we have received this event. This fixes the flow, allowing a printer to be selected for each report that is being printed in sequence. opw-4790299 Forward-Port-Of: odoo/enterprise#89705 Forward-Port-Of: odoo/enterprise#88538
Odoo now includes previously depreciated amounts imported during migration when calculating asset depreciation totals and reports. This prevents depreciation boards and schedules from understating cumulative depreciation for assets moved from another accounting system.
Original PR description
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration).…
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration). This depreciation is recorded in each account when starting in Odoo(the original balances) and in Odoo creating Journal Entries are skipped for this imported depreciated amount. Example:- - Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020, Method: Straight Line, Duration: 10 Years, Computation: No Prorata. - Now according to our computation this asset will depreciate \$1000.00 for the years 2020 to 2029 each, and Journal Entries would be created on 31st December each year. - Now someone migrating from other software to Odoo in the year 2025 will put Depreciated Amount: \$5,000.00 . - Now Odoo will create Journal Entries for only years 2025 to 2029 and skip creating Journal Entries for the years 2020 to 2024 as these entries are created in previous accounting package and are recorded in original balances while migrating. Before this commit:- - In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported depreciated amount. - Depreciation Schedule report displays constant \$5,000.00 as depreciated value for the years 2020 to 2024. After this commit:- - In Depreciation Board, imported depreciated amount is added in Cumulative Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till \$10,000.00 for the year 2029. - In Depreciation Schedule Report, `_simulate_imported_depreciation` method will modify report values to simulated imported depreciation amount and skipped Journal Entries. task-4864528 Forward-Port-Of: odoo/enterprise#90214 Forward-Port-Of: odoo/enterprise#88127
Restores a missing receipt registration step for Belgian POS blackbox setups. This ensures kiosk sales send the required blackbox response back to the server, helping receipt processing stay compliant and reliable.
Original PR description
- In this commit (f5cea73183c0a25039b44e8a16341095431de029), the `registerReceiptWeb` action was removed from the `pos_blackbox_be` module. This action was useful to call `registerReceipt` and then call `send_blackbox_response`. - This commit restores the `registerReceiptWeb` action in the `BlackBoxDriver`, ensuring that when calling it, we send the blackbox response to the server (which is used for Kiosk flows). task-id: 4901299 Forward-Port-Of: odoo/enterprise#90263
Deleting bank statement lines after applying a reconciliation model now keeps the model available by restoring it to the suspense line. This prevents losing reconciliation setup during accounting corrections and also cleans up demo data to avoid duplicate model assignment.
Original PR description
Before this commit when applying a reco model, the reco model is on the lines of the move except the liquidity line which means that when we delete the lines the reco models is lost. Now when deleting a line, if the statement line had a reco model, we place it back on the suspense. Also correcting some demo data where they added the reconcile model on the liquidity but since the reco model will be added at the creation of the reco model, that's not needed. task: 4908501 Forward-Port-Of: odoo/enterprise#89147
Facebook removed support for the metric previously used to report stories activity, which caused reporting errors and made other statistics show as zero. This update removes that unavailable Facebook stories statistic so the remaining social media metrics can load correctly.
Original PR description
Bug === `page_content_activity` has been deprecated, so the API return an error and the other statistics are set to zero. https://developers.facebook.com/docs/pages-api/changelog Now, the only equivalent is `post_activity_by_action_type`, but it needs to be called on all posts, and it does not support periods (so even if we call it for each post, we won't be able to compute the trend). So we simply removed the `stories` statistics for Facebook. Task-4914555 Forward-Port-Of: odoo/enterprise#89524 Forward-Port-Of: odoo/enterprise#89230
This update fixes how AS days are calculated in Swiss payroll processing. It helps ensure payroll reports and related calculations reflect the correct number of days, reducing the risk of incorrect payroll data.
Original PR description
Forward-Port-Of: odoo/enterprise#90191 Forward-Port-Of: odoo/enterprise#90153