Thursday, May 8, 2025
38 changes · saas-18.2
Resolved issues and error corrections
The Expenses app no longer crashes when its default email alias has been removed. Instead, it opens normally and simply treats the missing alias as unavailable, reducing disruption for users and support teams.
Original PR description
This error occurs when the user deletes the email alias expense `hr_expense.mail_alias_expense`. Steps to Reproduce: 1. Install the module `hr_expense`. 2. Go to Setting > Technical > Email > Aliases and delete `Expense`. 3. Open Expenses. `ValueError: External ID not found in the system: hr_expense.mail_alias_expense` This error occurs when the system is unable to fetch hr_expense.mail_alias_expense ID while opening the module `Expenses`. This commit ensures that if the ID does not exist, the function will return None instead of raising an exception. Sentry: 6559233309
This fix ensures restaurant order course data includes the information needed to load correctly in Point of Sale. It helps avoid loading problems for restaurant workflows, improving reliability without changing user-facing features.
Original PR description
Before this commit, the write_date field was not loaded for restaurant.order.course, which caused issues during the loading. opw-4779831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The unread conversation dot in the Discuss sidebar is now easier to see when using the dark theme. This helps users notice unread chats more reliably without changing the appearance in the light theme.
Original PR description
When a conversation is unread (and no important messages), the conversation in discuss sidebar has a small dot next to the item. In white theme its visibility is good, with `.opacity-50`. In dark theme however this indicator is hard to see. This commit fixes the issue by keeping 50% opacity in white theme but bumping to 75% in dark theme specifically.
This fix ensures that when work orders are managed through Shop Floor, the correct employee is assigned to the work order. This helps production records stay accurate and avoids confusion in employee tracking for manufacturing operations.
Original PR description
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 fixes a visual issue where the messaging menu's “mark as read” button appeared too wide. The button now has a cleaner, properly sized appearance, making the menu look more polished and consistent.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it…
Follow-up of https://github.com/odoo/odoo/pull/203142 PR above made several style improvements, one of which is to make the "mark as read" button on messaging menu item look more like a button: it looks like an icon, now this outline and squared like other buttons. To have a similar size as the counter, it had the `.badge` classname. The `.badge` classname has to do some shenanigans to have constant width for 1-digit values, one of which is to set a minimum width of `2.7ch`. When the "mark as read" button was changed, this become a button but the `.badge` classname was mistakenly kept. As a result, it kept `min-width: 2.7ch`, which made the width too large on this button. `min-width: 2.7ch` should not be used on the same node as `.fa`, as the width of font-awesome glyph is bigger than badge numbers. This commit fixes by removing the `.badge` classname altogether, so the button is sized properly. Another fix could have been to put the `.fa.fa-check` in child-node, but that results in the same visual so removing `.badge` results in simpler template. As the "mark as read" is a button with outline, there's also no longer need to have exact width as a badge. Task-4770926 Before <img width="478" alt="Screenshot 2025-05-05 at 16 55 22" src="https://github.com/user-attachments/assets/dc5ca989-be1d-436e-84e4-57b450f66908" /> After <img width="476" alt="Screenshot 2025-05-05 at 16 54 32" src="https://github.com/user-attachments/assets/06f99cb0-4ab4-4090-80ea-48e71970e80a" />
This update prevents errors in the point of sale when product pricing is checked without a specific product variant. It reads category information from the main product record instead, making product info and pricing screens more reliable.
Original PR description
Before this commit, the parentCategories field was read from the product variant, which could be missing in certain calls. For example, in getProductInfo, the getPrice method is called without a variant, leading to errors. opw-4772883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when the accounting reconciliation process reads currency amounts from transaction details. It improves reliability for users working with bank or transaction matching by handling the stored data format correctly and avoiding crashes when expected data is missing.
Original PR description
The Issue: Prior to this commit, retrieving the amount currency from the transaction details caused a traceback. This occurred because the transaction details are stored as a jsonb object, and the code attempted to access a string within a dictionary, resulting in a TypeError mismatch. The Fix: The jsonb object is now converted to a string before processing. Additionally, an IndexError is caught to handle cases where the expected group is not found in the match. opw-4754518
Miscellaneous changes
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guide
Original PR description
## Issue: A standard IBAN always breaks into two lines on the DIN 5008 report. ## Steps to reproduce: - Install l10n_de; - Change to DE Company; - Navigate to Settings; - Under the Companies section, click `Configure Document Layout`; - Select `DIN 5008` layout; - Check footer display. ## Cause: The commit 3a139b15a5270fb466b608b340013c93214557bb reset the font-size without thinking about the IBAN display. opw-4680515 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204296
**Problem:** The problem happens when a product can be sold by a packaging where the UOM of the packaging is not a reference unit (it depends from another unit, for instance a packaging of 33kg where the UOM is kg which depends from g) and the product price is based on the UOM of the packaging (in the exemple: kg). When in the point of sale app, if we scan the barcode of this packaging for the product, the quantity sold will be computed as if it was sold in the reference unit (here a
Original PR description
**Problem:** The problem happens when a product can be sold by a packaging where the UOM of the packaging is not a reference unit (it depends from another unit, for instance a packaging of 33kg where…
**Problem:** The problem happens when a product can be sold by a packaging where the UOM of the packaging is not a reference unit (it depends from another unit, for instance a packaging of 33kg where the UOM is kg which depends from g) and the product price is based on the UOM of the packaging (in the exemple: kg). When in the point of sale app, if we scan the barcode of this packaging for the product, the quantity sold will be computed as if it was sold in the reference unit (here as 33kg is 33.000 g, the quantity will be 33.000, even though we sell the product by kg so we expected a quantity of 33). **Steps to reproduce:** - Open Sale/Configuration/Products/Units&Packagings - Create a New record, set the quantity to 33kg and set a name - Check the "Group Products in POS" option - Go to Point of Sale/products and create a new product - Check the Sales and Point of Sale boxes - In general information in the "Sale Price" field select kg as the unit - In the Sales tab, in the packagings field select the packaging you just created - click on the tag of this packaging and write a barcode for it. - Open a shop in point of sale - Click on the three horizontal lines on the top right of the screen - Select Debug Window, write the barcode of your packaging - Click on scan **Current behavior:** The quantity of your product in order is 33.000 **Expected behavior:** The quantity should be 33 **Cause of the issue:** When the quantity sold is computed it's computed by taking the factor of the packaging which is the number of reference unit of this packaging. https://github.com/odoo/odoo/blob/9354163d9fe45a34e7c3686f2c88cb9e3d4fbfc2/addons/point_of_sale/static/src/app/models/pos_order_line.js#L55 Here the reference unit is g so the factor is 33.000. But the product is sold in kg so the quantity should be 33. **Fix:** The quantity sold should be the factor of the packaging divided by the factor UOM in which the product is sold (here : 33000/1000 = 33) opw-4652869 Forward-Port-Of: odoo/odoo#205026
The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the f
Original PR description
The electronic format field should not be displayed in the portal when no option is available for it. Steps to reproduce: ------------------- * (The reported flow was using PoS) * Install the l10n_mx_edi_pos module * Create a PoS and use the self invoicing feature * Make an order and pay for it * On the ticket scan the QR Code and access the invoice portal > Observation: The electronic format field is displayed in the portal but it is empty Why the fix: ------------ We hide the field when no value is available for it. opw-4628351 Forward-Port-Of: odoo/odoo#208124
Steps to reproduce: 1. Settings > Navigate to Configure Document Layout 2. Under Layout Background, select Custom and upload an image. Issue: Background image was being cut off at the end. The image was not covering the entire div. Solution: Updated the `.o_report_layout_background` CSS to use `background-size: contain` and remove 300px from `background-position` to ensure the image scales proportionally and stays centered. opw : 4727408 Before FIX :  After FIX :  Forward-Port-Of: odoo/odoo#207029
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the ‘Montserrat’ text font with ‘A4’ paper format in the ‘Configure Document Layout’ section of the general settings. The word "Páge" does not align correctly in a single line with "X/X" at the bottom right of the report. However, it prints correctly when using the other fonts. Solution: Applied
Original PR description
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the…
Steps to reproduce: 1. Go to Settings > Configure your document layout> Select Text as Montserrat 2. Preview Document > open downloaded file Issue: The issue is when printing reports using the ‘Montserrat’ text font with ‘A4’ paper format in the ‘Configure Document Layout’ section of the general settings. The word "Páge" does not align correctly in a single line with "X/X" at the bottom right of the report. However, it prints correctly when using the other fonts. Solution: Applied Bootstrap's text-nowrap class to prevent pagination text from breaking onto separate lines when using the Montserrat font. This addresses the issue where "<span class="page"/>" and "<span class="topage"/>" components were displaying on different lines in PDF reports. opw-4654332 Before FIX:  After FIX:  Forward-Port-Of: odoo/odoo#205160
Before this commit, when working with PoS on several devices, one of which is offline, a synchronization error occurred. Example: 1. PoS-1 creates a command and then loses its connection 2. PoS-2 the order is received from PoS-1, it is paid here. 3. PoS-1 adds a command line and recovers its connection. The command returns to “draft” state, which should not be possible. Now, once a command has been paid for, it cannot be drafted again. An error is returned to the user indicating that
Original PR description
Before this commit, when working with PoS on several devices, one of which is offline, a synchronization error occurred. Example: 1. PoS-1 creates a command and then loses its connection 2. PoS-2 the order is received from PoS-1, it is paid here. 3. PoS-1 adds a command line and recovers its connection. The command returns to “draft” state, which should not be possible. Now, once a command has been paid for, it cannot be drafted again. An error is returned to the user indicating that the order has been finalized. This commit also adds a server request in case of error during orders synchronization. Forward-Port-Of: odoo/odoo#208842 Forward-Port-Of: odoo/odoo#208448
Add the partner's `ref` field to the list of PartyIdentification>ID. task-4720252 Forward-Port-Of: odoo/odoo#206655
Original PR description
Add the partner's `ref` field to the list of PartyIdentification>ID. task-4720252 Forward-Port-Of: odoo/odoo#206655
When we install portal as well as account_peppol module and go to My Account, so feature are not working, for e.g. changing country will not change State selection, it is because we have PublicWidget with name `publicWidget.registry.portalDetails` in portal module while we are using same name in account_peppol module which replaces the existing PublicWidget `portalDetails`. To fix this issue we have used `inlcude` feature which will patch existing class `portalDetails` of portal module. Th
Original PR description
When we install portal as well as account_peppol module and go to My Account, so feature are not working, for e.g. changing country will not change State selection, it is because we have PublicWidget with name `publicWidget.registry.portalDetails` in portal module while we are using same name in account_peppol module which replaces the existing PublicWidget `portalDetails`. To fix this issue we have used `inlcude` feature which will patch existing class `portalDetails` of portal module. The issue arise with commit: https://github.com/odoo/odoo/pull/182585/commits/857b9a188c77cef2e3cd8a1c6b3035e7cd8d1305#diff-e0a8e9753f5e3ae55848bc264b7546eb7e187fe77c7500f9ebd97b1edfb23f46 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191658 Forward-Port-Of: odoo/odoo#186388
Steps to reproduce: - Create a product with two separate 'no-variant' attributes - Set that product as MTO / Manufacture - Create a BoM for that product, with a single component - Set that component as limited to the first 'no-variant' attribute - Create a Sale Order for that product, and select the second 'no-variant' attribute - Confirm the Sale Order Issue: A traceback will be raised, as the given attribute won't be found within the attributes set on the bom. When chekcing if we
Original PR description
Steps to reproduce: - Create a product with two separate 'no-variant' attributes - Set that product as MTO / Manufacture - Create a BoM for that product, with a single component - Set that component as limited to the first 'no-variant' attribute - Create a Sale Order for that product, and select the second 'no-variant' attribute - Confirm the Sale Order Issue: A traceback will be raised, as the given attribute won't be found within the attributes set on the bom. When chekcing if we should skip the bom line, there will be an issue if there's a miss-match between the attributes written on a line and the ones given to the MO. To avoid this, we now directly exclude a line when there's no common attribute between the two, then validate it once at least one match was found. opw-4758951 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208623
Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `g
Original PR description
Versions -------- - 16.0+ Steps (saas-17.4) ----------------- 1. Install `l10n_ar_website_sale`; 2. run `:TestWebsiteSaleProductFilters` test suite. Issue ----- 2 tests fails. Cause ----- The filters search for sale orders from `get_current_website`. Even though the correct website is passed to the `MockRequest`, the result of the call is a website from an Argentinian company with no sales orders. Solution -------- Add `force_website_id` to the `MockRequest` session, so `get_current_website` returns the intended website: https://github.com/odoo/odoo/blob/1ea4f285aba925d437a5129cd36143d9987c6e6a/addons/website/models/website.py#L1121 > [!Note] > Alternatively, we can check for `request.website` being set in `get_current_website`. No idea if there's a reason it doesn't already. runbot-111554 runbot-111555 Forward-Port-Of: odoo/odoo#208687 Forward-Port-Of: odoo/odoo#201433
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian company (with `l10n_be_pos_sale` installed). This error was raised becaues we try to load Intra-Community chart template which is defined on the parent company. - Now we use `sudo()` to correctly load the Intra-Community chart template of the parent company, because if the user has permission to op
Original PR description
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian…
- Before this fix, when a user which have only access to a company branch (not access to the parent company), he was not able to open a POS session. This issue was only appearing when using a belgian company (with `l10n_be_pos_sale` installed). This error was raised becaues we try to load Intra-Community chart template which is defined on the parent company. - Now we use `sudo()` to correctly load the Intra-Community chart template of the parent company, because if the user has permission to open a POS session on a company branch, he should be able to load its Intra-Community chart template (even if it's defined on the parent company). - Update the test `test_pos_branch_company_access` so the `pos_user` have only access to the company branch (not the parent company anymore). Steps to reproduce: - Install ``l10_be_pos_sale` module - Create a new belgian company with a branch - Create a new user with access to this company branch (not the parent company) - Create a new POS config for this company branch (with admin user) - Try to open a POS session with the newly created user - => Access error opw: 4736949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208573
Steps to reproduce: - With an AE Company - Enable Multicurrency (USD) - Create an invoice in USD with total 0.00 - Print Issue: Traceback will raise """ odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2] Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision"
Original PR description
Steps to reproduce:
- With an AE Company
- Enable Multicurrency (USD)
- Create an invoice in USD with total 0.00
- Print
Issue: Traceback will raise
"""
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero
Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2]
Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision": 5}"/>
"""
opw-4724401
Forward-Port-Of: odoo/odoo#208396Writing the account code is restricted on l10n_de accounts. Odoo checks that the code we write is different from the old one, and if so it checks of there are already some entries for that accounts. If any of the condition is met, the write is prevented. When we try to map an account from another company to a l10n_de company, the _inverse_code function from the account mapping will try and update the account code in the other company, as the code is company dependent. The issue is that we
Original PR description
Writing the account code is restricted on l10n_de accounts. Odoo checks that the code we write is different from the old one, and if so it checks of there are already some entries for that accounts. If any of the condition is met, the write is prevented. When we try to map an account from another company to a l10n_de company, the _inverse_code function from the account mapping will try and update the account code in the other company, as the code is company dependent. The issue is that we check that the l10n_de code remains the same, even if we are in another, non l10n_de company. This PR adapts the check to l10n_de account to only check the code if we are writing it from the l10n_de company. opw-4711417 Forward-Port-Of: odoo/odoo#208538
Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208571
Original PR description
Steps to reproduce: - Connect IoT box with scale to DB - Configure PoS with the scale - Configure product to be available in PoS and has to be weighed - Make an order with the product - Scale window pops up for weighing - Close window directly - One unit of product is still added, we expect nothing to be added opw-4643243 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208571
<b>Steps to reproduce:</b> 1. Go to Sales > Create New Quotation. 2. Add a customer and a product(e.g., "Acoustic Bloc Screens testingggggggggg"). 3. Go to POS > Open any register. 4. Navigate to Actions > Quotation/Order, select SO. 5. Apply a down payment percentage. 6. Enter the percentage, select Payment > Cash, and validate the payment. 7. Navigate Print full receipt. <b>Issue:</b> Unintended scrolling behavior in the order line section. <b>Cause:</b> Although the container
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create New Quotation. 2. Add a customer and a product(e.g., "Acoustic Bloc Screens testingggggggggg"). 3. Go to POS > Open any register. 4. Navigate to Actions > Quotation/Order, select SO. 5. Apply a down payment percentage. 6. Enter the percentage, select Payment > Cash, and validate the payment. 7. Navigate Print full receipt. <b>Issue:</b> Unintended scrolling behavior in the order line section. <b>Cause:</b> Although the container had the class overflow-y-auto, it wasn't the root cause. The issue occurred with long product names in certain configurations, leading to unintended scrolling behavior. <b>Solution:</b> Added the product-name class to handle content display and prevent unnecessary scrolling. opw-4479286 Forward-Port-Of: odoo/odoo#205659
Introduced in odoo/odoo#164793. Steps to reproduce: - Configure a POS to use self order - Add an Adyen payment method to this POS - Attempt to pay for a self order using the Adyen payment method - The payment fails immediately with an error message, however the payment does go through to the payment terminal. This bug was introduced by the refactor to use related models. The `start_payment` method in the payment page wasn't updated accordingly, leading to an error due to calling a non-
Original PR description
Introduced in odoo/odoo#164793. Steps to reproduce: - Configure a POS to use self order - Add an Adyen payment method to this POS - Attempt to pay for a self order using the Adyen payment method - The payment fails immediately with an error message, however the payment does go through to the payment terminal. This bug was introduced by the refactor to use related models. The `start_payment` method in the payment page wasn't updated accordingly, leading to an error due to calling a non-existent function. All other payment terminals are unaffected as they override this method, but Adyen does not, so the bug was only affecting Adyen payments. task-4749171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207205
PR https://github.com/odoo/odoo/pull/207213 modified the logic which was used to fetch a new pairing code from iot proxy. It made it so that if the IoT Box doesn't initially have internet access it never fetches a pairing code unless you restart odoo. This PR fixes the logic so that the pairing code is fetched when needed no matter the initial state of the IoT Box Forward-Port-Of: odoo/odoo#208755
Original PR description
PR https://github.com/odoo/odoo/pull/207213 modified the logic which was used to fetch a new pairing code from iot proxy. It made it so that if the IoT Box doesn't initially have internet access it never fetches a pairing code unless you restart odoo. This PR fixes the logic so that the pairing code is fetched when needed no matter the initial state of the IoT Box Forward-Port-Of: odoo/odoo#208755
PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208729 Forward-Port-Of: odoo/odoo#208247
Original PR description
PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208729 Forward-Port-Of: odoo/odoo#208247
In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included
Original PR description
In some cases, it's not possible for customers to trim the description of an invoice line to the accepted length (e.g. for traceability or completeness). It turns out that Avalara will trim and transform the descriptions on our behalf to make them compatible with the government's API. As part of that process, they translate `\n` characters to ` | ` before sending it to the government. Unfortunately, there seems to be a bug with that process on their side. When a '\n' character is included in the description, they don't trim the description they send to the government sufficiently. Perhaps they trim before the '\n' to ' | ' translation, or perhaps they have some other bug. We sidestep the issue by doing that same translation on our side and sending them that. It doesn't result in any change on the EDI PDF or XML, and this way we can avoid hardcoding these limits on our side. task-4726372 Forward-Port-Of: odoo/enterprise#84777 Forward-Port-Of: odoo/enterprise#84700
Currently it's possible for a timesheet user to set and write the project to False in the timesheet list view. The UI will say the project is missing but the analytic line is changed anyway. This PR add check that the project is set before writing to the analytic line record. opw-4649817 Forward-Port-Of: odoo/enterprise#84636 Forward-Port-Of: odoo/enterprise#83420
Original PR description
Currently it's possible for a timesheet user to set and write the project to False in the timesheet list view. The UI will say the project is missing but the analytic line is changed anyway. This PR add check that the project is set before writing to the analytic line record. opw-4649817 Forward-Port-Of: odoo/enterprise#84636 Forward-Port-Of: odoo/enterprise#83420
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
Original PR description
This commit removes the demo data for portal user as a portal user cannot be assigned to tasks. taskid:3703637 Forward-Port-Of: odoo/enterprise#81826 Forward-Port-Of: odoo/enterprise#56588
Steps to reproduce the issue: - Create a quality check with any parameters - Add a future activity - Click on the activity icon in the top bar - The activity summary shows: - 0 Late, 0 Today, 1 Future - Click on "Late" Issue: No filter is applied and all quality checks are displayed. Solution: Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin. opw-4727840
Original PR description
Steps to reproduce the issue:
- Create a quality check with any parameters
- Add a future activity
- Click on the activity icon in the top bar
- The activity summary shows:
- 0 Late, 0 Today, 1 Future
- Click on "Late"
Issue:
No filter is applied and all quality checks are displayed.
Solution:
Added predefined filters for activity deadlines (Late, Today, Future) in the search view of the quality.check model, to align with other models using mail.activity.mixin.
opw-4727840
Forward-Port-Of: odoo/enterprise#84523It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a
Original PR description
It is possible that a employee won't have a contract (maybe a freelancer) nor a user related. In such case when asked to sign a document, the document cannot be signed. It is possible to reproduce this behaviour on runbot https://www.awesomescreenshot.com/video/39482670?key=9eed08257cc76b5749c1c8c0dda62377 This commit aims to set a user, since the user cannot be false. I believe that since one of the options would be set it to the manager of the contract the employee is under, it would be a valid option considering that the employee has no contract, to set it to whoever sent the request, in this case, the request create_uid opw-4750010 Forward-Port-Of: odoo/enterprise#84711
**How to reproduce:** - Create a partner with name 'abc' and email 'xyz@xyz.com' - Select a document/folder - Click the 'Share' button - Search by email, it'll work - Search by name, it doesn't work **Before this commit:** Search by name is not working **Technical reason:** Partner's display name is passed in a variable called 'label' **After this commit:** Search on name will work on member invite modal Task-4758923 Forward-Port-Of: odoo/enterprise#84481
Original PR description
**How to reproduce:** - Create a partner with name 'abc' and email 'xyz@xyz.com' - Select a document/folder - Click the 'Share' button - Search by email, it'll work - Search by name, it doesn't work **Before this commit:** Search by name is not working **Technical reason:** Partner's display name is passed in a variable called 'label' **After this commit:** Search on name will work on member invite modal Task-4758923 Forward-Port-Of: odoo/enterprise#84481
Current behavior before PR: - When showing analytic columns in reports, a filter can be applied from 'Options' menu to show analytic simulations (analytic items not linked to any move). This filter didn't work properly. Desired behavior after PR is merged: - Analytic simulations are integrated in the already existing analytic groupby columns Link to the task : - https://www.odoo.com/odoo/project/967/tasks/4603267 Forward-Port-Of: odoo/enterprise#81183
Original PR description
Current behavior before PR: - When showing analytic columns in reports, a filter can be applied from 'Options' menu to show analytic simulations (analytic items not linked to any move). This filter didn't work properly. Desired behavior after PR is merged: - Analytic simulations are integrated in the already existing analytic groupby columns Link to the task : - https://www.odoo.com/odoo/project/967/tasks/4603267 Forward-Port-Of: odoo/enterprise#81183
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - F
Original PR description
The incoterm code of a line in the intrastat report is the incoterm code from the move or if there is no incoterm code on the move, the one from the company. When creating the request when unfolding report lines, the incoterm code was always checked on the move and not on the company. This would not return lines without incoterm code. This commit changes the incoterm domain to also check the incoterm code of the move company when no incoterm code is set on the move. Steps to reproduce: - From an EU company, create an invoice to a company in another EU country - Do not set an incoterm on the invoice - In settings, set a default incoterm on the company - Display the intrastat report for the time period of the invoice - Try to unfold the line corresponding to the invoice opw-4642781 Forward-Port-Of: odoo/enterprise#84734
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the gro
Original PR description
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the group `group_account_basic` does not have any access. Solution --------- Add 2 access rules on `account.online.link` that allows a Advanced billing user to see (and only see) those records. Note that it does not change anything for `group_account_user` which inherits both from `group_account_readonly` and `group_account_basic`, since it already had readonly access thanks to the first aforementioned. task-4731654 Forward-Port-Of: odoo/enterprise#83889
Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref. This fix ensures that only non-empty refs are considered when processing FEC files. Steps to reproduce: 1. Install the `l10n_fr_fec_import` module. 2. Create a contact and set its ref to an empty string (`""`). 3. Import an FEC file containing lines without `CompAuxNum`. 4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`. opw-4592290 Forward-Port-O
Original PR description
Currently, an empty partner ref in an FEC line could incorrectly match a partner with an empty ref. This fix ensures that only non-empty refs are considered when processing FEC files. Steps to reproduce: 1. Install the `l10n_fr_fec_import` module. 2. Create a contact and set its ref to an empty string (`""`). 3. Import an FEC file containing lines without `CompAuxNum`. 4. The created contact will be incorrectly assigned to all lines without `CompAuxNum`. opw-4592290 Forward-Port-Of: odoo/enterprise#84855 Forward-Port-Of: odoo/enterprise#81676
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
Original PR description
Description of the issue this commit addresses: Zero balance lines are creating friction when reconciling lines. They will never need a renconciliation but they still impair the user's ability to reconcile other lines together if selected. --- Desired behavior after this commit is merged: When reconciling lines, the zero balance ones are simply ignored and the reconciliation proceeds as if they were not selected. --- task-4723956 Forward-Port-Of: odoo/enterprise#84851
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
Original PR description
In 65576b109249fbb0f111f57b42d48940a46f63db we added schema files to mock the l10n_ar_edi services. But their filenames contained `?` which is not a valid filename character on Windows. As a result, users cannot pull the repository on Windows anymore. This commit removes the `?` character from the filenames. task-none Forward-Port-Of: odoo/enterprise#84852
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue
Original PR description
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for…
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue occurs because when all food items are removed, `note_history` does not contain the `qty` key and it attempts to access `qty` from `note` at [1]. This commit resolves the issue by adding an additional check to ensure that 'qty' is in `note` before accessing the `qty` key. [1] - https://github.com/odoo/enterprise/blob/f1615134029860d32b95ade09738549a7bb1632d/pos_preparation_display/models/pos_order.py#L79-L80 Sentry - 6303446407 Forward-Port-Of: odoo/enterprise#84730 Forward-Port-Of: odoo/enterprise#79685