Daily updates from Odoo
Navigate
Branch
Tuesday, February 6, 2024
73 changes
19 changes
Enhancements to existing features
The Sign app now uses a lighter signature capture tool that does not rely on jQuery. This reduces dependencies and helps prepare the product for future frontend modernization while keeping signing flows working as expected.
Original PR description
The jSignature library depends on jQuery. As we plan to remove jQuery in the future, jSignature is replaced by another (simpler) library, with fewer dependencies. Enters signature_pad [1], which looks well maintained, has no external dependency and is (roughly) 1/3 of the size. This commit adapts the related components. task-3599215 [1]: https://github.com/szimek/signature_pad
Creating a Helpdesk team with the same name as an existing team no longer fails because of a duplicate email alias. The system now automatically adjusts the new team's email alias, reducing setup interruptions for support teams.
Original PR description
Currently, creating a helpdesk team with an existing name results in an error due to the limitation of using identical email aliases for separate teams. This PR introduces a change: If a team's creation generates an already-used email alias, the system will add '2' to the new alias. task-3450431
Resolved issues and error corrections
This fix prevents an error that could occur when users click detected fields after OCR processing a vendor bill. It helps keep the invoice upload and review flow stable for accounting users using document recognition.
Original PR description
This commit addresses the missing props declaration in the BoxLayer component. The following changes were made: - Added the previously omitted onClickBoxCallback props definition. - Corrected the validation method for the pageLayer props. Steps to reproduce: 1. Open Accounting with an IAP OCR setup in debug mode. 2. Navigate to Vendor Bills > Upload (Choose a scanned PDF or picture). 3. Wait for the OCR process to complete. 4. Click inside a detected field => Traceback.
A field service test tour now accounts for the setup prompt that appears when no worksheet templates exist. This prevents automated checks from failing in empty or freshly configured databases, improving reliability without changing normal user workflows.
Original PR description
…template Steps to reproduce: - start TestIndustryFsmUi python test after removing all your worksheet templates. Source: - A wizard was added to create a worksheet template if there is no worksheet template. So this wizard doesn't usually appear and when it appears there is no step in the tour to handle it. Fix: - An additional step was added to the tour to verify if the wizard exist and choose to create a new template. task-3716386 X-original-commit: https://github.com/odoo/enterprise/commit/2b1c2af82d1fbb4286d4eb16f156f5e1092c17b8
Code cleanup and technical improvements
The spreadsheet pivot setup has been adjusted to use a newer internal definition format. This keeps pivot insertion and related spreadsheet features aligned with platform changes, helping maintain reliability without changing the user workflow.
Miscellaneous changes
Sending a CANCEL request while a SIP session is being established will result in a 487 Request Terminated response to the pending INVITE request. Prior to this commit, cancelling a SIP session would cause the session to be deleted twice: once immediately after the CANCEL request was sent, then a second time after the response to the INVITE request was received, resulting in a crash the second time because the session had already been deleted. After this commit, 487 Request Terminated respo
Original PR description
Sending a CANCEL request while a SIP session is being established will result in a 487 Request Terminated response to the pending INVITE request. Prior to this commit, cancelling a SIP session would cause the session to be deleted twice: once immediately after the CANCEL request was sent, then a second time after the response to the INVITE request was received, resulting in a crash the second time because the session had already been deleted. After this commit, 487 Request Terminated responses are ignored, preventing the code from attempting to delete the already deleted session and causing a crash. opw-3702140 Forward-Port-Of: odoo/enterprise#55842
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at the same time because: - The Amazon documentation didn't say anything about it - It avoided the problem of a strange configuration of the customer where a product in FBM could be placed in the Amazon location, as nothing ensure that everything placed there is, indeed, a FBA product, even if this is t
Original PR description
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at…
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at the same time because: - The Amazon documentation didn't say anything about it - It avoided the problem of a strange configuration of the customer where a product in FBM could be placed in the Amazon location, as nothing ensure that everything placed there is, indeed, a FBA product, even if this is the recommended setting. - After testing the synchronization of the FBM stock, we couldn't see any changes in the Amazon backend, which lead us to think that we couldn't, in fact, update the stock of a FBA product as Amazon would ensure the stock used would be the one in their warehouse. Recently, we got some problem with FBA order that Amazon considered being FBM. After investigation, it was found that the stock send for FBA would be set as having a "DEFAULT" fulfilment channel, but this wasn't shown anywhere on Amazon backend, only in their DB. So from time to time, instead of using the set fulfilment channel of a product, Amazon would use that default one, with a separate, virtual, stock. With this fix, we ensure that this "default" channel is now filled with a quantity of 0 instead, for FBA product. We assume the set-up of the Amazon account on Odoo is correctly made and all products in the Amazon location are FBA. task-3693853 Forward-Port-Of: odoo/enterprise#54737
Previously, we were always returning a box in the validation request, even when no box was clicked by the user. Now, the box will only be part of the request if it was indeed clicked by the user and that its text matches the text of the field. This has little impact on the learning of the AI model as it was mostly relying on the text of the validated value, not its box. Forward-Port-Of: odoo/enterprise#55783 Forward-Port-Of: odoo/enterprise#55643
Original PR description
Previously, we were always returning a box in the validation request, even when no box was clicked by the user. Now, the box will only be part of the request if it was indeed clicked by the user and that its text matches the text of the field. This has little impact on the learning of the AI model as it was mostly relying on the text of the validated value, not its box. Forward-Port-Of: odoo/enterprise#55783 Forward-Port-Of: odoo/enterprise#55643
Step to reproduce: - have two products - add one quant of each in the same package - create a out stock move - scan 1 item - scan the package Issue: A high volume of product arrivals with multiple barcodes per item can lead to occasional errors in scanning the wrong barcode (package). Time consuming to redo everything. Solution: Whenever one or multiple item have already been scanned, we ask the user a confirmation if they scan a package barcode. opw-3610819 Forward-Port-Of: odo
Original PR description
Step to reproduce: - have two products - add one quant of each in the same package - create a out stock move - scan 1 item - scan the package Issue: A high volume of product arrivals with multiple barcodes per item can lead to occasional errors in scanning the wrong barcode (package). Time consuming to redo everything. Solution: Whenever one or multiple item have already been scanned, we ask the user a confirmation if they scan a package barcode. opw-3610819 Forward-Port-Of: odoo/enterprise#55748 Forward-Port-Of: odoo/enterprise#54389
Backport of https://github.com/odoo/enterprise/pull/48385 Forward-Port-Of: odoo/enterprise#55718 Forward-Port-Of: odoo/enterprise#55444
Original PR description
Backport of https://github.com/odoo/enterprise/pull/48385 Forward-Port-Of: odoo/enterprise#55718 Forward-Port-Of: odoo/enterprise#55444
Before this commit, when the load is slow and the user does not wait the load method be executed and launches another search, the section, row and column ids could be altered by the both load are currently executed (the current one and the previous one whom is not yet finished). The problem with that is the section, row and column id is a global variable in the file and so the id is incremented by the both loads once a section, row or column is created and so the user could see a big gap between
Original PR description
Before this commit, when the load is slow and the user does not wait the load method be executed and launches another search, the section, row and column ids could be altered by the both load are currently executed (the current one and the previous one whom is not yet finished). The problem with that is the section, row and column id is a global variable in the file and so the id is incremented by the both loads once a section, row or column is created and so the user could see a big gap between the grid header and his first result displayed because the row id could be for instance 21 instead of 1. This commit fixes the issue by removing the global variable and define the attributes to increment for section, row and column id into `GridDataPoint` to be sure the id will only be incremented by only one load. Forward-Port-Of: odoo/enterprise#55361
When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted. Problem:- By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller.
Original PR description
When the user tries to send a conversational WhatsApp message, it fails saying that the phone number is blacklisted. Problem:- By default, the archived records are not searched in `.search()` unless `active_test` is given `False` in context. Here while searching blacklisted numbers in `_send_message`, the `False` value is obtained for `active_test` in context due to which archived blacklisted numbers are also being searched. This context is obtained from the `mail_message_post` controller. https://github.com/odoo/odoo/blob/46d94c4bdaec287615e47aac6597f36f498cf8de/addons/mail/controllers/thread.py#L96 Solution:- We will forcefully pass the `active_test` with `True` while searching blacklisted phone numbers. Due to this archived records will not be searched and it will let the user send the WhatsApp message using the discuss channel. Task - 3698511 Forward-Port-Of: odoo/enterprise#55399
When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow
Original PR description
When grouping by analytic plan and/or account in a report, clicking the amount always opened an empty tree view, except for the default "Projects" plan which properly displayed the analytic lines making the amount. This was due to the fact the domain was built using field account_id of account.analytic.line, which is only used for the default plan (other plans dynamically create fields on account.analytic.line to store their chosen account). auto_account_id is overridden in the model to allow searching on all plans, and should hence be used in this context. Forward-Port-Of: odoo/enterprise#50893
Steps (from customer DB): - Setup automation rules that send mail - Run the rules No precise steps found, running the existing code in SA is enough too trigger an issue ``` Partner = env['res.partner'] Partner._parse_partner_name('johndoe@example.com') ``` Actual result: - Traceback due to missing attribute for partner - _parse_partner_name definition has been removed in 17.0, still exist in 16.4 Expected result: - no traceback, mail send - email is parse to name opw-369312
Original PR description
Steps (from customer DB):
- Setup automation rules that send mail
- Run the rules
No precise steps found, running the existing code in SA is enough too trigger an issue
```
Partner = env['res.partner']
Partner._parse_partner_name('johndoe@example.com')
```
Actual result:
- Traceback due to missing attribute for partner
- _parse_partner_name definition has been removed in 17.0, still exist in 16.4
Expected result:
- no traceback, mail send
- email is parse to name
opw-3693124
task-2612945
Forward-Port-Of: odoo/enterprise#54690Fix a decimal issue on reconciliation. Steps: - Set a reconciliation model with payment tolerance of 2% - Create an invoice for $1210 - Create a bank stmt with a line for $1185.80 -> Reconciliation model is not apply This is because of a decimal issue when calculating the residual balance after reconciliation, leading to the difference being 2.000000000000004% instead of 2%. opw-3672092 Forward-Port-Of: odoo/enterprise#55615
Original PR description
Fix a decimal issue on reconciliation. Steps: - Set a reconciliation model with payment tolerance of 2% - Create an invoice for $1210 - Create a bank stmt with a line for $1185.80 -> Reconciliation model is not apply This is because of a decimal issue when calculating the residual balance after reconciliation, leading to the difference being 2.000000000000004% instead of 2%. opw-3672092 Forward-Port-Of: odoo/enterprise#55615
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded by the ORM. Steps to reproduce: 1. Install `crm` and `data_merge` on a new DB 2. Run data merge for `crm.leads` Data Cleaning > Configuration > Deduplication Rules > Lead/Opportunity > DEDUPLICATE 3. Try to install data_merge module `./odoo-bin ... -i data_merge` We get a `ParseError`: ```
Original PR description
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded…
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded by the ORM.
Steps to reproduce:
1. Install `crm` and `data_merge` on a new DB
2. Run data merge for `crm.leads` Data Cleaning > Configuration > Deduplication Rules > Lead/Opportunity > DEDUPLICATE
3. Try to install data_merge module `./odoo-bin ... -i data_merge`
We get a `ParseError`:
```
...
File "/home/odoo/src/odoo/15.0/odoo/tools/convert.py", line 694, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/15.0/data_merge/security/security.xml:4
Invalid domain: 'crm.lead'
```
This issue happens during upgrades 14.0->15.0
The actual reason for the failure is that this line https://github.com/odoo/odoo/blob/dbd37953957b94a2e05908d96cf8e4d7dea42d72/odoo/addons/base/models/ir_rule.py#L79 eventually gets into
https://github.com/odoo/enterprise/blob/0db3d7c9473034da0714f96fe915a7dedb7b667e/data_merge/models/data_merge_record.py#L101 and this causes a `KeyError` because `crm.lead` is not loaded yet.
This error didn't happen before because at XML load there was no attempt to generate a `Query` from a domain expression. After the linked commit above we now force the parse of such queries. That involves the call to `_search_company_id` for `data_merge.record` entries.
The patch proposed here skips `ValidationError`s at install of `data_merge`. This still keeps the validation active for usual DB operations.
X-original-commit: 5a64974501b5be231e2eed941f42ae6dfe110f18
Forward-Port-Of: odoo/enterprise#55847When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55619 Forward-Port-Of: odoo/enterprise#52966
Original PR description
When totals below section option is set, there is a redundancy in the display of data. Indeed, the amount will be displayed once on the line itself and once again in the total line. For now on, if the total below section is set and the total line is displayed (unfolded), the amount will only on the total line. task-3642826 Forward-Port-Of: odoo/enterprise#55619 Forward-Port-Of: odoo/enterprise#52966
Steps to Produce: - Navigate to the 'Project' form view on a mobile device. - Go to the 'Documents & Analytics' section in the 'Default Tags.' - When you try to create new tags in the 'Category' field, observe that it shows existing tags. Issue: - 'name_search' is not work for kanban view of mobile. Solution: - To resolve the issue, we need to add the missing domain to the 'facet_id' field. task-3549328 Forward-Port-Of: odoo/enterprise#55825 Forward-Port-Of: odoo/enterprise#49586
Original PR description
Steps to Produce: - Navigate to the 'Project' form view on a mobile device. - Go to the 'Documents & Analytics' section in the 'Default Tags.' - When you try to create new tags in the 'Category' field, observe that it shows existing tags. Issue: - 'name_search' is not work for kanban view of mobile. Solution: - To resolve the issue, we need to add the missing domain to the 'facet_id' field. task-3549328 Forward-Port-Of: odoo/enterprise#55825 Forward-Port-Of: odoo/enterprise#49586
This PR addresses a traceback issue in the l10n_in_reports_gstr module when attempting to match data without existing JSON. The fix includes the implementation of error handling to display a user-friendly message when JSON data is not available. Forward-Port-Of: odoo/enterprise#54007
Original PR description
This PR addresses a traceback issue in the l10n_in_reports_gstr module when attempting to match data without existing JSON. The fix includes the implementation of error handling to display a user-friendly message when JSON data is not available. Forward-Port-Of: odoo/enterprise#54007
54 changes
New functionality added to Odoo
A new feature has been added that allows users in India to scan QR codes on e-invoiced vendor bills directly in the Accounting app. This streamlines the bill entry process by automatically extracting invoice data from the QR code and creating vendor bills with partner information, reducing manual data entry and improving efficiency.
Original PR description
Now the user can scan the QR code on e-invoiced vendor bills, which allows user the following functionalities: -create a new vendor bill and also will create the partner if not found with help of the data received from qr code and partner autocomplete Functional Steps: - install l10n_in_qr_code_bill_scan - Go to Account app > Vendors > Bills - Go to tree/kanban view - Click on Scan button - Scan E-invoice QR Code task-3626437
This update adds Russian language translations to numerous enterprise modules in Odoo 17.0. The translations were generated using DeepL to provide Russian-speaking users with a fully localized experience across accounting, payment, asset management, and other key business modules. This expansion of language support makes the software more accessible to Russian-speaking organizations.
Original PR description
Enterprise side of what was done in COM PR: https://github.com/odoo/odoo/pull/152285
This update adds Latvian language translations to the Subscription Sales module, enabling Latvian-speaking users to use the system in their native language. The translation files have been backported from the community version to ensure consistency across Odoo versions.
Original PR description
Community: https://github.com/odoo/odoo/pull/148658 Forward-Port-Of: odoo/enterprise#55838 Forward-Port-Of: odoo/enterprise#53921
This update adds comprehensive Russian language translations to Odoo 17.0 across all standard modules. The translations were generated using automated translation tools with manual corrections for technical terms, enabling Russian-speaking users to use the system in their native language. This is the first complete translation pass for Russian support.
Original PR description
Final goal of this PR is to add in a first pass full auto-translation of Odoo into Russian. Steps taken to do so: 1. Re-export all pot files to ensure correct terms to translate + clean them up in…
Final goal of this PR is to add in a first pass full auto-translation of Odoo into Russian. Steps taken to do so: 1. Re-export all pot files to ensure correct terms to translate + clean them up in general due to human error 2. Add missing pot files for modules that were added after the last cleaning/freeze and therefore were also missing from the .tx config file (later PR to follow to add in modules missing from config file, but already have a pot file) 3. 1 large master po file of all the modules exported in steps 1 + 2 were feed into an auto-translator 4. Master po file was split back into respective module's ru.po files (missing ones due to module not being in config file were auto-generated, these modules will be added into the config in a later PR). Note that because msgmerge would not auto-update the existing po files with the new translations for some reason, the metadata of the previous translators was discarded for the sake of automating the splitting of the master po translation file into the individual module ones in a simple way 5. Manual fixes of incorrect translating (i.e. of code terms) were done where noticed, additional bugs may pop up in the future as users use db in Russian more Same process was done for Enterprise. ENT PR: https://github.com/odoo/enterprise/pull/55637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update significantly speeds up the process of assigning live chat operators to visitors. The system was taking multiple seconds to find available operators on large databases, which caused delays when many visitors were using auto-popup chat. The improvement reduces this time to under 50 milliseconds by optimizing how the system searches through operator availability data.
Original PR description
Since #135113, calls to /im_livechat/get_session can become very expensive on large databases with a long history of livechat sessions. Operators who have thousands of past livechat sessions…
Since #135113, calls to /im_livechat/get_session can become very expensive on large databases with a long history of livechat sessions. Operators who have thousands of past livechat sessions (channels) can cause the SQL query in get_operator() to take multiple seconds. When the livechat is set to auto-popup and there are lots of visitors, this can become very significant. This patch changes two aspects: - introduce a CTE for the RTC session part, in order to avoid a JOIN cardinality explosion between livechat channels and channel_members - we only care about channel membership for a RTC session AFAICT - restrict the selection of livechat channels created **within the last 24h**, considering that we only care about messages sent in the last 30 minutes anyway The second part may change the result ordering in the presence of old channels (>24h) with recent messages - but that is rather unlikely, and an operator will be selected anyway. This change makes a huge difference on a database with 300k livechat channels and 1 million `discuss_channel_member` records, from several seconds to >50ms. The results are identical or extremely similar in most cases, and the database only needs to look at a few hundred records instead of millions.
This update adds database indexes to the analytic plan columns to speed up searches when working with large datasets. This improvement makes operations like deleting accounts faster and more efficient, especially when the system has many analytic items linked together.
Original PR description
The table linked to analytic items can be pretty huge, and searching by account needs to be fast. For instance, this index can be used when deleting an account because of the foreign keys.
This change reorders the website sitemap to list manually created pages before system controllers. Pages are typically more important content that users intentionally create, are updated more frequently, and are fewer in number than controllers. This ordering may help search engines prioritize crawling your most important content, especially if they have limited crawling budgets for large websites.
Original PR description
This shouldn't change anything regarding SEO, but is worth a try. It will also impact the link suggestion when creating a link in the editor, but having pages listed first also have sense there, or…
This shouldn't change anything regarding SEO, but is worth a try. It will also impact the link suggestion when creating a link in the editor, but having pages listed first also have sense there, or at least it won't be worst. The idea for the SEO part is that if the sitemap order (if too long) would have some impact as crawlers might have a limited crawling budget for your website and it will only crawl the first pages it finds. Are those "first pages" impacted by the sitemap order? It's almost sure it's not, as Google definitely knows how to crawl on its own, and is even probably ignoring the sitemap most of the time. Also, pages: - Are probably always important content since you created manually a page to write something, while (some) controllers might just be content you care less about. Pages are probably always important while we can't say that for controllers. - Should be fewer in number than controllers most of the time - Have a lastmod set, as opposed to controllers For all those reasons, this commit reverse the pages vs controllers order in the sitemap. This is coming from our prod where some pages are yet not indexed while they have been published months ago.
This update adds and improves Latvian language translations across multiple Odoo modules including accounting, expenses, purchasing, sales, and reporting dashboards. Users in Latvia will now see more complete and accurate translations throughout the system, improving usability for Latvian-speaking organizations.
Original PR description
\*: account, hr_expense, purchase, sale, spreadsheet_dashboard_purchase, spreadsheet_dashboard_purchase_stock, spreadsheet_dashboard_sale, web Enterprise: https://github.com/odoo/enterprise/pull/53921 opw-3667913 Forward-Port-Of: odoo/odoo#152692 Forward-Port-Of: odoo/odoo#148658
Resolved issues and error corrections
This fix ensures that text labels in the Tax Report's filter options are properly exported for translation into other languages like French. Previously, the options "With Draft Entries" and "Posted Entries Only" were not being translated because of how the code was structured. The fix reorganizes the code to make these terms translatable.
Original PR description
Steps to reproduce: - Change language to French for example - Install accounting - Go to the "Tax Report" - Options will display "With Draft Entries" or "Posted Entries Only" Issue: The terms are not exported since we were using t-esc. Cause: Replace the ternary operator with an t-if and t-else. opw-3356916 Forward-Port-Of: odoo/enterprise#53142
This fix resolves an error that occurred in the VoIP module when users blocked their browser's access to the microphone during a call. Previously, the system would crash with an "Invalid state transition" error. Now the application handles this scenario gracefully, allowing users to continue using the VoIP feature even if microphone permissions are denied.
Original PR description
To reproduce: 1. Install and configure the VoIP module in prod mode 2. Place a call to anyone 3. Block the browser from accessing the microphone Error: Invalid state transition from Terminated to Terminated Fixed in https://github.com/onsip/SIP.js/commit/f06939c119149a3e00ad8acf69f37360d3331a62 Adapt it in old version. Task-2810572 Forward-Port-Of: odoo/enterprise#53581
This update fixes critical issues in the Documents and Documents Account guided tours that were causing them to get stuck during final steps. The fix corrects missing interface elements and improves the tour flow so users can successfully complete the document processing workflow without interruptions.
Original PR description
Before this commit: - The `documents_tour` progresses as desired but is stuck during the final few steps. - The `documents_account_tour` has the same issue but additionally has a misplaced prompt to select the first image `mail.png` having the `inbox` tag. - The `o_FileViewer` class is incorrect. Issue: - The classes inside the trigger are missing/incorrect. - After we process the initial set of pages, the prompt to select the last remaining page is missing. After this commit: - Rectified the classes and added an extra step to select the remaining page and then process the tour. - Updated the `o_FileViewer` to `o-FileViewer`. task-3537521 Forward-Port-Of: odoo/enterprise#49027
This update fixes an issue in the bank reconciliation feature where exchange rate differences were being calculated incorrectly when processing transactions in foreign currencies. The fix ensures that currency conversion amounts are properly calculated when reconciling bank statements with foreign currency transactions, improving the accuracy of financial records.
Original PR description
The exchange difference on the bank reconciliation widget is wrongly computed when the statement line has a foreign currency but not the counterpart aml mounted on the widget. opw: 3376318 Forward-Port-Of: odoo/enterprise#55051 Forward-Port-Of: odoo/enterprise#53606
This update fixes a decimal rounding issue that was preventing the reconciliation model from correctly applying payment tolerance rules. When reconciling invoices with bank statements, the system was calculating tolerance percentages with excessive decimal precision (2.000000000000004% instead of 2%), causing valid matches to be rejected. This fix ensures that payment tolerance thresholds work as intended.
Original PR description
Fix a decimal issue on reconciliation. Steps: - Set a reconciliation model with payment tolerance of 2% - Create an invoice for $1210 - Create a bank stmt with a line for $1185.80 -> Reconciliation model is not apply This is because of a decimal issue when calculating the residual balance after reconciliation, leading to the difference being 2.000000000000004% instead of 2%. opw-3672092 Forward-Port-Of: odoo/enterprise#55615
This fix prevents the VoIP system from crashing when a call invitation is cancelled. Previously, the system would attempt to delete the same call session twice, causing an error. Now it properly handles cancelled calls without crashing, ensuring a more stable calling experience.
Original PR description
Sending a CANCEL request while a SIP session is being established will result in a 487 Request Terminated response to the pending INVITE request. Prior to this commit, cancelling a SIP session would cause the session to be deleted twice: once immediately after the CANCEL request was sent, then a second time after the response to the INVITE request was received, resulting in a crash the second time because the session had already been deleted. After this commit, 487 Request Terminated responses are ignored, preventing the code from attempting to delete the already deleted session and causing a crash. opw-3702140
This update corrects two important issues in the follow-up process: emails sent for automatic follow-ups now display the correct sender address, and follow-up messages in the system now accurately show who initiated the action rather than incorrectly attributing them to the account manager. These fixes ensure proper communication tracking and accountability in customer follow-up workflows.
Original PR description
This PR addresses two issues in the account_followup module: 1. Corrected the email_from value in emails sent for automatic follow-ups. 2. Fixed the incorrect author attribution displayed in follow-up chatter, accurately reflecting the user who initiated the action. Each commit resolves a specific issue. Forward-Port-Of: odoo/enterprise#55696 Forward-Port-Of: odoo/enterprise#55376
Fixed an issue in the barcode app where the quantity display showed too many decimal places when using the +1/-1 buttons in the number pad. Now the quantity will maintain the same decimal precision as what the user originally entered, making the display cleaner and more accurate.
Original PR description
Steps to reproduce: - Select any transfer in barcode App - Click add product to manually edit quantity - Set quantity to 0.0002 - Click on -1 multiple times then +1 Bug: the quantity is displayed with too many precision digits (defaul float) Fix: The addition and subtraction with the +1 / -1 button should be upto the decimal value entered. opw-3551250 Forward-Port-Of: odoo/enterprise#55786 Forward-Port-Of: odoo/enterprise#53378
Fixed an issue where CFDI XML documents were not being attached to payment receipt emails in Mexican companies. This restores functionality that was lost during a recent module refactoring, ensuring that payment receipts sent via email now include the required CFDI documentation as they did previously.
Original PR description
Steps to reproduce: - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [any] (e.g. INMOBILIARIA CVA) * Product: [any product with an UNSPSC Category] - Confirm the invoice - Generate CFDI via "Send & Print" button - Register Payment (Payment Way: Effectivo) - Click on "Update Payments" button - Go to the payment - Force CFDI - Send receipt by email Issue: The CFDI document of the payment is 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-3678484 Forward-Port-Of: odoo/enterprise#55016
This fix resolves an error that occurred when increasing the value of an asset that uses constant period depreciation. The issue was caused by incorrect calculation of asset lifetime days due to rounding. The system now uses decimal precision instead of whole numbers, allowing asset increases to be properly validated and processed.
Original PR description
When increasing an asset with constant periods, we get an error
on increase asset validation, due to the asset lifetime days
being wrongly computed.
Steps:
- Asset configuration:
- Original value: 1200
- Acquisition date: 10/01/2023
- Method: linear
- Duration: 12 Months
- Computaion: Constant Periods
- Confirm asset
- Modify it: action 'modify' and date 01/15/2024
- Validate
-> UserError("The remaining value on the last depreciation line must be
0")
This is due to the fact that the field `asset_lifetime_days` is an
Integer field and it is computed to satisfy this constraint.
With this commit we change this field (non stored) from Integer
to Float and adapt its computation.
opw-3691191
Forward-Port-Of: odoo/enterprise#55648This update fixes data validation errors in the Australian payroll module's demo data and tests. The demo data was incorrectly assigning an employee record to a partner field, and tests were referencing accounting features that the module doesn't depend on. These fixes ensure the module works correctly during system setup and testing.
Original PR description
As seen in the nightly build https://runbot.odoo.com/runbot/build/57728091 There is an issue with the demo data where a hr employee record is trying to be set in a res.partner field. Also, one test is setting accounting stuff while this module isn't dependent on any account modules.
This update fixes a translation issue in the bank reconciliation feature that was preventing text from displaying correctly in Odoo 17.0. The fix updates the code to use the correct translation method, ensuring that users see properly translated text in their preferred language when using the bank reconciliation tool.
Original PR description
Replace `this.env._t()` (not supported in 17.0) by `_t()`.
This fix prevents old appointment URLs from being added to the website sitemap. These legacy URLs were generating many broken links (403 errors) because they're restricted by country. By excluding them from the sitemap, the website will have cleaner search engine indexing and better user experience.
Original PR description
It generates a lot of urls that will return 403 since it is restricted by country.
This fix corrects how numbers are formatted when displayed in various modules. A recent code reorganization moved number formatting logic to a shared utility, but some modules that display field values weren't updated to use the correct formatter that handles special cases. This fix ensures all field displays use the proper formatting function, preventing potential display inconsistencies.
Original PR description
Commit [1] moved (almost all of) the code of formatFloat from views/fields/formatters.js to core/utils/numbers, to make it accessible in the frontend. A formatFloat function was kept in formatters.js to handle the false case, which makes no sense in number utils, but is useful for fields. However, a lot of imports have been updated to use the numbers.js instead of formatters.js (i.e. they no longer benefit from the support of false), whereas they are actually formatting field values, so they should have kept using the formatFloat from formatters.js This commit adapts the places where the formatFloat to use must come from formatters.js, not numbers.js. [1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8 task 3722043
This fix resolves a technical error that occurred in the GST Return module when users attempted to match data without existing JSON information. The system now displays a clear, user-friendly message instead of a confusing error, improving the user experience when working with GST return data.
Original PR description
This PR addresses a traceback issue in the l10n_in_reports_gstr module when attempting to match data without existing JSON. The fix includes the implementation of error handling to display a user-friendly message when JSON data is not available. Forward-Port-Of: odoo/enterprise#54007
Fixed an issue where the Warehouse Analysis report in the Inventory application was not translating operation types when users changed their database language. The fix improves the report's usability for international teams by ensuring all labels display correctly in the selected language.
Original PR description
**Current behavior:** Changing the language of the database does not translate the operation_type field in the stock.report model's views. --- **Expected behavior:** The field operation_type gets translated in the stock.report model's views. --- **Steps to reproduce:** 1. In the Inventory application, use the menu bar to navigate to 'Reporting' -> 'Warehouse Analysis' 2. Change the database/user language to something non-English 3. Issue can be observed in the pivot view (first column) --- **Cause of the issue:** The stock.report model stores the operation_type field as a Char field type. --- **Fix:** Add an operation_type_id (M2o) field and use it to replace all references to the old operation_type field. --- opw-3663227 Forward-Port-Of: odoo/enterprise#55737 Forward-Port-Of: odoo/enterprise#53802
This fix resolves an issue where Amazon was incorrectly treating FBA (Fulfillment by Amazon) orders as FBM (Fulfillment by Merchant) orders. The problem occurred because stock inventory was being sent to Amazon's default fulfillment channel for FBA products, causing Amazon to sometimes use the wrong stock level. The fix ensures that FBA products no longer update the default channel inventory, preventing order fulfillment confusion.
Original PR description
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at…
Following commit 1b2977811516cce4830ceaf1a7585c8f7061243a we now send the stock inventory for all the products linked to an Amazon offer. At the time, it was decided to send FBA and FBM updates at the same time because: - The Amazon documentation didn't say anything about it - It avoided the problem of a strange configuration of the customer where a product in FBM could be placed in the Amazon location, as nothing ensure that everything placed there is, indeed, a FBA product, even if this is the recommended setting. - After testing the synchronization of the FBM stock, we couldn't see any changes in the Amazon backend, which lead us to think that we couldn't, in fact, update the stock of a FBA product as Amazon would ensure the stock used would be the one in their warehouse. Recently, we got some problem with FBA order that Amazon considered being FBM. After investigation, it was found that the stock send for FBA would be set as having a "DEFAULT" fulfilment channel, but this wasn't shown anywhere on Amazon backend, only in their DB. So from time to time, instead of using the set fulfilment channel of a product, Amazon would use that default one, with a separate, virtual, stock. With this fix, we ensure that this "default" channel is now filled with a quantity of 0 instead, for FBA product. We assume the set-up of the Amazon account on Odoo is correctly made and all products in the Amazon location are FBA. task-3693853 Forward-Port-Of: odoo/enterprise#54737
The tax report was displaying a warning banner whenever draft accounting entries existed, even when those entries were just routine closing entries that don't require user attention. This fix removes the banner for closing entries only, ensuring users only see warnings for draft invoices and entries that actually need review. The change also improves performance by optimizing the search query.
Original PR description
On the tax report, a banner can be displayed if there exist some draft moves for the selected period. We don't want the banner to appear if the only draft move is a closing entry. The goal of the banner is indeed to warn the user if he still needs to pay attention to draft invoices/entries that might impact the report. We therefore exclude all closing entries from draft moves search. A bit of refactoring was necessary to only apply the logic to tax reports. A limit=1 has also been added on the search_count to improve performances. task-3682431 Forward-Port-Of: odoo/enterprise#55573 Forward-Port-Of: odoo/enterprise#55167
This fix resolves an issue where installing the data merge module alongside CRM would fail with validation errors during database upgrades. The problem occurred because the system was trying to validate rules for models that hadn't been fully loaded yet. The fix allows the data merge module to install successfully while maintaining validation checks during normal operations.
Original PR description
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded…
Since odoo/odoo@f0cb56f3651da487c1f4fe34adc25e7401678703 we check rules domains. This has the side effect of making rules in data_merge fail because they may pertain models that are yet to be loaded by the ORM.
Steps to reproduce:
1. Install `crm` and `data_merge` on a new DB
2. Run data merge for `crm.leads` Data Cleaning > Configuration > Deduplication Rules > Lead/Opportunity > DEDUPLICATE
3. Try to install data_merge module `./odoo-bin ... -i data_merge`
We get a `ParseError`:
```
...
File "/home/odoo/src/odoo/15.0/odoo/tools/convert.py", line 694, in _tag_root
raise ParseError(msg) from None # Restart with "--log-handler odoo.tools.convert:DEBUG" for complete traceback
odoo.tools.convert.ParseError: while parsing /home/odoo/src/enterprise/15.0/data_merge/security/security.xml:4
Invalid domain: 'crm.lead'
```
This issue happens during upgrades 14.0->15.0
The actual reason for the failure is that this line https://github.com/odoo/odoo/blob/dbd37953957b94a2e05908d96cf8e4d7dea42d72/odoo/addons/base/models/ir_rule.py#L79 eventually gets into
https://github.com/odoo/enterprise/blob/0db3d7c9473034da0714f96fe915a7dedb7b667e/data_merge/models/data_merge_record.py#L101 and this causes a `KeyError` because `crm.lead` is not loaded yet.
This error didn't happen before because at XML load there was no attempt to generate a `Query` from a domain expression. After the linked commit above we now force the parse of such queries. That involves the call to `_search_company_id` for `data_merge.record` entries.
The patch proposed here skips `ValidationError`s at install of `data_merge`. This still keeps the validation active for usual DB operations.
X-original-commit: 5a64974501b5be231e2eed941f42ae6dfe110f18
Forward-Port-Of: odoo/enterprise#55847This update fixes the ecological report in the Sign module so that text cards are now properly translated into different languages. Additionally, several English phrases have been corrected for clarity and better user experience, including changing "carbon" to "carbon emissions," fixing "sparred" to "saved/reduced," and replacing "like" with "that's" for clearer messaging about environmental savings.
Original PR description
The cards in the ecological report weren't translated due to the strings being defined in t-values. This is switched so that they will now be correctly exported to the .pot file + translated.…
The cards in the ecological report weren't translated due to the strings being defined in t-values. This is switched so that they will now be correctly exported to the .pot file + translated.
Additionally cleaned up some of the incorrect English for a better UX. More terms could be improved/fixed as well, but they do not affect the users as much + are already translated so changing them was avoided in stable.
- Carbon => "carbon emissions": this or CO_2 are used when referring
to reducing pollution due to burning fuel. "carbon" on its own implies
the element, whereas adding "emissions" to the end of it implies CO_2
(emissions), because English ¯\_(ツ)_/¯
- sparred => saved/reduced: sparred is both spelled wrong (i.e. should be spared) and incorrect to use in this case
- like => that's: "like" doesn't make sense to use in this case and is confusing to read. "That's" indicates how much the user is saving/reducing/etc. "Approximately" or "about" also would have worked, but are less friendly sounding
Forward-Port-Of: odoo/enterprise#55823
Forward-Port-Of: odoo/enterprise#54685This fix resolves an issue where creating new tags in the Documents & Analytics section of the Project form on mobile devices was not working properly. The search functionality for tags in the mobile kanban view has been corrected by adding the proper domain filter to the facet_id field, ensuring users can now properly create and manage tags on mobile devices.
Original PR description
Steps to Produce: - Navigate to the 'Project' form view on a mobile device. - Go to the 'Documents & Analytics' section in the 'Default Tags.' - When you try to create new tags in the 'Category' field, observe that it shows existing tags. Issue: - 'name_search' is not work for kanban view of mobile. Solution: - To resolve the issue, we need to add the missing domain to the 'facet_id' field. task-3549328 Forward-Port-Of: odoo/enterprise#55825 Forward-Port-Of: odoo/enterprise#49586
Fixed an issue where the invoice extraction system was incorrectly including box data in validation requests even when users didn't select them. Now boxes are only sent when actually clicked and their text matches the field value. This improves data accuracy for the AI model's learning process.
Original PR description
Previously, we were always returning a box in the validation request, even when no box was clicked by the user. Now, the box will only be part of the request if it was indeed clicked by the user and that its text matches the text of the field. This has little impact on the learning of the AI model as it was mostly relying on the text of the validated value, not its box. Forward-Port-Of: odoo/enterprise#55783 Forward-Port-Of: odoo/enterprise#55643
This fix resolves a problem where product image editing options would disappear when entering edit mode on product pages with slow network connections. The issue occurred because code was executing after the page editor was closed, causing the loss of editing functionality. The fix ensures that code only runs when the editor is still active.
Original PR description
[FIX] sale: ensure widget is alive before executing code Steps to reproduce the bug: - Add a delay (for example 10 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Go on…
[FIX] sale: ensure widget is alive before executing code Steps to reproduce the bug: - Add a delay (for example 10 seconds) at the beginning of the `/sale/get_combination_info_website` route. - Go on a product page and enter edit mode. Note that the `websiteSaleCarouselProduct` is destroyed. - Click on the the product image. Note that the "Replace" button appears. - Wait for the added delay to finish. -> If you click on the product image, the "Replace" button does not appear. In this situation, the added delay represents a slow rpc answer. Let's analyse the flow of instructions in order to better understand the problem: - When you go on a product page, the `WebsiteSale` public widget is started. `_getCombinationInfo` of `VariantMixin` is then called through the `start()` of the public widget. As the rpc is taking time to answer, `_onChangeCombination()` is not directly called. - When entering edit mode, the `WebsiteSale` public widget is destroyed. Due to the edit mode, the `o_editable` class has been added on editable elements. - After the added delay and thanks to the rpc answer, `_updateProductImage()` is called through `_onChangeCombination()`. The `_updateProductImage()` replaces some elements of the DOM and by doing so, removes the `o_editable` class of some elements. Consequently, the snippet option linked to the image is not displayed. The problem here is that the `_updateProductImage` method is called even if its associated public widget has been destroyed. To solve the problem, we first check that the associated widget is alive before handling the result of the rpc answer in the `VariantMixin` mixin. Note that the first idea was to use `this._rpc()` instead of `ajax.jsonRpc()` in the mixin. Indeed, the advantage of using `this._rpc()` is that it already ensures that the associated widget is alive before handling the result of the rpc answer. The problem is that some widgets that use the `VariantMixin` are created in such a way that `this._rpc()` can not be used on them (for example `OptionalProductsModal`). Related to runbot-28700 Forward-Port-Of: odoo/odoo#148716
This fix resolves a problem where the undo and redo functions in the web editor were not working correctly after dragging and dropping elements. The issue was caused by internal class changes being recorded in the history. By preventing these internal changes from being tracked, users can now undo and redo their edits properly without encountering unexpected behavior or extra undo steps.
Original PR description
Since commit [1], which removed jQueryUI for the drag and drop, the history when editing breaks easily. Steps to reproduce: - Drag and drop "Text-Image", save and go back to edit mode. - Click on a…
Since commit [1], which removed jQueryUI for the drag and drop, the history when editing breaks easily. Steps to reproduce: - Drag and drop "Text-Image", save and go back to edit mode. - Click on a column, move it to the right using the arrow and then to the left, still with the arrow. - Undo: no issue, the column went to the right. - Undo: nothing changed => the column should have gone to the left. - Undo: the column goes to the left => there should not be a third undo since we only did two changes. - Redo: no issue, the column goes to right. - Redo: nothing changed => the column should have gone to the left. - Nothing to redo anymore => the column never goes to the left again. This happens because with the new drag and drop, an `o_draggable` class is added on the elements when their editor are started, which adds mutations in the history. Even though it does not explicitely add a step, these mutations are well reverted when undoing/redoing (e.g. this is what happens when nothing changes in the steps to reproduce). This commit fixes this history issue by ignoring the mutations linked to the `o_draggable` class. Note that commit [2] already fixed other `o_draggable` class issues. This commit therefore fixes them in a more general way. [1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76 [2]: https://github.com/odoo/odoo/commit/32a6729dd094d53eb4a653ebb9d69d2b8cbe2390 task-3698536
Users can now successfully mark slides as incomplete after marking them as complete. A technical update to the slide completion system was preventing users from reverting their progress status. This fix restores the ability to undo slide completion, giving users more flexibility in managing their course progress.
Original PR description
Before this PR, users were unable to successfully revert the 'done' status of slides. Technical Reason: In this commit https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b, the transition from qweb.render to the Owl render engine (renderToElement) was done. This caused a problem when trying to undo the 'done' status of slides. The issue was that using 'true' as a boolean in Owl turned it into an empty string. This fix solves the problem by making sure we use '0' or '1' as boolean values in Owl. After this PR, user can revert slides 'done' status. **Task**-3667904
This update significantly improves the speed of searching for journal entries in the accounting module. By adding a database index and simplifying the search logic, query times have been reduced from over 2 minutes to less than 1 second on large databases. Users will experience much faster and more responsive searches when looking up journal entries.
Original PR description
On a big database, the search for journal entries is basically not usable.
This is because there is a missing index on the reference, as well as a complex OR generated by the clause `('move_id.partner_id', 'ilike', self)`.
This commit will of course add the index, but will also remove the clause because it is almost always possible to find the journal entry via the partner by using the right filter instead, and since it is not really an easy to discover "feature" it is most likely not even used.
On the test database, queries went from over 2 minutes to less than 1 second.This fix restores the cumulated balance feature in the accounting module, which was previously removed and broken by system updates. The feature is now available again and can be displayed in views through customization tools like Studio, though it remains hidden by default to maintain the standard view appearance.
Original PR description
The cumulated balance has been removed from the standard view [^1] Since then it has been broken by a series of refactors of the ORM, making it impossible to add the field back to the view. [^2] This commit is fixing this, keeping the field hidden by default, but can still be added via Studio or other means. [task-3703749](https://www.odoo.com/web#id=3703749&model=project.task) [^1]: https://github.com/odoo/odoo/commit/652292a4788f6aca978ed97682577024ba53d7d0 [^2]: https://github.com/odoo/odoo/commit/7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 https://github.com/odoo/odoo/commit/2a121a32a2c7a20163daba94ca7b621a6877a23e
This fix corrects a confusing issue where customers see "Thank you for your order" on the confirmation page even when their payment failed or was canceled. The page now only displays this success message when payment is actually completed, preventing customer confusion and ensuring accurate transaction status communication.
Original PR description
**Issue Description**: Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are…
**Issue Description**: Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are directed to /payment/status with an error message. However, selecting the "Skip" button redirects them to a confirmation page titled "Thank you for your order", suggesting successful payment. This misleading information can lead to confusion, especially since it results in the card being cleared for public users despite non-receipt of payment. **Steps to Reproduce**: 1. Navigate to the 'Shop' section of the website, add a product to the cart, and proceed to checkout. 2. Click the "Pay with demo". 3. Select "Canceled" as the Payment Status and then "Pay". 3. Click the "Skip" button during the payment process. 4. Observe redirection to a confirmation page with the title "Thank you for your order", implying successful transaction. **Proposed Solution**: This issue, present in versions 17.0 and later, is due to a modification in the <template id="confirmation">, where the "Thank you for your order" title is now displayed regardless of the payment state. To resolve this, we propose introducing a conditional check to display this title only when the payment state is "done", ensuring accurate representation of the transaction status. opw-3688785
This fix resolves issues where image links and customization settings (like filters and shapes) were lost when users added or reordered images in website gallery snippets. The system now properly preserves all image properties and links during these operations, ensuring a better user experience when managing image galleries on websites.
Original PR description
[FIX] *: keep image link and options after image reordering in a gallery *: website Steps to reproduce: - Add an "Images Wall" snippet on the website. - Add a link on the first image. - Add a new…
[FIX] *: keep image link and options after image reordering in a gallery *: website Steps to reproduce: - Add an "Images Wall" snippet on the website. - Add a link on the first image. - Add a new image on the wall. -> Problem: the first image does not have a link anymore. When adding an image or reordering the images on a wall, the system re-renders the snippet (see `nomode()`, `masonry()`, `grid()`) by adding each images on the wall structure. The problem is that the system only takes the images into account and not a possible image wrapped into an anchor. This is now fixed as the system renders the images or the wrapped anchored images returned by `_getImgHolderEls`. The process is a bit different when adding an image or reordering the images of an "Image Gallery" snippet. In this case, the system re-renders the `website.gallery.slideshow` template. The problem here is double: First, the template does not take a possible wrapped anchored image into account. Second, there are only few image attributes that are rendered by the template. This leads to a new problem: - Add an "Image Gallery" snippet on the website. - Add a "Blur" filter on the first image. - Click on "move to next" to move the first image at the second position. -> Problem: the image option does not show the filter and it is now impossible to change some image options such as "Filter", "Shape" and "Quality". To solve those two problems, the images rendered by the `website.gallery.slideshow` template are replaced by the images (or the wrapped anchored images) returned by `_getImgHolderEls`. By doing so, the rendered images have the correct attributes (so the options can be correctly displayed and modified) and they are still correctly anchored. opw-3535829 Forward-Port-Of: odoo/odoo#152134 Forward-Port-Of: odoo/odoo#142669
This fix resolves a system error that occurred when updating purchase order quantities in specific manufacturing scenarios. The issue happened when canceling backorders and then adjusting ordered quantities. The fix prevents unnecessary operations that were causing the error, allowing users to update purchase quantities smoothly without system crashes.
Original PR description
**Steps to reproduce the bug:**
- Create a storable product X1:
- Route: MTO + buy
- Vendor: Azure Interior
- BoM:
- Type: subcontractor
- Subcontractor: Azure interior
- Component: any component
- Create a MO:
- product: P1
- Component: X1, qty: 3
- Confirm the MO
- Go to the created PO
- Confirm the PO
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line to 2
**Problem**:
A traceback is triggered: File "/home/odoo/src/odoo/addons/purchase_stock/models/purchase.py", line 542, in _prepare_stock_move_vals
'picking_id': picking.id,
AttributeError: 'bool' object has no attribute 'id'
**Solution**:
When updating the quantity in the purchase order, if no picking requires an update, it is better to avoid creating a new picking and new moves.
opw-3681064
Forward-Port-Of: odoo/odoo#152473This fix corrects an issue where new sales team members without an assigned team would see the wrong email alias when viewing their empty CRM pipeline. The system now displays the correct team-specific email address, ensuring users can properly contact their sales team through the pipeline interface.
Original PR description
Steps to reproduce: - Create a new user with no affiliated sales team - Activate custom mail server with an alias domain - Login with new user - Check pipeline in CRM - The empty pipeline message will show the wrong alias Issues: The alias displayed is not for the team of the user. opw-3608263 Forward-Port-Of: odoo/odoo#152287 Forward-Port-Of: odoo/odoo#144133
This update removes an unnecessary code change that was causing incorrect action buttons to appear in leave request forms before they were saved. The fix restores the proper behavior by relying on the existing state calculation function that has been in place since version 14.0, ensuring users see the correct options when creating new leave requests.
Original PR description
Ever since 14.0, from PR #45414, there has been a _compute_state function for recalculating the state on holiday_status_id change The reverted commit becomes unnecessary and causes incorrect action buttons to be shown before creation Note: Reverts commit 015f8ecfa863ae2fcca983b6bb21e38577b220e7 from #82552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150826
This fix resolves an issue where physical mail (snailmail) was not being sent to customers who don't have an email address on file. Previously, the system would skip snailmail creation if no email was present, even when the customer explicitly requested physical mail delivery. Now snailmail will be properly generated for these customers while maintaining normal email functionality.
Original PR description
Current behavior: --- If a customer has no email set, creating an invoice for that customer and clicking on send and print will not generate a snailmail for the invoice, even if, the checkbox…
Current behavior: --- If a customer has no email set, creating an invoice for that customer and clicking on send and print will not generate a snailmail for the invoice, even if, the checkbox (checkbox_send_by_post) is True. Expected behavior: --- A snailmail should be sent to the customer. Steps to reproduce: --- Create a customer invoice for a customer without email > print and send > check "By Post" > send and print. Cause of the issue: --- The action action_send_and_print defined in account_move_send.py filters the moves that trigger a mail creation in the var "success". This variable filters out all moves without a partner_id.email. This makes perfect sense for emails but not for snailmails. However, creations of both types of mails are triggered by the method "_hook_if_success" taking "success" as one of its argument. Fix: --- To allow snailmail creations and correctly trigger email creation, we filter the moves with a partner email after the method "_hook_if_success" and only for email creation, not for snailmails. opw-3668487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152107 Forward-Port-Of: odoo/odoo#149553
This update prevents system errors that could occur when users delete analytic accounts or plans that are still referenced in the system. The fix adds defensive checks throughout the code to safely handle deleted accounts and includes new safeguards to prevent deleting plans while they're still in use. This ensures a more stable and reliable experience when managing analytic data.
Original PR description
Deleting an account or a plan shouldn't raise errors or provoke errors elsewhere. Since the `analytic_distribution` doesn't have a proper foreign key, an account might be deleted while still being referenced. Because of this the code needs to be defensive everywhere: we can't trust the content of the JSON field. Also, add tests to ensure that we can't delete a plan while the field is still referenced in views.
This fix resolves an issue where sample data would incorrectly disappear when users switch between different views (like from Kanban to Calendar and back). Users will now see their sample data preserved when navigating between views, providing a more consistent and reliable experience when working with filtered data.
Original PR description
This commit solves an issue where sample data would be erased when the user switches from a view with no sample data to another that should contain them. This commit also removes unnecessary usage of nextTick in assets loading. Steps to reproduce: - go to project and open one - enter a no match filter and save it as favorite - reload - switch from kanban to calendar view and switch back to kanban - after the fix, sample data should no longer be erased from kanban task-3701143 Forward-Port-Of: odoo/odoo#152061 Forward-Port-Of: odoo/odoo#151739
This update improves the appearance of product filters on the online store by removing the visible scrollbar that appeared when filters had many options. Users can still scroll through filter options, but the interface now looks cleaner without the scrollbar being displayed.
Original PR description
When filtering column had too much attributes, scrollbar would appear. Scrollbar was deleted but ability to scroll is left. task-3609062 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145934
This fix resolves an issue where creating new product tags from a product variant view was failing. The system was incorrectly using the variant's ID instead of the template's ID when creating tags. This has been corrected by adjusting how the variant view inherits settings from the template view, ensuring tags are properly associated with the correct product template.
Original PR description
Before this fix, the ORM tried to fetch the `product.template` using the `product.product`'s id when creating a new product tag. This was caused by the `context="{'product_template_id': id}"` attribute on the `product_tag_ids` field in `product_template_form_view` [1]. However, `product_normal_form_view` inherits `product_template_form_view` [2], so `context="{'product_template_id': id}"` ended up assigning a `product.product` id to `product_template_id`.
The fix overrides the context attribute in `product_normal_form_view`.
[1] https://github.com/odoo/odoo/blob/06c4d0363e56a640b2239a17ff32e6681ba78018/addons/product/views/product_views.xml#L85
[2] https://github.com/odoo/odoo/blob/06c4d0363e56a640b2239a17ff32e6681ba78018/addons/product/views/product_views.xml#L387
task-3619625
Forward-Port-Of: odoo/odoo#149502This fix resolves an issue where users encountered an error when trying to cancel activities linked to calendar events (calls or meetings) in the chatter. Previously, the system would fail to properly delete these activities and they would remain visible. The fix ensures that the necessary information is properly passed through the system so activities can be successfully removed.
Original PR description
Before this PR: Canceling an activity linked to an event produces error because of non provided thread. Steps to reproduce: - Create an activity with event (call or meeting) in chatter - Try to cancel this activity - There is an error about undefined thread and activity remains on the chatter After this PR: - Thread is provided in `onUpdate` method to use in `load()` in chatter - `activityService` deletes the activity with event in `unlink` patch
This fix eliminates the problem where printing a receipt in the Point of Sale system would produce an unwanted blank page, wasting paper and causing operational issues. The issue was caused by a notification element appearing on the print page, which has now been removed to ensure only the actual receipt content is printed.
Original PR description
Before this commit, printing a receipt would result in an additional empty page being printed. This not only wasted paper but also caused issues. The problem was related to the notification element on the print page. By removing this element, the issue has been resolved. opw-3706233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where locally-stored Google fonts could not be removed from the website theme. When users added a Google font and disabled cloud serving, attempting to delete the font would fail. The problem was caused by a technical change in how the system handles font parameters, which has now been corrected to ensure fonts can be properly removed.
Original PR description
Steps to reproduce the bug: - Enter edit mode. - Click on the "Theme" tab in the options panel. - Click on "Add a Google Font" in the "Font Family" select. - Paste the address of a font page in the…
Steps to reproduce the bug: - Enter edit mode. - Click on the "Theme" tab in the options panel. - Click on "Add a Google Font" in the "Font Family" select. - Paste the address of a font page in the input. - Disable the "Serve font from Google servers" toggle. - Save the dialog. - After the reload, click on the "Theme" tab. - Open the "Font Family" select. - Click on the "Remove" button for the recently added font. - Confirm your choice to close the dialog. - After the reload, click on the "Theme" tab. - Open the "Font Family" select. - Bug: the font has not been removed. This bug appeared with commit [1]. With the transition to the Owl render engine, the 'true' value passed as a parameter in the 'delete_google_font_btn' template, defining whether a font is local, wasn't being set as the attribute value in the template. In this Owl context, 'true' indicates the attribute's presence, not its value. To address this, we replaced the boolean 'true' with the string '"true"' to ensure the parameter value is correctly passed to the template. [1]: https://github.com/odoo/odoo/commit/f956e83c744bd9c970d3f16ce1cb3cff8bba2f6b task-3714768
This update resolves an issue where the stock traceability report couldn't be accessed through external API connections. The system was returning invalid data that caused API calls to fail. By correcting the data format returned by the report, external integrations can now successfully retrieve stock traceability information.
Original PR description
Trying to call the get_lines() method of the stock.traceability.report model was failing using the external API, due to the response containing None values. Making sure that False is returned instead of None fixes this. The XML-RPC client error is the following: TypeError: cannot marshal None unless allow_none is enabled --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147831
This fix resolves an issue where Mercado Pago payment processing would crash with an unhandled error when receiving responses without a body from the payment gateway. The fix improves error handling to gracefully manage these edge cases, ensuring customers can complete their checkout process without encountering technical errors.
Original PR description
[FIX] payment_mercado_pago: handle mercado pago no body responses Issue: When using a mercado pago invalid access token with extra tabs, we get 403 response from mercado pago without a body which…
[FIX] payment_mercado_pago: handle mercado pago no body responses Issue: When using a mercado pago invalid access token with extra tabs, we get 403 response from mercado pago without a body which raises and exception while handling this exception we fail to parse the response as it has no body. line causing the issue: https://github.com/odoo/odoo/blob/9764e6f7fe39a10f3b04e1764110d8c274d0431a/addons/payment_mercado_pago/models/payment_provider.py#L70 Steps to reproduce: 1- Enable mercado pago as a payment provider 2- Set a valid access token for mercado pago with extra tabs 3- Go to website 4- Fill the cart 5- Checkout with the cart using mercado pago 6- You see error message of unhandled json parsing error Solution: We should wrap parsing the response in a try statement to handle the responses without body opw-3654133 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 Forward-Port-Of: odoo/odoo#152762 Forward-Port-Of: odoo/odoo#152102
This update fixes critical bugs in the Italian EDI module that were preventing users from sending invoices. The module had compatibility issues after a recent code migration that caused system errors. Applying this fix restores the ability to send invoices to the Italian EDI system without errors.
Original PR description
The compatibility was broken in a couple of points, clients are required to update the `l10n_it_edi` or cannot send invoices to the Italian EDI. Updating the module fixes the errors. (View changes…
The compatibility was broken in a couple of points, clients are required to update the `l10n_it_edi` or cannot send invoices to the Italian EDI. Updating the module fixes the errors. (View changes and the warning_message will not be used anymore)
These two errors may appear:
```
[...]
File "/home/odoo/work/odoo/odoo/fields.py", line 1216, in __get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign account.move.send(<NewId 0x7ff2da360eb0>,).l10n_it_edi_warning_message
[...]
File "/home/odoo/work/odoo/addons/l10n_it_edi/wizard/account_move_send.py", line 57, in _compute_l10n_it_edi_warning_message
action = error_data['action']
~~~~~~~~~~^^^^^^^^^^
KeyError: 'action'
```
Credit goes to @salvorapi for his first analysis.
Original broken PR: odoo/odoo#142596
- Missing default
- Action being mandatory in the `warning_message` field
This update resolves a build failure in the Point of Sale IoT system by removing an unnecessary upgrade step during the build process. The base image is already up-to-date, so the "apt upgrade" command has been removed to prevent compatibility issues with new Linux packages and allow the build to complete successfully.
Original PR description
The iot build fails following the installation of the new linux-image-6.1.0-rpi8-* packages The base image is recent enough to skip the upgrade during the build The "apt upgrade" command is therefore removed from the build Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how numbers are formatted when displayed in various Odoo modules. A previous change inadvertently broke number formatting in several areas by using the wrong formatting function. This fix restores proper number display across manufacturing, project, stock, and other modules.
Original PR description
Commit [1] moved (almost all of) the code of formatFloat from views/fields/formatters.js to core/utils/numbers, to make it accessible in the frontend. A formatFloat function was kept in formatters.js to handle the false case, which makes no sense in number utils, but is useful for fields. However, a lot of imports have been updated to use the numbers.js instead of formatters.js (i.e. they no longer benefit from the support of false), whereas they are actually formatting field values, so they should have kept using the formatFloat from formatters.js This commit adapts the places where the formatFloat to use must come from formatters.js, not numbers.js. [1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8 task 3722043 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
Documentation and clarification updates
This update adds new members to the Tecnativa Contributor License Agreement and updates existing member information with current due dates. This ensures the CLA documentation remains accurate and reflects the current status of Tecnativa contributors.
Original PR description
Add some new members and update old ones with the due date. @Tecnativa Forward-Port-Of: odoo/odoo#152745