Daily updates from Odoo
Navigate
Branch
Tuesday, May 7, 2024
71 changes
1 change
Enhancements to existing features
Website language links now prefer simpler short codes, such as using /es for Latin American Spanish when appropriate. This improves consistency for multilingual sites and helps visitors and search engines reach the right localized pages more reliably.
Original PR description
1. When activating a language, sets it's url_code to the short form, if possible. Exemple, if installing fr_BE, it might reset fr_FR to fr_FR if it's not installed (instead of fr), and use the short code fr for fr_BE. 2. There should always be a shortened hreflang code, regardless if there is only one or multiple lang for this "group" of lang. For instance, if fr_BE and fr_FR are enabled for the french group of lang, one of them should be shortened and considered the default french lang for all the one not matching a sub-french lang. 3. Special case of previous point 2. for es_419, which is not a valid hreflang and always need to be the one shortened even if there is other spanish lang. For other langs, we don't care which one is shortened as long as one is, but for this one we need to be sure it's es_419 which is shortened. 4. Spanish LATAM should be the one with default /es url code. Courtesy of fpodoo for first point.
21 changes
Enhancements to existing features
Financial reports are now easier to read by showing currency units once on the report instead of repeating them in column headers. The Lakhs unit is also consistently available for currencies and regions where it is commonly used, improving clarity for affected users.
Original PR description
This commit improves the readability and simplicity of the reports by removing the currency units from column headers and displaying it only once on the report. + The Lakhs currency unit is now always available because a significant amount of countries (~10 in Asia) use this unit frequently task: 3798397
French FEC imports now preserve the settings of journals that already exist in the system. This prevents imported files from unexpectedly changing accounting journal information, reducing the risk of unintended configuration changes.
Original PR description
Prevent changing existing journals values when importing FEC file. https://www.odoo.com/web#model=project.task&id=3852683 Task-3852683
This update makes appointment setup and reporting clearer, improves consistency in Knowledge, and ensures social media posts link correctly to their live Instagram posts. It also fixes missing Instagram demo content so previews and published posts match more reliably.
Original PR description
*: appointment, knowledge, social, social_demo, social_instagram [Task 3775424](https://www.odoo.com/web#id=3775424&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form) [COM…
*: appointment, knowledge, social, social_demo, social_instagram
[Task 3775424](https://www.odoo.com/web#id=3775424&cids=1&menu_id=6478&action=4043&model=project.task&view_type=form)
[COM PR](https://github.com/odoo/odoo/pull/160182)
## Purpose
### Social
Make sure that each social post has a globe with a link to the real postFix the HTML message (tags should not be showed)
https://www.awesomescreenshot.com/image/46871268?key=9e8a3366f3cc69705f9fb42e8c74b62e
Looks like the IG demo post is not created while it appears in the previewhttps://tinyurl.com/29hmvt8k
### Appointments
Let's move this field to the options so that the basic config is easier https://tinyurl.com/258anfxb
Do not let people create resources calendar events (this is configuration)
Improve the action helper here: https://www.awesomescreenshot.com/image/46530811?key=82f07ef48c5ac9046dc6f019aab46440
No data yet!
Use this menu to overview your Appointments once you get some bookings.
Make sure that the "Published" is aligned with the rest of the card https://tinyurl.com/yneypsew
### Knowledge
Use the same brush icon on both sides https://www.awesomescreenshot.com/image/46530613?key=7a57b0b8451f090ce0ed1fbf8697f708
## Changes
### Social
- Fix a string format in an log message when posting on social media fails
- Implement the _compute_live_post_link() method on the social_instagram module so that the url for instagram post is now compute and usable.
- Add a missing record in the demo data of the social_demo_instagram. The live post record was missing therefore only the preview of the instagram post was visible.
### Appointments
- Move `<field name="avatars_display" widget="radio" options="{'horizontal': true}" required="1"/>` to the 'Options' page in the appointment_type_view_form
- Make the resources readonly from a calendar event (add `readonly="1"` and remove `editable="bottom"`)
- Reword the message of the helper in calendar_event_action_report_all and calendar_event_action_appointment_reporting
### Knowledge
- Change `fa-image` to `fa-paint-brush` in the sidebar templateUnread message counters now use the server as the source of truth, making counts more reliable across sessions and devices. This helps users see more accurate unread indicators and reduces confusion from outdated local counters.
Original PR description
part of task-2628317 commnity: https://github.com/odoo/odoo/pull/163341
Code cleanup and technical improvements
This update removes obsolete internal markers from Point of Sale-related files after a platform change made them unnecessary. It does not change business functionality, but helps keep the codebase simpler and easier to maintain.
Original PR description
In this commit we remove all instances of `/** @odoo-module */` in all the pos modules, as they no longer serve a purpose. After merging https://github.com/odoo/odoo/pull/142858, the `odoo-module` comment is not required anymore. Task: 3908813
Point of Sale WhatsApp receipts now use the same shared sending flow as email and SMS. This gives store staff a more consistent receipt-sending experience and makes future receipt delivery options easier to support.
Original PR description
In the corresponding PR we create a mechanism that allows easily adding methods for receipt sending. In this commit we adapt the whatsapp integration of pos the use the new mechanism, automatically integrating the changes described in task 3411407 with relation to the new common input box for all methods ( email, sms, whatsapp ) Task: 3905468
Miscellaneous changes
**Steps to reproduce:** - Install l10n_us_1099 - Go to "Accounting / Vendors / Vendors" - Create 2 vendors with "1099 Box" set to "MISC - 3 Other income" - Create a vendor bill with Vendor 1 - Create a vendor bill with Vendor 2 - Create another vendor bill with Vendor 1 - Go to "Accounting / Reporting / Management / 1099 Report" - Remove all lines from the wizard - Add the 3 created vendor bills - Make sure that the 2 bills from Vendor 1 are not successive as followed: 1) Vendor bill f
Original PR description
**Steps to reproduce:** - Install l10n_us_1099 - Go to "Accounting / Vendors / Vendors" - Create 2 vendors with "1099 Box" set to "MISC - 3 Other income" - Create a vendor bill with Vendor 1 - Create a vendor bill with Vendor 2 - Create another vendor bill with Vendor 1 - Go to "Accounting / Reporting / Management / 1099 Report" - Remove all lines from the wizard - Add the 3 created vendor bills - Make sure that the 2 bills from Vendor 1 are not successive as followed: 1) Vendor bill from Vendor 1 2) Vendor bill from Vendor 2 3) Vendor bill from Vendor 1 - Generate **Issue:** In the CSV file, there are 2 lines for Vendor 1. They should be grouped in one line as it is done when the lines are successive. **Cause:** A sort by partner is performed on the lines, but it is wrongly done. opw-3862390 Forward-Port-Of: odoo/enterprise#62058
Props aren't translated. This commit re-declares human-readable text outside of the props. opw-3908071 Forward-Port-Of: odoo/enterprise#62092
Original PR description
Props aren't translated. This commit re-declares human-readable text outside of the props. opw-3908071 Forward-Port-Of: odoo/enterprise#62092
The rental schedule (Gantt view) shows the display name of the rented products, which is read in sudo mode (`models.py` > `_read_group_format_result`). This display name includes the total product quantity, which considers all companies in the DB when computed in sudo mode (and without specifying a warehouse or location). However, we should only consider the selected companies. This change adds a domain which limits the companies that are considered when computing product quantities.
Original PR description
The rental schedule (Gantt view) shows the display name of the rented products, which is read in sudo mode (`models.py` > `_read_group_format_result`). This display name includes the total product quantity, which considers all companies in the DB when computed in sudo mode (and without specifying a warehouse or location). However, we should only consider the selected companies. This change adds a domain which limits the companies that are considered when computing product quantities. Community PR: https://github.com/odoo/odoo/pull/164196 opw-3877326 Forward-Port-Of: odoo/enterprise#61871
Functionality was removed during the refactor of the voip module between 16 and 17 where you could enter any number through the phone keypad on voip or receive a call and have access to the information on the customer with the associated phone number. This was a functionality that the customer on the ticket was using prior to upgrade. I have added back this functionality through a non blocking call to a new function in res.partner that will search up the contact based on the phone nu
Original PR description
Functionality was removed during the refactor of the voip module between 16 and 17 where you could enter any number through the phone keypad on voip or receive a call and have access to the information on the customer with the associated phone number. This was a functionality that the customer on the ticket was using prior to upgrade. I have added back this functionality through a non blocking call to a new function in res.partner that will search up the contact based on the phone number entered in the softphone. When the data comes back from the back end the UI will be updated with the partner information if it found it. This also has a side effect of fixing the customer wizard button as well. opw-3770625 Forward-Port-Of: odoo/enterprise#61995 Forward-Port-Of: odoo/enterprise#60383
In this commit [1], we forgot to have the same title for 2 filters: Analytic Filter and Analytic Group By. The aim of this commit is having the same title for these 2 filters and distinct them by using correct icon. We're using the group account from search view for the group by and the filter one for the analytic filter. In the mean time, we change the extra options one for something meaning more that it's a setting than a filter. no task id [1]: https://github.com/odoo/enterprise/comm
Original PR description
In this commit [1], we forgot to have the same title for 2 filters: Analytic Filter and Analytic Group By. The aim of this commit is having the same title for these 2 filters and distinct them by using correct icon. We're using the group account from search view for the group by and the filter one for the analytic filter. In the mean time, we change the extra options one for something meaning more that it's a setting than a filter. no task id [1]: https://github.com/odoo/enterprise/commit/a13a54921f8ae79e9ac3e2eb3f153a946a667192 Forward-Port-Of: odoo/enterprise#62091
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
Original PR description
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
After the two refactoring in [1] and [2], the `notification_data` key has been removed, so adapt the heuristic to detect if an App is installed by testing the presence of `storeData` instead. [1]: https://github.com/odoo/odoo/commit/c340cf73d656 [2]: https://github.com/odoo/odoo/commit/9c87c322471b Forward-Port-Of: odoo/enterprise#61467
Original PR description
After the two refactoring in [1] and [2], the `notification_data` key has been removed, so adapt the heuristic to detect if an App is installed by testing the presence of `storeData` instead. [1]: https://github.com/odoo/odoo/commit/c340cf73d656 [2]: https://github.com/odoo/odoo/commit/9c87c322471b Forward-Port-Of: odoo/enterprise#61467
Adds a new module for the PoS adaptation for Ecuador. task-3505211 Forward-Port-Of: odoo/enterprise#52783
Original PR description
Adds a new module for the PoS adaptation for Ecuador. task-3505211 Forward-Port-Of: odoo/enterprise#52783
**Current behavior:** POS preparation lines are currently created in a manner that is liable to have incorrect quantity information when the same product appears multiple times on a new order. **Expected behavior:** The preparation screen should display complete order data. **Steps to reproduce:** 1. Install pos_restaurant with demo data 2. In the restaurant pos session, add some productA to the order and modify its price with the keypad 3. Add the same product to the orde
Original PR description
**Current behavior:** POS preparation lines are currently created in a manner that is liable to have incorrect quantity information when the same product appears multiple times on a new order.…
**Current behavior:**
POS preparation lines are currently created in a manner that is
liable to have incorrect quantity information when the same
product appears multiple times on a new order.
**Expected behavior:**
The preparation screen should display complete order data.
**Steps to reproduce:**
1. Install pos_restaurant with demo data
2. In the restaurant pos session, add some productA to the order
and modify its price with the keypad
3. Add the same product to the order so that the two order lines
do not merge (as their prices are different)
4. Confirm the order, go to the Kitchen Display, observe that
there is only 1 preparation line
**Cause of the issue:**
In `_process_preparation_changes()` when we end up with a line
that should have >1 quantity, this value is not correctly
evaluated.
**Fix:**
Iterate over the order lines to create preparation order lines
with accurate quantities.
opw-3857347
Forward-Port-Of: odoo/enterprise#61155This commit removes the write override of calendar.event records, since this override was doing unnecessary requests on Google side when synchronizing again events that were just synchronized. After this commit, the function get_post_sync_values() will reuse the values returned by the insertion in Google and write in the event right away, saving requests to Google. The objective of the previous write override was to write the google meet URL in the event, and now this is still being done
Original PR description
This commit removes the write override of calendar.event records, since this override was doing unnecessary requests on Google side when synchronizing again events that were just synchronized. After this commit, the function get_post_sync_values() will reuse the values returned by the insertion in Google and write in the event right away, saving requests to Google. The objective of the previous write override was to write the google meet URL in the event, and now this is still being done correctly by means of the new strategy. related-to: https://github.com/odoo/odoo/pull/163364 task-389382 Forward-Port-Of: odoo/enterprise#61465
Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/152897 Forward-Port-Of: odoo/enterprise#61711 Forward-Port-
Original PR description
Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/152897 Forward-Port-Of: odoo/enterprise#61711 Forward-Port-Of: odoo/enterprise#55972
Configure 'Cash Discount Tax Reduction' on 'On early payment' Have a payment term configured with 2% discount for early payment Create an invoice with the said payment terms and the following lines: 1) qty 1, price unit 468, discount 28, tax 19% 2) qty 1, price unit 480, discount 28, tax 19% 3) qty 1, price unit 85, discount 28, tax 19% 4) qty 1, price unit 6, discount 0, tax 19% 5) qty 2, price unit 6, discount 0, tax 19% Register the payment with the early payment discount Check the
Original PR description
Configure 'Cash Discount Tax Reduction' on 'On early payment' Have a payment term configured with 2% discount for early payment Create an invoice with the said payment terms and the following lines:…
Configure 'Cash Discount Tax Reduction' on 'On early payment' Have a payment term configured with 2% discount for early payment Create an invoice with the said payment terms and the following lines: 1) qty 1, price unit 468, discount 28, tax 19% 2) qty 1, price unit 480, discount 28, tax 19% 3) qty 1, price unit 85, discount 28, tax 19% 4) qty 1, price unit 6, discount 0, tax 19% 5) qty 2, price unit 6, discount 0, tax 19% Register the payment with the early payment discount Check the payment Early payment lines amount are 15.23 + 2.90 (tax discount) = 18.13 Go to General Ledger Export "DATEV (ZIP)" and check accounting_entries.csv Early payment line amount will be 18.12 This occurs because when exporting the system recompute the tax amount due for each line with tax, so we give just a line with the gross amount. However, when the payment is created, the system check for rounding errors and adjust the computed tax amount. This is not done when exporting data and we have a 0.01 difference with the payment entry opw-3801374 Forward-Port-Of: odoo/enterprise#61968 Forward-Port-Of: odoo/enterprise#60927
The translation files for the Italian accounting reports were out of date. Also, some terms in the reports were still in Italian, while all the rest was in English. In this commit, we make sure all source terms are in English and all translations are exported and translated correctly. Forward-Port-Of: odoo/enterprise#61464 Forward-Port-Of: odoo/enterprise#61437
Original PR description
The translation files for the Italian accounting reports were out of date. Also, some terms in the reports were still in Italian, while all the rest was in English. In this commit, we make sure all source terms are in English and all translations are exported and translated correctly. Forward-Port-Of: odoo/enterprise#61464 Forward-Port-Of: odoo/enterprise#61437
Here https://github.com/odoo/odoo/blob/8c853caed272154e74f4f1547891944c8848ff90/addons/survey/controllers/main.py#L88-L90 To authorize user, we check whether answer_sudo.partner_id != request.env.user.partner_id Thus, when we send survey to user, we should first get employee.user_id.partner_id. Otherwise if employee.user_id.partner_id is not the same as employee.work_contact_id and we send survey to user on employee.work_contact_id, they will be redirected to answer_wrong_user Forward-Port-O
Original PR description
Here https://github.com/odoo/odoo/blob/8c853caed272154e74f4f1547891944c8848ff90/addons/survey/controllers/main.py#L88-L90 To authorize user, we check whether answer_sudo.partner_id != request.env.user.partner_id Thus, when we send survey to user, we should first get employee.user_id.partner_id. Otherwise if employee.user_id.partner_id is not the same as employee.work_contact_id and we send survey to user on employee.work_contact_id, they will be redirected to answer_wrong_user Forward-Port-Of: odoo/enterprise#61225 Forward-Port-Of: odoo/enterprise#61130
Issue: ====== In kanban view , some data are missing. Steps to reproduce the issue: ============================= - Make sure to have some subscriptions in progress stage. - Go to kanban view, there is no subscription in the progress stage. Origin of the issue: ==================== Calling `_group_expand_states` will add 2 stages `3_progress` and `4_paused` but when calling `web_read_group` there is already group `3_progress` so in `read_group_fill_result` we will have duplicate gr
Original PR description
Issue: ====== In kanban view , some data are missing. Steps to reproduce the issue: ============================= - Make sure to have some subscriptions in progress stage. - Go to kanban view, there is no subscription in the progress stage. Origin of the issue: ==================== Calling `_group_expand_states` will add 2 stages `3_progress` and `4_paused` but when calling `web_read_group` there is already group `3_progress` so in `read_group_fill_result` we will have duplicate group, The first we loop over the group we have the data correctly but we remove it from the dict and then for the second time we don't find any data and it will be overriden and become empty. Solution: ========= Return only distinct groups. opw-3891031 Forward-Port-Of: odoo/enterprise#61742
49 changes
Enhancements to existing features
This update improves the Nigerian tax reporting system by adding warning messages to tax reports and removing the Closing Entry button from the Withholding tax report. These changes help ensure compliance and prevent incorrect actions when processing Nigerian tax documents. The update also includes new tests to verify the reports work correctly.
Original PR description
This commit extends tax reports added in l10n_ng to show warnings and hide the Closing Entry button on Withholding tax report. Also adds tax report tests. Odoo PR: https://github.com/odoo/odoo/pull/148370 Task [link](https://www.odoo.com/web#model=project.task&id=3607459) task-3607459
This update adds support for a 5% non-deductible tax option in Odoo's Spanish localization module. Previously, users who needed to declare this specific tax type on vendor bills had to manually enter it in the SII system afterward. Now the tax is automatically available, streamlining the accounting process for Spanish businesses that require this tax classification.
Original PR description
Description of the issue/feature this PR addresses: - Needing to declare a 5% non-deductible tax on a vendor bill but not having the available tax in Odoo, needing to declare manually in SII afterwards Current behavior before PR: - There are currently 0, 4, 5, 10 and 21% taxes in Spain and non-deductibles for 4, 10 and 21. The 0 and 5 are new this year added in this https://github.com/odoo/odoo/pull/108868 PR, they don't apply to that many things so it isn't very common to get the need to declare 5% non-deductible, but if you do it isn't available Desired behavior after PR is merged: - The tax is created automatically with the rest of the non-deductibles --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159127 Forward-Port-Of: odoo/odoo#128498
This update improves the performance of deleting batch payments by adding database indexes to key payment-related tables. Deleting large batch payments (500+ payments) is now 10 times faster, reducing processing time from over 20 minutes to less than 2 minutes.
Original PR description
Description of the issue/feature this PR addresses: When deleting a batch payment including all its payments (around 500) it took ages until the query was through. Current behavior before PR: To delete it takes more than 20 minutes. Desired behavior after PR is merged: After adding these indexes the time got reduced so that it took less than 2 minutes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164654 Forward-Port-Of: odoo/odoo#163564
Resolved issues and error corrections
Fixed a bug where users could delete the "Signature Request" tag from contracts, causing signing to fail. The system now prevents deletion of this critical tag to ensure contracts can always be signed properly.
Original PR description
Steps to reproduce the bug: -create a contract -send him to sign -delete the tag "Signature Request" -connect has the signer -try to sign the contract -> error Expected behavior: The tag shouldn't be deletable fix: add a constraint to prevent the deletion of the tag and force create task-3695553
This fix resolves a critical error that occurred when users tried to filter the Journal Report by account types. The report was crashing because the database query was missing a required table reference. Users can now successfully apply the account type filter in their accounting reports without encountering errors.
Original PR description
Module : account_reports Issue reproduction : - Go to Accounting / Configuration / Management / Accounting reports - Edit "Journal Report" - Activate the filter "Account types" in the options tab -…
Module : account_reports Issue reproduction : - Go to Accounting / Configuration / Management / Accounting reports - Edit "Journal Report" - Activate the filter "Account types" in the options tab - Go on Accounting / Reporting / Audit reports / Journal Report - traceback with a psycopg2.errors.UndefinedTable error Cause : The query generated in **_query_journal()** on account_journal_report.py doesn't use **account_account** table in the FROM clause. This table is included in the **tables** value created from **_query_get()** but this variable can't be used as it is because it starts with the **account_move_line** table for the FROM clause. Solution : Use the **tables** variable and modify the sql query. Versions impacted : - 16.0, saas-16-1, saas-16-2, saas-16-3, saas-16-4 - 17, saas-17-1 Note : **filter_account_type** change from a boolean field to a selection field from version 17 but the error is the same Support ticket : 3708809 Forward-Port-Of: odoo/enterprise#58885 Forward-Port-Of: odoo/enterprise#57828
This fix resolves an issue where duplicating marketing campaigns would fail if they contained server action activities instead of email activities. Previously, the system incorrectly required email-specific fields for all activity types, causing errors. Now users can successfully duplicate marketing campaigns regardless of the activity type used.
Original PR description
### [FIX] marketing_automation: CP MarketingCampaign with server action activity Until now copying MarketingActivity it was required to have mass_mailing_id. However MarketingActivity can have other activity_type than email in which mass_mailing_id is not existent, thus causing errors when trying to duplicate an Activity. ### [Reproduce] Steps to reproduce: - Install marketing_automation - Go to Marketing Automation / Campaigns - Create a marketing automation with an activity called "server action" - Duplicate the marketing automation -> BUG: Traceback ### [Related] https://github.com/odoo/enterprise/commit/4275e172342cd4b201d1eb703aa02cfc1ceb0a76 <-this commit introduced copy_data opw-3745805
Fixed an issue where cancelled work orders were incorrectly displayed in the shop floor interface. When creating a backorder for manufacturing operations, previously completed operations would be marked as cancelled but still visible to users. This update ensures cancelled work orders are hidden from the shop floor display, reducing confusion and improving the user experience.
Original PR description
Steps to reproduce: - Create a BOM with multiple operations - Create an MO for it with qty 2 - Mark all operations as done with qty 2 excpet the last - Set qty as 1 on the last operation and create a backorder Bug: the created WO for the first operations are cancelled since all the necessary components have already been produced but they shouldn't be displayed since they are already cancelled opw-3737758
This fix resolves an issue where selecting "None" as a functionality filter in Sendcloud shipping configuration would incorrectly filter out all shipping methods and display an error. The problem was that the system was comparing the text string "None" against a null value type. The fix ensures proper string comparison so that "None" selections work as intended.
Original PR description
Steps to reproduce: Configure Sendcloud with a shipping product that provides customizable functionalities, and select `None` as the functionality filter. All of the shipping methods will be filtered out and we get an error message: `There's no shipping method matching all your selected filters for this picking/order.` The issue is that `'None'` is passed as a string in the list of functionalities but it is checked as `None` type. To fix the issue we check if the string exists in the filter. opw-3878116
This update resolves a technical error that occurred when customers canceled their PayPal subscription payments. The system was throwing an error during the cancellation process, preventing subscriptions from being properly canceled. This fix ensures that subscription cancellations through PayPal now work smoothly without interruption.
Original PR description
TypeError: PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given opw-3708875
The rental schedule view was incorrectly displaying product quantities by combining data from all companies in the system, rather than just the selected company. This fix ensures that when viewing the rental schedule, product quantities are calculated only for the relevant company, providing accurate inventory information for each business unit.
Original PR description
The rental schedule (Gantt view) shows the display name of the rented products, which is read in sudo mode (`models.py` > `_read_group_format_result`). This display name includes the total product quantity, which considers all companies in the DB when computed in sudo mode (and without specifying a warehouse or location). However, we should only consider the selected companies. This change adds a domain which limits the companies that are considered when computing product quantities. Community PR: https://github.com/odoo/odoo/pull/164196 opw-3877326
The Italian accounting reports module had outdated translation files with inconsistent language use—some terms were in Italian while others were in English. This update standardizes all source text to English and ensures all translations are properly exported and translated, improving consistency and user experience for Italian-speaking users.
Original PR description
The translation files for the Italian accounting reports were out of date. Also, some terms in the reports were still in Italian, while all the rest was in English. In this commit, we make sure all source terms are in English and all translations are exported and translated correctly. Forward-Port-Of: odoo/enterprise#61464 Forward-Port-Of: odoo/enterprise#61437
This fix resolves an issue where grouping financial reports by certain field types (like boolean fields) would cause the system to crash. The update ensures that only model-related fields are converted to numeric IDs during processing, while other field types are handled correctly. This allows users to group account reports by any supported field without errors.
Original PR description
Trying to group on a field such as the boolean tax_tag_invert, for example, used to crash because of the value conversion that was done in the process of parsing the generic id assigned to the groupby line. We fix that by ensuring the value only gets converted to an int when a model is assigned to the line, meaning the value has to be a model id. In all other cases, the value will be put as-is in the generic id, and its string representation will hence be used in the UI. Forward-Port-Of: odoo/enterprise#61389
This fix restores the ability to attach CFDI (Mexican tax) documents to payment receipt emails when sending them in bulk. Previously, these required documents were missing from email attachments after a system refactoring, which could cause compliance issues for Mexican companies. The fix ensures that when users send multiple payment receipts by email, the necessary CFDI XML files are properly included.
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create 2 invoices: - Customer: [any] (e.g. Deco Addict) - Product: [Three-Seat Sofa] - Confirm the invoice - Generate CFDI via "Send & Print" button - Register Payment (Payment Way: Monedero Electrónico) - Click on "Update Payments" button - Go to the payment - Force CFDI for both payment - From the view list, select both payments and send receipts by email Issue: The CFDI documents of the payments are not in the attachments of the email as it was in previous versions. Cause: The feature was lost during the refactoring of "l10n_mx_edi" module to not depend on "account_edi" module opw-3838799 Forward-Port-Of: odoo/enterprise#61552
This fix corrects how vendor information is grouped in the 1099 tax report. Previously, when vendor bills from the same vendor were not listed consecutively, they would appear as separate lines in the generated CSV file instead of being combined into one. The fix ensures all bills from the same vendor are properly consolidated into a single line, regardless of their order in the report.
Original PR description
**Steps to reproduce:** - Install l10n_us_1099 - Go to "Accounting / Vendors / Vendors" - Create 2 vendors with "1099 Box" set to "MISC - 3 Other income" - Create a vendor bill with Vendor 1 - Create a vendor bill with Vendor 2 - Create another vendor bill with Vendor 1 - Go to "Accounting / Reporting / Management / 1099 Report" - Remove all lines from the wizard - Add the 3 created vendor bills - Make sure that the 2 bills from Vendor 1 are not successive as followed: 1) Vendor bill from Vendor 1 2) Vendor bill from Vendor 2 3) Vendor bill from Vendor 1 - Generate **Issue:** In the CSV file, there are 2 lines for Vendor 1. They should be grouped in one line as it is done when the lines are successive. **Cause:** A sort by partner is performed on the lines, but it is wrongly done. opw-3862390 Forward-Port-Of: odoo/enterprise#62058
The "open record" button in the VoIP correspondence details panel was not working after a recent refactoring. When users clicked the button, the softphone would collapse but the record wouldn't display. This fix restores the functionality by adjusting how the system retrieves data, ensuring records open properly when requested.
Original PR description
Since the complete refactoring of the module in 17, the "open record" button of the CorrespondenceDetails no longer works: Clicking it causes the softphone to fold, but nothing more happens (the record is not displayed as expected). This is because we started retrieving the ORM service from the `useService` hook, whereas before we used to retrieve it from the env. `useService` untransparently wraps the ORM call in a "_protectMethod", which drops the return value of an RPC if the component that made it has been destroyed in the meantime. Since clicking the "open record" button also folds the softphone, it destroyed the Correspondence Details component, preventing it from ever receiving the RPC's return value. This commit changes the way the ORM service is retrieved in order not to use `useService` and to solve the problem. opw-3904519
This update fixes an issue where certain text in the POS order tracking display feature was not being translated into different languages. The fix reorganizes how text is structured in the code to ensure all customer-facing content can be properly translated for international users.
Original PR description
Props aren't translated. This commit re-declares human-readable text outside of the props. opw-3908071
This fix resolves an issue where employees receiving appraisal surveys were incorrectly denied access if their work contact address differed from their user profile address. The system now properly authorizes employees to access surveys sent to their work location, improving the appraisal feedback process.
Original PR description
Here https://github.com/odoo/odoo/blob/8c853caed272154e74f4f1547891944c8848ff90/addons/survey/controllers/main.py#L88-L90 To authorize user, we check whether answer_sudo.partner_id != request.env.user.partner_id Thus, when we send survey to user, we should first get employee.user_id.partner_id. Otherwise if employee.user_id.partner_id is not the same as employee.work_contact_id and we send survey to user on employee.work_contact_id, they will be redirected to answer_wrong_user Forward-Port-Of: odoo/enterprise#61225 Forward-Port-Of: odoo/enterprise#61130
This fix resolves a system error that occurred when users without timezone settings (such as public/guest users) accessed the rental website. The system now automatically uses UTC timezone as a fallback when a user's timezone is not configured, preventing the application from crashing.
Original PR description
**Issue** Traceback happening when a user has no tz set (ex: public user). Introduced by 33769684021e0d9692253f13a7a509637bc9fb3d **Fix** Check if user has tz and fallback on UTC. opw-3911386
This fix resolves an issue where GST treatment information was not being calculated when bills were created directly from expense sheets. The system now properly computes GST treatment details at the moment a bill is created, ensuring accurate tax classification for Indian GST compliance.
Original PR description
When creating a bill from an expense sheet, we post it directly, therefore the `l10n_in_gst_treatment` field is not computed because the move does not satisfy the condition, that is to be in draft in `_compute_l10n_in_gst_treatment()` since https://github.com/odoo/odoo/commit/f7147b36da0b3963e5bafb09cb585f130dcbfcf0 By adding precompute to the field, we allow it to be computed directly at the creation of the record. opw-3802240
This fix adds a warning message when users try to reserve a serial number that is already out of stock in a rental order. Previously, the system would allow the same serial number to be reserved multiple times without alerting the user, which could cause inventory issues. Now when a reserved lot is selected, the system checks availability and warns if the item is unavailable.
Original PR description
Steps to reproduce: ------------------- - create a storable product tracked by serial number; - create a serial number for this product; - add 1 quantity on hand for it; - create a rental order with the product; - add the created serial number in "Reserved lot"; - confirm and pickup; - create an other rental order; - add the product and the same "Reserved lot"; Issue: ------ There is no warning even if the serial number of the product is already out of stock. Solution: --------- Add a check when the `reserved_lot_ids` field is modified using an onchange method. Note: ----- Use `lot_id.ids` instead of `lot_id.id` in order to fallback on the id of the original record during a virtual record (which is the case during onchange). This also makes it possible to check multiple stock lot at the same time. opw-3839116
The Accounting app's Chart of Accounts was showing the "Duplicate" action menu twice when selecting entries. This fix removes the redundant duplicate action that was defined in the accounting module, since the same action is now provided by the system's list view. Users will now see the action only once, providing a cleaner and less confusing interface.
Original PR description
**Steps:** Go to Accounting App > Configuration > Chart of Accounts Select checkbox for any entry Now click on the Action Button **Issue:** "Duplicate" action menu is displayed 2 times…
**Steps:** Go to Accounting App > Configuration > Chart of Accounts Select checkbox for any entry Now click on the Action Button **Issue:** "Duplicate" action menu is displayed 2 times  **Cause:** Prior to this update, the 'list_controller.js' file in version saas~16.4 did not included the "Duplicate" menu action within the [getActionMenuItems](https://github.com/odoo/odoo/blob/saas-16.4/addons/web/static/src/views/list/list_controller.js#L287-L325) function. However, in the same version, the 'account.account' model defined this action in the [account_account_views.xml](https://github.com/odoo/odoo/blob/saas-16.4/addons/account/views/account_account_views.xml#L189-L198) file, utilized within the 'Chart of Accounts' in the Accounting app. In version 17.0, the "Duplicate" menu action was added to the [getStaticActionMenuItems](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/list/list_controller.js/#L304-L349) function of 'list_controller.js'. Following the update, despite the addition of the "Duplicate" menu action in the 'list_controller.js' file for version 17.0, it still remained present in the [account_account_views.xml](https://github.com/odoo/odoo/blob/17.0/addons/account/views/account_account_views.xml#L188-L197) file. **Fix:** Removed the 'action_duplicate_account' from account_account_views.xml, and 'action_duplicate_accounts' function from account_account.py, to ensure the same menu action "Duplicate" do not exist twice, in the 'Chart of Accounts'. Affected Version: 17.0 ~ master Task ID: [3854557](https://www.odoo.com/web#id=3854557&cids=2&menu_id=4720&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
This fix resolves an error that occurred when adding Spanish electronic invoicing certificates to company settings. Previously, users would encounter a system error when trying to save a Spanish certificate. The update corrects the certificate field validation, allowing Spanish companies to properly configure their electronic invoicing certificates without errors.
Original PR description
Description of the issue/feature this PR addresses: Fix the error None field by checking the certificates field Current behavior before PR: Using an spanish certificate in res.company (field ->…
Description of the issue/feature this PR addresses: Fix the error None field by checking the certificates field Current behavior before PR: Using an spanish certificate in res.company (field -> l10n_es_edi_facturae_certificate_id) returns error none field. When trying to save the changes you get the error: RPC_ERROR Odoo Server Error Traceback (most recent call last): File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1765, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying result = func() File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1792, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1996, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "/home/odoo/src/odoo/17.0/odoo/http.py", line 722, in route_wrapper result = endpoint(self, *args, **params_ok) File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 24, in call_kw return self._call_kw(model, method, args, kwargs) File "/home/odoo/src/odoo/17.0/addons/web/controllers/dataset.py", line 20, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 468, in call_kw result = _call_kw_multi(method, model, args, kwargs) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 453, in _call_kw_multi result = method(recs, *args, **kwargs) File "/home/odoo/src/odoo/17.0/addons/web/models/models.py", line 73, in web_save self = self.create(vals) File "<decorator-gen-364>", line 2, in create File "/home/odoo/src/odoo/17.0/odoo/api.py", line 414, in _model_create_multi return create(self, [arg]) File "/home/odoo/src/odoo/17.0/addons/l10n_es_edi_facturae/models/l10n_es_edi_facturae_certificate.py", line 54, in create if fields.datetime.now() > certif.not_valid_after: AttributeError: 'NoneType' object has no attribute 'not_valid_after' Desired behavior after PR is merged: Save the certificate.
This update fixes an issue where Senegal phone numbers weren't being formatted correctly in the contacts module. The phone validation system now uses updated formatting rules for Senegal numbers, ensuring they display properly with correct spacing. Additionally, the testing approach was improved to be more reliable and maintainable.
Original PR description
### [FIX] phone_validation: Upgrade SN Senegal phonenumbers module metadata The Python module 'phonenumbers' received an update, which includes localization data for Senegal "SN" phone number…
### [FIX] phone_validation: Upgrade SN Senegal phonenumbers module metadata
The Python module 'phonenumbers' received an update,
which includes localization data for Senegal "SN" phone number patterns.
At odoo we still use non-updated version of the 'phonenumbers', because
'phonenumbers' is an external module tied to the Ubuntu module repository,
that is not expected to receive a bump to the latest version soon.
This commit brings changes from the newest phonenumbers version into the
odoo as a metadata patch.
### [Reproduce]
- Ensure 'phonenumbers' version 8.12 is used by Odoo.
- Install the contacts module.
- Create a new contact.
- Insert "+221750142092" into the phone or mobile field.
- Bug: Observe that the number isn't formatted correctly
(spaces are not inserted to divide the number).
### [Issue Explanation]
In version 8.12 of the 'phonenumbers' module in the Ubuntu repository,
the regex used to recognize mobile numbers was: "7(?:[06-8]\d|21|90)\d{6}"
which failed to capture some numbers. In the latest version of
'phonenumbers', the regex has been updated to:
"7(?:(?:[06-8]\\d|21|90)\d|5(?:01|[19]0|25|[38]3|[4-7]\\d))\d{5}"
opw-3663379
## [[REF] phone_validation: phonenumbers moneky poatches redesigned approach](https://github.com/odoo/odoo/pull/156442/commits/e78196deb34daaa09323e4f30ccf44e66e3ca3f1)
### I Test purpose
Before tests were doing 2 things:
- checking if monkey patch was applied (with rather complicated check)
- checking if numbers that we consider correct are correct
After
- tests are only responsible for ensuring that numbers are passed corrctly
### II was patch applied?
What about checking if patch was applied? Well that depends strictly
on the version of phonenumbers that got installed. So if the version of
phonenumber is withing boundaries defined for patching then we patch
else we don't patch.
Logging mechanism was added such that we'll know that we started
using newer version of phonenumbers and the monkeypatch can be removed
from the code
### III Test consistency
Before each test had slightly different approach to checking whether
parsing is performed correctly, but they were doing so with different
granuality: some tests were only checking whether number is valid, some
if parsed country code is correct
After the refactor we have one-for-all testing approach which
is based on creating a dataset of inputs and outputs. We run parsing for
all the inputs and then we perform checks against given outputs (which are
considered to be ground-truths). We can specyfy all the outputs (we
check region and national number of the parsed results), some of them, or
none (in which case we'd only check simple validity of parsed number).
### IV Naming convetions
coutry code in difrent sources can mean either literal ISO code (eg. "SN")
or numeral code (eg. +221). This commit sticks to the following
convention
"region" always refers to the 2 letter literal ISO country code (eg. "SN")
"code" - always refers to number code (eg. +221)
Forward-Port-Of: odoo/odoo#163955
Forward-Port-Of: odoo/odoo#156442This fix corrects a bug in the Point of Sale module where tax amounts were being counted twice in the tax report when using QR code invoices. The issue occurred because reversed POS entries had inverted amounts but kept the same tax tags, causing incorrect tax calculations. This fix ensures tax amounts are properly adjusted when reversing entries.
Original PR description
With BE localization Enable 'Use QR code on ticket' in Settings Open POS Session Add a Product with 21% Tax Pay > Save QR link for later Close Pos session Access QR link, generate invoice Check Accounting>Reporting>Tax Report Issue: Line '03 - Operations subject to 21% VAT' will account twice the product amount instead of canceling it This occurs because when reverting the POS closing entry we create an entry having amounts with inverted signs but same tax tags as the original invoice. opw-3815770 opw-3821017 opw-3869363 X-original-commit: 594a0e2800eb4cb516051231535cd14b06727189 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
The rental schedule view was incorrectly displaying product quantities by considering inventory from all companies in the system instead of just the selected companies. This fix ensures that when viewing the rental schedule, product quantities are calculated only for the companies you've selected, providing accurate inventory information for multi-company operations.
Original PR description
The rental schedule (Gantt view) shows the display name of the rented products, which is read in sudo mode (`models.py` > `_read_group_format_result`). This display name includes the total product quantity, which considers all companies in the DB when computed in sudo mode (and without specifying a warehouse or location). However, we should only consider the selected companies. This change adds a domain which limits the companies that are considered when computing product quantities. Enterprise PR: https://github.com/odoo/enterprise/pull/61871 opw-3877326
Fixed an issue where customers could only click on the text label of product attribute pills in eCommerce, making it difficult to select options. Now the entire pill button is clickable, providing a better user experience when browsing products with pill-style attributes.
Original PR description
Steps to reproduce: 1) Configure an attribute with the display type 'pills' 2) Go to a product page in eCommerce 3) Try to click on the edges of pills Problem: Only label is clickable for pills. After this commit the whole pill will be clickable. opw-3890267 Forward-Port-Of: odoo/odoo#164202
This fix resolves a checkout failure (403 error) that occurred when customers tried to purchase items after a previous order had been created with certain delivery addresses. The system was incorrectly using delivery address information from all past orders instead of just website orders, causing permission issues during checkout. Now the system only considers website-based orders when preparing a new cart, ensuring a smooth checkout experience.
Original PR description
Steps ----- - Install Ecommerce - Create a new internal user - Website > Ecommerce > Orders, create an order for a portal user (Joel Willis for example) and use as a delivery address the contact of…
Steps ----- - Install Ecommerce - Create a new internal user - Website > Ecommerce > Orders, create an order for a portal user (Joel Willis for example) and use as a delivery address the contact of the user created at the previous step. Confirm this order. - Make sure Joel Willis doesn't have open quotations. - With Joel Willis, add an item to your cart on the website and go to checkout. ** 403 Forbidden ** Issue ----- When a partner proceeds to checkout, a new SO is created using the delivery address of the last SO. https://github.com/odoo/odoo/blob/d4b046e2388635d9a328dbdec9315963c9447a6a/addons/website_sale/models/website.py#L362-L366 Which results in a 403 in the checkout proccess because the partner used in the delivery is not in https://github.com/odoo/odoo/blob/d4b046e2388635d9a328dbdec9315963c9447a6a/addons/website_sale/controllers/main.py#L805 Some cases where it fails: - the delivery address on the last SO was an employee. - the delivery address on the last SO was the contact created when a user is created, as the contact will be linked to the company of the created user. Fix ----- Use the last SO coming from the website so non ecommerce orders don't impact default cart creation. opw-3827114 Forward-Port-Of: odoo/odoo#162623
This fix corrects a bug where the "Check Availability" button was incorrectly displayed in picking batches when a picking was canceled, even though all items were already reserved. The button now only appears when it's actually needed, improving the user experience and reducing confusion.
Original PR description
Before this commit, if a picking batch contains a canceled picking, the "Show Availability" button is shown, even if it makes no sense (for receipts or when all reservable qty. are already reserved). How to reproduce: - Create a batch with at least two pickings, those pickings have to be fully reserved; - Cancel one picking -> The "Check Availability" button is displayed even if all relevant pickings have already their reservation. Also, removes unused import. Forward-Port-Of: odoo/odoo#162183 Forward-Port-Of: odoo/odoo#162008
This fix resolves an error that appeared when customers clicked the "Buy Now" button on website product pages. The issue occurred because the system was trying to process a response that wasn't properly formatted as a Promise. By ensuring the response is always treated as a Promise, customers can now successfully complete their purchase without encountering an error popup.
Original PR description
__Current behavior before commit:__ When clicking on the "Buy now" button on a website product page, [`_submitForm`][1] is called. At some point, `this._super` might call [`sendRequest`][2] which…
__Current behavior before commit:__ When clicking on the "Buy now" button on a website product page, [`_submitForm`][1] is called. At some point, `this._super` might call [`sendRequest`][2] which does not return a Promise. A popup with the following traceback will therefore appear because `then` is called on `ret` which, in this case, is not a Promise: `TypeError: Cannot read properties of undefined (reading 'then')` __Description of the fix:__ Use `Promise.resolve` to make sure `ret` is a Promise. __Steps to reproduce the issue on runbot:__ 1. Create a product and publish it on the website (make sure `optional_product_ids` is empty) 2. Activate the "Buy Now" button (view: `product_buy_now`) in the website editor 3. Add the new product to the cart 4. After that, click on "Buy now": the traceback appears opw-3879952 [1]: https://github.com/odoo/odoo/blob/ce38df6/addons/website_sale_product_configurator/static/src/js/website_sale_options.js#L44 [2]: https://github.com/odoo/odoo/blob/ce38df6/addons/website/static/src/js/utils.js#L257 Forward-Port-Of: odoo/odoo#163144
This fix corrects an issue where kit product orders were showing incorrect Delivered/Received quantities when using multi-step delivery processes. When a purchase order quantity is updated for kit products (products made from component parts), the system now properly tracks the component movements instead of the kit itself, ensuring accurate delivery status reporting on purchase orders.
Original PR description
Steps to reproduce: - Enable multistep delivery/reciept - Create a kit and subkit with product quantity set on the bom (exemple values in the tests) - Create and confirm an PO (pickings created with correct values) - Update the orders quantity Bug: wrong Delivered/Recieved ammount on the PO line FIX: move_dest in the case of kits are the components moves not the order line product opw-3827388
This fix resolves an issue where popup snippets set to open "on click" were not functioning properly on product pages with variants. The problem occurred because product variant information stored in URL hashes was conflicting with popup anchor links. The fix ensures that customers can now successfully click links to open popups on product pages, improving the user experience for e-commerce sites.
Original PR description
Since [1], product variants have been managed through URL hashes containing unique IDs, causing conflicts with popup snippets "on click" functionality (see [2]). Steps to reproduce: - Go to the website and navigate to "Shop" - Select "Customizable Desk" - Enable "Edit" mode - Drag and drop the "Popup" snippet - Change the "Display" option to "On Click (via link)" - Close the popup - Select any text on the page and convert it into a link - Paste the anchor automatically copied to the clipboard by hitting Ctrl-C in the URL field - Save the changes - Click on the link to open the popup - Bug: Nothing happens This commit resolves this issue. opw-3888248 [1]: https://github.com/odoo/odoo/commit/0a79d9a90fc6c53d8d37257c07df5dd9ec068ffa [2]: https://github.com/odoo/odoo/commit/b043f0671a650f2ae1b44e569ae7abb6762cab2a
This fix resolves a critical issue where users encountered a system error (Error 500) when logging in after certain access control rules were configured on websites. The problem occurred because the system was getting stuck in an infinite loop while trying to determine which website a user should access during login. The fix prevents this loop by temporarily disabling access checks during this specific operation, allowing users to log in successfully.
Original PR description
If an `ir.rule` about websites involves obtaining the rule's evaluation context, an infinite recursion happens right after login: - the `_login` tries to create a `res.users.log` record which needs…
If an `ir.rule` about websites involves obtaining the rule's evaluation context, an infinite recursion happens right after login: - the `_login` tries to create a `res.users.log` record which needs to resolve the ACL - to do this `_eval_context()` is called on `ir.rule`, which in its `website` module override uses `get_current_website()` - in turn, this calls `website`'s `_get_current_website_id()` which is not cached yet - this involves a `search()` on `website` which needs to resolve the ACL - to do this `_eval_context()` is again called on `ir.rule`, causing the loop This commit prevent this infinite recursion by disabling the ACL check when determining the current website id in `get_current_website()`, similarly to what is done in [1] in future versions. Steps to reproduce: - Create a rule about `website` with `domain_force` set to `[(1, '=', 1)]`. - Log in from an incognito browser. => Error 500 because of an infinite recursion. [1]: https://github.com/odoo/odoo/commit/c68fa610d4e49eedd5f117675b973c551c771e75#diff-5e92e473fa4d3da6db7ef727fb217dad51ef6c2383913edca73fe040a23e82c2R978 task-3884701 opw-3603541 Forward-Port-Of: odoo/odoo#163951 Forward-Port-Of: odoo/odoo#162892
This fix resolves an issue where validating a scrap picking would incorrectly trigger a backorder creation wizard. The system now properly handles scrap moves by checking if a quantity has been recorded for disposal, rather than requiring the "picked" status that applies to regular inventory transfers. This allows warehouse staff to complete scrap operations without unnecessary confirmation steps.
Original PR description
**Steps to reproduce the bug:**
- Create a storable product “P1” and update its quantity to 10.
- Create a picking:
- Source location: Wh/Stock
- Destination location: Virtual Locations/Scrap
- Product: 10 units of P1.
- Mark as to-do.
- Try to validate the picking.
**Problem:**
A wizard asking to create a backorder is triggered. This occurs because when validating the picking, we check if all the moves are picked and the quantity is set. However, for the scrap moves that are ignored, we'll consider the move as not picked and no quantity done is set, hence the creation of a backorder is proposed.
**Solution:**
For the scrap moves, ignore the check of "picked" but check if a quantity done is set when validating the picking.
opw-3900082Website forms can now properly handle special characters (like quotes and backslashes) in field labels without causing errors or displaying incorrectly in emails. The fix ensures that when users add form fields with special characters in their labels, the data is processed correctly from creation through to email delivery, eliminating display issues like unwanted HTML encoding in received messages.
Original PR description
[IMP] website: enable to use special characters in a form Before [1], the usage of some characters as field label inside a form led to a traceback. As explained in [1], the problem came from the…
[IMP] website: enable to use special characters in a form Before [1], the usage of some characters as field label inside a form led to a traceback. As explained in [1], the problem came from the selector given to the `querySelector()` method. To solve the problem, [1] encoded the problematic characters. The problem is that the backslash character was not taken into account and still led to a traceback if it was used as a field label. [2] solved the problem by adding this special character in the list of the characters to encode. The problem of encoding problematic terms manually is that others (still unknown) can still be problematic and would have to be encoded in the future. To solve the problem, it has been decided to escape the problematic selectors with the `CSS.escape()` method, which is the right method to promote when adding anything unknown inside a selector anyway. [1]: https://github.com/odoo/odoo/commit/ccaf4f1e52f10308ef507059316732c02ad6e6e4 [2]: https://github.com/odoo/odoo/commit/03f230a77c0d38b46944d45b4991f48e45b275dd task-3510450 ----------------------------------------------------------------------------------------------------------------------------------------------------------- [FIX] website: decode special characters of website form Steps to reproduce: - Add a form on the website. - Add a field and put `test"` as label. - Save and send the form. -> `test"` is displayed in the received mail. Since [3] (and [4]), some characters are escaped when the user changes the label of a field. The problem appeared since [5] where fields are escaped on the server side upon form reception. Indeed, here is what happens at form reception; the already escaped `test"` is stored as `test&quot;` in the database. Due to it, the mail displayed contains `test"` while `test"` is wanted. To solve the problem, the characters encoded at label change in the client side are decoded on the server side before the form is processed. This is done at the server side as we still encode client-side since it appears that if a form is sent with an input that has a `"` character in its `name` attribute, it is received as `%22` server side (see previous commit in-code comment for details). [3]: https://github.com/odoo/odoo/commit/ccaf4f1e52f10308ef507059316732c02ad6e6e4 [4]: https://github.com/odoo/odoo/commit/03f230a77c0d38b46944d45b4991f48e45b275dd [5]: https://github.com/odoo/odoo/commit/db62d8c42b25b74210b4bae79200398acc4bb8de task-3510450 Forward-Port-Of: odoo/odoo#164205 Forward-Port-Of: odoo/odoo#135797
Employees without a profile picture were displaying incorrectly in the Kiosk Mode attendance system. The system was using the wrong image format specification for default avatars. This fix ensures that default employee avatars display properly when manually identifying employees at the attendance kiosk.
Original PR description
Steps to reproduce: ------------------- - create an employee without picture (generated by default) - go on Attendances/Kiosk Mode - click on identify manually Issue: ------ The employee without picture has a strange display. Cause: ------ This is because the ‘Uniform Resource Identifier’ (URI) scheme is forced to `data:image/png;base64,...`. The default image uses `svg+xml`. Solution: --------- Use the correct URI depending on the source (which is base64). opw-3911343
This update corrects how the inventory system calculates reserved quantities by properly handling decimal precision values. The fix ensures that quantity comparisons use the correct precision settings, preventing potential calculation errors in stock management operations.
Original PR description
Versions -------- - 17.0+ Issue ----- `stock.quant`'s `_get_reserve_quantity` method makes a call to `float_compare`, passing a `precision_rounding` value as a `precision_digits` parameter. Issue found working on opw-3705546
A test in the Purchase Stock module was updated to use the correct field reference. This is a minor correction to ensure the test accurately validates the stock valuation functionality, improving the reliability of automated quality checks.
Original PR description
Fine-tuning of 98ffe8af5f5fa6ae535ad26f1cc36ef802e0ad3e
This fix ensures that the currency field is properly locked (read-only) when viewing branch company records, preventing accidental modifications. Previously, the currency field remained editable for branches when it should have been protected, as branches inherit their currency from the parent company.
Original PR description
STEP TO REPRODUCE: -Create a branch -Save it and go to branch tab -> The currency field is not readonly as expected REASON: the 'readonly' value should be "parent_id != False" 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 fix ensures that when you change a customer's tax status (fiscal position) on a sales order, the product prices are recalculated consistently. Previously, products added before the tax change would have different final prices than products added after the change, even though they should be the same. Now all products are priced the same way regardless of when they were added to the order.
Original PR description
Before this commit, recomputing the taxes on a sale order after updating the fiscal position will not update the `price_unit` set on the sale order lines. As a consequence, when taxes included in the price are mapped by the new fiscal position, this will change the price before taxes. In contrast, when adding the same product after updating the fiscal position, the `price_unit` does reflect the changed taxes and will adapt the `price_unit` to make sure the price before taxes stays the same. This makes sense: let's say the fiscal position applies a tax exemption for a selected partner: this should not change the price before taxes. This commit makes sure the computed prices are the same, regardless of when the product was added: before or after changing the fiscal position. Ticket [here](https://www.odoo.com/web#model=project.task&id=3335939) opw-3335939 Forward-Port-Of: odoo/odoo#135948
Fixed an issue where dropdown menus for text formatting options would remain open when clicking outside the editor panel. This improves the user experience by ensuring dropdowns close automatically when users click elsewhere, making the editor feel more responsive and intuitive.
Original PR description
Step to reproduce: 1. Drop a multiple text snippet 2. Select the text and open the dropdown of any options 3. Click any other text or anywhere outsite the snippet editor 4. Dropdown remains open. Dropdown should be close if we click outside. Before this commit, when clicking anywhere outside the snippet editor panel, the opened dropdowns for inline text options would remain open. This issue arose due to the presence of multiple HTML document objects. The Bootstrap dropdown was not being triggered outside the iframe. Therefore, in this commit, we handled the closing of the dropdown manually if clicked outside option panel. task-3544708 Forward-Port-Of: odoo/odoo#162376
This update fixes a technical compatibility problem that was causing errors on older Android devices. The fix adds a fallback mechanism to ensure the web interface works properly across a wider range of devices, improving the user experience for customers using older mobile devices.
Original PR description
should add fallback for backend as well as frontend, otherwise error will occurred on some old android devices. ref: https://github.com/odoo/odoo/pull/160758 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where Odoo was repeatedly attempting to fetch the same existing bills from the Italian tax authority proxy server, preventing new bills from being imported. The system now properly skips bills that already exist in the system, allowing the automated bill retrieval process to work correctly and fetch new invoices as they arrive.
Original PR description
The issue: When many bills that already exist in the system and are in a pending state in the proxy server, Odoo infinitely tries to pull them at each call of the cron, which leads to not fetching the new bill and being stuck only with the existing ones Expected behavior: To fetch new bills and avoid the existing ones in the upcoming calls of the cron opw-3851896
The system was showing confusing error dialogs to website visitors when third-party scripts (like Google Analytics or Meta app scripts) encountered issues. These errors are outside Odoo's control and frustrate visitors. The fix stops showing these error dialogs to regular visitors, only displaying them to developers in debug mode and logged-in users who can actually help resolve issues.
Original PR description
Previously, if an error occurred in a third-party script loaded from a different origin (eg: google analytics or scripts injected into the in-app browsers of Meta apps such as Facebook or Instagram),…
Previously, if an error occurred in a third-party script loaded from a different origin (eg: google analytics or scripts injected into the in-app browsers of Meta apps such as Facebook or Instagram), we would show an error dialog mentioning a "CORS" error with no details. There are three problems with this: first, this is not actually a CORS error. It is normal error, but in Chrome and Safari, the details of the error are unavailable inside of code from scripts hosted on a different origin, this unavailability is caused by CORS but the error is *not* a CORS error. The second problem is that we're showing these error dialogs to website visitors, who are both likely to be confused or frustrated by the error and very unlikely to report it. Lastly, because the error occurred in a third party script, it's likely code that is not even controlled by the Odoo instance in any way, which means that it oftentimes cannot be fixed in Odoo. In Firefox, the first point doesn't hold true, as Firefox does not hide the error details, but we still do not want to display an error dialog because of the two other points. This commit fixes this by simply not displaying these errors to visitors outside of debug mode. Actual visitors will not be in debug mode, but it could be useful to still show the error for people developing integrations with third-party libraries and scripts. The error dialog will still not contain much information in non-Firefox browsers, but we encourage the developer to look at the browser console for extra details. We still display these errors for logged-in users in all cases as users are much more likely to report such issues. Ideally, we may not want to show these errors to portal users either, but this information is not currently available in JS. opw-3857323 Forward-Port-Of: odoo/odoo#164502 Forward-Port-Of: odoo/odoo#163710
This fix resolves a technical error that occurred when canceling PayPal transactions in Odoo. The issue prevented users from properly canceling PayPal payments, which has now been corrected to ensure smooth payment management workflows.
Original PR description
'TypeError: PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given' opw-3708875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent update was causing payment processing to fail with an error in certain situations. This fix removes that problematic error check so payments can be processed normally again. This resolves issues where legitimate payment transactions were being incorrectly blocked.
Original PR description
This [commit](https://github.com/odoo/odoo/commit/2d2a7729a77f8004aa046998ce75cd85280b3a6e) introduced an unwanted side effect by raising an error when it wasn't legitimate.
opw-3901083
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update brings the spreadsheet application to version 17.0.21 with multiple bug fixes and performance enhancements. Key improvements include fixing Excel export issues, resolving chart display problems, preventing validation icon overlaps, and optimizing memory usage. These changes ensure spreadsheets work more reliably and efficiently for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/998bea0bf [REL] 17.0.21 https://github.com/odoo/o-spreadsheet/commit/cefa5596c [PERF] helpers: reduce toZone memory allocation Task: 3915798 https://github.com/odoo/o-spreadsheet/commit/e8d14442c [FIX] Export xlsx: export value for non-exportable formulas Task: 3895465 https://github.com/odoo/o-spreadsheet/commit/6eb43533d [FIX] chart: avoid useless chart updates Task: 3697660 https://github.com/odoo/o-spreadsheet/commit/5cc411f10 [FIX] chart: wrong line dot size Task: 3697660 https://github.com/odoo/o-spreadsheet/commit/60f9fddc5 [FIX] data_validation: prevent icon overlap Task: 3684182 https://github.com/odoo/o-spreadsheet/commit/68ce80857 [MOV] filter_icon_overlay: move tests to correct folder Task: 3684182 https://github.com/odoo/o-spreadsheet/commit/1f97287d3 [FIX] charts: time axis broken with long formatted date Task: 3857242
This fix improves the messaging menu by displaying notification subtype descriptions when a notification doesn't have a body text. Previously, empty notifications would show nothing to users, making it unclear what the notification was about. Now users will see helpful context information instead.
Original PR description
Before this PR, a notification without body did not display anything inside the messaging menu. This PR adds a fallback to the `subtype_description`. Task-3749144 Forward-Port-Of: odoo/odoo#163960 Forward-Port-Of: odoo/odoo#162986
This fix corrects how product taxes are applied when using branch companies in Odoo. Previously, both parent and branch company taxes were incorrectly applied together. Now the system correctly applies only the branch company's tax, and falls back to the parent company's tax only when needed. This ensures accurate tax calculations across invoices, purchase orders, point of sale, eCommerce pricing, delivery charges, and loyalty programs.
Original PR description
**Steps to reproduce:** - Install Accounting - Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany) - Switch to Branch Company - Create a product with taxes from the parent…
**Steps to reproduce:** - Install Accounting - Create a branch company (e.g. Branch Company) for a company (e.g. YourCompany) - Switch to Branch Company - Create a product with taxes from the parent and the branch companies - Create an invoice - Add a line with the created product **Issue:** Both taxes from the branch company and its parent are set on the invoice line. It should only take the tax from the branch. And if there is no tax, it should check the parent company for a tax and so on, as it is done in Sales. The same issue happens in: - "Purchase": the taxes on PO lines - "Point of Sale": the taxes on the products when loading a session - "eCommerce": (when "Tax Included" is configured for "Display Product Prices") * the displayed price on product page * the displayed price on the products list page * the displayed price on the Products snippet - "Delivery": the taxes on the delivery line of a SO - "Sale Loyalty": the taxes on the free product or free shipping opw-3850514 opw-3873659 opw-3775579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163775
This update fixes phone number validation for Morocco by updating the phone number patterns to match the latest international standards. The fix ensures that valid Moroccan phone numbers like +212780137429 are correctly recognized by the system, improving data quality for businesses operating in Morocco.
Original PR description
The Python module 'phonenumbers' received an update, which includes localization data for Morocco "MA" phone number patterns. Given that 'phonenumbers' is an external module tied to the Ubuntu module…
The Python module 'phonenumbers' received an update, which includes localization data for Morocco "MA" phone number patterns. Given that 'phonenumbers' is an external module tied to the Ubuntu module repository, it is not expected to receive a bump to the latest version soon.
### [Reproduce]
- Ensure that odoo is using (old) phonenumbers python module in version 8.12
- Install -i phone_validation
- Run odoo shell (`odoo-bin shell` command)
- check if "+212780137429" is a valid number
To run in odoo shell: Check Moroccan number
```python
import phonenumbers
phonenumbers.is_valid_number(phonenumbers.parse('+212780137429',region='MA',keep_raw_input=True))
```
### [Issue Explanation]
In version 8.12 of the 'phonenumbers' module in the Ubuntu repository, the regex used to recognize mobile numbers is not up to date.
### [This commit changes]
This commit brings changes from the newest phonenumbers version into the current one.
### [Why was existing test modified]
_local_load_region function was previously defined dynamically only for the versions patched in the previous fix. Since my fix needs to reuse that function it was moved outside of patched scope.
Existing test used the hypothesis "if _local_load_region was defined" to assess that the patching was performed. This is no longer possible with _local_load_region beeing out of the specyfic patched scope. Instead I use the fact that _local_load_region gets assigned to the specyfic region loaders when patching is performed, and check for that.
opw-3763407
## Merge note
There was similar fix in 17.0, will perform integration of those two in the forward-port branch
Forward-Port-Of: odoo/odoo#164040
Forward-Port-Of: odoo/odoo#158076