Wednesday, July 16, 2025
36 changes
18 changes
Resolved issues and error corrections
This fix ensures a company's currency cannot be changed once accounting entries exist, even when a user has switched to another company. It protects financial records from accidental inconsistencies across companies.
Original PR description
To_reproduce: ============== 1- switch company. 2- update any other company currency that has journal items. 3- company currency changed. Problem: ========= - When switching companies, users could update the other company's currency even when journal items existed for that company. Solution: Solution: ========= - Added .sudo() to the account.move.line search to bypass access rights and properly detect existing journal items in that company. opw-4920206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219063 Forward-Port-Of: odoo/odoo#217929
Point of Sale orders now correctly use the default price list and fiscal position when a preset does not define its own. This prevents orders from missing expected pricing or tax settings, reducing manual corrections and improving checkout consistency.
Original PR description
Before this commit, if the pricelist or fiscal position was not explicitly set on a preset, the order would not inherit the default values defined in the PoS config. This fix ensures that the system now correctly falls back to using the default pricelist and fiscal position from the PoS configuration when they are not specified on the preset. opw-4913400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217112
This fix prevents multiple Point of Sale sessions from being opened when the start request is delayed. It helps avoid duplicated cash opening records and related cash closing inconsistencies.
Original PR description
Before this commit, if request to open the PoS would take a bit of time there was possibility to have more than one session created. This issue would cause several issues, like incorrect opening and closing cash record as 2 sessions would be created with the same opening cash. To prevent this issue this commit adds a lock. opw-4890965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217288
This fixes an issue in Point of Sale where special products could no longer be found through search or category filtering. Staff can now locate and sell these products as expected, reducing checkout friction and product visibility problems.
Original PR description
After commit https://github.com/odoo/odoo/commit/2668181c98de4a9c6f33787372adefc01cf1d0bc, it was no longer possible to locate special products via the search function. Additionally, if these products belonged to a specific category, they would not be visible when filtering by that category. opw-4925867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217898
Turkish Nilvera e-invoices now place subscription billing period dates at the document level, matching the required UBL TR format. If subscription lines in the same invoice have different start or end dates, users are warned and sending/printing is blocked to prevent invalid e-invoices.
Original PR description
The UBL TR 1.2.1 format does not support \<InvoicePeriod\> element in invoice lines in the XML generated for e-invoice. This commit moves the \<InvoicePeriod\> element from invoice lines to document level. It also validates that the start and end dates of all subscription invoice lines in one invoice should be same, or else it shows warning and disables the `Send & Print` wizard button TaskId:4885865 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218820 Forward-Port-Of: odoo/odoo#215819
The website editor's image transformation controls now work reliably again, including resizing, rotating, active-state display, and closing the transform box. This improves the editing experience for website builders and prevents errors when adjusting images.
Original PR description
Description of the issue/feature this PR addresses: Fixed the working of the "Transform Image" button in website builder. Current behavior before PR: The button was non-functional due to an undefined "trasnformImage" user command. Desired behavior after PR is merged: The button works as as expected. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from sending unnecessary invitation, update, or reminder emails for calendar events that have already ended. For events synced with Google or Microsoft calendars, it also ensures the external calendar handles reminders so users do not receive duplicate notifications.
Original PR description
Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. Recently, we had to revert the two original PRs due to an emergency at odoo/odoo#215449. The issue got solved, so we're adding this fix back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-4684432, 4316693 Forward-Port-Of: odoo/odoo#219157 Forward-Port-Of: odoo/odoo#219060
Fixes an issue where the project creation dialog could remain stuck open after creating a new project. Users can now complete project creation and move into the new project's task view without being blocked by an unclosable popup.
Original PR description
- Open a Project; - Create a new project; Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and…
- Open a Project; - Create a new project; Before this commit, the dialog that allows you to create a new project would sometimes stay open and could not be closed. This occurs because, since [1] and especially [2], we waited for the view to reload before closing the dialog. However, while the view was reloading, it was destroyed and replaced by the Kanban view of the tasks of the new project. This meant that the reload promise was never resolved. Consequently, the code that actually closes the dialog [3] was never reached, as `await onClose?.(closeParams)` was never resolved. [1] https://github.com/odoo/odoo/pull/202512 [2] [d606be7](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686) [3] [d606be7#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318](https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318) opw-4880968 Forward-Port-Of: odoo/odoo#219065 Forward-Port-Of: odoo/odoo#218988
Sales orders containing kit products with repeated components can now be canceled and confirmed again without causing an error. This helps sales and warehouse teams avoid interruptions when revising or reprocessing kit orders.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/pull/207955
Steps to reproduce the bug:
- Create a kit product:
- BoM:
- Components:
- 1 unit of C1
- 1 unit of C1 (same product)
- Create a SO with one unit of kit
- Confirm the SO
- The delivery is created
- Cancel the SO → the delivery is canceled.
- Set the SO back to quotation and confirm again
Problem:
A traceback is triggered:
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: mrp.bom.line(24, 25)
When a kit's BoM contains the same product multiple times, multiple bom_line_ids match a given move. Assigning them causes an error. Additionally, cancelled moves were incorrectly considered.
Solution:
Filter out cancelled stock moves before accessing the bom_line_id to ensure only active moves are considered.
opw-4919875
Forward-Port-Of: odoo/odoo#218476
Forward-Port-Of: odoo/odoo#218187When a purchase order linked to a sales delivery is cancelled, the delivery can now use stock already on hand instead of staying blocked. This helps orders continue smoothly when purchased replenishment is no longer expected but inventory is available.
Original PR description
Steps to reproduce the bug:
- Unarchive the MTO route
- Create a product P1:
- Type: Storable
- Route: MTO
- Supplier: Vendor A
- Create a sales order for 1 unit of P1
- Confirm the SO
→ A purchase order is created for Vendor A with 1 unit of P1
- Cancel the PO
- Update the quantity on hand of P1 to 1
- Go to the delivery picking of the SO
- Check availability
Problem:
The quantity on hand is not taken into account, and the picking remains
in the "Waiting Availability" state.
When the purchase order is cancelled, the stock move should switch to
MTS instead of remaining in MTO.
opw-[4876611](https://www.odoo.com/web#id=4876611&view_type=form&model=project.task)
opw-[4874199](https://www.odoo.com/web#id=4874199&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#218365
Forward-Port-Of: odoo/odoo#214785Fixes an issue in Project reporting where clicking chart bars after grouping by tasks could fail because report-only filters were sent to the task view. The system now removes incompatible filter fields before opening the detailed task view, making report drill-downs more dependable for users.
Original PR description
Step to reproduce - Go to Project - Go to Reporting > Task Analysis - Group by Tasks (not Task) - Click on any of the blue bars Issue: since odoo/odoo@c36ad1896 we now allow user to drill down to base model from report view, this causes issue when a field which is present in report model but not in base/main model. For now we directly pass the domain created for report view to base model. FIx: we only open the view, when the such fields are not present in domain opw-4798353 related : https://github.com/odoo/enterprise/pull/88356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215167
Website footer updates now handle expected formatting issues without hiding serious database conflicts. This helps prevent failed update processes and allows automatic retry handling when concurrent edits happen.
Original PR description
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update…
Updating website footer views sometimes fails with "could not serialize access due to concurrent update" errors due to concurrent database writes, causing transaction aborts and breaking the update process. Error: `InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block` The issue arises because the exception block at [1] catches and silently suppresses all exceptions, including critical `serialization errors`. These serialization errors cause the current database transaction to fail. However, since the exception is caught and not properly handled or propagated, execution continues within the context of the failed transaction. As a result, subsequent operations fail with an `InFailedSqlTransaction` error. This commit addresses the issue by specifically handling the `etree.XMLSyntaxError` raised by `etree.fromstring(view_id.arch_db)`. The error is safely caught and logged with an appropriate message. Additionally, it adds logging when the `configurator_footer_links` element is not found in the view and prevents further execution in that case. All other exceptions, including database-related errors, are no longer caught at this level; instead, they are allowed to propagate and are handled at the request level, where automatic retries are triggered. handled at the request level, where automatic retries are triggered. [1]:- https://github.com/odoo/odoo/blob/5cc57cc0ca8ee17060905b692727ed965e197f61/addons/website/models/website.py#L722-L725 sentry-5665538920 Forward-Port-Of: odoo/odoo#210103
Submitting the UAE VAT201 tax return no longer triggers an error caused by using the wrong report calculation. This helps businesses complete VAT filings reliably without being blocked by a system traceback.
Original PR description
When submitting a tax return for the basic AE tax report (VAT201 Form), a traceback was being thrown. The issue arose because the report was considered to be the Corporate Tax report instead of the VAT201, and was trying to apply some incompatible computation. task-4935937
This fix corrects how accident or sickness-related days are calculated in Swiss payroll reporting. It helps ensure payroll declarations use accurate day counts, reducing the risk of incorrect employee payroll data being submitted.
Original PR description
Forward-Port-Of: odoo/enterprise#90191 Forward-Port-Of: odoo/enterprise#90153
Salary configuration and offer flows now save personal details such as address and marital status on the correct contract version record. This prevents employee offer data from being stored in the wrong place after the contract version model change, improving accuracy for HR and Belgian payroll processes.
Original PR description
With the change from the contract to the version model, more adaptation was required for the salary configuration and the offer management. Before that change, the personal info were always written on the employee model. But now, some of the personal information (like the address or the marital status) need to be written on the new version. This commit fixes the issue by adding support to directly write the version fields of the salary configurator on the new version. task-4933745
Signing and counter-signing a job offer now assigns the correct current contract salary version to the newly created employee. This prevents archived versions from being selected by mistake, helping HR records remain accurate after recruitment offers are completed.
Original PR description
When signing an offer, an employee and a version are generated. Some methods of the controller are using the active_test context, but without resetting to its default value. This was causing some issue when creating or computing field of the versions. For example the current_version_id was computed to be an archive version, which is wrong. This commit fixes the issue by resetting the active_test context to its default value. The new version is also unarchived before archiving the old version to not trigger the version constraint about the active field. Steps to reproduce: - Create a job position and a candidate in recruitement. - Generate an offer for the candidate. - Sign and counter-sign. - The current version on the newly created employee is wrong. task-4926361
Deleting bank statement lines after applying a reconciliation model now keeps the model available by restoring it to the suspense line. This prevents users from losing reconciliation setup during corrections and keeps bank reconciliation workflows consistent.
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 calculate stories activity, which caused reporting errors and could make other statistics show as zero. This update removes that unavailable Facebook stories statistic so the remaining social media metrics continue to work reliably.
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
3 changes
Resolved issues and error corrections
When a Sign template layout is reused on a new document, grouped radio buttons now remain connected. This keeps single-choice fields working as expected for signers and avoids broken form behavior after applying a template layout.
Original PR description
If applied, this commit will make so that when a user uses the layout of a template document on a new document, the radio buttons will stay linked.…
7 changes
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…
8 changes
Resolved issues and error corrections
This change ensures Odoo respects the setting that prevents missing standard records from being recreated during accounting setup or upgrades. It helps avoid upgrade failures and incomplete tax group records with missing account information, especially in localization scenarios such as Pakistan.
Original PR description
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be…
If applied, this commit will make so that when a user uses the layout of a template document on a new document, the radio buttons will stay linked. _____________________________________________________ Using the layout of a template document, containing radio buttons, on a new document will unlink radio buttons, making them useless. 1. Go to the Sign module, and click on the Templates tab. 2. Click on the "Upload PDF" purple button, and upload a PDF of your choice. 3. On the left side of the screen, there's a panel where we can drag and drop sign items. Drag and drop a Radio button. 2 buttons will automatically show, and a yellow link will appear between the buttons. This link indicates that, when a user opens the document to sign, when clicking on a radio button, the other one will automatically be unselected if previously selected. 4. Save and return to the Templates window. 5. A new row has appeared with the name of the document. On the right side of this row, hover the house next to the share button and click on the 3 dots. Then, click on Use Layout. 6. Upload a PDF of your choice. 7. When the PDF shows, there's no yellow link between the radio buttons, unlike on the template from which the layout was used. In the file sign/models/sign_document.py, in the method _copy_sign_items_to(self, new_document), we copy every sign item from the template to the new document. However, the copy method we call doesn't take into consideration the special link between radio buttons, replicating the buttons correctly but not the link. This link is expressed by the radio set to which the radio buttons belong: indeed, after the copy of sign items, each radio button belongs to a different radio set, separating them. ### Explanation of the fix The fix consists of a rework of the _copy_sign_items_to method and a brand-new method specifically used to copy radio buttons. To keep the link between them, we assign all the buttons of the same set on the original documents to the same brand new radio set. The first button is copied normally: this creates a new radio set. Then, for the remaining buttons, we call copy_radio_item, to which we pass the button created first to use the information the next buttons will share with it. ______________________________________________________________ opw-4842590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how accident-related salary days are calculated in Swiss payroll. It helps ensure payroll reports and employee compensation figures are accurate, reducing the risk of incorrect payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#90191 Forward-Port-Of: odoo/enterprise#90153
Facebook deprecated the data source used for the stories activity metric, which caused API errors and made other statistics show as zero. This update removes that unavailable Facebook stories statistic so remaining social dashboard metrics can load reliably.
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
## 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
**Description** - The `force_create` attribute was added to `try_loading` in odoo/odoo@a3c57b4f0198236b04486d336d56b25de74677b8 allowing control over whether missing standard records should be created. However, this wasn't respected for `account.tax.group`. As a result, tax groups could still be created even when `force_create=False`, leading to null values in accounts fields like `tax_payable_account_id` and `tax_receivable_account_id`. **The issue which prompted this patch:** - A recent patch in upgrade: odoo/upgrade@d2d16a2321abb525fe3fe2c403f89009f51c1394 This patch was made to update the `reconcile` and `non_trade` flags on standard accounts due to recent changes across localizations. During the upgrade, we overrode the `write` method of `account.tax.group` to conditionally update these flags. However, in a client’s database, `account.tax.group` records were missing for the `l10n_pk` module, while the standard account records were present. When `try_loading` was triggered at the end, it attempted to `create` the missing tax groups. But since the create method is called during creation and does not include the conditional update logic for `reconcile` and `non_trade` the upgrade failed with the same error that the original patch aimed to resolve. - To avoid such errors and prevent tax groups from being created with null account fields when `force_create=False`, this patch ensures `force_create` is respected for `account.tax.group`. **Steps to reproduce:** - Create a `v17` DB and install `l10n_pk` - Delete the standard tax groups - Upgrade to `v18` OPW-4915394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where point of sale sessions with a payment difference could generate incorrect accounting entries. Payment amounts now remain accurate, helping businesses keep reliable sales and reconciliation records.
Original PR description
When a payment difference was created in the PoS, it was introducing errors in the accounting entries. Steps to reproduce: ------------------- * Make sure bank payment method has an outstanding account * Open PoS and make a sale paid by bank for 100$ * Close the session and introduce a payment difference of -10$ * Check the accounting entries created for the PoS session > Observation: The difference is correctly recorded but the payment appears as a payment of 80$ instead of 90$. Why the fix: ------------ We revert this fix (https://github.com/odoo/odoo/pull/196253) that was wrongly modifying the payment amount to fix the session report. opw-4723227
This fixes a calendar issue where privacy-related filtering could use the wrong kind of internal data, causing event visibility rules to break in some cases. Calendar privacy checks now receive the expected list of users, helping ensure events are shown or hidden correctly.
Original PR description
Using `_search()` was returning a query object, which broke the domain logic when checking `user_id.res_users_settings_id`. Replaced with `search(...).ids` to ensure a proper list of IDs is passed. `_get_default_privacy_domain` timing: before is always the same since it doesn't execute the sql query | Number of users | Before PR | After PR | |:------------------:|:-----------:|:--------:| | 10k | 0.1 ms | 8 ms | | 30k | 0.1 ms | 14 ms | | 50k | 0.1 ms | 20 ms | | 70k | 0.1 ms | 28 ms | | 90k | 0.1 ms | 35 ms | opw-4841266 bug introduced in:[#5f55544][1] [1]:https://github.com/odoo/odoo/commit/5f5554460c61d3e715e71dd7c946b77083411ae7
Survey questions that require a numerical answer now properly reject text or incomplete number entries across browsers. This prevents invalid responses from being mistakenly treated as skipped questions, improving answer accuracy and respondent guidance.
Original PR description
_______________________________________ ## Short functional explanation of the error On a survey, when answering a question that requires only a numerical answer, there's a different behavior…
_______________________________________ ## Short functional explanation of the error On a survey, when answering a question that requires only a numerical answer, there's a different behavior observed based on the navigator used: 1. On chrome, characters other than numerical characters are rejected, except 'e' (for scientific notation). This causes a problem if the answer simply consists of 'e' and not an actual scientific number. 2. On firefox, every character is accepted. This causes the answer to be set as "skipped" instead of registering a result. ## Reproduction Steps 1. Go to the survey module. 2. Click on new. Add a title, Click on the 'survey' radio button and add a question. 3. Set a title and the type of the question to Numerical value. 4. Click on share and copy the link obtained. 5. Open a new incognito window and paste the link in it. 6. Start the survey and, if you're on chrome, enter 'e'; if you're on firefox, enter anything except a normal number. Then, hit submit. ### Expected behavior The answer shouldn't be submitted, and a red message saying "This is not a number" should appear. ### Unexpected behavior The answer is accepted, and when reviewing your answers, you'll see that the question has been skipped. ## Origin of the issue In the corresponding XML, the input type has been set to numerical. However, in that case, Chrome sets restrictions for writable characters but still accepts the 'e' character for scientific notations. However, if only the 'e' character is entered, when clicking on submit, nothing is sent as an answer. On Firefox, the issue is similar: nothing is sent except if the answer is a well formatted number, but there are no restrictions on what users can enter. As nothing is sent, the answer is considered as skipped. Note: if you setup the question as mandatory, only entering 'e' on Chrome or random characters on firefox will trigger the error message 'This question requires an answer.' _________________________________________ opw-4883341 --- --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
IoT boxes now keep their existing drivers when a driver download fails or returns an invalid file. This prevents devices from losing working handlers when the connected database is unavailable, improving reliability for IoT operations.
Original PR description
Before this commit, if the IoT box was connected a DB which then went offline (e.g. expired runbot), and it tried to download drivers, the request would fail but it would still delete the old handlers. After this commit, we avoid this problem in two ways. Firstly, we check that we received an OK HTTP status before trying to process the response body. Secondly, we check that the reponse we have received is a valid zip file BEFORE deleting the old handlers. This way we only delete them if we are sure we have something to replace them with. task-4933638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218163
Mercado Pago payments that return a processing status are now treated as still in progress rather than failed. This prevents unnecessary “unknown payment status” errors at the point of sale and lets the normal retry flow continue until the payment is confirmed.
Original PR description
The Mercado Pago 'PROCESSING' payment status was not handled. As a result, when receiving this status, the payment was treated as failed and the user saw an 'Unknown payment status' message. This fix treats 'PROCESSING' as an in-progress state, just like 'OPEN' and 'ON_TERMINAL'. It triggers the same retry mechanism. opw-4918455 Forward-Port-Of: odoo/odoo#218990
Vendor bills using the Saudi 15% reverse charge tax now create the expected reverse charge accounting entry. This ensures the tax amount is reflected in the correct account and appears properly on the VAT filing report.
Original PR description
Steps to reproduce: - With a SA Company setup - Create a Vendor Bill - Add a Service product and apply 15% R C tax - Confirm Issue: The reverse charge account is not hit by the tax amount, no reverse charge entry is created and it does not show on the VAT filling report opw-4755993 Forward-Port-Of: odoo/odoo#218897 Forward-Port-Of: odoo/odoo#217384
This fix prevents appointment pages from breaking after users add slideshow content to an appointment description with the website editor. It keeps the page editable and allows richer description content such as forms or slideshow navigation controls.
Original PR description
Scenario: - in 18.0, insert a slideshow in the appointment.type().message_intro with the website editor - reload the page Result: a traceback is shown, the page becomes not editable Cause: the appointment.type().message_intro field is sanitize_form=True which removes the button used to navigate in the slideshow, this itself causes a JS error (that expects to have the buttons). Fix: several fixes are being investigated, one of which is allowing button even if sanitize_form=False is set, but meanwhile the issue is still happening for that particular case. This PR proposes to allow form tags in the field message_intro so people could add form in it or not have an error when inserting a slideshow. opw-4844700 __PR note:__ a general solution is proposed in `https://github.com/odoo/odoo/pull/215445` but it's not sure when and if it will be merged, so this PR proposes just handling the particular case of this ticket.