Thursday, October 24, 2024
91 changes
14 changes
Resolved issues and error corrections
This fixes a display issue where message author avatars could disappear in public channels after the sender left, especially for guests viewing the conversation. It helps keep chat history clear and recognizable for users without changing the conversation content.
Original PR description
Steps to reproduce: - Create a public channel - Add a non website_published user as a new member - Log in as that new member and send a message then leave the channel - Open the channel as a quest - The author avatar of the message is not there
Miscellaneous changes
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
Original PR description
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
26 changes
Enhancements to existing features
Indian GST reports and tax group labels now use SGST/UTGST instead of SGST. This makes the wording more accurate for businesses operating in Union Territories and improves compliance-related reporting clarity.
Original PR description
with this PR: Renamed SGST to SGST/UTGST in Tax Groups and GST Report Heading task - 4231745
47 changes
Enhancements to existing features
Technical users can now import attachments while preserving their links to related records and fields. This makes controlled attachment data migrations easier from the debug-only technical menu.
Original PR description
readonly=True on `res_model`/`res_field`/`res_id` of ir_attachment making these fields not importable. Attachment menu is only accessible in debug mode in the technical menu anyway. Then we suppose that user in attachment views understand what he does (hopefully). task-4252555
4 changes
Resolved issues and error corrections
This update resolves a bug that prevented the 'Data Merge: Find Duplicate Records' process from correctly identifying duplicate records when a model's company field wasn't directly stored. The fix ensures the system can now accurately match duplicates even when relying on related fields, improving data accuracy.
Original PR description
Steps ----- 1. Create a deduplication rule for a model with a non-stored company field (e.g. Document). Add a field to the deduplication rules. 2. Run the "Data Merge: Find Duplicate Records" scheduled action. ** ValueError: <class 'psycopg2.errors.UndefinedColumn'>: "column documents_document.company_id does not exist ** Change ----- Handle the case where the company field of the model is not stored but still accessible through its related field in another table. opw-4114062 Forward-Port-Of: odoo/enterprise#68816
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b
Original PR description
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However…
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode 1. Set a livechat channel on the website, make sure there is no chatbot on it 2. Enter the livechat channel with the admin 3. Open the website on an incognito window (the chat bubble should be there) 4. Leave the livechat channel with the admin 4. Refresh the incognito window The chat bubble is still there. Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before. opw-4233744 [1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100 [2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86 Forward-Port-Of: odoo/odoo#184644
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order lin
Original PR description
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will…
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order line 3. Click on a linked record in the "Used by" column in the report table 4. Click the browser back button -> traceback **Cause of the issue:** When trying to rebuild context, we get the actual model name provided by this.props.action.res_model. This was invariably treated as a stringified number in a read call to `ir.model` to try to get the model name -> result of the read is nonsense and when it is later used in an RPC, it tries to read fields from a nonexistent model. **Fix:** Get rid of the String -> Number conversion, directly use the value in `res_model` as the new `this.resModel`. opw-4181590 Forward-Port-Of: odoo/odoo#183742
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Original PR description
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce (on runbot): 1. enable "extra hours" and add extra hours to an employee 2. as an admin go to management > time off 3. make a new time off and choose "extra hours" as the time off type 4. The duration of extra hours is duplicated The issue happens because the form view inherits two identical views. This commit removes the unnecessary view. task-4102491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178866 Forward-Port-Of: odoo/odoo#176929
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with
Original PR description
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with a selection field - rename or remove the model - upgrade the module This commit fixes #179392. It was inspired by #104624. opw-3024537 Forward-Port-Of: odoo/odoo#184764
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184810
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 th
Original PR description
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different…
The password reset email was not being translated according to the receiver's language. This caused the template to render in the website language, leading to confusion for receivers with different language. The problem came form Convert the "Reset Password" template into QWeb view in https://github.com/odoo/odoo/pull/125874, Before, to sent the email `mail.send_mail()` function was used, and it has a check for the receiver language. and after https://github.com/odoo/odoo/pull/125874 the function wasnt used any more. it replaces with `mail.send()` that send the rendered content directly. To resolve this issue, the language of the receiver user is explicitly set in the context before rendering the email template. This ensures the email content is translated based on the user's preferred language then calling the function that send it. Now the template is rendered using the receiver's language (`user.lang`), or falls back to the website language `self.env.lang` if the receiver's language is not set. Or falls back to 'en_US' if the language is not set. owp-4149894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182635
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that
Original PR description
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that the `short_url_host` value will be False and this leads to a traceback when the compute method of `short_url` triggers. Ref of the breaking commit:- https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5 sentry-5969318187 Forward-Port-Of: odoo/odoo#182898
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar v
Original PR description
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on…
### Issue: `test_dblclick_event_from_calendar` tour test fails on Saturday ### Explanation: In the tour, we test an event with daily recurrence. Since the Weekly Calendar starts on Sunday and ends on Saturday, if an event starts on Saturday, the second occurrence of the event is on the next week and can not be reached. ### Fix: Moving to next week for the occurrence test, limiting recurrence to 8 days to remove useless rendering. Setting `drag_and_drop` tour in Monthly Calendar view to avoid issues caused by potential `drag_and_drop` behaviour changes. In Monthly Calendar view, some days from previous and following months are visible, with a maximum of 6 before (Feb 23, see Mar 2025) and 14 after (Mar 14, see Feb 2026). Initial date being set in the backend, it does not have to respect those limitations. Changes operated in the frontend are bound to these and must be set between 15 and 22 included with the current selector. runbot-error-65494 Forward-Port-Of: odoo/odoo#166502
Public users now see a close button on the thank-you dialog after signing a document. This makes the signing flow easier to exit and keeps the experience consistent with portal users.
Original PR description
**Before this PR:** - Previously, when portal users signed documents, they received a "Thank You" dialog that included a close button for convenience. However, public users did not have this close button in their "Thank You" dialog, potentially leading to a less intuitive experience. **After this PR:** - To enhance the user experience for public users, a close button has now been added to the "Thank You" dialog. This adjustment aligns the experience of public users with that of portal users, providing a consistent and user-friendly interface. task-4069539 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Features or functions removed from Odoo
This update removes support for an older internal field option that was used when defining certain model fields. It keeps enterprise modules aligned with the main Odoo platform changes and helps prevent inconsistencies in Studio, field service reports, quality worksheets, and exports.
Original PR description
See the community PR. https://github.com/odoo/odoo/pull/133446 https://github.com/odoo/upgrade/pull/5091 https://github.com/odoo/upgrade-util/pull/154
Code cleanup and technical improvements
Side panel section titles now use a clearer configuration method while preserving translation support. This is an internal cleanup that makes spreadsheet-related side panels easier to maintain without changing user workflows.
Original PR description
Currently, the title of a `Section` component is a title slot. We are using a slot to translate the title: a props like `title="'My title'"` wouldn't work since this props is javascript expression, while text content inside xml elements are extracted and translated. But since the introduction of the `.translate` modifier, we can use a props! It's much more natural (props vs slot) and explicit (`.translate`) Task: 4226704
A duplicate menu item in the spreadsheet edition area was removed because the same option is already provided by the core spreadsheet component. This keeps the menu configuration simpler and more consistent without changing the intended user experience.
Original PR description
This menu item is also defined in o-spreadsheet but overwritten here with the same thing (except the name, sequence and separator, which have been adapted in o-spreadsheet) Task: 4242125
Miscellaneous changes
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72685 Forward-Port-Of: odoo
Original PR description
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72685 Forward-Port-Of: odoo/enterprise#71347
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#72614 Forward-Port-Of: odoo/enterprise#71851
Forward-Port-Of: odoo/enterprise#72581 Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72581 Forward-Port-Of: odoo/enterprise#72260
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position. Forward-Port-Of: odoo/enterprise#72548 Forward-Port-Of: odoo/enterprise#71857
In the `test_serial_product_packaging` tour, we scan 4 different serial numbers without waiting which can cause race condition (in case a scanned SN is finished to be processed before the previous scanned SN.) To fix that, two solutions: - Update each trigger to wait the result of previous scan; - Scan all SN as one single barcode, which force them to be processed in the right order. Second option is used by this commit since it's simplier. runbuild error: 99539 Forward-Port-Of: odoo/en
Original PR description
In the `test_serial_product_packaging` tour, we scan 4 different serial numbers without waiting which can cause race condition (in case a scanned SN is finished to be processed before the previous scanned SN.) To fix that, two solutions: - Update each trigger to wait the result of previous scan; - Scan all SN as one single barcode, which force them to be processed in the right order. Second option is used by this commit since it's simplier. runbuild error: 99539 Forward-Port-Of: odoo/enterprise#72520
task_id: 4261885 Forward-Port-Of: odoo/enterprise#72567
Original PR description
task_id: 4261885 Forward-Port-Of: odoo/enterprise#72567
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
### Before this PR: - The task column data was visible even when timesheets were grouped by task_id or helpdesk_ticket_id. - This caused misalignment in the table when grouped by these fields. ### After this PR: - The task column is hidden when timesheets are grouped by task_id or helpdesk_ticket_id. - The table headers is now correctly aligned. task-4184455 Forward-Port-Of: odoo/enterprise#71180
Original PR description
### Before this PR: - The task column data was visible even when timesheets were grouped by task_id or helpdesk_ticket_id. - This caused misalignment in the table when grouped by these fields. ### After this PR: - The task column is hidden when timesheets are grouped by task_id or helpdesk_ticket_id. - The table headers is now correctly aligned. task-4184455 Forward-Port-Of: odoo/enterprise#71180
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Steps to Reproduce: - Open All Timesheets in Timesheets app. - Scroll down in the grid view - Change view using view switcher Issue: - You can see that grid view starts at the top. - It is not the case in other views. Fix: - Adding root reference in useSetupAction Reason: - When a root reference is added it scrolls down the page to its previous state. task-4010043 Forward-Port-Of: odoo/enterprise#70637
Original PR description
Steps to Reproduce: - Open All Timesheets in Timesheets app. - Scroll down in the grid view - Change view using view switcher Issue: - You can see that grid view starts at the top. - It is not the case in other views. Fix: - Adding root reference in useSetupAction Reason: - When a root reference is added it scrolls down the page to its previous state. task-4010043 Forward-Port-Of: odoo/enterprise#70637
**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the cre
Original PR description
**Steps to reproduce:** 1. In the Sign app, create a sign request for a partner. 2. From the sign request email, cancel the request as the public user (partner). 3. The cancellation log is created without a partner assigned. **Issue:** When a public user (partner) cancels a sign request, the cancellation log entry does not have a partner_id. **Cause:** The partner_id was set as none when there was a public user **Solution:** Assign the partner_id to the sign log during the creation. task-4213637 Forward-Port-Of: odoo/enterprise#71335
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_
Original PR description
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next…
Current behaviour: --- When you click on the "request a document" link, then upload a document, you get a CSRF error Steps to reproduce: --- 1. Install documents 2. In documents, click the arrow next to "new", then "request" 3. Add a name, and a "request to", then click "request" 4. Go to messages, copy the link in the generated email 5. Paste the link in an incognito window 6. Upload a document, CSRF error Cause of the issue: --- The js file that adds the CSRF token (documents_public_pages.js) could not be loaded due to an error caused by website_sale_renting: `TypeError: odoo.define is not a function` The mixin file was loaded before the odoo module loader. Caused by: https://github.com/odoo/enterprise/commit/93d09071a08bd5de948886729d827b1c46e907d9 Fix: --- Put js code from website_sale_renting before owl.js which is right after assets_frontend_minimal, containing module_loader.js opw-4138333 Forward-Port-Of: odoo/enterprise#72159 Forward-Port-Of: odoo/enterprise#70577
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#72530 Forward-Port-Of: odoo/enterprise#71216
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: Unit - Create a transfer for one dozen of P1: - Mark it as "To Do" - Go to the MPS: - Add the product “P1” - In the filter, add “Actual Demand” Problem: The demand is shown as one unit instead of 12 units. The quantity of the move is not being converted into the UoM of product P1. opw-4199710 Forward-Port-Of: odoo/enterprise#72530 Forward-Port-Of: odoo/enterprise#71216
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over
Original PR description
## Description When looking for related documents on a large projects, it can inline a large list of ids (`task_ids`) into the following `_read_group` to retrieve the documents associated with any of the project's tasks. The improvement consists of using a subquery instead of a list of ids when the list `task_ids` becomes "too large". We are using `PREFETCH_MAX` for the "too large" threshold. ## Benchmark The `_read_group` to fetch the related documents on 5 projects, one of which has over 1M tasks. | | Before | After | Speed-up | |---------------|--------|-------|----------| | Timings (hot) | 2.85s | 1.16s | 2.45x | Forward-Port-Of: odoo/enterprise#72603 Forward-Port-Of: odoo/enterprise#72468
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
We we tried to open the report with a company without journal and that the report had journal filter set, it would crash. The goal is to set the label of the filter explicitely to "No Journal" and make the filter unclickable when this is the case. task-4267503 Forward-Port-Of: odoo/enterprise#72226
Original PR description
We we tried to open the report with a company without journal and that the report had journal filter set, it would crash. The goal is to set the label of the filter explicitely to "No Journal" and make the filter unclickable when this is the case. task-4267503 Forward-Port-Of: odoo/enterprise#72226
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onC
Original PR description
Steps to Reproduce: - Open Field Service in mobile view. - Change to Gantt View. - Click on any planning task in gantt view. Issue: - You get a traceback. Reason: - After the PR https://github.com/odoo/enterprise/pull/54292 we can have multiple buttons in gantt popover. - Here we try to add a onClick to button Edit/View. - Code was not adapted for multiple buttons being available. Fix: - Adapted code to work with multiple buttons and find the View/Edit button and add onClick. task-4204936 Forward-Port-Of: odoo/enterprise#72540 Forward-Port-Of: odoo/enterprise#71314
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archIn
Original PR description
Steps to reproduce ================== - Go to accounting > customer invoices - Open studio - Switch to the view tab - => The mass edit option is missing - Switch 'when creating record' to 'add record on top' - => The mass edit is displayed Cause of the issue ================== The mass_edit was displayed when `archInfo.editable` was set, but editable is meant to add new record on top or bottom. Solution ======== What we want is to show the mass_edit if we can edit: `archInfo.activeActions.edit === true` opw-4272416 Forward-Port-Of: odoo/enterprise#72616 Forward-Port-Of: odoo/enterprise#72516
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144 Forward-Port-Of: odoo/enterprise#72459
Original PR description
After this commit: === - When the user clicks the Create Store button, the location is now created in Atlas. task-4270144 Forward-Port-Of: odoo/enterprise#72459
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72455 Forward-Port-Of: odoo/enterprise#72396
Original PR description
In this PR: - Added a `rate_by_tax_tag` dictionary to store tax rates by tax type (IGST, CGST, SGST) at the line level. - Adjusted the logic to populate `gst_tax_rate` by summing the values from `rate_by_tax_tag`, ensuring accurate tax rate calculations when multiple tax types are involved. - This change improves handling of scenarios with different tax types and ensures consistent and accurate GST reporting. Forward-Port-Of: odoo/enterprise#72455 Forward-Port-Of: odoo/enterprise#72396
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays
Original PR description
Current behavior before PR: On mobile, when a guest joined a public channel via an invitation URL, the `Add a Reaction` icon appeared as `[]` instead of the `oi-smile-add` icon. This was due to Font Awesome loading after `odoo_ui_icons`, causing a conflict with the `fa` class. Before / After  Desired behavior after PR is merged: This PR fixes the issue, and now the `Add a Reaction` icon displays correctly. Related : [odoo/ #184552](https://github.com/odoo/odoo/pull/184552) Forward-Port-Of: odoo/enterprise#72507
The mail search panel was cleaned up by removing an unused setting that had no effect on how it appeared or behaved. This keeps the code simpler and easier to maintain without changing the user experience.
Original PR description
Purpose of this commit: This commit removes the unused `className` prop from the SearchMessagePanel, as it was never utilized in the component's template.
Resolved issues and error corrections
The table picker in the HTML editor now closes when users press most keys, instead of staying open while they type. This makes table insertion feel more predictable and avoids the picker lingering over the editing area.
Original PR description
**Current behavior before PR:** - After opening the table picker, it does not close when typing, unless Escape key was pressed **Desired behavior after PR is merged:** - Now, the table picker will close when any key is pressed except for arrow keys.
This fix ensures mobile users can create stock move records when required details are filled automatically in the background. It prevents situations where warehouse staff could be blocked from recording stock movements on mobile devices.
Original PR description
Since the `name` field is set via onchange, we need it here. Currently on mobile, a user may be prevented altogether from creating a stock move record in some situations. opw-4278098
Restores a previously removed action so customers with older analytic views can still use the view button without hitting an error. This prevents a user-facing crash and keeps existing custom or not-yet-updated screens working as expected.
Original PR description
The `action_read_distribution_model` method was removed from the following commit. https://github.com/odoo/odoo/pull/182278/commits/777dea298fd74f2349ca22d05fe7f48596216dfe Since the client's non-updated views still call it, but get a traceback as it doesn't exist anymore. Error:- ``` AttributeError: The method 'action_read_distribution_model' does not exist on the model 'account.analytic.distribution.model' ``` We add it again to fix the issue. sentry-5804153543
Sharing a project without adding collaborators no longer sends an unnecessary notification. This prevents confusing messages and makes the sharing flow clearer for users.
Original PR description
Previously, when a project was shared without adding collaborators, an incorrect notification was sent, potentially confusing for the user. this commit ensures no notification is triggered if the collaborator's O2M field is empty,thereby avoiding misleading messages. task-3956252
Changing a user's tour setting from the form now correctly stops any running guided tour when tours are disabled. This prevents unwanted onboarding or help tours from continuing after a user or administrator turns them off.
Original PR description
Before this commit, changing tour_enabled on the form view of the user was not deactivating the running tour. After this commit, the running tour is deactivated if the tour_enabled is false when loading the tour service. TASK-ID: 4276412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps the work order button column in manufacturing orders sized correctly when start, pause, or stop buttons appear or disappear. Users should see a cleaner, more reliable layout without needing to resize the page to refresh the view.
Original PR description
The column containing the buttons start/pause/stop does not recompute it's size when one of the button appears/disappears, but it does when the column/the page is resized. In this fix, we revert https://github.com/odoo/odoo/pull/169177 which was not relevant anymore and we ensure to recompute the width every time if we're not using the magic column width.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Pivot titles used only in dashboard editing screens will no longer be sent for translation. This reduces unnecessary translation work without changing what end users see in standard dashboards.
Original PR description
In standards dashboards, pivot titles are currently extracted from the json files to be translated. But those titles are not visible in dashboard mode (only in edit mode, in the side panels and menus). The cost of translating those titles is not worth it. .pot files will be re-exported later, when TIC is back. She already warned the translators to skip those translation anyway. Task 4239967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The analytic distribution model list now relies on Odoo's built-in form-opening button instead of a duplicate custom button. This keeps the interface consistent and avoids redundant controls for users when opening records.
Original PR description
In this commit: https://github.com/odoo/odoo/commit/43027a34a6e51901ff869beec2bba74218b29356 They added a new button to open the form view directly. If the view has an attribute open_form_view to True or being in debug mode. Since we manually added a button to do the exact same thing, let's use the button from the list view. task: 4204366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new Link Tracker record no longer triggers an error when required URL details are not yet filled in. This prevents an interruption for users setting up tracked links from Link Tracker or related apps like mass mailing.
Original PR description
After the new `_monkeypatches` of `url_join`/`_check_str_tuple` we're getting TypeError traceback on creating a Link Tracker. Steps ===== Install Link Tracker and an associate module(i.e., mass mailing) Turn on developer mode Open Link Tracker app and try to create a new record Traceback: `TypeError: Cannot mix str and bytes arguments (got (False, 'False'))` Technical: ========== When creating a new we don't have `short_url_host` or `code`, thus its giving False. Also, code was in in `""`, means False , "False", its unnecessary. After this commit: =================== There will be no traceback on creating a Link Tracker. Task-4279725
The payroll accounting test suite for Switzerland was adjusted to match a recent internal payslip validation change. This helps keep automated checks reliable and reduces the risk of payroll-related regressions reaching users.
The balance sheet report now handles companies that have no journals configured instead of showing an error. This prevents users from hitting a traceback when opening financial reports in empty or newly configured databases.
Original PR description
When there are no journals and the user tries to open the balance sheet report, a traceback will appear. Steps to reproduce the error: - Install ``account_reports`` module without demo data - Remove…
When there are no journals and the user tries to open the balance sheet report,
a traceback will appear.
Steps to reproduce the error:
- Install ``account_reports`` module without demo data
- Remove all journals
- Go Reporting > Open Balance sheet
Traceback:
```
StopIteration: null
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 1914, in get_options
initializer(options, previous_options=previous_options)
File "home/odoo/src/enterprise/18.0/account_reports/models/account_report.py", line 379, in _init_options_journals
options['journals'].extend(next(iter(company_journals_map.values())))
```
https://github.com/odoo/enterprise/blob/302eb1052609462fe607f77fcc934690f9abbe5a/account_reports/models/account_report.py#L379
When there are no journals ``company_journals_map`` will be empty,
So, it will lead to the above traceback.
sentry-5993507281Spreadsheet side panels now use a consistent bold style for their titles and labels. This fixes a visual inconsistency, making the interface feel more polished and easier to scan for users.
Original PR description
## Description The font weight of this side panel was previously inconsistent with other side panels. This commit ensures that the font weight is now uniform across all side panels. Task: 4194259
A test was added to ensure spreadsheet pivot autocomplete works correctly when using positional pivot arguments in Odoo. This helps prevent a previously fixed issue from returning and supports more reliable spreadsheet behavior for users.
Original PR description
This commit adds a test for a bug fix merged in o-spreadsheet, but the behavior can actually only be triggered in odoo, with positional pivot arguments. Task: 4235329
Miscellaneous changes
Follow-up of https://github.com/odoo/odoo/pull/182347 PR above improved out-of-focus counter, one of such improvements is to take new inbox messages into account. However, doing so had to unintended side-effect to make them play sound, open chat bubble, and display more than 1 notification. This happens because the inbox notification were treated like new message in chat notifications. This commit fixes the issue by limiting PR above of inbox new messages to contribute for the out-of
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/182347 PR above improved out-of-focus counter, one of such improvements is to take new inbox messages into account. However, doing so had to unintended side-effect to make them play sound, open chat bubble, and display more than 1 notification. This happens because the inbox notification were treated like new message in chat notifications. This commit fixes the issue by limiting PR above of inbox new messages to contribute for the out-of-focus counter. In other words, the following behaviors have been fixed: - new inbox messages from chatter no longer open a chat bubble - new inbox messages from chatter no longer play sound - new inbox messages from chatter only show 1 notification at most Forward-Port-Of: odoo/odoo#184620
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the
Original PR description
Problem: When a user is on a branch, they are unable to view the parent company's discounts and are unable to apply it to the sales orders. Purpose: The branch should have access to the discounts & loyalty programs from the parent company. Steps to Reproduce on Runbot: 1. Install sale_loyalty 2. Create a branch 3. On the branch company, observe that no discounts & loyalty programs from the parennt company are displayed 4. Attempt to apply a coupon code from a discount belonging to the parent company on a sales order and receive a ValidationError opw-4079487 closes odoo/odoo#182392 X-original-commit: 85d130302e88deb4ee8d1172d847d7ab78918418 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184807
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product
Original PR description
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost…
Fixes a rounding issue where the cost of kit components is rounded too early in the stock valuation process, leading to discrepancies in the final stock valuation layer values. The kit's total cost was being calculated with an early rounding step, which caused a small mismatch between the expected and actual values. This fix ensures that the correct unit cost is used in the stock valuation layer without affecting the product's standard price. Example: 1.) Create Product A: Storable Product Type Route = Manufacturing Category = AVCO or FIFO 2.) Create Product B: Storable Product Type Routes = Buy Category = AVCO or FIFO 3.) Make a BOM Product A Quantity = 1 Kit Components: 12 units of Product B 4.) Create a Purchase Order: Buy 1 unit of Product A at $100 5.) Confirm PO -> this will generate a receipt 6.) Validate receipt 7.) Note the valuation is 12 units @ a value of 99.96 where it should be 100 Current behavior before PR: svl.value = 99.96 Desired behavior after PR is merged: svl.value = 100 opw-4208554 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184805 Forward-Port-Of: odoo/odoo#183267
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). All l10n_* modules were changed in this PR: https://github.com/odoo/odoo/pull/183359 task-3794536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185027
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
Original PR description
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183901 Forward-Port-Of: odoo/odoo#166499
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that
Original PR description
A traceback occurs from version 18.0 when the user creates a new link tracker. To reproduce this issue in 18.0: 1) Install website, link tracker and enable debug mode 2) Tries to create a new link tracker record from the link tracker Error:- ``` TypeError: Cannot mix str and bytes arguments (got (False, 'False')) ``` The onchange sets computes to False by default when they're requested, and apparently does not recompute them if they don't depend on anything. Because of that the `short_url_host` value will be False and this leads to a traceback when the compute method of `short_url` triggers. Ref of the breaking commit:- https://github.com/odoo/odoo/pull/170548/commits/20d2f122568feead98df18706ca0a4691c8393c5 sentry-5969318187 Forward-Port-Of: odoo/odoo#182898
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184791 Forward-Port-Of: odoo/odoo#184584
Original PR description
An error message was missing a space in between "a" and "hamburger" in "ahamburger". This commit fixes this typo. Task-4173938 Forward-Port-Of: odoo/odoo#184791 Forward-Port-Of: odoo/odoo#184584
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
e-Resguardo document type must not have internal type **Current behavior before PR**: e-Resguardo document type has "invoice" internal type  **Desired behavior after PR is merged**: e-Resguardo document type do not have internal type **Task Adhoc side**: 43467 **Task Latam side**: 1280 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184810
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected.
Original PR description
Problem: When creating a purchase order (PO) for a company with branches, products from all branches are shown in the product list, even if only the main company is selected. However, users are not allowed to create POs for products belonging to other branches, leading to confusion. Steps to reproduce: - Create a company with branches. - Configure some products for the main company and others for the branches. - In the company selector, choose the main company, keeping branches selected. - While creating a PO, products from the branches appear in the product list. opw-4116680 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184757 Forward-Port-Of: odoo/odoo#180623
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06
Original PR description
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located…
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12) 2- We moved the taxes from files to match the same structure as l10n_ar Current behavior before PR: After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates. [[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a) Desired behavior after PR is merged: The taxes are no longer duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168945
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with
Original PR description
When upgrading a module where a model has been removed entirely, the ORM does a clean up for 'ir.model.fields.selection' records. However, in this case it doesn't work, because the records reference a model that no longer belongs to the registry (if there are no migration scripts). This commit simply makes the cleanup ignore such a case. It makes sense, because the whole table will be deleted anyway (if there are no migration scripts). STEPS - install a module that defines a model with a selection field - rename or remove the model - upgrade the module This commit fixes #179392. It was inspired by #104624. opw-3024537 Forward-Port-Of: odoo/odoo#184764
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-
Original PR description
A known issue in Brave (https://github.com/brave/brave-browser/issues/2362#issuecomment-571775236) prevents push notifications unless "Use Google Services for Push Messaging" is enabled in settings. Before this commit, attempting to enable desktop notifications in Brave resulted in a traceback. This commit handles the failure by displaying a more helpful message, suggesting enabling Google Services when using Brave, or showing a generic error for other browsers. task-4191214 Forward-Port-Of: odoo/odoo#184394 Forward-Port-Of: odoo/odoo#183968
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. opw-4247067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184679
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Original PR description
This commit allows uninvited admins to edit non-private events (public, confidential). It was a needed change since administrators might have to change the event information of these types of events day to day. A re-work of the compute methods will be made on master followed by the addition of the proper ACL rules for handling calendar events. task-4182649 Forward-Port-Of: odoo/odoo#180051
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in
Original PR description
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes #94390 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184962 Forward-Port-Of: odoo/odoo#94395
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376 Forward-Port-Of: odoo/odoo#184045
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184686 Forward-Port-Of: odoo/odoo#182509
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b
Original PR description
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase -…
Steps to reproduce: - Install `l10n_ec_website_sale` - Change the company of the first website to 'EC Company' - Change company of demo user to 'EC Company' - Connect as demo - Make a purchase - Checkout and fill the address - Create a new billing address Issues: A traceback appears, the reason is that `show_vat` is false here as we are editing a new billing address as such `partner_sudo != order_sudo.partner_id`. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/website_sale/controllers/main.py#L1159-L1168 Since `show_vat` is False the VAT fields will not be shown. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/views/templates.xml#L1990 However for ecuadorian company for example `vat` and `l10n_latam_identification_type_id` is set as mandatory. https://github.com/odoo/odoo/blob/4c025f91d4a13c9a150c4c16ac9754da0b2c79e4/addons/l10n_ec_website_sale/controllers/main.py#L17-L18 This discrepancy causes a traceback later on as we are requiring a field which is not visible in the view. https://github.com/odoo/odoo/blob/d61a8212ca795009ca4f39462991614a42e41700/addons/website_sale/static/src/js/address.js#L127-L135 opw-4139919 Forward-Port-Of: odoo/odoo#183705
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
Original PR description
Use Case : Argentinian Company (pesos) Invoice in USD Payment received in USD, with withholding tax on it The current logic will convert the withholding values from USD (payment currency) to USD (invoice currency) instead of converting to ARS (company currency) and set this value as balance. This is of course incorrect. opw-4150317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183726
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order lin
Original PR description
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will…
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order line 3. Click on a linked record in the "Used by" column in the report table 4. Click the browser back button -> traceback **Cause of the issue:** When trying to rebuild context, we get the actual model name provided by this.props.action.res_model. This was invariably treated as a stringified number in a read call to `ir.model` to try to get the model name -> result of the read is nonsense and when it is later used in an RPC, it tries to read fields from a nonexistent model. **Fix:** Get rid of the String -> Number conversion, directly use the value in `res_model` as the new `this.resModel`. opw-4181590 Forward-Port-Of: odoo/odoo#183742
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
Original PR description
The test depended on a module that was not in the depends. Forward-Port-Of: odoo/odoo#184578
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this b
Original PR description
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However…
__Current behavior before commit:__ The `info` variable contains the entry `isAvailable` used [here][1]. This should be updated as soon as a livechat operator enters or leaves the channel. However since this view is cached (by [this line][2]) it happens that the livechat bubble appears without any operators available and vice versa. __Description of the fix:__ Add a t-nocache to prevent `info` from being cached and always be up-to-date. __Steps to reproduce the issue:__ On runbot this behavior is inconsistent since each worker has its own cache. It is however consistent in local with only one worker. Make sure you are **not** in debug mode 1. Set a livechat channel on the website, make sure there is no chatbot on it 2. Enter the livechat channel with the admin 3. Open the website on an incognito window (the chat bubble should be there) 4. Leave the livechat channel with the admin 4. Refresh the incognito window The chat bubble is still there. Note that the chat bubble might not appear at all even when the admin enter the livechat if the opposite has been cached before. opw-4233744 [1]: https://github.com/odoo/odoo/blob/837a6a8/addons/im_livechat/views/im_livechat_channel_templates.xml#L100 [2]: https://github.com/odoo/odoo/blob/2997afa/addons/website/views/website_templates.xml#L86 Forward-Port-Of: odoo/odoo#184644
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of:
Original PR description
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import. Forward-Port-Of: odoo/odoo#184845
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72395
Original PR description
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom Task: 4273554 Forward-Port-Of: odoo/enterprise#72395
Forward-Port-Of: odoo/enterprise#72336 Forward-Port-Of: odoo/enterprise#72260
Original PR description
Forward-Port-Of: odoo/enterprise#72336 Forward-Port-Of: odoo/enterprise#72260
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Original PR description
CAF is based on the AVS Salary and not the GROSS Forward-Port-Of: odoo/enterprise#72550 Forward-Port-Of: odoo/enterprise#72534
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72480 Forward-Port-Of: odoo
Original PR description
Problem: The issue occurs when trying to select a different plan for a recurring product with variants in the e-commerce view. We are not refreshing the list of plans when we select another combination. Steps to reproduce: - Create a recurring product with variants. - Add multiple subscription plans with variants. - Go to the website and view the product page. - The selection of alternative plans is unavailable. opw-4179086 Forward-Port-Of: odoo/enterprise#72480 Forward-Port-Of: odoo/enterprise#71347
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead,
Original PR description
Steps to reproduce the issue: 1. Install the MRP module 2. Go to Production Analysis 3. Click on the pivot table 4. Select the `Expected component cost / unit` field 5. The miscalculation will be show for `expected_component_cost_unit`. It is dividing by the MO quantity produced rather than the BOM quantity. Explanation: The issue lies in the SQL query, where the expected cost is divided by `prod_qty.product_quantity`, meaning we are using the quantity produced by a MO. instead, it should be divided by the BOM quantity. Fix reasoning: With this commit, the issue is resolved by dividing the expected cost by the BOM `product_qty`. Forward-Port-Of: odoo/enterprise#69905
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#72579 Forward-Port-Of: odoo/enterprise#70405
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no wa
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172 Forward-Port-Of: odoo/enterprise#72503 Forward-Port-Of: odoo/enterprise#71851
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends t
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#72404 Forward-Port-Of: odoo/enterprise#70110
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643 Forward-Port-Of: odoo/enterprise#72523
This update fixes an inconsistency in how query counts are measured for the test_mail module. Previously, a specific setup caused inaccurate results, particularly in single-module builds. This change adds a reliable query counter, addressing a performance issue that has been resolved through an optimization in the ORM.
Original PR description
The query count in single module build is higher than the one with all modules installed. - test_mail_enterprise…
The query count in single module build is higher than the one with all modules installed. - test_mail_enterprise   - test_mail_enterprise + documents_project   In summary, a one2many fields document_ids on document_projects triggers an [orm optimisation](https://github.com/odoo/odoo/pull/111651/files) leading to 10 less queries. In 16.0 the query count adapted in an all-enterprise build fails in single module In 17.0 a regression of performance was missed because a margin is added on a bunch of query count that didn't break in the all-enterprise build This pr proposes to add a field with the corresponding optimization in the test module in stable, to have reliable query counter. This field will be moved to the document module in master. RunbotError-65777 Forward-Port-Of: odoo/enterprise#72598
This update resolves an issue where clicking 'Insert in spreadsheet' in pivot views incorrectly redirected users to the dashboard without saving. The fix, implemented starting with saas-17.4, completely removes the 'Dashboards' tab from the pivot view, eliminating the error. This ensures users can properly access spreadsheet functionality.
Original PR description
Steps to reproduce: - install Documents and CRM - login as Marc Demo - go to any pivot view - click on "Insert in spreadsheet" - select the Dashboards tab and confirm => boom In this version, the fix is sub-optimal. The user will be redirected to the dashboard, but nothing happens. It's fixed properly starting with saas-17.4 because the code changed and it's mush easier and safer to fix. The Dashboard tab won't appear at all. Task: 4273554
This update resolves a problem preventing the Social Marketing tour from functioning correctly. The fix addresses an issue with accessing a key input field and updates the tour's triggering mechanism for compatibility across Odoo versions. This ensures a smoother onboarding experience for new users.
Original PR description
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#71016