Daily updates from Odoo
Friday, March 29, 2024
44 changes · 17.0
Resolved issues and error corrections
Fixed a confusing error message that appeared when users added companies to a worksheet template that previously had no companies assigned. The error message now clearly explains the issue instead of displaying blank company names, making it easier for users to understand what went wrong and how to fix it.
Original PR description
This commit's purpose is to improve the error message when a user is adding new company to a template that had none set before. Steps to reproduce: - open fsm app - open configuration menu, worksheet template - select the 'Device installation and maintenance' worksheet (it is the one with tasks linked to it) - add a new company 'my company (chicago)' and save. A validation error message pops up. That is fine and the expected behavior, since the new companies of the template are not consistent with the task already linked to it. Source: the generic message is using the old values of the companies of the worksheet, but since there were none, no names are displayed and the error message is confusing. Solution: check if the worksheet used to have companies set before the user changes. If not, display a relevant error message task - 3749225
Corrected a bug in Ecuador's withholding tax feature where adding multiple withholding lines would incorrectly use the same tax base amount for each line instead of calculating the remaining balance. This fix ensures accurate tax withholding calculations when processing bills with multiple withholding entries.
Original PR description
With an Ecuador company setup Create a bill adding: - Ecuador partner - Bill Date - Document Number (ex. 001-001-123456789) - Payment Method - a bill line with tax "12% 510 01" Post the bill Hit 'Add witholding' In the witholding widget: - Add a line with tax "10% WH" - Add a second line with tax "10% WH" Issue: second line base amount will be same as first, while it should use the remaining withholding base amount opw-3763838
This update corrects misleading button and filter labels in the Documents module. Users were seeing "Archive" labels on buttons and filters that actually move documents to trash, causing confusion. The labels have been updated to accurately say "Move to trash" to match the actual behavior of the feature.
Original PR description
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Configuration -> Workspaces - Click on the search view dropdown - The filters section still has a filter named 'Archived Workspace' instead of 'Moved to trash' even though it displays trashed workspaces. This PR changes the string of filter from 'Archived Workspace' to 'Moved to trash'. Task: [3787404](https://www.odoo.com/web#id=3787404&cids=2&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form)
This fix resolves an error that occurred in the General Ledger report when attempting to format currency values (such as K$, M$). The issue was caused by incorrect handling of currency data when reformatting values. The fix ensures currency information is properly processed, preventing errors both in standard and expanded report views.
Original PR description
In General Ledger report, we get an error when trying to reformat value (K$, M$, ..) Reason: When setting the 'currency' value on each column, we take the currency of the account, which is interpreted as a string on js side, then used to call format_value in where we try to get `currency.id`, leading to the error. To avoid that, we return only the id of the currency if there is one. Also, we get a KeyError whendoing the same flow with unfolded lines opw-3793209
The permission panel in the Knowledge module was not refreshing when its values changed, causing users to see outdated information. This fix ensures the panel now properly updates and displays the latest values whenever changes occur.
Original PR description
**Before this PR:** The permission panel was not being updated when its values changed, resulting in outdated values being displayed. **After this PR:** the permission panel now re-rendered to reflect the updated values correctly. **Task**-3792165 Forward-Port-Of: odoo/enterprise#58825
This fix corrects test validation values for eco voucher calculations in the Belgian payroll module. The expected test values were not updated in a previous change that excluded parental time off from eco voucher eligibility. This ensures payroll tests run correctly without demo data.
Original PR description
Expect value for test without demo data wasn't changed in this PR :odoo/enterprise#50794 Fixed with this commit. task: 3837296
This fix prevents subscription orders from being locked when the "Lock Confirmed Sales" setting is enabled. Previously, enabling this security setting would incorrectly lock subscription orders after invoicing, preventing further modifications. The fix ensures this setting only applies to regular sales orders, not subscriptions, as intended.
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/odoo/pull/157026 opw-3754106 Forward-Port-Of: odoo/enterprise#59118 Forward-Port-Of: odoo/enterprise#58332
Fixed an issue where importing Mexican electronic bills (CFDI) would crash if certain tax rate information was missing. Now the system gracefully handles these cases by logging a message and continuing the import process instead of failing completely.
Original PR description
When trying to import a bill that sometimes did not had TasaOCuota attribute. This resulted in a crash of a failed float parse Now when this happens, a message in the chatter is created and the tax_id is ignored task:3777664 Forward-Port-Of: odoo/enterprise#58812
This update fixes appointment scheduling tests that were failing when demo data wasn't available. The system now properly handles timezone settings and removes dependencies on specific demo user accounts, making tests more reliable and independent of sample data.
Original PR description
* With no demo data, the current user does not have a timezone set. As the default value of appointment_tz is based on that, it leads to an error. We now set manually the appointment_tz for the appointment type created. * Remove the use of demo data (Mitchell Admin and Joe Willis) for test tour.
Fixed an issue where the "Connect to a bank" button would disappear from the journal dashboard after removing a bank synchronization. Users can now properly reconnect to their bank after resetting the sync without needing to refresh or navigate away from the dashboard.
Original PR description
…ter reset sync - Connect to a bank with the button in the journal dashboard - Remove sync (sometime you should do this) --> Issus the button Connect to a bank is not show on the dashboard
This fix resolves an issue where deleting trashed documents from the activity view would lose the applied search filter. Now when users delete a document that was filtered to show inactive items, the filter is properly maintained after the deletion, ensuring a consistent user experience.
Original PR description
**Before this PR:**
When user deletes a trashed document (accessed by applying a custom filter
with domain `[('active', '=', False)]`) from the activity view, search domain
(i.e. existing filter) is not applied after deletion.
**After this PR:**
The issue has been addressed by calling the 'load' method of activity model
along with the model 'config' as arguments to ensure that proper domain is
applied according to the search filter after delete operation.
Task: [3714544](https://www.odoo.com/web#id=3714544&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form)
Forward-Port-Of: odoo/enterprise#59661
Forward-Port-Of: odoo/enterprise#56357This update corrects how planned hours are calculated when they fall on public holidays or employee leaves. Previously, a workaround was needed because timesheets weren't created for holidays, but this is now fixed in version 16.3+. The system now properly accounts for holidays by automatically subtracting actual timesheet hours from planned hours, ensuring accurate remaining hours in the Timesheets & Planning analysis.
Original PR description
This reverts commit 55cba9f899be0f058834bcd81bd239547c9cebd6. The issue this intended to fix was rooted in the fact that no timesheets were created for public holidays, leading to the remaining hours shown in Timesheets & Planning analysis being wrong. This is no longer an issue starting from version 16.3, timesheets do get created, so any *planned* hours that fall on a holiday get subtracted by the corresponding effective hours from timesheets. opw-3509155 Forward-Port-Of: odoo/enterprise#59645
Fixed an issue that prevented non-accounting managers from opening journal statements due to a bank synchronization check requiring manager access rights. The system now skips this update for non-managers, allowing them to view journals while managers handle the synchronization updates.
Original PR description
…when opening journal statements When opening journal, a check is done to update the bank sync state It is not possible to update the state without accounting manager access rights Introducing a skip for non account managers to allow opening the journal. Furthermore, non-managers can't see the online sync anyway so we don't update it until a manager opens the journal. opw-3800147
This update fixes an issue with DHL shipping where shipper and receiver reference information was not being set correctly during delivery validation. The fix ensures that when customers create sales orders with DHL shipping and validate deliveries, the proper reference details are now included in the DHL shipment request, improving the accuracy of shipping documentation.
Original PR description
Steps to reproduce: - Set up DHL shipping - Create Sale order add dhl shipping and validate the delivery Fix: set the correct shipper and receiver referrence opw-3775347 Forward-Port-Of: odoo/enterprise#59627
This fix ensures that product tracking is properly enabled in barcode scanning tests, preventing test failures when demo data is not available. The change ensures that test lines are correctly grouped during barcode operations, maintaining test reliability across different environments.
Original PR description
The product tracking is enabled by default in the demo data. Running the test without those data will break, as the 2 lines in the tour won't be grouped. runbot 54158 Forward-Port-Of: odoo/enterprise#59647
A test in the Planning module was failing due to daylight saving time changes. This fix ensures the test consistently uses UTC timezone throughout, eliminating failures caused by seasonal time changes. This makes the test more reliable and easier to maintain.
Original PR description
Before this commit, the test fails since 23 March 2024 because next week the hours changed (summer time). The problem is there if the timezone is not UTC. This commit ensures the whole test uses the same timezone and only UTC one to avoid having to manage summer/winter time in the test. runbot-60932 Forward-Port-Of: odoo/enterprise#59366
This update fixes an issue where Ponto's consent expiration dates were not being tracked correctly in the online account synchronization system. The fix ensures that expiration dates are checked and updated each time the system communicates with Odoofin, providing more accurate and timely information about account access permissions.
Original PR description
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
This update fixes two issues in the barcode scanning system for warehouse transfers. Previously, users could scan any location as a source location, and packages stored in sub-locations were incorrectly rejected during scanning. Now the system properly recognizes packages and locations that belong to the picking's source location or its child locations, allowing warehouse staff to complete transfers more efficiently without unexpected error messages.
Original PR description
**[FIX] stock_barcode: scan only picking's (sub)loc** > Before this commit, it was possible to scan any location as the source location. > This commit fixes that and a location can be used as the source only if it's the picking's source location or one of its child locations. **[FIX] stock_barcode: Package source location** > Steps to reproduce: > - Edit internal transfers setting: -- general tab: Move entire Package "Checked" -- barcode tab: Source Location "No Scan" > - Create a new storable product > - Update onhand qty: 20 package: PKG1, location: WH/Stock/Shelf 1 > - in Barcode app create a new transfer and scan PKG1 > > Bug: > the current package location is different from the default source location therefore package is ignored and an error is thrown (you are expected to scan one or more products ....) > > Fix: > check if the package is in a child location aswell > > opw-3595643 Forward-Port-Of: odoo/enterprise#59526 Forward-Port-Of: odoo/enterprise#58896
Portal users were unable to filter opportunities by activity date (Overdue/Today/This Week) due to insufficient access rights, resulting in a 403 error. This fix adjusts how the system handles permission checks during searches, allowing users to properly filter their assigned opportunities while maintaining security controls.
Original PR description
…search **Issue Description:** Due to changes in field access rights verification as seen here: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345…
…search **Issue Description:** Due to changes in field access rights verification as seen here: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345 And the removal of sudo rights for CrmLead: https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/addons/website_crm_partner_assign/controllers/main.py#L98 Attempting to open a search by domain with the `activity_date_deadline` field triggers a 403 error: "You do not have enough rights to access the fields 'activity_date_deadline' on Lead/Opportunity (crm.lead). Please contact your system administrator." **Steps to Reproduce:** 1. Install the `website_crm_partner_assign` module. 2. Assign Joel Willis a partner level (via the partner assignment tab in the `Contact` app). 3. Navigate to CRM, select an opportunity, and assign it to Joel Willis (using the assigned partner tab in the lead form). 4. Log in to the portal as Joel Willis, navigate to Opportunities, and click any filter on the activities date `Overdue / today / this week activities`. This action results in a crash. **Proposed Solution:** Our approach focuses on secure and efficient access to data, especially for sensitive fields like `activity_date_deadline` and `activity_ids.date_deadline`. We selectively apply higher permissions during search operations to ensure users can access crucial information without compromising data security. By carefully using higher permissions and applying internal rules after searches, we strike a balance between making data available for legitimate needs and upholding our security measures. opw-3703583
This fix resolves an issue where uploading files or using the image command in the email composer was causing errors. The code was not properly updated after recent changes to how the system handles file relationships, preventing attachments from being correctly added to messages.
Original PR description
When using the `/image` command in the composer, or otherwise uploading a file the editor should add the attachment to the composer if it is the current model During a change in js relational models [1] the code was not adapted properly. This lead to a traceback when using the command inside the composer. [1]: 218ad8456a06503dd508e7216edcffdc90b35cac task-3741858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where batch transfers would fail validation when some products didn't require lot/serial tracking while others did. Now users can validate operations with mixed tracked and non-tracked products, and the system automatically creates backorders for incomplete items instead of blocking the entire operation.
Original PR description
In Settings>Inventory>Operations enable "Batch Transfers" Create a [NonTrackedProd] product: - Product Type: Storable Product - Tracking: No tracking Create a [TrackedProd] product: - Product Type: Storable Product - Tracking: By Lot Create and confirm two POs with: - Prod [NonTrackedProd] qty 1 - Prod [TrackedProd] qty 1 Open Barcode Scanning app Select "Batch Transfers" Create a new batch with the incoming transfers from the POs Set only the [NonTrackedProd] lines as done and validate Issue: Error will block validation "You need to supply a Lot/Serial number for products" The system should let the user validate the operation and create a backorder instead of blocking the user opw-3777701
This fix ensures that only active employees can be assigned to project tasks. Previously, inactive users were appearing in the assignment dropdown, which could lead to tasks being assigned to users who are no longer active in the system. This improves data quality and prevents confusion when managing task assignments.
Original PR description
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task…
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task ### Cause of the issue: Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 is overriden in the view: https://github.com/odoo/odoo/blob/fcd66ee3321649405cf21bc1d625d71abf3d5819/addons/project/views/project_task_views.xml#L649 inactive users will not be filtered out by the domain. On the other hand, they chould still be filtered out during this call because inactive records should automatically be filtered out by the `_where_calc` method, unless explicitely asked for: https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5389 https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5091-L5093 However, since the `'active_test'` is set to `False` in the context of the the `user_ids` field: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 the inactive records will also not be filtered out by the call of the `_where_calc` method. #### Note: Prior to version 17.0, the flow worked "as expected" since the context set in the `user_ids` was not properly taken into account and inactive records were therefore filtered out by the call of this `_where_calc` method. Thanks to commit c3e497f this context is now relevant. opw-3796425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where kit products and their components were being incorrectly mixed together on delivery slip documents. Previously, when generating a delivery slip for orders containing both kit products and regular products, items would appear in the wrong sections. Now kit components appear only under their parent kit, and regular products appear in the correct non-kit section.
Original PR description
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section…
Current behaviour: --- When you generate a Delivery Slip for a list of kit and non kit products with no backorder, kit and non kit products get mixed. ie: there are kit products in the section "products not associated with a kit" Steps to reproduce: --- 1. Create 4 products (K1,P1,P2,C1,C2) 2. Create a Bills of Materials for K1 3. Set Type as Kit 4. Add C1 and C2 as components 5. Create a sale quotation for K1, P1, P2 6. Set the quantity at 4 for all products 7. On the quotation, click on Delivery 8. In Done, put 4 for P1 and 3 for C1,C2,P2 9. Validate and select No Backorder 10. Click on Print, Delivery Slip 11. In the document: 12. P2 is in the kit section (K1) 13. C1,C2 in the "not associated with a kit" section Expected behaviour: --- Only C1 and C2 should be in the K1 section Only P1 and P2 should be in the "Products not associated with a kit" section opw-3568390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144276
This fix ensures that when an email is received, the system correctly identifies which company's contact should be used, especially when the same email address exists for contacts in multiple companies. Previously, the system would always use the first contact found, regardless of which company was actually receiving the email. This fix prioritizes contacts that match the company context, preventing tickets from being incorrectly assigned to the wrong company's contact.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have two companies with helpdesk teams; 2. create a contact associated with company 1; 3. create a contact associated with company 2 w/ the same email address; 4. from this address, send an email to team 2 to create a ticket. Issue ----- Ticket is created using company 1's contact. Cause ----- When searching for partners associated with an email address, it only looks at the first one. Solution -------- Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized the current user, further prioritize based on companies matching the records passed to `_mail_find_partner_from_email`, avoiding potential access rights errors in multi-company environments. opw-3705199 Forward-Port-Of: odoo/odoo#156158
Internal transfer picking reports were not showing the destination location information when printed. This fix corrects the report template logic to properly display destination details for all internal transfers, ensuring users have complete information when processing warehouse transfers.
Original PR description
### Steps to reproduce: - Activate "Storage Locations" in the settings and create a warehouse - Inventory > Operations > Transfers > Internal - Create a new internal transfer with a non-zero product move line - Print the "Picking Operations" ### Expected behavior: The destination of the move should be on the document. ### Current behavior: The report (and hence the printed version) of an internal transfer does not display the destination of the transfer. ### Cause of the issue / fix: This part of the report is displayed under a `t-elif` condition. However for internal trasnfers the condition of the `t-if` and of the `t-elif` are both `true` so that two `t-if` should be used for an appropriate display of the report. ### Note: Prior to commit 567b8d6, two `t-if` were used. opw-3797998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158852
This fix allows users to change a location to or from a scrap location even when there are completed inventory moves in that location. Previously, the system was incorrectly blocking these changes. The fix ensures that only active (non-completed) reservations prevent location changes, restoring the correct behavior from before Odoo 17.
Original PR description
## Before this commit: Modifying a location from/to a scrap location should be restricted when there are move lines with reservation. However, starting from Odoo 17, the quantity field indicates the reserved quantity only when the move line's state is different from done. ## After this commit: Only check if there are reservation lines (move lines not in done) in the location when changing from/to a scrap location to match the behaviour before Odoo 17. opw-3815275
This update fixes an issue where users encountered errors when uploading images to mass mailing campaigns. The system now properly handles invalid image files instead of generating error logs, providing a smoother user experience when managing email marketing content.
Original PR description
Currently, a logger exception is generated when the user tries to upload any document in the mass mail.
Stack trace on sentry:
```
UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f1ad928db70>
File "addons/mass_mailing/models/mailing.py", line 1437, in _get_image_by_url
image = Image.open(io.BytesIO(content))
File "PIL/Image.py", line 3008, in open
raise UnidentifiedImageError(
```
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1]-https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
Forward-Port-Of: odoo/odoo#157513This fix prevents subscription orders from being locked when the "Lock Confirmed Sales" setting is enabled. Previously, enabling this security setting would incorrectly lock subscription orders, preventing further modifications. The fix ensures that subscription orders remain editable regardless of this setting, as intended by the product team.
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#158553 Forward-Port-Of: odoo/odoo#157026
This update fixes the table picker tool to work intuitively in right-to-left languages like Arabic. The table now expands in the correct direction based on the language setting, and arrow key controls are adjusted accordingly. Additionally, spacing issues between table columns in right-to-left mode have been corrected.
Original PR description
Issue: ====== Table picker isn't intuitive in rlt language and doesn't expand in the correct direction. Steps to reproduce the issue: ============================= - Install arabic language - Go to notes and create a new one - Write `/` and choose table - Use left/right arrow keys to see how the table expand. Solution: ========= For rtl direction it's better to make left for increase and right for decrease since that's the direction of the langauge. Also the table should be fixed on the right and expand on the left. (exactly the opposite of ltr direction). Before: ======  After: =====  task-3721794 Forward-Port-Of: odoo/odoo#159468 Forward-Port-Of: odoo/odoo#157400
This update adds a missing Spanish translation for a term used in Chilean invoices. The translation was previously unavailable, which could have caused display issues for Spanish-speaking users in the Latin American region. This fix ensures all invoice text displays correctly in the appropriate language.
Original PR description
Issue ----- A term doesn't have a translation available. Note: no Transifex project associated. **opw-3816657** Forward-Port-Of: odoo/odoo#159147
This fix improves the user experience when someone accidentally tries to upload a folder instead of a file using the /file command in Knowledge. Previously, the upload would fail silently with no error message. Now users will see a clear error notification explaining that only files can be uploaded, not folders.
Original PR description
**Steps to reproduce:** **OS:** Ubuntu 20.04.4 LTS with nautilus **Browser:** Google Chrome Version 123.0.6312.58 - type /file command in knowledge - select a folder and click on open - traceback occurs **Current behavior before PR:** When a user attempts to upload a folder using /file command, the processing begins, but the folder is not uploaded because the `getDataURLFromFile` return promise is not fulfilled. Additionally, there is no indication of any warnings or errors during the folder upload process. **Desired behavior after PR is merged:** If a user attempts to upload a folder instead of a file using the /file command, it results in an error message in the toaster notification. task-3690847 Forward-Port-Of: odoo/odoo#151755
This update improves the SMS sending functionality by adding a database identifier to the SMS API communication. This ensures proper tracking and routing of SMS messages through the system, making the SMS service more reliable and secure.
Original PR description
This commit updates the parameters passed to the IAP SMS API route ("/api/sms/3/send") to include the DB UUID.
Task: 3829793This fix corrects a bug where splitting a manufacturing order into multiple orders resulted in incorrect component quantities. When a manufacturing order to produce 10 units was split into 10 separate orders, each order incorrectly showed component quantities of 0.1 instead of 1. The fix ensures that component quantities are calculated correctly when manufacturing orders are split.
Original PR description
**Steps to Reproduce the Bug:** - Create a BoM: - Product: P1, Quantity: 1 unit - Component: - C1, Quantity: 1 unit - Create a MO to produce 10 units of P1: - This requires 10 units of C1 - In draft…
**Steps to Reproduce the Bug:**
- Create a BoM:
- Product: P1, Quantity: 1 unit
- Component:
- C1, Quantity: 1 unit
- Create a MO to produce 10 units of P1:
- This requires 10 units of C1
- In draft state, split the quantity into 10
**Problem:**
The created MOs have component quantities of 0.1 instead of 1.
When the MO is split, we update the product quantity of the original MO to 1, which triggers the `_compute_move_raw_ids` because it depends on the product_qty of the MO. Therefore, the move will be updated to 1.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1793
Subsequently, the factor is calculated based on the `move_qty` and the `qty_initial` of the MO.
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1828
Factor = 1 / 10 = 0.1
Afterwards, this quantity is set on the original move and the backorder moves:
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1830
https://github.com/odoo/odoo/blob/17.0/addons/mrp/models/mrp_production.py#L1835
opw-3825708
Forward-Port-Of: odoo/odoo#159492This fix resolves two issues with Saudi invoice printing in foreign currencies: it prevents errors when printing unconfirmed invoices and ensures the correct exchange rate is displayed based on the invoice date rather than the confirmation date. This ensures invoices accurately reflect the currency rates that apply to the actual transaction.
Original PR description
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the…
Currently, attempting to print an unconfirmed Saudi invoice in foreign currency results in an error. Furthermore, even if the invoice is confirmed, the exchange rate displayed is not correct, the rate of the confirmation date is used, instead of the accounting date. ### Steps to reproduce * install `l10n_sa_edi` * switch to a Saudi company * create an invoice in a foreign currency. * without confirming the invoice, attempt to print it You should be met with a traceback: `Undefined Function: operator does not exist: date <= boolean` * confirm the invoice, ensuring the confirmation and invoice dates have different currency rates. * print the confirmed invoice.* print the invoice You should see that the printed rate does not align with the actual transaction amounts. ### Cause The system incorrectly uses the `l10n_sa_confirmation_datetime` to calculate and display the currency rate on the PDF. This field is only populated upon invoice confirmation, leading to errors when printing unconfirmed invoices. Moreover, using this date for confirmed invoices results in displaying an incorrect rate, as it may differ from the `invoice_date`, which should be used for accurate rate calculations. opw-3731624 Forward-Port-Of: odoo/odoo#156054
This fix prevents Odoo from sending duplicate SMS messages when users send an SMS from a sales order and don't change the pre-filled phone number. Previously, if the specified number matched the customer's phone number, the system would attempt to send the message twice, causing errors. Now the system correctly recognizes when the additional number is the same as the customer's number and skips the duplicate.
Original PR description
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number…
[FIX] sms: prevent sms duplication when using additional numbers When sending an SMS via the action from the sale order view (specifically with sale_subscription), it is possible to specify a number to send the SMS to. However, if the specified number is identical to the partner's number (the number of the sale order's customer), Odoo attempts to send the message twice, resulting in duplication. [This commit change] This commit addresses this issue by ensuring that additional numbers are skipped if they are the same as the partner's number. [Reproduce] - Install mass_mailing_sms, sale_management, and sale_subscription modules. - Add an SMS token to the IAP account. - Create a contact (C) with a valid phone number. - Create a new quotation with contact (C) as the partner. - Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module). - Do not change the contact number on the pop-up (ensure it matches C's phone number exactly). - Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error. opw-3596207 Forward-Port-Of: odoo/odoo#153429
This fix resolves a system crash that occurred when users tried to add working hours to a newly created work schedule after removing all existing hours. The issue happened because the system attempted a mathematical calculation with zero, which is not allowed. The fix adds a safety check to prevent this error and allows users to successfully add new working hours without the application crashing.
Original PR description
This error occurs when the user adds a new ``Working Schedule`` to the resource, switches to the two-week calendar view, removes all the existing ``Working Hours`` lines, and then attempts to add a…
This error occurs when the user adds a new ``Working Schedule`` to the resource, switches to the two-week calendar view, removes all the existing ``Working Hours`` lines, and then attempts to add a new line under ``Working Hours.``
Steps to reproduce:
- Install ``resource`` module
- Settings -> Technical -> Resource -> Working Schedules
- New -> Switch to 2 week calendar -> Remove all ``Working Hours`` lines
- Click on Add a line
Traceback:
```ZeroDivisionError: float division by zero
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1081, in onchange
snapshot1 = RecordSnapshot(record, fields_spec)
File "addons/web/models/models.py", line 1168, in __init__
self.fetch(name)
File "addons/web/models/models.py", line 1183, in fetch
self[field_name] = self.record[field_name]
File "odoo/models.py", line 6671, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4984, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar_attendance.py", line 83, in _compute_duration_days
attendance.duration_days = 0.5 if attendance.duration_hours <= attendance.calendar_id.hours_per_day * 3 / 4 else 1
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4984, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/resource/models/resource_calendar.py", line 109, in _compute_hours_per_day
calendar.hours_per_day = calendar._get_hours_per_day(attendances)
File "addons/resource/models/resource_calendar.py", line 185, in _get_hours_per_day
return float_round(hour_count / float(number_of_days), precision_digits=2)
```
This commit implements a check for the variable ``number_of_days``. If the value of ``number_of_days`` is zero or not found, the function will return zero. This ensures that the function behaves appropriately in cases where the number of days is zero.
https://github.com/odoo/odoo/blob/5177e21aea68959eedc73e0034ed984992392dd7/addons/resource/models/resource_calendar.py#L185
sentry - 5108250957
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue in the recruitment survey process where retaking a survey would lose the connection to the original applicant. Previously, only the first survey attempt would be properly linked to the applicant, but now all survey retakes maintain the correct applicant ID association. This ensures complete and accurate tracking of all candidate survey responses.
Original PR description
Description of the issue/feature this PR addresses: - module: hr_recruitment_survey Current behavior before PR: - when retaking the survey, the survey input not map with the applicant id, so if you retake 5 time, only the 1st survey has value of applicant_id Desired behavior after PR is merged: - all survey retakes have the same applicant id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects inaccurate information in the Stripe payment module's documentation. The README contained an incorrect description of the payment flow process, which has been fixed to accurately reflect how Stripe payments are processed in Odoo. This ensures users and administrators have reliable documentation when setting up and managing Stripe payments.
Original PR description
Forward-Port-Of: odoo/odoo#159621
This fix resolves an issue where the sales report tree view was not accessible, preventing users from exporting sales data to Excel or viewing individual report lines. The fix restores the ability to interact with and export sales reports, improving data accessibility for business users.
Original PR description
Description of the issue/feature this PR addresses: Before this commit, it is not possible to export sale.report by excel or show the lines. @Feyensv --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157870
This update fixes a test failure in the inventory system's test suite that was causing errors when running the unpacking and quantity history test. The fix ensures the test runs reliably without encountering index errors, improving the stability of the inventory testing process.
Original PR description
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
Forward-Port-Of: odoo/odoo#159611This fix resolves a bug where border and rounded corner styling options were being reset to zero after being applied to text elements in the web editor. The issue occurred because styling properties were being incorrectly cleared each time the styling function was called. This update restores the proper handling of styling options so they persist correctly when users apply borders or rounded corners to content blocks.
Original PR description
Since [1], the `extraClass` is handled globally across all properties of a composite option such as "Border" or "Round Corners". But [2] did reset the `extraClass` each time `applyCSS` is called. Because of this, the `extraClass` is now missing after setting a "Border" or a "Round Corner". This commit reverts [2] partially to remove the `extraClass` handling from within the `applyCSS` function. Steps to reproduce: - Drop a "Text - Image" block. - Select the text. - Set a "Border". => The "Border" option is reset to 0. [1]: https://github.com/odoo/odoo/commit/2a6355c36ebfc4397451289589ebbeaa2afc1396 [2]: https://github.com/odoo/odoo/commit/d3c3dab8950abc25b29937605091d8ce32305fa4 task-3800288 Forward-Port-Of: odoo/odoo#159657 Forward-Port-Of: odoo/odoo#159452
The live chat chatbot was stopping unexpectedly when redirecting users to different sections of the same page (like anchor links). This fix ensures the chatbot continues working properly in these scenarios by removing the dependency on page reloads that don't occur during same-page redirects.
Original PR description
Before this PR, the chat bot would stop after redirecting a user on the same page that the current one (e.g. anchors) because it was counting on the page reload that do not occur in this case. This PR fixes the issue. opw-3801598 Forward-Port-Of: odoo/odoo#159644 Forward-Port-Of: odoo/odoo#159320
This update improves the Italian EDI invoice import feature to correctly handle both incoming and outgoing invoices. Previously, the system assumed all imported invoices were bills (incoming). Now it intelligently determines whether an imported invoice is outgoing or incoming and processes it accordingly, enabling businesses to import invoices from other software systems during onboarding or data migration.
Original PR description
Currently we assume that all imported invoices are incoming (i.e. bills). This was i.e. done since the tax agency only sends users bills. But some clients import invoices from other software (i.e. onboarding/starting). After this PR we decide whether the invoice is outgoing or ingoing and import the invoice correctly in either case. Link: https://www.odoo.com/web#model=project.task&id=3650355 task-3650355 Forward-Port-Of: odoo/odoo#159737 Forward-Port-Of: odoo/odoo#151139
This fix resolves an issue where journals without system identifiers were not being properly matched during chart reloads, which could result in duplicate journals and database errors. The fix improves the matching logic to compare journal names and codes against translated values in addition to the default language, ensuring accurate identification of existing journals during the reload process.
Original PR description
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name). This then leads to duplicate journals being…
Currently there is the following problem when reloading the chart. Journals without xmlid may not be matched to chart data correctly (via code or name).
This then leads to duplicate journals being created / uniqueness constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
- (1) We load the chart data in en_US to be able to use the code translations
- (2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2); Code is not translatable.
- We compare those values (journal code / name) against the en_US term due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version) against the translated values.
Forward-Port-Of: odoo/odoo#159738
Forward-Port-Of: odoo/odoo#159635