Wednesday, May 14, 2025
29 changes · saas-18.1
Resolved issues and error corrections
The IoT box image no longer keeps an outdated web server setup that could incorrectly redirect visits to port 80 when the access point was not running. This prevents confusing web access behavior and removes the unused default splash page.
Original PR description
In odoo/odoo#209104, the nginx config was revamped to allow for a better access point experience. However, a side-effect of this was that the nginx config in `overwrite_before_init`, which was previously always overwritten, was now being used, causing accesses to port 80 to always be redirected even when the access point was not running. To fix this, we delete the old config file, and also delete the default nginx splash page website. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Description of the issue this commit addresses: In the move form view, the sections and notes are made readonly too soon. For example in a purchase order form, when the PO is confirmed, it is still possible to add notes and sections but not to edit them so they are locked once the focus is lost. As it is intended to be able to add notes at such point so it should be possible to edit them too. --- Desired behavior after this commit is merged: This commit makes it so that the readonly
Original PR description
Description of the issue this commit addresses: In the move form view, the sections and notes are made readonly too soon. For example in a purchase order form, when the PO is confirmed, it is still…
Description of the issue this commit addresses: In the move form view, the sections and notes are made readonly too soon. For example in a purchase order form, when the PO is confirmed, it is still possible to add notes and sections but not to edit them so they are locked once the focus is lost. As it is intended to be able to add notes at such point so it should be possible to edit them too. --- Desired behavior after this commit is merged: This commit makes it so that the readonly attribute of the sections and notes depends on the state of the move of the form. Currently, we want the readonly only if the parent is cancelled (cancel), locked (done) or posted (posted). --- Note on the fix: The addition of the sectionAndNoteIsReadonly() getter is the part of the fix that really allows the user to edit text that was previously uneditable. On the other hand, the override of the isCellReadonly method is only here to make sure no readonly classes like text-muted are applied if the cell is still editable. --- opw-4744367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208638
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Versions -------- - 16.0+ Steps ----- 1. Enable abandoned cart reminder emails; 2. have an event with a limited number of seats; 3. open a cart for a ticket to the event; 4. abandon the cart; 5. have available seats fill up. Issue ----- You still get an email reminding you to buy the ticket, even though it's no longer available. As a consequence, you can still pay the sales order, but it won't get confirmed. Cause ----- There is no custom logic in place for `website_event_sa
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable abandoned cart reminder emails; 2. have an event with a limited number of seats; 3. open a cart for a ticket to the event; 4. abandon the cart; 5. have…
Versions -------- - 16.0+ Steps ----- 1. Enable abandoned cart reminder emails; 2. have an event with a limited number of seats; 3. open a cart for a ticket to the event; 4. abandon the cart; 5. have available seats fill up. Issue ----- You still get an email reminding you to buy the ticket, even though it's no longer available. As a consequence, you can still pay the sales order, but it won't get confirmed. Cause ----- There is no custom logic in place for `website_event_sale` to filter out abandoned carts with tickets that are no longer eligible. Additionally, the `is_sold_out` field of tickets can be `False` while the event's `event_registrations_sold_out` field is `True`. Solution -------- - Add the event's `event_registrations_sold_out` field as a dependency to `event.event.ticket`'s `_comute_is_sold_out` method. - Add an override for `_filter_can_send_abandoned_cart_mail` which filters out carts with tickets that are sold out, or events with no free places remaining. opw-4453539 Forward-Port-Of: odoo/odoo#209565 Forward-Port-Of: odoo/odoo#199877
Before this commit, when the user is in debug mode and go to the form view of a task with some timesheets, he can optionally display the view button in the sub list view of timesheets. The problem is the view button will return the first form view found in timesheet model. Since timesheet model is in fact `account.analytic.line`, the first form view opened is the one used for Analytic Items and not for the timesheets. This commit alters the form view by using `form_view_ref` context key on ti
Original PR description
Before this commit, when the user is in debug mode and go to the form view of a task with some timesheets, he can optionally display the view button in the sub list view of timesheets. The problem is the view button will return the first form view found in timesheet model. Since timesheet model is in fact `account.analytic.line`, the first form view opened is the one used for Analytic Items and not for the timesheets. This commit alters the form view by using `form_view_ref` context key on timesheet_ids field to be able to load the expected form view. task-4781729 Forward-Port-Of: odoo/odoo#209653
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Google, when the synchronization of user A starts or resumes, the event will be synchronized with the user A as organizer in Google. In the meanwhile, in Odoo, the event ownership will be shown as user B, mismatching the organizer field between the two ends. This is problematic because the ownership of the event will be forever wrong in Google. After this commit, when user A start
Original PR description
Before this commit, when an user A is invited by an event of user B and none of these users are synchronized with Google, when the synchronization of user A starts or resumes, the event will be synchronized with the user A as organizer in Google. In the meanwhile, in Odoo, the event ownership will be shown as user B, mismatching the organizer field between the two ends. This is problematic because the ownership of the event will be forever wrong in Google. After this commit, when user A starts or resumes its synchronization with Outlook, previous Odoo events which user A is attendee but not organizer won't be synchronized until the organizer synchronizes its calendar. This will keep the ownership of the event intact in Odoo, and when the organizer synchronizes its calendar with Google, it will be correctly synchronized in Google as well. task-4269432 Forward-Port-Of: odoo/odoo#188848
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
Original PR description
**Issue:** When sharing a project, the project manager was accidentally removed from the project's followers **Steps to reproduce:** - create a new project. - in the project settings, click “Share Project”. - add a collaborator and share. The project manager disappears from the follower list, leaving only the new collaborator. opw-4764035 Forward-Port-Of: odoo/odoo#208753
With Jordan Company setup: - Set dummy values on the Jordan electronic invoicing settings - Enable USD, set a rate and currency precision to 5 - Set the Product Price decimal accuracy to 5 - Make an invoice in USD adding a line as follows: - Price 0.13793 - Qty 9 - Discount 100% - Tax: 16% - Confirm - Send & Print, activate e-invoice (JoFotara (Jordan EDI)) Issue will raise: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template Template: accou
Original PR description
With Jordan Company setup: - Set dummy values on the Jordan electronic invoicing settings - Enable USD, set a rate and currency precision to 5 - Set the Product Price decimal accuracy to 5 - Make an…
With Jordan Company setup: - Set dummy values on the Jordan electronic invoicing settings - Enable USD, set a rate and currency precision to 5 - Set the Product Price decimal accuracy to 5 - Make an invoice in USD adding a line as follows: - Price 0.13793 - Qty 9 - Discount 100% - Tax: 16% - Confirm - Send & Print, activate e-invoice (JoFotara (Jordan EDI)) Issue will raise: ``` odoo.addons.base.models.ir_qweb.QWebException: Error while render the template Template: account_edi_ubl_cii.ubl_20_MonetaryTotalType Path: /t/t/cbc:TaxInclusiveAmount Node: <ns0:TaxInclusiveAmount xmlns:ns0="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" t-att-currencyID="vals[\'currency\'].name" t-out="format_float(vals.get(\'tax_inclusive_amount\'), vals.get(\'currency_dp\'))"/> ``` This occurs because on high currency precision we may work with numbers that are represented in scientific notation (-2e-09) that when converted to string may keep the literal form unless using a specific format opw-4739342 Forward-Port-Of: odoo/odoo#209624
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been vali
Original PR description
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this…
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been validated ### Cause: This is happening because when trying to link the lines to the invoice we consider the timesheets within the date range that the user might have set in the create invoice wizard. https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/wizard/sale_make_invoice_advance.py#L33-L51 https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/models/sale_order.py#L153 ### Fix: In subscription we can use the last and next invoice dates if the user hasn't set a period for the invoice. opw-4523727 Forward-Port-Of: odoo/odoo#205029
Before this commit, when a product had multiple taxes, the X report was displaying a wrong total base tax amount. This was due to the fact that the tax amount was being calculated as the sum of all the tax bases. This was wrong as the amount tax excluded of the product sold was included twice in this sum. opw-4727830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208642
Original PR description
Before this commit, when a product had multiple taxes, the X report was displaying a wrong total base tax amount. This was due to the fact that the tax amount was being calculated as the sum of all the tax bases. This was wrong as the amount tax excluded of the product sold was included twice in this sum. opw-4727830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208642
**Purpose:** - The label `File Content (base64)` is still visible even if the attachment type is URL. **Specifications:** - Hide label `File Content (base64)` when attachment type is URL. task-4778138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209210
Original PR description
**Purpose:** - The label `File Content (base64)` is still visible even if the attachment type is URL. **Specifications:** - Hide label `File Content (base64)` when attachment type is URL. task-4778138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209210
The outdated page watcher checks whether bus notifications were missed when the bus reconnects after an unexpected disconnection. To do so, it checks if the last known notification id is still in the bus table. When the bus disconnects, the last notification id is saved. However, disconnect event is not correctly sent when switching from online to offline. This commit fixes this issue. follow up of https://github.com/odoo/odoo/pull/208625 backport of https://github.com/odoo/odoo/pull/20947
Original PR description
The outdated page watcher checks whether bus notifications were missed when the bus reconnects after an unexpected disconnection. To do so, it checks if the last known notification id is still in the bus table. When the bus disconnects, the last notification id is saved. However, disconnect event is not correctly sent when switching from online to offline. This commit fixes this issue. follow up of https://github.com/odoo/odoo/pull/208625 backport of https://github.com/odoo/odoo/pull/209472 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#209609
Versions -------- - 16.0+ Steps ----- 1. Have multiple companies; 2. create an eWallet program available to all companies; 3. set its email template to "Gift Card: Gift Card Information"; 4. create & confirm an order containing the "Top-up eWallet" product; 5. switch to a different company; 6. create an new order for the same client. Issue ----- Access Error Cause ----- Commit eaa6f6c5a415f added the `_get_mail_author` method to ensure gift card emails always have an author
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have multiple companies; 2. create an eWallet program available to all companies; 3. set its email template to "Gift Card: Gift Card Information"; 4. create &…
Versions -------- - 16.0+ Steps ----- 1. Have multiple companies; 2. create an eWallet program available to all companies; 3. set its email template to "Gift Card: Gift Card Information"; 4. create & confirm an order containing the "Top-up eWallet" product; 5. switch to a different company; 6. create an new order for the same client. Issue ----- Access Error Cause ----- Commit eaa6f6c5a415f added the `_get_mail_author` method to ensure gift card emails always have an author. When using the gift card template for eWallets, this can cause an issue for 2 reasons: 1. When creating an eWallet via the top-up product, its `order_id` is the order that created the eWallet. This order may belong to a different company than the one it is getting used for. 2. The `send_reward_coupon_mail` method fetches its coupons by calling `_get_reward_coupons` on the order. This returns any applied eWallets, therefore calling `_send_creation_communication` whenever the eWallet gets used. The reason it returns applied eWallets as a "reward coupon" is because `_update_programs_and_rewards` creates `sale.order.coupon.points` records with 0 points when applying a `loyalty.card`, which then get assumed to be a reward, despite not granting any points: https://github.com/odoo/odoo/blob/9e22dbb7b6fb581d2f11bf0ec48b230047686050/addons/sale_loyalty/models/sale_order.py#L499-L504 Solution -------- 1. In the `_get_mail_author` yield to `super` if the order's company isn't in `self.env.companies`. 2. In the `_get_points_programs` and `_get_reward_coupons` methods, filter out `coupon_point_ids` that don't grant any points. (Alternatively, we could avoid creating `sale.order.coupon.points` records with 0 points, but this might be risky for stable.) opw-4731588 Forward-Port-Of: odoo/odoo#209515 Forward-Port-Of: odoo/odoo#208637
In the case where the name of the related partner is changed, the bank account holder name will not reflect the changes, we add here a dependency on partner_id.name Forward-Port-Of: odoo/odoo#209436
Original PR description
In the case where the name of the related partner is changed, the bank account holder name will not reflect the changes, we add here a dependency on partner_id.name Forward-Port-Of: odoo/odoo#209436
### Steps to reproduce: - Install "l10n_din5008" - In Settings > Layout, select DIN5008 as the report and change the two possible colors - Create a quotation, print it - The address is colored ### Cause This [commit](https://github.com/odoo/odoo/commit/92e4c3cb3bec0b3d5537a50fd441a22fa6509ed1) reduced the size of the address by replacing `div` with `span` which is applied `font-size: 0.8em;`. But also `color: $o-default-report-secondary-color;` ([see](https://github.com/odoo/odoo/blob/
Original PR description
### Steps to reproduce: - Install "l10n_din5008" - In Settings > Layout, select DIN5008 as the report and change the two possible colors - Create a quotation, print it - The address is colored ###…
### Steps to reproduce: - Install "l10n_din5008" - In Settings > Layout, select DIN5008 as the report and change the two possible colors - Create a quotation, print it - The address is colored ### Cause This [commit](https://github.com/odoo/odoo/commit/92e4c3cb3bec0b3d5537a50fd441a22fa6509ed1) reduced the size of the address by replacing `div` with `span` which is applied `font-size: 0.8em;`. But also `color: $o-default-report-secondary-color;` ([see](https://github.com/odoo/odoo/blob/d3e43681fd2b989ae7272731662cc3ac6a6d913b/addons/l10n_din5008/static/src/scss/report_din5008.scss#L47-L50)). ### Solution Don't use `span` in the CSS to select the text. Instead we create a new class `colored_address` to apply the color and apply the same font size on the entire address block. This way the addresses will always have the same font size and the color should only be applied where we want it to. Before:  After:  Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4725169) opw-4725169 Forward-Port-Of: odoo/odoo#209020
This commit adds an `await animationFrame()` in a reference field test. This makes the first assertion relevant, as it wasn't before (the view could never be there instantly). It also makes the test more robust as it could sometimes fail for the second assertions (race condition), see https://runbot.odoo.com/runbot/build/80157085 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the
Original PR description
This commit adds an `await animationFrame()` in a reference field test. This makes the first assertion relevant, as it wasn't before (the view could never be there instantly). It also makes the test more robust as it could sometimes fail for the second assertions (race condition), see https://runbot.odoo.com/runbot/build/80157085 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#209474
- It's not auto-exported (for now...) - It was out of date - We forgot to include the industry modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
- It's not auto-exported (for now...) - It was out of date - We forgot to include the industry modules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Steps to reproduce the bug: - Enable multi-steps route - Set a remove destination location (e.g., WH/stock/shelf1) on the repair operation type. - Create a new route: - name: Push route - Rule: - Action: push to - Operation type: internal transfer - Source location: WH/stock/shelf1 - Destination location: WH/stock/shelf2 - Create a storable product “P1”: - Update the Qty to one unit in WH/stock - Create a sotrable product “C1”: - Route: select the
Original PR description
Steps to reproduce the bug: - Enable multi-steps route - Set a remove destination location (e.g., WH/stock/shelf1) on the repair operation type. - Create a new route: - name: Push route - Rule: -…
Steps to reproduce the bug:
- Enable multi-steps route
- Set a remove destination location (e.g., WH/stock/shelf1) on the repair operation type.
- Create a new route:
- name: Push route
- Rule:
- Action: push to
- Operation type: internal transfer - Source location: WH/stock/shelf1 - Destination location: WH/stock/shelf2
- Create a storable product “P1”:
- Update the Qty to one unit in WH/stock
- Create a sotrable product “C1”:
- Route: select the new created route → “Push route”
- Create a repair order:
- Customer: Azure interior
- Product: P1
- part:
- Remove one unit of C1
- Confirm the repair
- Start the repair
- End the repair
Problem:
The move of “C1” is duplicated and added to the repair
When a push rule triggers an internal transfer for a component removed during a repair, the newly created stock move wrongly inherits the "repair_id" from the original move.
This happens because the "repair_id" field was not excluded from being copied, resulting in the duplicated move being incorrectly linked to the repair order.
https://github.com/odoo/odoo/blob/11e69870db1c49d9a6af79ffd263e4e162b34b6b/addons/stock/models/stock_move.py#L1854-L1855
https://github.com/odoo/odoo/blob/11e69870db1c49d9a6af79ffd263e4e162b34b6b/addons/stock/models/stock_move.py#L968-L969 https://github.com/odoo/odoo/blob/11e69870db1c49d9a6af79ffd263e4e162b34b6b/addons/stock/models/stock_rule.py#L212
https://github.com/odoo/odoo/blob/11e69870db1c49d9a6af79ffd263e4e162b34b6b/addons/stock/models/stock_rule.py#L240
Solution:
By setting copy=False on the repair_id field, we prevent this unintended propagation.
opw-4689206
Forward-Port-Of: odoo/odoo#208653We don't need to create values when the uuid is NULL. Otherwise we get a long running upgrade for no reason. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209647
Original PR description
We don't need to create values when the uuid is NULL. Otherwise we get a long running upgrade for no reason. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209647
The live chat uses a shadow DOM to preserve its styles. However, shopify hides empty block. Since the live chat root only contains the shadow DOM, it is considered empty which leads to the chat bubble not being displayed. This commit fixes the issue by explicitly setting the "display" style on the live chat root. opw-4768389 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CL
Original PR description
The live chat uses a shadow DOM to preserve its styles. However, shopify hides empty block. Since the live chat root only contains the shadow DOM, it is considered empty which leads to the chat bubble not being displayed. This commit fixes the issue by explicitly setting the "display" style on the live chat root. opw-4768389 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#209592
Issue: ------------ The width of the "Upload and Set" button did not adjust based on its text, resulting in the text being clipped. Fix: ----------- This commit enables automatic width adjustment for the "Upload and Set" button to ensure both the button and its text are fully visible on the same line. Steps to Reproduce (mobile view): ------------------ - Install the project module - Open the task Kanban view - Click on Set Cover Image task-3761269 Forward-P
Original PR description
Issue: ------------ The width of the "Upload and Set" button did not adjust based on its text, resulting in the text being clipped. Fix: ----------- This commit enables automatic width adjustment for the "Upload and Set" button to ensure both the button and its text are fully visible on the same line. Steps to Reproduce (mobile view): ------------------ - Install the project module - Open the task Kanban view - Click on Set Cover Image task-3761269 Forward-Port-Of: odoo/odoo#160913
Steps to reproduce: - Open a list view in which integer field having default value as false like ID field which has enable_formatting option as False. - Create a record Issue: - False is shown inside in integer field before saving. Reason: - When enable_formatting is False the value is returned and no checks are done. Fix: - A basic check to make sure we are sending out a number not a boolean. task-4700791 Forward-Port-Of: odoo/odoo#208262
Original PR description
Steps to reproduce: - Open a list view in which integer field having default value as false like ID field which has enable_formatting option as False. - Create a record Issue: - False is shown inside in integer field before saving. Reason: - When enable_formatting is False the value is returned and no checks are done. Fix: - A basic check to make sure we are sending out a number not a boolean. task-4700791 Forward-Port-Of: odoo/odoo#208262
During uninstall, fields (columns) bound to the module get deleted first, so the columns used for the search don't exist anymore and the search fails, which leads to the tables not being properly dropped, which can then lead to the module reinstallation not being clean e.g. because there are rows left in the table which can lead to constraints not being addable on install. This has been the cause of `resource` failing forever in the uninstall nightly test: it's most likely been failing since
Original PR description
During uninstall, fields (columns) bound to the module get deleted first, so the columns used for the search don't exist anymore and the search fails, which leads to the tables not being properly dropped, which can then lead to the module reinstallation not being clean e.g. because there are rows left in the table which can lead to constraints not being addable on install. This has been the cause of `resource` failing forever in the uninstall nightly test: it's most likely been failing since this hook was introduced. Forward-Port-Of: odoo/enterprise#85439
### Before this PR If the backorder is "always", on the shopfloor when clicking "close production" on the "production overview", it redirects to the backend ### After this PR Clicking on close production it does not redirect to backend Forward-Port-Of: odoo/enterprise#84739 Forward-Port-Of: odoo/enterprise#79918
Original PR description
### Before this PR If the backorder is "always", on the shopfloor when clicking "close production" on the "production overview", it redirects to the backend ### After this PR Clicking on close production it does not redirect to backend Forward-Port-Of: odoo/enterprise#84739 Forward-Port-Of: odoo/enterprise#79918
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been
Original PR description
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this…
### Steps to reproduce: - Create a recurring service (product) with invoicing policy set as 'Based on Timesheets' - Create a subscription using the created product - Create a task and link it to this subscription order - Timesheet 3 line in the task one in the past one on the same date of creation and one in the future. - Create an invoice for this order - Notice the quantity has been invoiced is the present timesheet line only - Notice that the 3 timesheet lines have all been validated ### Cause: This is happening because when trying to link the lines to the invoice we consider the timesheets within the date range that the user might have set in the create invoice wizard. https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/wizard/sale_make_invoice_advance.py#L33-L51 https://github.com/odoo/odoo/blob/9a4ec08b9a6b07470747923d09adcf51f7e4cd6a/addons/sale_timesheet/models/sale_order.py#L153 ### Fix: In subscription we can use the last and next invoice dates if the user hasn't set a period for the invoice. opw-4523727 Forward-Port-Of: odoo/enterprise#80582
Since f82f9ab7b0351d0c1239c4cafa772bea8c17c6ff, the unreconciled aml domain includes payable accounts, which leads to issue when processing followup. Since we need to get the total value including payable accounts, we add `account_id` to the group by, this way we can conditionnally set the computed values regarding the type of account, but also get the total due/overdue amounts, by adding two computed fields. Steps to reproduce new issue: - create a vendor bill for Demo (Joel Willis), with du
Original PR description
Since f82f9ab7b0351d0c1239c4cafa772bea8c17c6ff, the unreconciled aml domain includes payable accounts, which leads to issue when processing followup. Since we need to get the total value including payable accounts, we add `account_id` to the group by, this way we can conditionnally set the computed values regarding the type of account, but also get the total due/overdue amounts, by adding two computed fields. Steps to reproduce new issue: - create a vendor bill for Demo (Joel Willis), with due date 15 days ago - confirm the bill, print the PDF and attach it to the bill (as if we received it from the vendor) - now open the follow-up wizard from the partner form, and notice that the Vendor bill is attached opw-4664402 Forward-Port-Of: odoo/enterprise#85296
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the plan used in the analytic distribution in "Analytic" group option **Issue:** In the "End Balance" column, all the amounts are summed in the total colu
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic…
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the plan used in the analytic distribution in "Analytic" group option **Issue:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic plan. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. This is a complement to previous fix for the grouping by analytic account where the analytic plan groupby case was forgotten: https://github.com/odoo/enterprise/commit/05bbab713c749b7d7450d5dbaf2eda1ba4f68712 **Note:** From saas-18.1, there is no issue. Just forwarding the test. opw-4648009 Forward-Port-Of: odoo/enterprise#85344
Fixed the following issues in the SLSP reports: - When filters "Including Partners Without TIN" and "Including Importations" are updated, the lines are not refreshed - When the filters above are updated, the name of the current active filters are not refreshed - When "Including Partners Without TIN" is enabled, the grand total does not consider lines from those partners - When exported, amounts from the previous row are carried forward to the current row, if the current row has no
Original PR description
Fixed the following issues in the SLSP reports: - When filters "Including Partners Without TIN" and "Including Importations" are updated, the lines are not refreshed - When the filters above are updated, the name of the current active filters are not refreshed - When "Including Partners Without TIN" is enabled, the grand total does not consider lines from those partners - When exported, amounts from the previous row are carried forward to the current row, if the current row has no value for that amount 4748216 Forward-Port-Of: odoo/enterprise#85249
### Before this PR Try to do a receipt with a product, then a full discount of this product. You can't do a receipt with 0.0 as the amount because it is missing printRecTotal ### After this PR: You can do receipt with an amount of 0.0 This PR depends from odoo/enterprise#80951 (i can't create draft PR, but when that PR will be merged i will rebase) Forward-Port-Of: odoo/enterprise#81376
Original PR description
### Before this PR Try to do a receipt with a product, then a full discount of this product. You can't do a receipt with 0.0 as the amount because it is missing printRecTotal ### After this PR: You can do receipt with an amount of 0.0 This PR depends from odoo/enterprise#80951 (i can't create draft PR, but when that PR will be merged i will rebase) Forward-Port-Of: odoo/enterprise#81376