Monday, October 27, 2025
29 changes · saas-18.4
Resolved issues and error corrections
Helpdesk can now create tickets from incoming emails even when the sender email matches a contact belonging to another company. This prevents missed support requests in multi-company setups by ensuring the ticket uses a company-compatible contact.
Original PR description
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with…
**Steps to reproduce** - Have a helpdesk team for company A, with an email alias set up. - Have a `res.partner` belonging to company B with an email. To reproduce, there should be no contact with this email in company A or with no company. - Send a message with the email of the `res.partner` to the alias of the helpdesk team. Issue: the ticket is not created. **Cause** The `_check_partner_id_has_the_same_company` constraint fails, preventing the ticket from being created. **Solution** We stop using the `author_id`, since it is not guaranteed to respect the constraint. https://github.com/odoo/enterprise/blob/a1fe558c8d6e27b435d350c23e19b93bbe611eb7/helpdesk/models/helpdesk_ticket.py#L755 This values comes from `_mail_find_partner_from_emails` in the mail module, which will prioritise a contact from the same company, but will not prevent one from another company being used. The existing code in `create` will call `_find_or_create_partner` to find/create one based on the name and mail. `_mail_find_partner_from_emails` is used instead of `find_or_create` to be able to provide an additional domain to ensure company consistency. opw-5154449 Forward-Port-Of: odoo/enterprise#98126 Forward-Port-Of: odoo/enterprise#97734
This fixes a crash when users expand a Spanish VeriFactu document record. The unnecessary messaging panel was removed from a screen that does not support it, so users can open and review these documents without an error.
Original PR description
The system will crash with error when user clicks on expand button. **Error:** `AttributeError: 'l10n_es_edi_verifactu.document' object has no attribute '_get_thread_with_access'` **Cause:** - `l10n_es_edi_verifactu.document` does not inherits ['mail.thread', 'mail.activity.mixin'] and used chatter in it's form view. - In this PR, removed `<chatter/>` from view. Already fixed for master here: https://github.com/odoo/odoo/pull/231477 **sentry-6792833694** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231739 Forward-Port-Of: odoo/odoo#231601
This fixes a self-ordering checkout issue where customers returning from payment could see an incorrect cart total and be unable to edit items. The cart state is now reset properly when navigating back, making the ordering flow more reliable.
Original PR description
Steps to reproduce: =================== - Start a self-order session. - Add some products to the cart. - Navigate to the payment page. - Click the back button. Issue: ====== - When going back to the cart page from the payment page, products in the cart are not editable. - On the product page, the cart total shows 0. Cause: ====== - `lineChanges` were not cleared on back navigation, leaving previous data in the cart. Fix: ==== - Clear `lineChanges` when navigating back from the payment page to ensure a clean state. Task: 5055279 Forward-Port-Of: odoo/odoo#228672
This fixes an unstable automated test for the website builder sidebar behavior. It reduces false failures caused by timing issues, helping teams validate website changes more consistently without affecting customer-facing functionality.
Original PR description
Tour added in that [commit], was previously failing and the earlier [fix] only reduced the frequency of failures. However, it still occasionally fails due to race conditions of the iframe becoming ready and the moment the builder opens the block tab after the iframe has been reloaded. This commit aims to fix it. [commit]: odoo@a5455bf [fix]: https://github.com/odoo/odoo/commit/0a9522792cc0e18a895c0589f34977123d091d1a runbot-233438
This change adds a safeguard to ensure invoice PDFs show the correct product information when a line has an added description. It helps prevent a past issue where the product name could be omitted from printed invoices, improving invoice clarity for customers.
Original PR description
Issue: If a description is added on a product line, the printed invoice PDF only shows the description without the product name. Purpose of this PR: To add a test to ensure that the product description is correctly reflected on invoice PDF. Original issue was fixed by this PR: https://github.com/odoo/odoo/pull/222589 opw-4985815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where changing a website header style could make the header text disappear, such as on shop or cart pages. Editors can now adjust heading levels without losing visible content, reducing the risk of accidental page content loss.
Original PR description
Problem: When trying to change the header type of "All products" in the "/shop" page on Website, the title disappears. Cause: The title is `h1[data-oe-field]`. When we update it, we replace the node with a new header node. This triggers `handleMutations` with both the removed node and the new node. The old removed node with no content is processed in `normalizeHandler`, which causes removal of the content from the new node as well. Solution: In `FieldChangeReplicationPlugin.handleMutations`, filter out removed nodes so they are not processed in `normalizeHandler`. Steps to reproduce: 1. Enter Website. 2. Go to the cart and select the header "Order Summary". 3. Attempt to change the font style (Header 1, Header 2, etc.). → The header disappears. opw-5106712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
French FEC imports now use a valid debit account for rounding differences after a chart of accounts change made the previous account code a grouping account. This prevents import issues and helps ensure accounting data is posted to the correct usable account.
Original PR description
This commit:https://github.com/odoo/odoo/commit/0ebf80b613d229ef5fb07ea97d406496f9df6254 change the COA of french localisation and the account 6850 was change to be an account group instead. This commit will change the debit account code used to put an existing one instead. no task-id Forward-Port-Of: odoo/enterprise#97283 Forward-Port-Of: odoo/enterprise#96972
This fixes unreliable automated checks around two-factor authentication setup by making the test steps wait for clearer completion signals. The change helps reduce false failures in testing environments, improving confidence in releases without changing user-facing behavior.
Original PR description
- Remove timing-sensitive check on modal closed, wait for the row to be deselected instead (this assumes the list view has been reloaded and can be interacted with again, whereas the security check modal is closed before we actually run the action) (?). - Replace odd and somewhat brittle `run()` functions by equivalent (or better) triggers, with or without ~~you~~ clicks. - Replace a few waits on modals closed by waits on the corresponding notification appearing, this is likely more reliable. Locally this looks to be making the totp tours a *lot* more reliable under load, hopefully this also works on runbot: this aims to solve a jumble of uncommon non-deterministic errors: - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/107908 - https://runbot.odoo.com/odoo/error/161302 - https://runbot.odoo.com/odoo/error/233265 - https://runbot.odoo.com/odoo/error/233513 Forward-Port-Of: odoo/odoo#232986 Forward-Port-Of: odoo/odoo#232958
Corrects how Peppol verification status changes are logged for contacts. This ensures the system records the expected verification information even when multiple identifier checks are involved, improving traceability for electronic invoicing setup.
Original PR description
Failed fw-port in https://github.com/odoo/odoo/pull/231142. The logging won't happen if a value is found for the second tested EAS. task-none Forward-Port-Of: odoo/odoo#232900
This update prevents automatic invoice sending from stopping when a Spanish VeriFactu credit note cannot be processed because its original invoice lacks the required VeriFactu document. Affected records are now reported clearly while other eligible invoices can continue to be sent.
Original PR description
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the…
### Steps to reproduce: - Install l10n_es_edi_verifactu and switch too Spanish company - Create an invoice, add a nonzero product and Confirm - Select "Reverse" to create a credit note - Confirm the credit note - Select Send (or Send and Print), deselect everything except VeriFactu and email, then select Confirm - An error appears that takes the user to the failed record - Navigate to Accounting > Customers > Credit Notes - Select the credit note created and at least one other credit note, then select "Send" - Navigate to Settings > Technical > Scheduled Actions - Click into the "Send Invoices Automatically" record, then select "Run Manually" - Version 18.3: the scheduled action fails, no error message appears. The traceback can be seen in the logs - Version 18.0 and lower: The scheduled action fails, but an error message does appear ### Cause: When trying to generate the verifactu documents for a credit note whose invoice has no verifactu document, a `RedirectError` is raised. This means the scheduled action "Send invoices automatically" is cancelled if only one credit note as this issue: no invoices are sent. ### Solution: The usual way to handle user errors with the scheduled action is to append the key 'error' in the dictionnary `send_and_print_values`. This way a message is displayed when running the scheduled action mentioning the moves in error. So we check do the checks and remove the invalid moves before calling `_l10n_es_edi_verifactu_mark_for_next_batch()`. Like this we can change the key "error" in the dictionnary and stop the document generation there. We also extend `_hook_if_errors()` to raise a `RedirectWarning` if it's one of the errors related to Verifactu that we removed. opw-5091347 Forward-Port-Of: odoo/odoo#232763 Forward-Port-Of: odoo/odoo#230762
Italian electronic bill imports now avoid applying the same discount twice when the XML includes both a discount element and a matching negative line. This helps ensure supplier bills reflect the correct amount and reduces manual corrections for accounting teams.
Original PR description
When importing a bill in an IT company the system will automatically parse the xml and populate the record. In case of discount, an element <ScontoMaggiorazione> will be present, either for the whole document or for a single line. However, an extra negative line may be present in the xml representation of the bill, creating a double discount **Steps to reproduce** - With an IT Company setup - Import an xml bill having <ScontoMaggiorazione> element and a negative line representing the same discount **Issue** Double discount line will be created in the bill **Analysis** This occurs because, when parsing the bill, the system will import also negative lines, even if a discount has been already applied opw-4913335 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4913335) Forward-Port-Of: odoo/odoo#232880 Forward-Port-Of: odoo/odoo#225044
German POS sessions can now be closed even when an order includes products without taxes. The system treats untaxed order lines as 0% tax for Fiskaly reporting, preventing closing errors and reducing disruption at checkout.
Original PR description
Steps to reproduce: ------------------------- - Install the German localization with the POS module. - Register the company to fiskaly. - Create an order that includes a product with no taxes. - Attempt to close the POS session. Issue: ------- - There will be a traceback and session cannot be closed. Cause: --------- - While sending data to Fiskaly, the code references `l.tax_ids[0].amount`so If a line has no tax, this results in an error because there is no handling for an empty tax list. Fix: ----- - If a line has no tax, treat it as a 0% tax and fetch the corresponding `vat_definition_export_id` accordingly. opw- 5145258 Forward-Port-Of: odoo/enterprise#97076
Saving departure notes for archived employees no longer triggers an error. This prevents interruptions for HR users when maintaining employee records after departure.
Original PR description
Html fields are not part of the supported fields for tracking, see https://github.com/odoo/odoo/blob/11289fd128827587f6ed3fc5beed28f461c0e039/addons/mail/models/mail_tracking_value.py#L49 This causes a traceback when saving the `departure_description` on an archived employee. Added in https://github.com/odoo/odoo/commit/aa4d13b89b4497d2e5b33faa49ad86e0788782a2 Previous related fix: 9b723e2591224f2b563924d3b3dfe27ab909b7d0 opw-5140525
This fix prevents users from creating a new workplace directly from certain Swiss payroll forms when that shortcut could trigger an error. Users can still select existing workplaces, while avoiding a confusing failure during employee or contract setup.
Original PR description
The _rec_name was previously set to partner_id, causing type errors when typing a new workplace name in a Many2one field. Couldn't change it to anything else, as one should have to create a new field in that stable version and this is not the best practice. As a workaround, the corresponding field in the l10n_ch_hr_contract_views.xml is removed from it the quick_create to prevent the creation of new names on the fly. task-5043056 Forward-Port-Of: odoo/enterprise#96675 Forward-Port-Of: odoo/enterprise#93424
This fix prevents messaging and live chat screens from breaking when a channel member is loaded without full profile details. The system now safely falls back to an existing “unnamed” label, keeping conversations accessible in flows where member identity details are not needed.
Original PR description
Sometimes, channel members are received without their partner/guest because it's not important in the flow. However, some part of the JS code assume the persona is always set, resulting in errors. This PR guards access to persona when computing the member name, a fallback to "unnamed" is already in place. task-5184408 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#233056
Payroll now checks the correct document template separately for each payslip. This prevents cases where one payslip's missing or different template could affect others, helping ensure payroll documents are generated with the right layout.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template. Forward-Port-Of: odoo/enterprise#97639
FedEx rate requests no longer fail when a customer's state or province code is longer than FedEx accepts. Odoo now skips that optional field when needed, helping users get shipping rates successfully for affected international addresses, including Belgian customers.
Original PR description
**Issue**: Sending a `stateOrProvinceCode` longer than 2 characters causes a FedEx error. **Steps to reproduce**: - Ensure the FedEx delivery carrier is installed. - Open the Sales application. - Create a new quotation with a Belgian customer whose state is set to `East Flanders`. - Click on "Add shipping". - Select "FedEx International" and click on "Get rate". - An error is raised. **Cause**: Some Odoo state codes are longer than 2 characters and are not covered by [this commit](https://github.com/odoo/enterprise/commit/38276c9a237a1779ce7a3e6f31102ff615691690). **Solution**: According to FedEx developer support, in such cases the `stateOrProvinceCode` field is not required. Therefore, we simply omit sending it when the code length is invalid. **Additional note** This commit also fixes 3 mistakes among the mandatory countries: - 3 for United Arab Emirates opw-4875939 Forward-Port-Of: odoo/enterprise#93642
Fixed an issue where partially paid subscription upsell orders could show a down payment invoice amount of zero. Down payment invoices now reflect the actual amount paid, improving billing accuracy and customer clarity.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97412 Forward-Port-Of: odoo/enterprise#96719
Mobile self-order confirmations now keep the correct order selected after checkout. Customers see the right order number and the expected amount to pay at the counter, reducing confusion during repeat purchases.
Original PR description
…rmation **Steps to reproduce:** - Have a self order with the mobile setting (QR menu + self ordering) - Make a purchase, confirm it in the orders in the regular PoS - Make another purchase - The…
…rmation **Steps to reproduce:** - Have a self order with the mobile setting (QR menu + self ordering) - Make a purchase, confirm it in the orders in the regular PoS - Make another purchase - The order number did not increase and "Pay X at the counter" is not displayed **Why the fix:** Before this commit, on the confirmation page, we displayed the self order's current order, which was not correctly set in the case of a mobile self order. This is why we had the same order number (tracking_number) on the confirmation page. This is also why we did not display the "Pay X at the counter" part of the page, as the wrong order was chosen. With the current flow, the selectedOrderUuid was set to null after an rpc call, and was only set back if there was an open order and the current screen was different from confirmation. In this case, we had neither, because the current screen was confirmation and the function did not return any open order, as they are only considered open if they are older than the order we are currently working with. So with this, the selectedOrderUuid was set to null, just to stay like this. We then used the fallback in the currentOrder's getter (which works fine with the kiosk but not on mobile, and that's why it only works in kiosk), which gave us the wrong order (the last paid order). Right now, we do not set the selectedOrderUuid to null in the case where the current screen is the confirmation screen, as this seems to be the only issue we have with it. I couldn't find a way to test this, as we need to confirm the order from the regular PoS, then go back to the self order and make another sale. opw-5112561
This update corrects how notification preferences are checked for mail messages. Users should no longer receive duplicate push notifications for the same message when their inbox notification settings are applied.
Original PR description
**Current behavior before PR:** The `isInbox` condition was always evaluated as false because it incorrectly checked the user's notification preference in the wrong model. This caused users to receive two push notifications for the same message. **Desired behavior after PR is merged:** The `isInbox` condition now checks the user model for notification preferences, ensuring the correct behavior. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kiosk combo ordering now respects the specific product variants configured for a combo. This prevents customers from seeing unintended variant options or being charged extra prices that were not defined in the combo setup.
Original PR description
**Problem:** When we have a combo product that has a variant product, if we order it from the Kiosk, all the variants for that product will be displayed. The extra price will also be added, even…
**Problem:** When we have a combo product that has a variant product, if we order it from the Kiosk, all the variants for that product will be displayed. The extra price will also be added, even though it is not specified on the combo definition. **Steps to reproduce:** - Create a combo that has a variant product (like aluminium chair) - Go to the Kiosk and order said combo - In the combo page, click on the variant, all the possible variants are displayed **Why the fix:** When creating a combo, we should specify which product variant we want, so that only those are displayed on the combo selection page. The way it is done right now, every variant is displayed whether we want them or not, without a way to refrain them from being displayed. After this commit, if the variants are specified on the combo, only those are displayed in the Kiosk once we click on the combo. If we specify a product that has variants in the combo, all variants will still be displayed when clicking the product in the Kiosk, as it was before. opw-4924019 Forward-Port-Of: odoo/odoo#219908
German e-invoices now use the actual customer or parent company name when an invoice address has no contact name. This prevents labels like "Invoice Address" from appearing in XML invoice data when they are not shown on the customer-facing PDF.
Original PR description
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format…
**Steps to reproduce:** - Install Contacts, Accounting and l10n_de - Switch to a German company (e.g. DE Company) - Go to Contacts - Create a German contact with "XRechnung CIUS" as electronic format - For this contact, create an "Invoice Address" without "Contact Name" - Create an invoice with the invoice address as customer - Confirm the invoice - Generate "XRechnung" via "Send & Print" button **Issue:** In the generated ULB XML and in factur-x.xml file embedded in the PDF, the customer name contains the mention "Invoice Address", which doesn't appear on the PDF of the invoice. **Cause:** The used invoice address has no name, so its "display_name" is build from the name of the parent contact and the type of the child contact (i.e. Invoice Address). **Solution:** Only use "display_name" of a contact if "name" is set. Otherwise fall back on "display_name" of the commercial partner. opw-5159291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232819
Email Marketing templates using the showcase block now keep their separator styling after saving. This ensures recipients see emails as designed, improving visual consistency in campaigns.
Original PR description
Problem: When adding the `s_showcase` template in Email Marketing and saving, the separator is not properly rendered in the received email. Solution: Backport fix from `web_editor/convert_inline`: https://github.com/odoo/odoo/commit/7e3e6c1f42d97c2bb6830ed59dbec3a3b745d0c0 opw-5077992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230773
Non-admin POS users can now select tax-free configurable products in branch company restaurants without seeing an access rights error. This helps sales staff complete orders smoothly and avoids interruptions when using product configurators.
Original PR description
**Issue:** In POS, clicking on a tax-free, inventory-tracked, configurable product as a non-admin user can throw an Access Rights error when trying to access it on a branch company's POS config. **Steps to reproduce:** - Configure a branching company on a parent company - Create a new POS restaurant on the child company - Create a configurable product that has no taxes associated with it and add it to a POS category so that it can be chosen from the POS screen - On a non-admin POS user, try to click that product 🐛 **Before this commit:** The user will get an Access Rights error. **After this commit:** The configurator dialog will load successfully. opw-5145176
Internal users who click the View Product button in product-related emails are now taken to the internal product page instead of the public shop page. This keeps staff workflows accurate while preserving the public shop redirect for portal and public users.
Original PR description
### Issue: Mail action redirects only to shop page, even though the user has internal access to the product page. #### To reproduce: 1- Create a db with website_sale installed. 2- Create a product and publish it. 3- In the product page chatter, send a message to an internal user 4- In received email, click on `View Product` button 5- As you see the shop page opens This is reproduced after #202555 Inside `_get_access_action`, if the product is published, we are returning `website_url`. We can add a check to do that only if user is portal or public. opw-5155281 Forward-Port-Of: odoo/odoo#233030 Forward-Port-Of: odoo/odoo#231961
When several Spanish invoices are sent to TicketBAI together, they are now processed in their posting order instead of the list selection order. This keeps the official chain numbering aligned with invoice chronology, reducing compliance errors and confusion.
Original PR description
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list…
Steps to reproduce: 1) Install l10n_es and l10n_es_edi_tbai. 2) Create a Spanish contact with a valid address and NIF. 3) Create several customer invoices and confirm (post) them. 4) From the list view, select them and send to TicketBAI. 5) The TicketBAI “chain index” is inverted: the newest invoice gets the smallest index and the oldest gets the largest. The first invoice in the legal/chronological sequence is not index 1. Current behavior: - When sending multiple invoices at once, the processing loop uses the batch order as-is, which (from the list view) often arrives in reverse chronological order. The chain index is assigned incrementally based on that order, yielding an inverted chain (newest=1, oldest=N). Expected behavior: - The TicketBAI chain index must follow issuance/confirmation chronology: the oldest posted invoice in the batch is index 1, then 2, … up to the newest. Technical reason: - `_call_web_service_before_invoice_pdf_render` iterates `invoices_data.items()` without an explicit ordering by confirmation (posting) date. Depending on how the selection is built, items are processed newest-first, so the computed `chain_index` is reversed. Solution: - Sort the invoices before sending by posting date (`move.date`) ascending, with fallbacks to `invoice_date` and `create_date`, and a deterministic tiebreaker by `id`. Process sequentially after sorting and keep the per-invoice commit. opw-[5072667](https://www.odoo.com/odoo/my-tasks/5072667) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229736
This fixes an issue where warehouse users could be blocked from validating a partial package transfer for products valued and tracked by lot or serial number. The system now avoids raising an incorrect missing lot error when the lot information is already present, helping barcode-based transfers complete reliably.
Original PR description
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to…
**Problem:** With a valued by lot/SN product, assigning a partial barcode move line to a new package will trigger a lot error when validating even if there is a lot on the line. **Steps to reproduce:** - Create product tracked by lot and valued by lot/SN. - Set on on hand quantity of 100 in stock with a package that you create and a lot that you create. - Create an internal transfer for 100 of this product. - Mark it as to do. - Open it in barcode. - Scan stock. - Scan the package. - Edit the line to quantity of 50. - Scan any other empty package already existing to set it as the delivery package. - Validate. - On the incomplete transfer widget, also click on validate. **Current behavior:** An error 'Lot/Serial number is mandatory for product valuated by lot' is triggered even though there is a lot on the line. **Cause of the issue:** When _assignEmptyPackage() is called to assign the new package, it calls shouldsplitline() which returns true because line.qty_done is smaller thant line.reserved_uom_qty https://github.com/odoo/enterprise/blob/931779b845291e1dc7efdea91d91bdfa5ab703d6/stock_barcode/static/src/models/barcode_picking_model.js#L949-52 Therefore, splitLine() is called and a new line is created with no package and no lot. Then, when we validate, _action_done() is called on the move which calls _action_done() on the move lines. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock/models/stock_move.py#L2065 In the stock_account override, the error is raised for the line newly created because it has no lot_id and no lot_name. https://github.com/odoo/odoo/blob/30189db8a47e69038242a68706cfdfe6c152e779/addons/stock_account/models/stock_move_line.py#L90-L91 opw-5028008 Forward-Port-Of: odoo/odoo#231482
Contact addresses now include the second street address line when generating the complete address. This ensures emails and other documents show the full address for contacts who use an additional address line.
Original PR description
Issue: If a user with `street2` wants to utilize the `contact_address_complete` field, the `street2` field is not included. Purpose of this PR: To include the `street2` field in the `contact_address_complete` Steps to reproduce on Runbot: install contact fill in a contact's `street2` create email template that uses the `contact_address_complete` `street2` is omitted from the complete address opw-5186218 Forward-Port-Of: odoo/enterprise#98103
Signing an offer as the responsible HR no longer fails when an employee requested extra time off and automatic allocation is enabled. This ensures the salary package workflow can be completed smoothly without blocking HR users.
Original PR description
- When the employee requested extra time off, and the automatic allocation setting was turned on, signing the offer as the responsible HR caused an error. Task-5022631 Forward-Port-Of: odoo/enterprise#98060 Forward-Port-Of: odoo/enterprise#92663