Tuesday, July 29, 2025
25 changes · saas-18.4
Enhancements to existing features
Website image hover effects are now supported in Odoo’s new HTML builder, keeping the editing experience consistent with the updated website tools. This helps users continue applying visual image effects while benefiting from the newer builder interface.
Original PR description
Convert the previous image hover effect to the new html builder. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Gelato now depends on the basic sales module instead of the full Sales Management app. This lets e-commerce users enable Gelato without installing an extra paid app, helping free-plan users avoid an unintended plan upgrade.
Original PR description
By changing the dependence from 'sale_management' to 'sale' module, Gelato can be installed on e-commerce without installing Sale app. Users on free plan won't be moved to paid plan after enabling Gelato module as no second app will be installed.
Task searches by name no longer include task IDs, avoiding a slow database search pattern on large task lists. This improves responsiveness for users working with many project tasks, especially during peak usage.
Original PR description
### Issue Slowness when searching for tasks in a database containing ~430K `project.task` records. ### Analysis When searching for tasks by name, the `id` field is passed to the filter domain. This results in a suboptimal query plan, as the `id` field is cast as `text` in an `OR` leaf: ` [...] AND ((unaccent((name)::text) ~~* '%test%'::text) OR ((id)::text ~~* '%test%'::text)) [...]` Furthermore, since refactoring the web routes, the necessity of searching for an `id` in the search form has greatly diminished. ### Benchmarks Benchmarking the generated query using `\timing` in `psql`: | Number of records | Before | After | | -- | -- | -- | | 430K | 2.3s | 3ms | During high-usage periods, the query took up to ~10.8 seconds. #### References opw-4845258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219959 Forward-Port-Of: odoo/odoo#219901
Tax period locks now also cover related closing entries and tax returns, preventing them from being reset while the period is locked. This helps preserve compliance controls by requiring users to manually adjust lock dates before making changes to locked returns.
Original PR description
Before the closing move was not included in the tax lock date and could be reset while being locked. Now we also lock the closing move. Same for the return, we lock the return if the period is locked. Before, when we wanted to reset the return, it would automatically revert the lock date. Now user should do it manually otherwise he will not be able to reset the return. task-4818752 Forward-Port-Of: odoo/enterprise#86305
Businesses in Türkiye can now export the General Ledger in the required e-Ledger CSV format for any selected period. The file is automatically packaged as a ZIP archive to support submission requirements from the Türkiye Revenue Administration.
Original PR description
This PR implements the necessary functionality for Türkiye’s e-Ledger reporting, as mandated by Türkiye law (Law No: 15570). Taxpayers that switched to e-Invoice/e-Archive are also required to submit their General Ledger (GL) in the e-Ledger format. Summary of the change This update enhances the existing Türkiye General Ledger report in the `l10n_tr_reports` module with the following features: - Adds the ability for users to generate the General Ledger as a CSV file, formatted according to the Türkiye e-Ledger requirements. - Allows export for any selected period, including relevant and filtered fields. - The generated CSV file is automatically compressed into a ZIP archive to comply with the GIB (Türkiye Revenue Administration) guidelines for file delivery. Task-4270136 Forward-Port-Of: odoo/enterprise#91054 Forward-Port-Of: odoo/enterprise#86592
Resolved issues and error corrections
Mobile users can now open subtasks in the main task view instead of a pop-up dialog. This makes the discussion area available, so teams can communicate with customers directly from the subtask.
Original PR description
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the…
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed. This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected. Steps to reproduce the issue: ---------------------------- 1. Install project and go to project app. 2. Create a project A. 3. Add a task inside the project A 4. Add a subtask inside the new task created in step 3 5. Open the form view of the task created in step 3 in mobile 6. Click on the kanban record contained the subtask created in step 4 Expected behavior: ----------------- The chatter should be displayed in the form view of that subtask to be able to communicate with the customer. Current behavior: ---------------- Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed. task-4278273 Forward-Port-Of: odoo/odoo#220814 Forward-Port-Of: odoo/odoo#200178
Fixes an issue where updating stock quantities for one company while logged into another could use the wrong product cost. This prevents incorrect inventory valuation entries and keeps product costs accurate in multi-company setups.
Original PR description
**Problem:** when updating quantity of a product in company A from a user logged in on company B the svl are created with wrong values and standard price is incorrectly updated **Steps to…
**Problem:** when updating quantity of a product in company A from a user logged in on company B the svl are created with wrong values and standard price is incorrectly updated **Steps to reproduce:** - check two companies on the top right of the screen (comp A and comp B) - create a storable product with a avco category - make sure that the cost method of the category is avco both when logged in with company A and B (the cost method is company dependent) - while logged in with comp A create, confirm, receive and validate a PO for a quantity of 1 and a unit price of 100 - do the same while logged in with comp B but with a unit price of 10 - open the product form (cost should be 100 or 10 depending on the company) - while logged in on comp B click on the 'on hand' smart button - update from 1 to 2 the on hand quantity in the WH of comp A - switch to comp A and come back to prodcut form **Current behavior:** the standard price is 55. additionaly, when opening inventory/reporting/valuation and chossing the product we see that the svl created has a value of 55 **Expected behavior:** standard price should stay at 100 and the svl should be created with a value of 100 **Cause of the issue:** Product_price_udpate_before_done calls get_price_unit to compute the new standard price. https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L345 Inside get_price_unit, because the move has no unit_price we use self.product_id.standard_price which will take the standard price of comp B https://github.com/odoo/odoo/blob/750265bac921936a7c29cf73f8f9e926eea4a926/addons/stock_account/models/stock_move.py#L59 opw-4852096 Forward-Port-Of: odoo/odoo#219549 Forward-Port-Of: odoo/odoo#217524
This fixes issues in the website builder where clearing a date option could leave the field blank after repeated use, and where some design options no longer fell back to their intended default styling. It helps website editors get immediate, predictable results when configuring dates, numbers, borders, navigation, animations, logos, and theme settings.
Original PR description
[FIX] html_builder: handle clear button in BuilderDateTimePicker When the `clear` button was used three consecutive times in the BuilderDateTimePicker, the input field would remain empty instead of…
[FIX] html_builder: handle clear button in BuilderDateTimePicker When the `clear` button was used three consecutive times in the BuilderDateTimePicker, the input field would remain empty instead of reverting to its previous value. This occurred because `useDomState` wasn't being triggered due to no state change. Additionally, this fix ensures that the input field now updates immediately upon using the `clear` button, eliminating the need for subsequent validation or clicking outside the DateTimePicker. Steps to reproduce: - Drop `s_countdown` snippet. - Open DateTimePicker with the "Due Date" option. - Click the clear button, then apply. - Repeat the previous step two more times (for a total of three times). - The input field remains empty instead of displaying the current date. ------------------------------------------------------------------------------------------------------- [FIX] html_builder, website: reintroduce null default for options This commit restores the previous behavior where `data-customize-website-variable="null"` was used to set a null default value for website options, ensuring that SCSS correctly applies its own default styles to elements. This functionality was lost during the website refactor [1]. Additionally, the `BuilderNumberInput` now defaults to 0, aligning with the previous default in `UnitUserValueWidget`. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This update brings the spreadsheet component to the latest 18.4.3 version and fixes several issues affecting spreadsheet editing and calculations. Users should see more reliable row sizing, cleaner pasted content, corrected formulas, and improved pivot behavior.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4b596d77d [REL] 18.4.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4b596d77d [REL] 18.4.3 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8e43be7a8 [FIX] header_sizes_ui: preserve row sizes on insert and move ops [Task: 4885579](https://www.odoo.com/odoo/2328/tasks/4885579) https://github.com/odoo/o-spreadsheet/commit/76a224263 [FIX] evaluation: test array formula invalidation [Task: 4954710](https://www.odoo.com/odoo/2328/tasks/4954710) https://github.com/odoo/o-spreadsheet/commit/a45061c1d [FIX] auto_complete: remove toggle button for data validation [Task: 4854464](https://www.odoo.com/odoo/2328/tasks/4854464) https://github.com/odoo/o-spreadsheet/commit/30a11dd57 [FIX] Composer: Remove formatting when pasting external content [Task: 4910559](https://www.odoo.com/odoo/2328/tasks/4910559) https://github.com/odoo/o-spreadsheet/commit/71ec7d472 [FIX] Formulas: `COLUMN/ROW` spread with range [Task: 4916369](https://www.odoo.com/odoo/2328/tasks/4916369) https://github.com/odoo/o-spreadsheet/commit/cea21be36 [FIX] spreadsheet_pivot: empty row when number added to char field [Task: 4878778](https://www.odoo.com/odoo/2328/tasks/4878778) 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: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@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>
Shipping connector settings no longer show installation checkboxes that pointed users to older connector modules. Users are now directed to the Apps menu to choose the appropriate carrier connector, with clearer labeling for newer REST API versions and legacy options hidden by default.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218487 Forward-Port-Of: odoo/odoo#201583
This update makes removing website building blocks more consistent and reliable in the website editor. It reduces duplicated logic and helps prevent protected elements from being removed accidentally, improving editor stability for users.
Original PR description
This commit improves the code of the `remove` plugin: - Rename the `on_remove_handlers` and `after_remove_handlers` resources as `on_will_remove_handlers` and `on_removed_handlers` respectively, to…
This commit improves the code of the `remove` plugin: - Rename the `on_remove_handlers` and `after_remove_handlers` resources as `on_will_remove_handlers` and `on_removed_handlers` respectively, to be more consistent. - Adds a `is_unremovable_selector` resource in order to use it to get the selectors of the elements that are unremovable. It allows to have the resources in the different option plugins, instead of duplicating these selectors in multiple files. - Merge back the behaviors of `removeElementAndUpdateContainers` and `removeElement` as it was not correct to split them and in order to have only one main `removeElement` function. Its goal was to replace the old `remove_snippet` event, and it was clearly not used everywhere. - Remove the use of the `remove` plugin where only the JS element `remove` function was needed. We know if a given case needs to activate the parents/siblings and there are other ways to activate them anyway. - Use the `remove` plugin when this time it was necessary (e.g. when a "Table of Content" is empty). - Clean the code. task-4367641
This fixes cases where website pages and partner-related records could show a Publish button even when publishing was not actually allowed. The change makes publishing permissions more accurately calculated, reducing confusing access warnings for users managing website content.
Original PR description
*: website_crm_partner_assign, website_customer, website_membership, website_partner Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the…
*: website_crm_partner_assign, website_customer, website_membership, website_partner Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written. This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions. It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning). [1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550 [2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da [3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c Related to runbot-161791 Forward-Port-Of: odoo/odoo#220424 Forward-Port-Of: odoo/odoo#219389
Fixed an issue in Point of Sale loyalty programs where customers with existing points could still claim a reward after the program's maximum usage limit had already been reached in the session. This helps ensure promotions are applied fairly and according to configured limits.
Original PR description
When an existing partner with points tries to claim a reward from a loyalty program that has reached its max usage in the current session, he was still able to claim the reward. Steps to reproduce: ------------------- * Create a loyalty program with max usage set to 1 * Create a partner and assign points to him * Open PoS and select any partner and make an order * Claim the reward from the loyalty program * Select the partner that already has points * Make an order and try to claim the reward again > Observation: The reward can be claimed, even though the max usage is already reached. Why the fix: ------------ When updating programs, we were not removing the couponPointChanges for programs that are not applicable anymore. We now make sure to delete them when the program is not applicable anymore. opw-4805704 Forward-Port-Of: odoo/odoo#220658 Forward-Port-Of: odoo/odoo#218425
Fixes purchase orders billed in a foreign currency before goods are received so invoice amounts reflect the full ordered quantity, not just one unit. It also prevents small unwanted exchange differences from being created when the receipt is later validated, improving accounting accuracy.
Original PR description
**Current behavior:** Creating a purchase order in a foreign currency and billing the product prior to reception will produce 2 issues: A) The bill line for the product will only make a conversion of…
**Current behavior:** Creating a purchase order in a foreign currency and billing the product prior to reception will produce 2 issues: A) The bill line for the product will only make a conversion of 1 single unit of the product with the defined currency exchange rate, making the amount on the line incorrect when qty > 1 B) When the receipt is finally validated, there will be an unwanted exchange difference on the journal items generated due to asymmetrical rounding for the bill AMLs and receipt valuation AMLs **Expected behavior:** Correct bill line currency amounts and symmetric rounding. **Steps to reproduce:** 1. Set the company currenct to IQD, make a product invoiced on ordered qty, for sake of example set cost to 500 IQD 2. Create a currency exchange record to USD with a company rate of `0.00756` 3. Create a PO for 13 of the product created in step 1, with a discount of 1% 4. Confirm the PO and create the bill -> post it * Issue A) look at invoice line, see only 1 unit in the converted currency amount is accounted for by the `balance` 5) Receive the product -> look at the journal items generated and see that there is a diff of 0.185 IQD **Cause of the issue:** A) commit: 90158f6 added a method to try and calculate an AML balance from its purchase line values, but mistakenly is using `qty_received` instead of `qty_to_invoice` which explains why this issue only presents for the bill-before-receipt flow B) commit: 9f046d5 is using `round=False` context for `AccountTax.compute_all()` when the expected key is `round_base` **Fix:** A) Replace `qty_received or 1` with `qty_to_invoice` * Also make the test added in 90158f6 more robust B) Add `round_base=False` alongside the `round` key (not removing as that existing one could have become expected in this context) opw-4689170 Forward-Port-Of: odoo/odoo#220323 Forward-Port-Of: odoo/odoo#205850
Online paid self-ordering sales now appear correctly in the POS ticket list. Staff will see paid orders marked as paid and offered the refund action instead of being prompted to load them again.
Original PR description
**Steps:** - Configure POS with self-ordering via QR code and online payment. - Open a session and place a paid order through self-ordering. - In the POS UI, open the TicketScreen and apply the "Paid Orders" filter. **Issues:** - The paid order does not show the "Paid" tag. - The "Load Order" button appears instead of the "Refund" button. **Cause:** - The paid order retains an outdated uiState, with `uiState.locked` incorrectly set to false. **Fix:** - Use `finalized` instead of `uiState.locked` to determine order state on TicketScreen. - Remove the unused `locked` property from `uiState` in posOrder. Task: 4745869 Related: odoo/enterprise#86684 Forward-Port-Of: odoo/odoo#220729 Forward-Port-Of: odoo/odoo#207406
Sales commission achievement reports now include down payments and other invoice lines that do not have a product attached. This prevents mismatches between invoice analysis and commission results, especially for plans expected to match invoiced amounts.
Original PR description
In the sale achievement report, down payments and other account move lines that have no product attached to them would not be accounted for in the sale commission achievement report. This was due to the fact that the table was being inner joined on product_id which would get rid of records that had no product. Because of this behavior there would be a mismatch between the invoice analysis of a user and their commission even if the rate was 100% on the commission plan. Left joining the products onto the account move line keeps the lines with no products and fixes the discrepancy between the report and the invoice analysis. opw-4625340 Forward-Port-Of: odoo/enterprise#91010 Forward-Port-Of: odoo/enterprise#83477
Users working across multiple companies can now send signature templates from the company they are currently using. This prevents an access error that blocked signature requests when the template was linked to a different default company.
Original PR description
Problem: In a multi-company environment, users are unable to send templates in non-default companies despite them creating the template. A traceback gets thrown because the template is using the…
Problem: In a multi-company environment,
users are unable to send templates in non-default
companies despite them creating the template.
A traceback gets thrown because the template
is using the default company on the create user,
instead of the current environment's company.
Purpose: The user should be able to send templates they created in any allowed companies.
Steps to Reproduce on Runbot:
[ADMIN]
1. Install Sign
2. Navigate to Settings > Sign > Enable "Sign Default Terms & Conditions"
3. Create another company and allow Marc Demo access
[Marc Demo]
1. Change to a non-default company
2. Try to send a signature request (e.g. upload pdf to sign > send)
3. Traceback gets thrown
```
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/mylynahy/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/home/mylynahy/src/odoo/odoo/api.py", line 1020, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'res.company(2,).sign_terms_type'
During handling of the above exception, another exception occurred:
...
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
AccessError: Due to security restrictions, you are not allowed to access 'Companies' (res.company) records.
Records: BE Company CoA (id=2)
User: Marc Demo (id=6)
This restriction is due to the following rules:
- company rule employee
Note: this might be a multi-company issue.
Contact your administrator to request access if necessary.
Template: sign.sign_template_mail_request
Path: /t/table/tr[5]/t[1]/td/a
Node: <a t-att-href="\'%s/sign/terms\' % record.get_base_url()" class="text-dark"/>
```
opw-4706828
Forward-Port-Of: odoo/enterprise#85402Creating a helpdesk ticket from the timesheet timer now keeps the selected support project context, preventing validation errors about missing analytic accounts. The timer also correctly recognizes helpdesk projects even before they have existing tickets, so users see the ticket option instead of a task option.
Original PR description
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket…
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket Issue: ------ 1. Validation error raised: `At least one analytic account must be set.` 2. When we select a helpdesk project that does not have any ticket linked to it already, the field next to it is set to `Task` (task_id) instead of `Ticket` (helpdesk_ticket_id). Cause: ------ 1. When creating the ticket, we don't provide the default project who got the analytic account linked to it. 2. The field `helpdesk_ticket_id` is hidden because we consider that we the project is not linked to any helpdesk team; this is because we retrieve the projects based on tickets already created only. Solution: --------- 1. Set the default project in the context when creating the ticket (like for a task). In the create method, if no team is provided and we have a default project (from `list_value` or the `env.context`), we set the team based on the project if the project is linked to a helpdesk team. 2. Fetch all projects that have `helpdesk_team` field set. opw-4404097 Forward-Port-Of: odoo/enterprise#91110 Forward-Port-Of: odoo/enterprise#76779
Credit card payments in the Italian POS are now assigned the correct default index for fiscal printers. This prevents valid card payments from being incorrectly reported as not paid on Italian fiscal receipts.
Original PR description
In Italy if a payment method is of type 'Credit card' (type 2), and it's index is 0 the payment made with it is considered as 'Not paid' by the italian fiscal printer. Why the fix: ------------ We change the default index of the payment method to 1, so that it is considered as 'Paid' by the fiscal printer. opw-4963421 Forward-Port-Of: odoo/enterprise#90919
Rental orders with multiple planned service lines now check staff or resource availability before creating planning shifts. This prevents the same resource from being assigned to overlapping shifts and creates an open shift when no resource is available, reducing scheduling conflicts.
Original PR description
Steps to Reproduce: ---------------------- - Install the sale_renting_planning module. - Create a rental service product with `Plan Services` enabled. - Create a rental order with multiple lines for the same product. - Confirm the rental order Issue: --------------------------- - You'll see that some generated shifts are assigned to same resource causing conflict. Cause: --------------------------- - Shifts are being generated at the same time for all the SOL which cause them to be assigned to the same resource and make conflict. Fix: ----------------------------- - In this commit when the shift values are generated we will check if the resources are available or not. If no resource is available then it will create open shift for that SOL. task-4829807 Forward-Port-Of: odoo/enterprise#88767
Shipping settings no longer show install checkboxes that pointed users to older connector versions. Users are now directed to the Apps menu to choose the right shipping connector, with clearer labels for the newer REST API versions and legacy connectors hidden by default.
Original PR description
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. Forward-Port-Of: odoo/enterprise#90010 Forward-Port-Of: odoo/enterprise#81354
Bank reconciliation now handles models using a different currency correctly, so foreign currency amounts and company-currency balances are no longer treated as the same value. The receivable and payable actions also avoid creating automatic reconciliation models unexpectedly, reducing unintended accounting setup changes.
Original PR description
Before this commit when applying a reco model with a different currency, the amount currency and the balance were equals. task-4931177 Before this commit when applying the receivable or payable button, the automatic reco models would be created. We don't want that behavior task-4930730 Forward-Port-Of: odoo/enterprise#89775
Fixes errors that could block customers using invitation links during appointment booking. Users can now move back to the date/time or meeting selection steps without seeing server or access errors when multiple resources are available.
Original PR description
Fixes two issues regarding the buttons on the front-end progress bar in the appointment flow, when using an invitation link. Commit messages give steps to reproduce.
1. Fix 500 error when clicking 'Date & time' with more than one resource / user configured on the invitation link.
2. Fix 403 error when using the operator ('meeting' actually) step button with more than one specific resource in the invitation link.
Task-4897098
Forward-Port-Of: odoo/enterprise#90335
Forward-Port-Of: odoo/enterprise#88521This fixes a setup gap where the VAT return journal could be missing when accounting reports or accountant features were installed after accounting was already configured. Businesses get more reliable VAT return preparation, with the journal created only when appropriate to avoid unnecessary clutter for invoicing-only users.
Original PR description
Issue: The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created. Solution: Create it in the post init hook. Note that…
Issue: The VAT return journal is not created when installing `account_reports` (or `accountant`) after `account`, when the CoA is already created. Solution: Create it in the post init hook. Note that we force the creation of the journal only when `accountant` is installed because it would make noise for invoicing only in most cases. It will still be created automatically when needed. Also, make the code a little bit more robust: * instead of mixing "default misc journal" and vat return journal logic, just use one logic * the function `_get_tax_closing_journal` could return multiple journals but was always used as if it could only contain one * the function `_get_tax_closing_journal` could not return any journal. Instead, we now create the journal or look for a value on the parent companies if any. * Manage `show_on_dashboard` in `create` also by using an inverse field. Even if in normal cases the journal will always be created after the company the thus set through `write`, it is not impossible to set it in `create` when creating company branches. Since it is always done when setting the journal on the company, there is no need to set the field in the post-init hook. Forward-Port-Of: odoo/enterprise#91126
WhatsApp debug logging now handles file replies safely instead of trying to save raw file content as text. This prevents crashes when customers reply with PDFs, images, or other files while request debugging is enabled.
Original PR description
When Debug requests is enable on the whatsapp business account and user replies with the file, a traceback will appear. Steps to reproduce the error: - Install ``whatsapp`` and ``contacts`` - Create…
When Debug requests is enable on the whatsapp business account and user replies with the file, a traceback will appear. Steps to reproduce the error: - Install ``whatsapp`` and ``contacts`` - Create a whatsapp business account > Enable Debug requests - Create a contact > Add a phone number > send whatsapp message with any whatsapp template - Now reply with the file(ex. pdf or image) in message from the contact's whatsapp. - Traceback in terminal Traceback: ``ValueError: A string literal cannot contain NUL (0x00) characters.`` https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/models/whatsapp_account.py#L166 Here, ``message`` contains NUL (0x00) characters because user replies with the file, value for the ``message`` comes from the below response. response: https://github.com/odoo/enterprise/blob/b52a93da7d680b60646cb08a9126cf6c12f5307d/whatsapp/tools/whatsapp_api.py#L49-L57 Here, ``res.text`` contains NUL (0x00) characters. So, it will lead to the above traceback. sentry-6314521165 Forward-Port-Of: odoo/enterprise#91055 Forward-Port-Of: odoo/enterprise#83274