Search
Navigate
Branch
Monday, May 27, 2024
71 changes
15 changes
Resolved issues and error corrections
This change prevents an error when staff open the restaurant Mobile View after a register has been closed and there are no active orders. It keeps the self-ordering page accessible instead of triggering a backend failure, improving reliability for restaurant operations.
Original PR description
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the…
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the ``pos_restaurant`` and ``point_of_sale`` modules - Make sure there are no active orders in the restaurant - Dashboard > Open Register > Open session > Close Register - Dashboard > Restaurant > Dropdown Menu > Mobile View - An Error will be generated in the terminal Traceback : ``ValueError: bus.Bus only string channels are allowed.`` This situation arises because we have two self-ordering modes: i) ``Mobile`` and ii) ``kiosk``. When the condition at [1] is evaluated, it will become false because the session has been closed, causing ``pos_config.has_active_session`` to be false. Additionally, since the mode is ``Mobile``, the condition in the ``elif`` statement at [1] also evaluates to false. As a result, we will get the value of ``config_access_token`` as a boolean value from line [2] because the value of ``config_access_token`` will not be set from both of the above conditions. Due to ``config_access_token`` being a boolean value, the value of ``channels`` ends up being a boolean value. This commit will fix the above error by providing an empty string within ``config_access_token``, rather than boolean values. So, the value of ``channels`` will consistently be a string. [1]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L35-L47 [2]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L16C8-L23C50 sentry-5136273134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts a previous update that could incorrectly switch an online shopper's cart customer to OdooBot in some website shop requests. Reverting it prevents wrong customer assignments while a cleaner long-term solution is prepared separately.
Original PR description
This reverts commit 4246d6e93e8450adc727981f3bb2b8c24aebafc9. This commit included changes that triggered sale_get_order calls in routes/requests that did not use it previously. Since those routes were using an environment sudoed with the superuser, the call to sale_get_order wrongly changed the customer to OdooBot. This will be addressed in a cleaner way in a separate PR, but for now, we only revert the wrong commit. opw-3949391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Settings page now properly activates developer mode when users click the option. This ensures administrators can access advanced configuration tools without needing a manual workaround or page refresh.
Original PR description
Steps to reproduce ================== - Go to settings - Click on "Activate the developer mode" => Nothing happens Cause of the issue ================== The page isn't reloaded Solution ======== Use the router and pass the reload option. The same call is done in debug_provider.js opw-3922717
Fixed an issue where gift cards sold in Point of Sale could fail to generate when product loading was restricted by category. The checkout now includes the required gift card products from the start of the session, ensuring customers receive the expected generated gift card.
Original PR description
Steps: --- - Install pos_loyalty with demo. - Configure shop to restrict product loading, only chairs. - Also make sure the setting is "Generate PDF Cards". - Open pos. - Search for the gift card (search more to load the product from server). - Sell the gift card. Issue: --- At checkout, there should be a generated gift card. Cause: --- Gift card product was not being loaded at the start of the POS session due to category restrictions. This caused `trigger_product_ids` to be empty since the product with the matching ID wasn't loaded. FIX: --- When loading data at the start of the session, load all products listed in `trigger_product_ids`. task-3911737
Miscellaneous changes
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_o
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in…
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_option_visibility_update' event. However, this event then propagates to the column's parent elements (`<section>` and `<main>`). So, the attribute `data-invisible="1"` is also added to the `<section>`, causing the dropzone not to be inserted as expected. We should investigate this further later because it doesn't seem consistent. For now, we prefer not to make changes at this level to avoid introducing other bugs. In this commit, we change the selector that determines where not to insert dropzones so that it no longer considers `data-invisible="1"`. This was added by this commit [1], but it seems unnecessary, and ':not(:visible)' in the selector is sufficient to avoid placing dropzones between two non-visible elements. [1]: https://github.com/odoo/odoo/commit/f9bd3033b21dbd1e4487d6d6cd1d8d8fdfbfb2ac Forward-Port-Of: odoo/odoo#165797
31 changes
New functionality added to Odoo
This adds payroll localization for Turkey, including salary structures, payroll rules, and accounting setup. It helps businesses in Turkey run payroll more accurately in Odoo and align payroll accounting with local requirements.
Original PR description
Turkey payroll localization - [Ticket#: 3689866](https://www.odoo.com/odoo/4996/tasks/3689866?cids=14)
25 changes
New functionality added to Odoo
This update adds a redirect link to the documentation repository in the GitHub issue template configuration. This improvement helps users and contributors quickly access the official Odoo documentation when creating issues, enhancing the support experience and reducing confusion about where to find help resources.
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155029 Forward-Port-Of: odoo/odoo#153993
Original PR description
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155029 Forward-Port-Of: odoo/odoo#153993
If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l
Original PR description
If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l10n_hu_edi (if they don't want to use it) opw-3912298 Forward-Port-Of: odoo/odoo#166043
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available. - Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping. ## Steps To Reproduce: - Install UPS US on your db and publish it. - unpublish the other shipping methods. - Go to /shop and purchase any product a
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165832
Forward-Port-Of: odoo/odoo#161704### Issue: Trying to validate a wave transfer with an empty picking will raise and error. ### Expected behavior: The empty picking should be removed from the wave transfer and the rest of the operations should be validated. ### Steps to reproduce: - In the settings: enable Batch Transfers > Wave Transfers - Create 2 receipts: 1) 1 x product P1 2) 1 x product P2 - In the inventory overview, click on the dots of receipts > operations - Select your receipts > Add to w
Original PR description
### Issue: Trying to validate a wave transfer with an empty picking will raise and error. ### Expected behavior: The empty picking should be removed from the wave transfer and the rest of the…
### Issue:
Trying to validate a wave transfer with an empty picking will raise and error.
### Expected behavior:
The empty picking should be removed from the wave transfer and the rest of the operations should be validated.
### Steps to reproduce:
- In the settings: enable Batch Transfers > Wave Transfers
- Create 2 receipts:
1) 1 x product P1
2) 1 x product P2
- In the inventory overview, click on the dots of receipts > operations
- Select your receipts > Add to wave > Create new wave transfer
- Go to inventory > Operations > Transfers > Wave transfers
- Open your wave transfer and set the quantity of P1 to 0
### Cause of the issue:
Currently, only the empty pickings 'waiting for another operation' are removed from the batch when it is validated:
https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L204
In particlar, other empty pickings will not pass the sanity check: https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L217-L218 and an operation error will be raised for them.
opw-3884043
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163320**Current behavior before PR:** Opening a chatwindow for a channel the user is not a member of would result in an error. This occurs because the chatwindow' fold state is saved to the server, but the server expects the user be a member of the channel. **Steps to reproduce:** 1. Create a channel and change it's Authorized group to null making it public 2. Mention a user who is not a member of this channel. 3. Login through the mentioned user. 4. Open the systray and click on the mess
Original PR description
**Current behavior before PR:** Opening a chatwindow for a channel the user is not a member of would result in an error. This occurs because the chatwindow' fold state is saved to the server, but the server expects the user be a member of the channel. **Steps to reproduce:** 1. Create a channel and change it's Authorized group to null making it public 2. Mention a user who is not a member of this channel. 3. Login through the mentioned user. 4. Open the systray and click on the message notification. 5. It will open the chatwindow and throw the error. **Desired behavior after PR is merged:** Prevent saving the fold state to server if the user is not a member of the channel. task-[3890519](https://www.odoo.com/web?debug=1#id=3890519&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163161
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website p
Original PR description
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website page of the course. 4. Open the quiz in fullscreen. 5. A "false" message is displayed on the top-left corner. opw-3887445 Forward-Port-Of: odoo/odoo#164549
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor bill in USD (10 $) > Now Receive the quantities > Check the valuation > Wrong value (15.92 $) the value should be 10$ (taken from the bill) Bug: In the case of BIlling policy on Ordered Quantities and PO in a foreign currency we assume the bill will be in same currency as the PO Fix:
Original PR description
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor…
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor bill in USD (10 $) > Now Receive the quantities > Check the valuation > Wrong value (15.92 $) the value should be 10$ (taken from the bill) Bug: In the case of BIlling policy on Ordered Quantities and PO in a foreign currency we assume the bill will be in same currency as the PO Fix: currently unit price is first computed in PO currency and then converted in the end to company currency added conversion from bill to PO opw-[3805454](https://www.odoo.com/web#id=3805454&view_type=form&model=project.task) also fixed a rounding issue opw-[3773413](https://www.odoo.com/web#id=3773413&view_type=form&model=project.task) alternative fix: compute everything in company currency (https://github.com/odoo/odoo/pull/155937) Forward-Port-Of: odoo/odoo#166346 Forward-Port-Of: odoo/odoo#162827
Default Price on POS would not show on older versions if there was a default pricelist set already on the POS. But would show default price if it was unset. This was not changed in the refactor, so the line that was referenced to see if default pricelist was set was referring to a variable that was no longer being set. Using the current default pricelist that is stored at pos.config.pricelist_id achieves the same functionality as before on this version of the POS. opw-3926123 --- I con
Original PR description
Default Price on POS would not show on older versions if there was a default pricelist set already on the POS. But would show default price if it was unset. This was not changed in the refactor, so the line that was referenced to see if default pricelist was set was referring to a variable that was no longer being set. Using the current default pricelist that is stored at pos.config.pricelist_id achieves the same functionality as before on this version of the POS. opw-3926123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166577
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166597 Forward-Port-Of: odoo/odoo#163938
Original PR description
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166597 Forward-Port-Of: odoo/odoo#163938
In september 2023 7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 replaced this._rpc by `this.bindService("rpc")`. In may 2024 58324ee59946c7bfe9970b5202cce8d4a36a69b0 was forward-ported without adaptating it to the new way rpc is used. This is causing report of an error in some case when using stripe express checkout. note: in saas-17.1 the code has to be changed again to `await rpc`. opw-3917632 Forward-Port-Of: odoo/odoo#166602
Original PR description
In september 2023 7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 replaced
this._rpc by `this.bindService("rpc")`.
In may 2024 58324ee59946c7bfe9970b5202cce8d4a36a69b0 was
forward-ported without adaptating it to the new way rpc is used.
This is causing report of an error in some case when using stripe
express checkout.
note: in saas-17.1 the code has to be changed again to `await rpc`.
opw-3917632
Forward-Port-Of: odoo/odoo#166602Australian payroll users can now register payments for an entire payslip batch instead of processing each payslip one by one. The change creates a batch payment record that supports ABA bank file generation, reducing manual work while keeping the existing single-payslip payment flow.
Original PR description
Currently, `action_register_payment` and the `account.payment.register` wizard depends on the payslip in the context to only register payment for one payslip. This restricts any way of registering payment for a batch of payslips. This PR extends the `hr_payroll_account` module to allow multiple payslips to be registered as a batch. However, it maintains the current flow for single payslip payment. This adds a register payment feature to the payslip batch that generates individual payments on payslips and returns a record of `account.payment.batch` with all the payments. This also simplifies the ABA file generation and moves it entirely to `account.payment.batch` instead of `payslip.run` task #3855817
Enhancements to existing features
Project task screens now provide embedded shortcuts to related Documents and Planning actions, making it easier for users to access supporting project information without leaving their workflow. The update also streamlines project view controls and adjusts related performance test expectations.
The invoice attachment viewer now works correctly when opened in a separate tab or window. This ensures visual extraction markers are placed in the right place, improving usability for accounting workflows.
Original PR description
The attachment viewer can now be popped out in another tab/window. We are now targetting the right window to add the boxes where needed. [task-3932781](https://www.odoo.com/web#id=3932781&model=project.task)
The Sign app onboarding has been improved to help users start creating templates more easily. Users can now drag and drop files, while clearer guidance and small usability refinements make the setup flow smoother and more satisfying.
Original PR description
The onboarding process for the sign app has been upgraded to make it easier to use and improve customer satisfaction. This PR allows users to upload templates with ease by simply dragging and dropping files. Additionally, the action helper has been updated to provide a more intuitive and seamless experience. The overall usability has been improved by fine-tuning menu sequences and other minor improvements. task-3764704 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Report export and filing wizards now use a shared error display that makes blocking issues easier to understand and act on. This improves consistency across accounting, SAF-T, Intrastat, and local reporting flows while keeping important errors sorted reliably for users.
Original PR description
`file_generation_error` has been superseded by `ActionableErrors` in `account` which is more generic. SAF-T and other wizards relying on the `critical` attribute need sorting. jsonb fields don't retain order in PostgreSQL, so we re-sort the actionable_errors field by critical and then by error key. Community PR: [odoo/odoo#159251](https://github.com/odoo/odoo/pull/159251) Upgrade PR: [odoo/upgrade#5917](https://www.github.com/odoo/upgrade/pull/5917) Task link: [odoo/task#3698183](https://www.odoo.com/web#model=project.task&id=3698183) task-3698183
Odoo now supports printing complete US checks in-house instead of requiring pre-printed Checkdepot stationery. Businesses can choose top, middle, or bottom check layouts that automatically include company and payment details, giving them more flexibility and control over check printing.
Original PR description
For the United States, Odoo currently offers the option to print checks using a "pre-printed" format that matches a specific supplier (Checkdepot). We don't cover the use case where checks are printed in-house without a pre-populated page with some static information. Also, if a company would like to change or edit some information from the pre-filled checks, it is impossible. We want to offer users the option to print "blank checks" by having a prepopulated template in Odoo that will adjust to the company's information. This commit adds 3 additional check layout to print: - print_blank_check_top - print_blank_check_middle - print_blank_check_bottom Where each of them are designed meticulously to position the required fields in blank checks, according to Checkdepot's layout. task-id: 3719584
The inventory onboarding flow for barcode operations has been updated to better match the latest business-to-business onboarding specification. This should make it easier for users to get started with inventory barcode workflows and understand the next steps during setup.
Original PR description
Task: 3647839
The subscription sales order logging code has been simplified to make it easier to maintain. This is an internal improvement that should reduce complexity and help future updates without changing day-to-day user workflows.
Original PR description
Simplify sale order log code
The website event social feature has been updated to use standard browser technology instead of an older dependency. This helps keep the platform easier to maintain and supports Odoo's broader effort to reduce reliance on legacy frontend libraries.
Original PR description
This PR aims to refactoring all jQuery code into Vanilla JS in website_event_social, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
Accountant users can now request and enter OTP codes for GSTR API verification without needing broader settings permissions. This reduces delays in GST return workflows and lets finance teams complete required verification steps with the access they already have.
Original PR description
Before this PR, users with accountant access rights lacking setting permissions could not send and enter OTP for GSTR verification. With this enhancement, users with accountant access rights can now successfully send and input OTP codes, streamlining the verification process. Task ID: 3895351
The website_sale_ups module is being updated to replace older page scripting with modern browser-based code. This reduces reliance on an external library, helping keep the online sales experience easier to maintain without changing the customer-facing workflow.
Original PR description
This PR aim to convert all jQuery code into Vanilla JS in website_sale_ups, this way we will reduce the dependency of jQuery in Odoo codebase. task-3770362
Resolved issues and error corrections
This change removes a temporary placeholder and switches Mexican e-invoicing screens to use the shared document status display already available in accounting. It reduces duplicate code and helps keep invoice, payment, POS order, and stock picking views consistent without changing the business workflow.
Original PR description
In a7adb61e41ef17459eb95d9252cd53db37ebe0b2, the document_state component was removed from l10n_mx_edi to be put in account. We had to keep an "empty shell" component in l10n_mx_edi to avoid having to modify the l10n_mx_edi views in stable. But in master, we can remove this "empty shell" and use the generic component from account.
A Planning test scenario now correctly handles cases when the current day is the first day of the week. This prevents false test failures and helps keep Planning updates more reliable.
Original PR description
Before this commit, the tour planning_split_shift_week would crash when the current day is the beginning of the current week. This happened because when today is the first day of the week, the selector used in the step "Select first day of the current week" would be the start of the previous week. Thus the final date range produced, would contain two weeks instead of one, making the tour timeout (waitUntil condition not met).
The spreadsheet pivot side panel now correctly shows the minimum calculation option. This helps users choose the right summary method when analyzing document spreadsheet data.
Original PR description
`min` aggregator was missing in the list of available aggregators in the pivot side panel. This commit adds it. Task: 3942858
This change reverts the addition of deferred start and end dates on invoice PDF reports. The dates were being shown for all customers, which was not intended, so the report is restored while a better approach is assessed.
Original PR description
In this commit https://github.com/odoo/enterprise/commit/84e0edcfc88c3361e1e042e80c82f6c4b950c738, we added the deferred_start_date and end_date in the pdf. This change is applied for everyone and it shouldn't be. A next task will be created to assess this problem but in the meantime we will revert the commit no task-id
Dashboard administrators can now insert items such as pivot views into spreadsheet dashboards without needing full system administrator rights. This restores the expected dashboard editing permissions for users in the Dashboard Admin group, especially when Documents is not installed.
Original PR description
[FIX] spreadsheet_dashboard_edition: allow to insert in dashboard Steps to reproduce: - install CRM (make sure Documents is not installed) - login with a user with "Dashboard Admin" group (but not system admin) - go to CRM and try inserting a pivot view in a spreadsheet => you can't Since odoo/odoo@0c50cbe18ce3f1 a new user group was created allowing to create and edit spreadsheet dashboards. However, members of that group are not able to insert anything because the group was not updated in the registry. Task: 3795574
Code cleanup and technical improvements
This draft refactors click interactions across automated tours and tests for accounting, reporting, approvals, documents, and spreadsheet workflows. It is marked as aborted and points to a replacement pull request, so there is no direct business-facing change expected from this draft.
Original PR description
Aborted => refer to https://github.com/odoo/enterprise/pull/63176
This refactoring prepares Odoo's automated web tours to use clearer, more consistent test steps. It reduces ambiguity in internal test behavior and helps future maintenance without changing end-user features.
Original PR description
Currently, in tour_compiler, to check that an element is actually present in the DOM in a step, there are 2 possibilities. - `isCheck: true` => Checks that the element is in the DOM. The latter can…
Currently, in tour_compiler, to check that an element is actually
present in the DOM in a step, there are 2 possibilities.
- `isCheck: true` => Checks that the element is in the DOM.
The latter can be disabled.
- `run() {}` => Checks that the element is in the DOM (because this
is what is done by default). However, if the element is disabled,
the step will be aborted.
In the codebase, we can see a lot of `run() {} //it's a check` and
`isCheck:true`. However, the behavior is not exactly the same.
What's more, there are 2 ways to do "the same thing".
In order to clarify the turns API, it was decided to no longer put an
action (step.run) by default. (Previously, the default action was
the "click" action).
From then on, it is no longer necessary to stipulate
`step.isCheck: true` nor `run() {}`.
The corollary is that now, you must explicitly write `run: click`, if
you want the click action to be triggered on the target.
This commit sets the stage for making this change.This change standardizes how self-ordering POS modules share related order data with the frontend. It supports reuse of the same frontend model structure across POS self-order, preparation display, IoT, and online payment flows, reducing future maintenance work with minimal direct user impact.
Original PR description
*:pos_online_payment_self_order_preparation_display, pos_self_order_iot, pos_self_order_preparation_display Like in `point_of_sale` we introduce related_models in `pos_self_order` to handle relation between models in the frontend. This will allow to use the same frontend models in all pos related models. Related: https://github.com/odoo/odoo/pull/164793
Miscellaneous changes
The number of months worked in the previous year was not including previous occupations. Thus, the commissions were not added as the number of months was 0. Forward-Port-Of: odoo/enterprise#63188
Original PR description
The number of months worked in the previous year was not including previous occupations. Thus, the commissions were not added as the number of months was 0. Forward-Port-Of: odoo/enterprise#63188
Adapt tests to community change See also: - https://github.com/odoo/odoo/pull/166609 Forward-Port-Of: odoo/enterprise#63191
Original PR description
Adapt tests to community change See also: - https://github.com/odoo/odoo/pull/166609 Forward-Port-Of: odoo/enterprise#63191
Steps to reproduce: ------------------- - create a product: - service - based on timesheet - create on order: project & task - create a sale order with this product - confirm the sale order - go on the created task - add timesheets with an employee - go to timesheet - validate created timesheets - go to the project settings - in invoicing tab, change de sale order item for the employee Issue: ------ The sale order item linked to the validated timesheets are mo
Original PR description
Steps to reproduce:
-------------------
- create a product:
- service
- based on timesheet
- create on order: project & task
- create a sale order with this product
- confirm the sale order
- go on the created task
- add timesheets with an employee
- go to timesheet
- validate created timesheets
- go to the project settings
- in invoicing tab, change de sale order item for the employee
Issue:
------
The sale order item linked to the validated timesheets are modified.
This behaviour causes negative side effects.
A validated timesheet should no longer be modified, but the backend logic does, which is not consistent.
Solution:
---------
Make the condition that filters timesheets to update take account of whether the timesheet is validated or not.
opw-3791062
Forward-Port-Of: odoo/enterprise#63163
Forward-Port-Of: odoo/enterprise#61122The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded.
Original PR description
The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded. The tour would then consider it did click the button, while the action didn't happen. We add a check to wait for the page to be fully loaded before clicking. Linked to runbot error 61458, 63532, 59031 (and happened before already). Forward-Port-Of: odoo/enterprise#63019 Forward-Port-Of: odoo/enterprise#61964
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62989 Forward-Port-Of: odoo/enterprise#62744
Original PR description
The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62989 Forward-Port-Of: odoo/enterprise#62744
__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811 Forward-Port-Of: odoo/enterprise#62980
Original PR description
__Current behavior before commit:__ When there is an incoming call, a VoIP provider may give a session description containing an audio sender and a video sender even if the video track is empty. In such case, `track` may be `null`. Therefore the page will crash when we try to set `track.enabled`. __Description of the fix:__ Check if each track is not `null` before setting its `enabled` property. opw-3833811 Forward-Port-Of: odoo/enterprise#62980
**Before this PR:** Table 14(a) in the GSTR-1 report was calculating incorrect entries. **After this PR:** Table 14(a) in the GSTR-1 now calculates correct entries. **Technical Reason:** Previously, the calculations were based on incorrect tax_tag_ids and subformula. Now, the calculations are made with the correct tax_tag_ids and subformula, and cess has also been added. **task**-3904018 Forward-Port-Of: odoo/enterprise#62829
Original PR description
**Before this PR:** Table 14(a) in the GSTR-1 report was calculating incorrect entries. **After this PR:** Table 14(a) in the GSTR-1 now calculates correct entries. **Technical Reason:** Previously, the calculations were based on incorrect tax_tag_ids and subformula. Now, the calculations are made with the correct tax_tag_ids and subformula, and cess has also been added. **task**-3904018 Forward-Port-Of: odoo/enterprise#62829
Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour hap
Original PR description
Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour happens if an invoice is created for a previous order. This commit adds l10n_mx_edi_usage to the partner fields to be loaded when loading the pos data. Then, the field in the popup can be filled with the default CDFI usage of the partner if it exists. Else, it behaves as before, displaying either the usage code selected in the POS session or code 'Acquisition of merchandise' if the field is undefined. task-3865331 Forward-Port-Of: odoo/enterprise#63022 Forward-Port-Of: odoo/enterprise#62261
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
Original PR description
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
TaskID: 3942303 Forward-Port-Of: odoo/enterprise#62956
Original PR description
TaskID: 3942303 Forward-Port-Of: odoo/enterprise#62956
Enhancements to existing features
This update significantly speeds up the process of cancelling large purchase orders. Previously, cancelling orders with over 50 lines would take several minutes or timeout; now the same operations complete in seconds. This improvement makes it practical for users to manage and cancel large orders without experiencing system delays.
Original PR description
# Current behavior: Cancelling a Purchase Order with more than 50 lines takes too much time to be processed. In the case of the client they had PO with more than 200 lines which makes it impossible for them to cancel them. # Step to reproduce: - Install mrp and mrp_subcontracting - Create PO with more than 50 order lines or more - Confirm the PO - Try to cancel it - Take a long time or timeout # Benchmark (made in 16): | No. of PO lines | Before | After | |-----------------|:-------:|:------:| | 9 | 650ms | 600ms | | 91 | 1min26 | 9s | | 273 | 4min50 | 34s | | 405 | 7min13 | 55s | # Fix: Batch more actions and records to reduce the number of queries generated by the ORM. # Reference: opw-3690875 Forward-Port-Of: odoo/odoo#166513 Forward-Port-Of: odoo/odoo#151526
Italian electronic document processing now validates files based on their actual XML structure rather than filename, making the system more reliable and consistent with other EDI methods. This change also improves handling of digitally signed files (.xml.p7m) by automatically removing signatures before processing.
Original PR description
Italian EDI used to look at the filename to determine whether the uploaded attachment is related to it or not. With this change we look at the structure of the XML file, making it more standard - it's what all other EDIs do. CADES signed files (.xml.p7m) have their signature removed and then they are treated like normal XML files. In order to be able to do this, we have to move the code that specially handles the account_predictive_bills for Italy to the `account` level. Related PR: odoo/odoo#163849 Related issue: #150382
Italian EDI document processing has been improved to validate the actual XML structure of uploaded files rather than relying on filename patterns. This makes the system more robust and consistent with how other EDI formats work. The change also properly handles digitally signed files (.xml.p7m) by removing the signature before processing.
Original PR description
Italian EDI used to look at the filename to determine whether the uploaded attachment is related to it or not. With this change we look at the structure of the XML file, making it more standard - it's what all other EDIs do. CADES signed files (.xml.p7m) have their signature removed and then they are treated like normal XML files. In order to be able to do this, we have to move the code that specially handles the account_predictive_bills for Italy to the `account` level. Old PR for master: odoo/odoo#165673 Related PR: odoo/odoo#163849 Related issue: #150382
Resolved issues and error corrections
The Austrian financial reports module had an unbalanced Balance Sheet that has now been corrected. The fix adds missing account classifications, separates current year profits from carried-forward profits in both the Balance Sheet and Profit & Loss statements, and aligns the reports with official Austrian accounting standards. This ensures accurate financial reporting for Austrian companies.
Original PR description
According to the Balance Sheet diagnostic test in #47602, the Balance Sheet was unbalanced. To fix this, - missing account tags have now been added (cf community PR); - the Balance Sheet Profit (loss) line has been split into the current year's profit/loss and the profit/loss carried forward. - the Profit and Loss carried forward from previous years has been created as a new line in the P&L. This is all done in accordance with the official Balance Sheet and Profit & Loss found at https://www.jusline.at/gesetz/ugb/paragraf/224 https://www.jusline.at/gesetz/ugb/paragraf/231 Community PR: https://github.com/odoo/odoo/pull/158542 Taskid: 3060790
This update fixes how payment tax documents (CFDIs) are dated in Mexico. Previously, payments created in Odoo before being sent to the government would use an incorrect date. Now the system uses the actual submission date, which complies with Mexican law allowing payments to be submitted up to 10 days into the following month. This ensures your tax filings are legally accurate.
Original PR description
[REF] l10n_mx_edi: change fecha date to sent date Issue: Sometimes payments are created in Odoo prior to sending the CFDI, by law payments don't have to be necessarily sent to the government on the same month and can sometimes be sent up to the first 10 days of the next month. Solution: fill the 'fecha' field with the current datetime for the cfdi of the payments, Then send it. Task-3885769
This fix resolves a crash that occurred when users tried to retry sending comment notifications in the Knowledge module. When a user tags another user in a Knowledge comment, the system attempts to send a notification email. If an error happens and the user retries, the system was crashing due to a missing data field. The fix ensures the system gracefully handles this situation so users can successfully retry sending notifications.
Original PR description
This commit fixes an issue with comments notifications in Knowledge. When a user tags another user in a Knowledge comment, a mail should be sent. When an error occurs the user have the possibility to retry to send the notification. Retrying this action triggers an error with threads because the msg_vals key doesn't exist when trying to access it inside `_notify_thread_by_email`. The fix is to use the get function of Python dict so that if the msg_vals aren't set, no error is triggered. task-3933062
This fix resolves an issue where shipping addresses with longer city and state names would cause Bpost delivery validation to fail. The system now properly limits the address field length to prevent errors when customers have addresses that exceed the character limit, such as "Marche-lez-Ecaussinnes, Brabant Wallon (BE)".
Original PR description
Steps to reproduce: - Create a contact who has the "City" and "State" populated, that would exceed 40 characters in the following format: "[City], [State] ([Country Code])" eg: "Marche-lez-Ecaussinnes, Brabant Wallon (BE)" - Enable Bpost and enter test credentials. - Create a Sales Order and add Bpost shipping. - Try to validate the transfer - Error about the "LocalityCode" being too long. Fix: same as for other fields impose max length limit opw-3895123 Forward-Port-Of: odoo/enterprise#62710
A search button has been added to the WhatsApp tab in mobile view, allowing users to easily find and search for WhatsApp channels on their mobile devices. This improvement enhances the mobile user experience by providing the same search functionality that was previously only available on desktop.
Original PR description
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#62680 Forward-Port-Of: odoo/enterprise#59530
This fix corrects how asset depreciation amounts are calculated when an asset's lifetime is extended through revaluation. Previously, when extending an asset's depreciation period (for example, adding 12 months), the depreciation entries would end too early. Now the system properly calculates depreciation amounts based on the original asset value, ensuring consistent monthly depreciation across the entire extended lifetime.
Original PR description
Create an asset for 2400$, acquisition date on 1/1/2023. Reevaluate it on 31/12/2023, 36 montths (+12) and add 1200$ to the amount. => The entries on the parent asset finish way too early. You don't get 36 months of lifetime. We would expect the amount of each new depreciation to be 50, so the amount of the parent + the child equals 100 each month for 36 months The reason why it happened is that we tried to compute the expected amount after each depreciation. This took into account changes of amount, but not changes of length. We don't have a good way to incorporate changes of length in the old computation. To fix this, for linear, we consider the original amount from the beginning/the reevaluation to compute the amount for each period. It does not hold for degressive_then_linear, so we separate the logic. opw-3811165 Forward-Port-Of: odoo/enterprise#62377
This fix resolves an issue where Knowledge articles couldn't embed certain views (like Cohort and Gantt views) if their optional modules were manually uninstalled. The system now intelligently detects which modules are loaded and only applies the necessary patches when available, preventing errors and ensuring a smooth user experience.
Original PR description
Cohort views were patched to allow inserting them as an embed in a Knowledge article, but `web_cohort` was not a dependency of `knowledge`. It was an issue if the `web_cohort` (which is auto_install: True) module was manually uninstalled. Using an odoo runtime import, we can evaluate if the module was loaded and apply the patch at that point. If the module was not loaded, the patch is not applied. task-3918938 Forward-Port-Of: odoo/enterprise#63100 Forward-Port-Of: odoo/enterprise#62181
Fixed an issue in the document signing process where users were unable to close the confirmation dialog box after signing documents. Previously, users had to close the entire browser window to dismiss the dialog. Now a close button has been added, allowing users to easily dismiss the dialog and continue with their work.
Original PR description
Steps to reproduce: - Install sign - Add two document to sign for the Marc Demo - Sign in as Marc Demo - Go to the sign app and sign both documents Issues: There's no button to close the dialog box, you are forced to close the window. opw-3847269 Forward-Port-Of: odoo/enterprise#61380
When revaluing an asset with an increase from a previous month, the system was incorrectly recording today's date on the value increase transaction instead of the actual revaluation date. This fix ensures the transaction is dated to match the asset's acquisition date, providing accurate financial records and proper period tracking.
Original PR description
To reproduce: Create an asset. Reevaluate, with an increase, last month. => the move of Value Increase has today's date. We decided to instead put the acquisition date of the child asset. (so it won't be the same in 16.0) opw-3922067 Forward-Port-Of: odoo/enterprise#63115 Forward-Port-Of: odoo/enterprise#63097
This fix prevents dashboards from disappearing when users accidentally remove all group assignments. By making the group field required, dashboards must always be assigned to at least one group, ensuring they remain accessible and cannot be lost.
Original PR description
Purpose ------- If you remove all groups of dashboard and save, the dashboard disappears and there's no way to find it back. Specification ------------- make the field required. Task: 3770194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where users without write permissions could not properly drag and drop items in kanban views. Previously, items would not reset to their original position when users lacked reordering rights. Now the drag-and-drop functionality works correctly for all users, with items properly returning to their original position when the action is not permitted.
Original PR description
Before this commit, drag-and-drop functionality for groups/records in the kanban view did not work properly if the user lacked write access. Steps to Reproduce: - Log in to Odoo as Marc Demo. - Open the Project module. - Attempt to drag and drop any group/record in the kanban view. Observed Behavior: The group in the kanban view does not reset to its original position if the user lacks the right to reorder the groups/records, rendering the group/record immovable. Expected Behavior: The group in the kanban view should reset to its original position if the user lacks the right to reorder the groups/records. After this commit, drag-and-drop functionality for groups/records in the kanban view now works properly, even if the user does not have write access. Task ID: 3865617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error that occurred when searching for vehicles by driver in the Fleet app when installed without the HR module. The fix ensures the vehicle search functionality works correctly regardless of which modules are installed alongside Fleet.
Original PR description
Problem: * If the fleet app is installed **by itself** (i.e. without hr) searching a vehicle by driver will throw an error. Notes about fix: * The error is caused by a hr_fleet child field being accessed in the base Vehicle model. opw-3858626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug in the Accounting app where PDF attachments uploaded to bills would not display a preview. The issue occurred because the system tried to show the PDF before it was fully saved. This update ensures the file is completely uploaded before attempting to display it.
Original PR description
Caused a bug in accounting app. ### Steps to reproduce: - Go to Accounting > Vendors > Bills - Create a new bill - Upload a pdf using the link button in the chatter - The pdf viewer displays but without preview ### Cause: The call to display the attachment occurs before the attachment record is created. This is due to the onUploaded function of mail not being async, so the program does not wait for it to end. ### Solution: Make the function async and waiting for the file to be uploaded. opw-3927764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where test emails sent through the mass mailing feature contained broken placeholder links that would result in 404 errors when clicked. The fix ensures that placeholder links are properly replaced with actual working links when test emails are sent, while preventing unsubscribe links from being modified to protect users from accidentally unsubscribing themselves.
Original PR description
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the…
This commit fixes an issue with the mailing_mailing_test wizard in mass_mailing. When sending a test email the snippet `s_mail_block_header_view` contains a placeholder link that is replaced by the actual link when rendered. When the user sends a test mailing, the mail sent will still contain the placeholder link without being replaced. This means that when clicking on it the user is redirected to a 404 error as this is a mere placeholder. This link isn't replaced because the mail created inside testing wizard did not give a res_id, linked to a `mailing.contact`, to the `mail.mail` created. This led the function `_prepare_outgoing_list` to be exited prematurely without replacing any placeholder. This commit fixes the issue by adding a res_id linked to the current user to the mail.mail created in order for the method to finish its execution. But we don't want the unsubscribe links to be replaced, as the user could blacklist himself. Thus we added a context key `send_as_test` which blocks the replacement of the unsubscribe link. task-3869575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where repair orders were not receiving auto-generated sequence numbers after a system upgrade. The problem was caused by an incorrect comparison logic that was checking for a translated value when the field doesn't support translation. By correcting this comparison, repair orders now properly generate their sequence numbers automatically instead of remaining with the default 'New' label.
Original PR description
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New'). However, the data type of the 'name' field is character and translate = False. Additionally, the default…
Issue: In the upgraded version, we have implemented the condition vals['name'] == _('New').
However, the data type of the 'name' field is character and translate = False.
Additionally, the default value for the 'name' field is set to 'New', causing
this condition to evaluate to false and consequently terminating the execution
of the if block.
Solution: To address this, we propose changing the condition to vals['name'] == 'New'
to ensure correct comparison. This modification is warranted due to the
[configuration](https://github.com/odoo/odoo/blob/89fbb75659ba71b8c76dddd62ba331966161f59b/addons/repair/models/repair.py#L31)
of the field:
The field is not translatable.
The field is required and set to readonly true, preventing customers from inputting values.
The default value for the field is set to 'New'.
Before:
Unable to obtain the auto-generated sequence (receiving default value 'New').
After:
The sequence is generated automatically.
OPW-3887638
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165771This update fixes an issue where portal access couldn't be granted to multiple customers with the same email address when they're linked to different websites. The system now correctly handles scenarios where customers create separate accounts per website, allowing each to receive portal access independently while preventing conflicts when appropriate.
Original PR description
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure…
[FIX] portal, website: allow to grant portal access for certain users Context: - Have a db with two websites (website1 and website2) with two different domains. - For those two websites, make sure that the "Shared Customer Accounts" setting is disabled. The user is so forced to create an account per website. - As a visitor, create an account in each website using the same email address. -> No issue; it is possible to create two accounts with the same email address. Steps to reproduce the issue: - Create two contacts (e.g. partner or customer) with the same email address. One is linked to website1, the other is linked to website2. - Select them, click on "Action" and then on "Grant portal access". - Click on "Grant Access" for the first contact; it works as expected. -> It is not possible to grant access for the second contact. The goal of this commit is to ensure that the two described behaviors lead to the same results. More specifically, it should be possible to grant portal access for two partners that have: - The same email address but are linked to different websites that have the "Shared Customer Accounts" setting disabled. - The same email address. One user is linked to a website that has the "Shared Customer Accounts" setting disabled and the other is not linked to a website. It should however not be possible to grant portal access for two partners that have: - The same email address and are linked to the same website that has the "Shared Customer Accounts" setting disabled. - The same email address and are not linked to a website. It should also not be possible to grant portal access for a partner that is not linked to a website if it exists a user with the same email address that is linked to the current website. Indeed, in this situation, the partner is redirected to the current website at the creation of its account and an "Access Denied" message would then be displayed. To solve the problem, the method `_get_similar_user_domain()` has been implemented in the "website" module. Its goal is to build the domain needed to find the users that have the same email than partners depending on their linked website characteristics. The `_is_portal_similar_than_user()` method has also been introduced. Its goal is to check if the credentials of a portal user and a user are the same. If it is the case, `email_state` field of the portal user is set to `exist`. task-3640503 Forward-Port-Of: odoo/odoo#166349 Forward-Port-Of: odoo/odoo#148482
This update corrects faulty translations in the Swedish language pack for sales templates that were causing system errors when messages were sent in Swedish. The fix ensures that Swedish-speaking users can properly send sales communications without encountering translation-related failures.
Original PR description
Correcting faulty translation of templates that will break the system when messages are sent in Swedish. Reported as support tickit #3900977.
This pull request contains multiple fixes and improvements across various Odoo modules including web editor link handling, accounting journal synchronization, delivery weight calculations, manufacturing operations, and inventory management. The changes address specific bugs that impact user workflows and system performance, such as incorrect picking weights, missing operation durations, and unnecessary recalculations in inventory systems.
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 corrects an incorrect placeholder in a translation string within the mail module. The fix ensures that translated messages display properly and consistently across different languages, improving the user experience for non-English users.
This fix corrects errors in the Swedish language translation of sales email templates that were causing emails to fail when sent. The translation contained mistranslated code and unclosed XML tags that prevented proper email generation. This resolves support ticket #3900977.
Original PR description
Current Swedish templates are done wrong and will give error when e-mail is sent out, because code has been translated and XML tags are not closed. There are also multiple lines copied multiple times. This is the fix for support ticket #3900977.
This fix resolves an issue in the website editor where drop zones (areas to place new content) would disappear when hiding a column in a snippet. The problem occurred because a visibility attribute was incorrectly propagating to parent elements. The fix adjusts how the system determines where to place drop zones, ensuring they remain available even when columns are hidden.
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in…
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_option_visibility_update' event. However, this event then propagates to the column's parent elements (`<section>` and `<main>`). So, the attribute `data-invisible="1"` is also added to the `<section>`, causing the dropzone not to be inserted as expected. We should investigate this further later because it doesn't seem consistent. For now, we prefer not to make changes at this level to avoid introducing other bugs. In this commit, we change the selector that determines where not to insert dropzones so that it no longer considers `data-invisible="1"`. This was added by this commit [1], but it seems unnecessary, and ':not(:visible)' in the selector is sufficient to avoid placing dropzones between two non-visible elements. [1]: https://github.com/odoo/odoo/commit/f9bd3033b21dbd1e4487d6d6cd1d8d8fdfbfb2ac Forward-Port-Of: odoo/odoo#165797
This update removes outdated scheduling options from many automated background tasks across accounting, payroll, HR, helpdesk, data cleaning, and related services. It keeps scheduled jobs aligned with the latest platform behavior, reducing maintenance risk without changing day-to-day user workflows.