Friday, April 11, 2025
17 changes · 18.0
Resolved issues and error corrections
Notification emails for sales quotations and orders no longer show the portal viewing button to followers who do not have portal access. This prevents confusion from sending those contacts to a login page they cannot use, while still keeping the button available for portal-enabled customers.
Original PR description
**Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the…
**Description of the issue/feature this PR addresses:** Currently all followers without portal access are able to see the button, in the email notification, that redirects to the portal (to see the quotation or sale order). This may be confusing and not logic, as the button will redirect them to the login page of the portal, to which they do not have access. **Current behavior before PR:** Currently the followers without portal access get access to the button to view the order or quotation, as the follower group is configured to have 'has_button_access' to True. That leads them to the login page of the portal. **Steps to reproduce** 1. Configure odoo to be able to send out emails. 2. Install sale_management. 3. Create a sale order for a customer and add as follower another partner that has no portal access. This follower needs to have an email you have access to. 4. Send a message to the follower. 5. Test in the received email that the "View Quotation/Order" button is shown and when clicked, the user is redirected to the login page. **Desired behavior after PR is merged:** Only followers with portal access, which will be categorized as "portal_customer" instead of "follower", will have access to the button. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The calendar's Share Availabilities menu now only shows appointment types that are based on staff users. This prevents resource-based options, such as room or table bookings, from appearing in a menu where they do not apply.
Original PR description
Steps to reproduce: 1) Open the Appointment module without loading demo data. 2) Create a resource-based appointment type using the helper (e.g., 'Book a Resource' or 'Table Booking'). 3) Open the calendar and check the 'Share Availabilities' dropdown menu—resource-based appointments appear there. Issue: Resource-based appointments should not be visible in the dropdown menu. Technical: We have set default value of `staff_user_ids` as self user. Inside the `appointment_get_user_appointment_types`'s domain we only specified, `staff_user_ids` but while creating a resource based appointment from the Helper, we directly select, `schedule_based_on` as `resources`, thus will not see `staff_user_ids` in view, there for its compute will never called, and we will get its default value, as the result that appointment will be valid as per `appointment_get_user_appointment_types`'s domain. After this PR: Only User based appointments will be displayed. Task-4680418
Miscellaneous changes
Turnstile was missing on website_mass_mailing. This lack of implementation caused the newsletter forms to not submit anymore. Task-4592066 Forward-Port-Of: odoo/odoo#204690 Forward-Port-Of: odoo/odoo#200158
Original PR description
Turnstile was missing on website_mass_mailing. This lack of implementation caused the newsletter forms to not submit anymore. Task-4592066 Forward-Port-Of: odoo/odoo#204690 Forward-Port-Of: odoo/odoo#200158
Since https://github.com/odoo/odoo/pull/143233, when we group by a many2many, the `__domain` of the Falsy group for records that don't have any many2many values) is expressed with `[('many2many', 'not in', <other group values>)]`. We did this because the ORM bypasses the 'ir.rule' for checking this type of domain: `[('many2many', '=', False)]` and changing this semantic is impossible in stable (and even hard to change in master). Unfortunately, this fix is not correct when the read_group() li
Original PR description
Since https://github.com/odoo/odoo/pull/143233, when we group by a many2many, the `__domain` of the Falsy group for records that don't have any many2many values) is expressed with `[('many2many', 'not in', <other group values>)]`. We did this because the ORM bypasses the 'ir.rule' for checking this type of domain: `[('many2many', '=', False)]` and changing this semantic is impossible in stable (and even hard to change in master).
Unfortunately, this fix is not correct when the read_group() limit is reached. In fact, the right part of the domain doesn't contain ids of many2many, which are filtered out by the limit.
Instead, use `[('many2many', 'not any', [])]` as the domain for the False group. Note that this may decrease the performance of the generated search because it will have to check ir.rule in the comodel and will generate more complex queries.
opw-4577443
Forward-Port-Of: odoo/odoo#205030Steps to reproduce: - Enter website edit mode. - Drag and drop the Tabs snippet onto the page. - Click on the third tab to activate it. - Click the minus (-) button to remove the tab. - No other tab is activated after removal, leaving the tab content area empty. This commit ensures that if a tab is removed, the next available tab is activated automatically. This commit fixes another minor issue: When the direction option is set to "vertical", the expected vertical padding was
Original PR description
Steps to reproduce: - Enter website edit mode. - Drag and drop the Tabs snippet onto the page. - Click on the third tab to activate it. - Click the minus (-) button to remove the tab. - No other tab is activated after removal, leaving the tab content area empty. This commit ensures that if a tab is removed, the next available tab is activated automatically. This commit fixes another minor issue: When the direction option is set to "vertical", the expected vertical padding was not applied due to an incorrect selector. Forward-Port-Of: odoo/odoo#204756 Forward-Port-Of: odoo/odoo#204253
The missing break was duplicating the file_data. For example, the PDF was there in PDF but also in binary. opw-4510745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205328
Original PR description
The missing break was duplicating the file_data. For example, the PDF was there in PDF but also in binary. opw-4510745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205328
Steps to reproduce: (This are for this specific case) 1. Get website_appointment_sale and a 2nd language for our website. 2. Make sure that for the appointment we select Allow Guests. 3. Now, we go to the website and go to the appointment, until we reach the "Add more details about you" page. 4. Here is when we have to try to modify the translation with editor. Issue: We're receiving an error as "Cannot read properties of null (reading '2')" which arises from the `trans` not being a
Original PR description
Steps to reproduce: (This are for this specific case) 1. Get website_appointment_sale and a 2nd language for our website. 2. Make sure that for the appointment we select Allow Guests. 3. Now, we go to the website and go to the appointment, until we reach the "Add more details about you" page. 4. Here is when we have to try to modify the translation with editor. Issue: We're receiving an error as "Cannot read properties of null (reading '2')" which arises from the `trans` not being appropiate due to the translation regex, which will cause the match to be null when calling it on this "defective" `trans`. Solution: The current solution will make the regex to better match anything in the translation, by modifying `(.*)` to ([\s\S]*?) we make sure that we're matching any character, including new lines. opw-4442038 Forward-Port-Of: odoo/odoo#204131 Forward-Port-Of: odoo/odoo#194416
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + fre
Original PR description
…ds) account move line text, based on pos orders **Description of the issue/feature this PR addresses:** During the close of the PoS session, account move are generated. the text of the lines depends on the sales (and refund). for the time being, some part of text are not translatable. **Current behavior before PR:**  **Desired behavior after PR is merged:** Text can be translated. + french translation added. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175016 Forward-Port-Of: odoo/odoo#174511
PoS user can't open the product information on the product screen of a PoS session. This is because it will lead to the compute of the quantities. Doing so, we will first go in the override of mrp, in case the product is a kit. This will query the BoM model. However, a PoS user hasn't any access to the module. The fix follows the same logic as - account: https://github.com/odoo/odoo/commit/fe6b351e04b7aa7d311cc07362d82f9843dde862 - purchase: https://github.com/odoo/odoo/commit/e9d809
Original PR description
PoS user can't open the product information on the product screen of a PoS session. This is because it will lead to the compute of the quantities. Doing so, we will first go in the override of mrp, in case the product is a kit. This will query the BoM model. However, a PoS user hasn't any access to the module. The fix follows the same logic as - account: https://github.com/odoo/odoo/commit/fe6b351e04b7aa7d311cc07362d82f9843dde862 - purchase: https://github.com/odoo/odoo/commit/e9d80990e0f907be7799c6449afd6cd19502d604 - sale: at least since https://github.com/odoo/odoo/commit/43977deb713ef8df02690d9000f9becff8d9d610 This commit also reverts: https://github.com/odoo/odoo/commit/98428145c4917bfcf8436569ab7560524d957880 Which is actually the reason why this commit is written: we should not have to give those rights to a PoS user Forward-Port-Of: odoo/odoo#205131 Forward-Port-Of: odoo/odoo#204512
Versions -------- - 16.0+ Steps ----- 1. Install `website_sale_loyalty` with default configuration; 2. add a payment provider; 3. as a public user, buy a gift card via eCommerce. Issue ----- No email is sent with the gift card's code to the provided email address. Cause ----- The email template doesn't have an `email_from` field added. Without this value, it falls back on the current user, but because we're Public User, this also doesn't have an `email` value. Additionally,
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Install `website_sale_loyalty` with default configuration; 2. add a payment provider; 3. as a public user, buy a gift card via eCommerce. Issue ----- No email is sent with the gift card's code to the provided email address. Cause ----- The email template doesn't have an `email_from` field added. Without this value, it falls back on the current user, but because we're Public User, this also doesn't have an `email` value. Additionally, if the order gets confirmed as a portal user, the email will be sent from the client's email address. Solution -------- Add a `_get_mail_author` hook to `loyalty.card`, which can be used when an email template lacks an `email_from` value. Mail author precedence for cards without an order: - current internal user > card's company > current company Mail author precedence for cards with an order: - salesperson > order's company opw-4687107 Forward-Port-Of: odoo/odoo#204644
Currently, an error occurs when opening a website cart if its `Payment method` record has been deleted. This results in preventing the user from accessing the cart. **Steps to produce:** - Install the `website_sale` module. - Navigate to `Website / Configuration / eCommerce / Payment Methods`. - Delete method `name: Payment method`. - Add the product to the cart and then open it. - Observe the error. **Error:** `ValueError: External ID not found in the system: payment.payment_method_
Original PR description
Currently, an error occurs when opening a website cart if its `Payment method` record has been deleted. This results in preventing the user from accessing the cart. **Steps to produce:** - Install…
Currently, an error occurs when opening a website cart if its `Payment method` record has been deleted. This results in preventing the user from accessing the cart. **Steps to produce:** - Install the `website_sale` module. - Navigate to `Website / Configuration / eCommerce / Payment Methods`. - Delete method `name: Payment method`. - Add the product to the cart and then open it. - Observe the error. **Error:** `ValueError: External ID not found in the system: payment.payment_method_unknown` The error occurs because the system attempts to access id of the payment method `payment.payment_method_unknown` at [1], but it is unavailable as the user has already deleted it. This commit adds validation to prevent deletion of the `payment_method_unknown`. [1] - https://github.com/odoo/odoo/blob/1c896c5da71b58b382269fe6cca556f4a61e4d5d/addons/website_sale/controllers/main.py#L1714 Sentry - 6177955401 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198728
### Issue: Currently, the default route set on an automatically created RR might not be set on the product. ### Steps to reproduce: - In the settings: enable Multi-Steps Routes - On your warehouse set Manufacture in 3 steps - Create a storable product without any set route - Create a need for that product, for instance by creating and confirming an SO for 1 unit. - Inventory > Operations > Procurement > Replenishment #### > A reordering rule was automatically created for your prod
Original PR description
### Issue: Currently, the default route set on an automatically created RR might not be set on the product. ### Steps to reproduce: - In the settings: enable Multi-Steps Routes - On your warehouse…
### Issue: Currently, the default route set on an automatically created RR might not be set on the product. ### Steps to reproduce: - In the settings: enable Multi-Steps Routes - On your warehouse set Manufacture in 3 steps - Create a storable product without any set route - Create a need for that product, for instance by creating and confirming an SO for 1 unit. - Inventory > Operations > Procurement > Replenishment #### > A reordering rule was automatically created for your product but the manufacture route is set by default. ### Cause of the issue: Entering the replenishment tab will create orderpoints and set their default routes: https://github.com/odoo/odoo/blob/884130330b600b4356c640cb679c2bb8fdb833a0/addons/stock/models/stock_orderpoint.py#L478-L481 However, the `_set_default_route_id` does not check that the route found to match a given orderpoint is actually selected on the product of the orderpoint: https://github.com/odoo/odoo/blob/884130330b600b4356c640cb679c2bb8fdb833a0/addons/stock/models/stock_orderpoint.py#L323-L336 opw-4681202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204850 Forward-Port-Of: odoo/odoo#204449
Analytic lines partner is not computed when changing the partner of the related move line. To solve this, we add the `move_line_id.partner_id` in the `depends` of the compute. To reproduce: - Create a journal entry - Set an analytic account on one of a line - Confirm journal entry - From the account move line list view, select the lines from the previous entry - Change the partner - Go to analytic reporting -> The partner on the analytic line has not been changed Ticket [link](
Original PR description
Analytic lines partner is not computed when changing the partner of the related move line. To solve this, we add the `move_line_id.partner_id` in the `depends` of the compute. To reproduce: - Create a journal entry - Set an analytic account on one of a line - Confirm journal entry - From the account move line list view, select the lines from the previous entry - Change the partner - Go to analytic reporting -> The partner on the analytic line has not been changed Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4626366) opw-4626366 Forward-Port-Of: odoo/odoo#205459 Forward-Port-Of: odoo/odoo#201512
Description of the issue/feature this PR addresses: Added my new email on the CLA 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#205479
Original PR description
Description of the issue/feature this PR addresses: Added my new email on the CLA 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#205479
Previously, the round-off amount was not being included in the E-Way Bill request when sending invoices from Odoo. This caused inconsistencies between the generated invoice and the data sent to the E-Way Bill portal. This commit ensures that the round-off amount is properly accounted for in the request, maintaining consistency between the invoice and the E-Way Bill data. opw-4708955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
Previously, the round-off amount was not being included in the E-Way Bill request when sending invoices from Odoo. This caused inconsistencies between the generated invoice and the data sent to the E-Way Bill portal. This commit ensures that the round-off amount is properly accounted for in the request, maintaining consistency between the invoice and the E-Way Bill data. opw-4708955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205522
when access planning by user in field service we will see that inactive user are also get fetched even though they dont have planning set this will happend if user have open assigned tasks with no `planned_date_begin` and `date_deadline` here we have made some refactor [ref](https://github.com/odoo/enterprise/pull/53499) and implemented the hook to prepare the domain to fetch the records of `project.task`, instead of overriding `_group_expand_user_ids` steps to reproduce: - navigate t
Original PR description
when access planning by user in field service we will see that inactive user are also get fetched even though they dont have planning set this will happend if user have open assigned tasks with no `planned_date_begin` and `date_deadline` here we have made some refactor [ref](https://github.com/odoo/enterprise/pull/53499) and implemented the hook to prepare the domain to fetch the records of `project.task`, instead of overriding `_group_expand_user_ids` steps to reproduce: - navigate to `Field Service > Planning > By User`. - open unassigned task - assigned it to user(create new or use existing user) - unschedule the task - archieve the user ref the video: https://drive.google.com/file/d/1hME_bPXXNJgO9wgWT_CPP3-gz1RaLhPe/view?usp=sharing Fix: - fetch the active user if not added filter manually - if manual filter then fetch based on filter **OPW: 4588785** Forward-Port-Of: odoo/enterprise#82862
… by making lambda selection Forward-Port-Of: odoo/enterprise#83146
Original PR description
… by making lambda selection Forward-Port-Of: odoo/enterprise#83146