Thursday, May 15, 2025
37 changes · saas-18.2
Enhancements to existing features
Inventory movement lines now determine their related stock quantity record automatically instead of relying on it being manually stored. This improves consistency in stock operations and reduces the chance of mismatched inventory data behind the scenes.
Original PR description
Make quant_id computed
Resolved issues and error corrections
This update fixes unstable automated checks for accounting reports that could fail depending on which accounting features were installed. It helps keep nightly validation reliable without changing customer-facing report behavior.
Original PR description
This commit fix some tests in account_reports which were failing in nightly on the runbot, see error 134654. First test fails because an account number sequence was changing depending on if the accountant module was installed or not. Fix the test by replacing the hardcoded account name by the used bank journal name. Second test fails because of payment_state computation which is different depending on if the accountant module was installed or not. Fix it by using the _get_invoice_in_payment_state method instead of hardcoded value. no task
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
The XML format used to cancel invoices for freelancers in Bizkaia was invalid. Steps to reproduce: - Configure a freelance company with Bizkaia as tax agency - Create and send an invoice to TicketBAI - Cancel it using "TicketBAI Cancel" - You get an error: "Invalid content was found starting with element 'Renta'. One of '(AnulacionTicketBai)' is expected." This fix follows the official Bizkaia documentation: https://www.batuz.eus/fitxategiak/batuz/lroe/Batuz_LROE_Especificaciones_Env%C
Original PR description
The XML format used to cancel invoices for freelancers in Bizkaia was invalid. Steps to reproduce: - Configure a freelance company with Bizkaia as tax agency - Create and send an invoice to TicketBAI - Cancel it using "TicketBAI Cancel" - You get an error: "Invalid content was found starting with element 'Renta'. One of '(AnulacionTicketBai)' is expected." This fix follows the official Bizkaia documentation: https://www.batuz.eus/fitxategiak/batuz/lroe/Batuz_LROE_Especificaciones_Env%C3%ADo_Masivo_V1_0_7.pdf (see page 30) and the example provided here: https://www.batuz.eus/fitxategiak/batuz/LROE/ejemplos/Ejemplo_Anulacion_1_LROE_PF_140_IngresosConFacturaConSG_79732487C.xml opw-4634677 Forward-Port-Of: odoo/odoo#209392
Problem: In a scrollable editable, the floating toolbar may overflow and appear on top of fixed elements like headers. Solution: Detect overflow relative to the scrollable container and hide the toolbar when it is no longer fully visible. Before:  After:  Steps to reproduce: 1. Open the TODO app. 2.
Original PR description
Problem: In a scrollable editable, the floating toolbar may overflow and appear on top of fixed elements like headers. Solution: Detect overflow relative to the scrollable container and hide the toolbar when it is no longer fully visible. Before:  After:  Steps to reproduce: 1. Open the TODO app. 2. Add enough content to make the editable scrollable. 3. Open the floating toolbar on the first element. 4. Scroll down. → The toolbar overlaps with the page header. opw-4770575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208401
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (
Original PR description
After more discussion and consideration, this error is considered to have relatively low value and furthermore to possibly be triggered by the chrome shutdown itself e.g. `Page.stopLoading` is documented as > Force the page stop all navigations and pending resource fetches. so that can be the source of "failed to fetch" errors, maybe (didn't actually test it). Note that this is hooked to `_result.done()` aka `not _result.running()`, so there is a window where the issue can still occur (at least as a result of `stopLoading`) while we're waiting for service workers to shut down as well as pending responses. If this is still an issue, we may want to add a separate flag and set it right before or after the `Page.stopLoading` call. Hides runbot errors 54858, 55676, 109214, 109473, 110840, 134469, 162284, 162340, 193182, 198562, and 199232 Forward-Port-Of: odoo/odoo#209902
Problem: In Firefox, typing the backtick character "`" can cause it to be automatically deleted. Cause: Typing "`" initiates a composition session. If the selection is changed while `isComposing` is true, Firefox cancels the session and deletes the character. Solution: In `InlineCodePlugin.onInput`, the selection is now modified only when the `<code>` tag is applied. This intentional change ends the composition safely. In all other cases, we avoid changing the selection during compositi
Original PR description
Problem: In Firefox, typing the backtick character "`" can cause it to be automatically deleted. Cause: Typing "`" initiates a composition session. If the selection is changed while `isComposing` is true, Firefox cancels the session and deletes the character. Solution: In `InlineCodePlugin.onInput`, the selection is now modified only when the `<code>` tag is applied. This intentional change ends the composition safely. In all other cases, we avoid changing the selection during composition to preserve user input. Steps to reproduce: 1. Open the HTML editor in Firefox. 2. Type "`". → The character disappears unexpectedly. opw-4760478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208255
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
Original PR description
Because an exception raised by the `_unlink_forbid_parts_of_chain` method when attempting to delete journal entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190019
During the rendering of email marketing templates, links will be automatically shortened to aliases, which also enable tracking on the links' activity. However, since some links are generated by Odoo, these are protected (blacklisted) from being shortened during the email generation process. Since that blacklist is keyword-based, some external pages are also affected by this (notably Google Docs' forms, whose URL contains "/viewform", matching keyword /view. Steps to reproduce: - Creat
Original PR description
During the rendering of email marketing templates, links will be automatically shortened to aliases, which also enable tracking on the links' activity. However, since some links are generated by Odoo, these are protected (blacklisted) from being shortened during the email generation process. Since that blacklist is keyword-based, some external pages are also affected by this (notably Google Docs' forms, whose URL contains "/viewform", matching keyword /view. Steps to reproduce: - Create a new mass mailing - Add a link to a Google Docs form, and a link to a Wikipedia page - Send the mass mailing - On the received email: The link to Wikipedia is shortened, the Google Docs form link is not To reduce the number of false positives, this commit makes it so that blacklist elements need to be followed by a path symbol ( / # ? or link termination) to be counted as positives. task-4196321 Forward-Port-Of: odoo/odoo#201060 Forward-Port-Of: odoo/odoo#190819
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 gu
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 Forward-Port-Of: odoo/odoo#209933
Scenario: in mobile, edit the link of the category back button Result: the link is changed, but it is overriden by t-att-href so will not be taken into account. Fix: add o_not_editable on parent to prevent editing this part, this prevent to change style but there is no simple way to prevent editing only the link and there is no information that there is a "t-att-href". opw-4725198 Forward-Port-Of: odoo/odoo#209500
Original PR description
Scenario: in mobile, edit the link of the category back button Result: the link is changed, but it is overriden by t-att-href so will not be taken into account. Fix: add o_not_editable on parent to prevent editing this part, this prevent to change style but there is no simple way to prevent editing only the link and there is no information that there is a "t-att-href". opw-4725198 Forward-Port-Of: odoo/odoo#209500
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#209870 Forward-Port-Of: odoo/odoo#188848
How to reproduce: – Revert fix: odoo/odoo#206361 which fix archived activities not being deleted when their related record are – Install project and log as admin – In Settings -> Activity Type -> To-Do -> check “Keep Done” – In Project -> Office Design -> Energy Certificate -> Schedule an activity To-Do for “Marc Demo” (it must be another user) – Mark it as done – Delete the task (cog menu) – Click on the clock on the top right – And then on “View all activities” – Remove all filters –
Original PR description
How to reproduce: – Revert fix: odoo/odoo#206361 which fix archived activities not being deleted when their related record are – Install project and log as admin – In Settings -> Activity Type ->…
How to reproduce: – Revert fix: odoo/odoo#206361 which fix archived activities not being deleted when their related record are – Install project and log as admin – In Settings -> Activity Type -> To-Do -> check “Keep Done” – In Project -> Office Design -> Energy Certificate -> Schedule an activity To-Do for “Marc Demo” (it must be another user) – Mark it as done – Delete the task (cog menu) – Click on the clock on the top right – And then on “View all activities” – Remove all filters – Add filter “Done” You get a “Missing Record” error: “Record does not exist or has been deleted.” The error happens on allowed_ids[res_model] = set(records._filtered_access(operation)._ids) because records contains the deleted task. Note that this line is bypassed for activities of the current user, that’s why it is important to assign the test activity to another user. We solve the problem by restraining the records to the existing one (using .exists on the recordset). Note that in v17, there is no problem because _filter_access_rules (with check_access_right) was used instead of _filtered_access. We've considered to clean the records as they were detected in the mail_activity _search method but that was not straightforward as it is usually executed with a readonly transaction (web_search_read) and there is any way already an upgrade script which suppress all orphan activities: https://github.com/odoo/upgrade/pull/6952. Technical note: the test doesn't reproduce exactly the problem (no exception) but we check that the records are filtered as explained above. Task-4730338 Forward-Port-Of: odoo/odoo#209115
Description of the issue/feature this PR addresses: Adding 2 new accounts that addresses newly enacted law for cash payment rounding. [Legal doc (only in Lithuanian)](https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/5d1b9590e33711ef8cdff2c320e69444?jfwid=m8xvfl87c) approving chart of account with the new added accounts. [Legal doc](https://www.e-tar.lt/portal/lt/legalAct/9926c840f1be11ee9f5b8ffa077f9188) approving the cash rounding itself. As a bonus I added translations for the new accounts
Original PR description
Description of the issue/feature this PR addresses: Adding 2 new accounts that addresses newly enacted law for cash payment rounding. [Legal doc (only in Lithuanian)](https://e-seimas.lrs.lt/portal/legalAct/lt/TAD/5d1b9590e33711ef8cdff2c320e69444?jfwid=m8xvfl87c) approving chart of account with the new added accounts. [Legal doc](https://www.e-tar.lt/portal/lt/legalAct/9926c840f1be11ee9f5b8ffa077f9188) approving the cash rounding itself. As a bonus I added translations for the new accounts, but unsure if I should have done that, let me know if I should remove them. [MORE INFO ABOUT IT ALL](https://www.lb.lt/en/rounding-of-cash-payments) Current behavior before PR: No `5009` and `6319` accounts Desired behavior after PR is merged: Accounts `5009` and `6319` present --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209096 Forward-Port-Of: odoo/odoo#208306
PR odoo/odoo#170012 modified the application of Pension Fund taxes to invoice lines. After the PR, only lines with: `.//AltriDatiGestionale/TipoDato[contains(text(), 'AswCassPre')]` and the correct kind in the `.//AltriDatiGestionale/RiferimentoTesto` tag, got their Pension Fund tax applied. `AswCassPre` is an additional tag belonging to a "best practice" standard agreement from [AssoSoftware](https://www.assosoftware.it/servizi-offerti/standard-fe-e-protocollo-dintesa/). These may be best p
Original PR description
PR odoo/odoo#170012 modified the application of Pension Fund taxes to invoice lines. After the PR, only lines with: `.//AltriDatiGestionale/TipoDato[contains(text(), 'AswCassPre')]` and the correct…
PR odoo/odoo#170012 modified the application of Pension Fund taxes to invoice lines. After the PR, only lines with: `.//AltriDatiGestionale/TipoDato[contains(text(), 'AswCassPre')]` and the correct kind in the `.//AltriDatiGestionale/RiferimentoTesto` tag, got their Pension Fund tax applied. `AswCassPre` is an additional tag belonging to a "best practice" standard agreement from [AssoSoftware](https://www.assosoftware.it/servizi-offerti/standard-fe-e-protocollo-dintesa/). These may be best practices, but they're not at all mandatory for using the SdI, so it happens that invoices do not follow these additional specifications. For everyone else, the Pension Fund tax must be applied on all lines where `.//DatiGeneraliDocumento/DatiCassaPrevidenziale/AliquotaIVA` tag matches the VAT tax of the line. This PR adds code that tells one case from the other. Task [link](https://www.odoo.com/odoo/project/967/tasks/4381089) task-4381089 Forward-Port-Of: odoo/odoo#209601 Forward-Port-Of: odoo/odoo#207853
### 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#205782 Forward-Port-Of: odoo/odoo#205029
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the C
Original PR description
When the `odoo-enterprise/iot/x509` encounters an unexpected error, we still get an OK response but the result is empty and instead there is an error object returned. Before this commit, we never checked for this error object and so continued to process an empty result, causing a crash. After this commit, we check for these errors and log them, with a different message to distinguish them from the existing errors that we already check for. task-4793795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209949 Forward-Port-Of: odoo/odoo#209819
revert the commit as when we fetch archived warehouse's pos type it will raise error for other source or destination loction for newly created stock operation type like even functinally also there is no need to fetch archived warehouse's operation type. ``` quality Control cross Dock, Storage type ``` we got this error during upgrade : ``` File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute res = self._obj.execute(query, params) psycopg2.errors.NotNullVi
Original PR description
revert the commit as when we fetch archived warehouse's pos type it will raise error for other source or destination loction for newly created stock operation type like even functinally also there is…
revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like
even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL: Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```
due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files
so we need to avoid to fetch archived warehouse's picking type.
ref:
odoo/upgrade#6631
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#185244So it appears from the tour build error screenshot that the redirect doesn’t happen that fast, so we need to wait for it to happen before checking the next step, which is 'Edit'—which overrides it and edits the event details instead of the events list. So, we need to wait for the redirect to happen before checking the next step build_error-164184 referencing this commit : https://github.com/odoo/odoo/commit/b1e424bcd5e985b74496e409fb16c9529bbe848e  Forward-Port-Of: odoo/odoo#209631 Forward-Port-Of: odoo/odoo#208381
This PR adds the reset of: 1) screen orientation 2) browser_url 3) iot_handlers_etag when disconnecting a database This allows to switch between the different versions of the database more easily and avoid getting stuck with a non existent runbot db instance pos customer display for example Forward-Port-Of: odoo/odoo#209231 Forward-Port-Of: odoo/odoo#209112
Original PR description
This PR adds the reset of: 1) screen orientation 2) browser_url 3) iot_handlers_etag when disconnecting a database This allows to switch between the different versions of the database more easily and avoid getting stuck with a non existent runbot db instance pos customer display for example Forward-Port-Of: odoo/odoo#209231 Forward-Port-Of: odoo/odoo#209112
This commit adds steps to the favorite_management_tour to ensure the all steps are performed sequencially between first favorite save and applying a new groupBy. Runbot-112238 Forward-Port-Of: odoo/odoo#209013
Original PR description
This commit adds steps to the favorite_management_tour to ensure the all steps are performed sequencially between first favorite save and applying a new groupBy. Runbot-112238 Forward-Port-Of: odoo/odoo#209013
Show all customers wallets on search pos ### Impacted versions: 18.0 and later ### Steps to reproduce: Add more than one customer with same first characters of their name Add gift cards to them with positive balance Search them by clicking customer button on a pos session Video on runbot: https://drive.google.com/file/d/1kFAYjxWJmTNuNOK2ul684x_H_GAptsjB/view?usp=sharing ### Current behavior: Only shows the first wallet found (fetchCoupons default limit 1) ### Expected behav
Original PR description
Show all customers wallets on search pos ### Impacted versions: 18.0 and later ### Steps to reproduce: Add more than one customer with same first characters of their name Add gift cards to them with positive balance Search them by clicking customer button on a pos session Video on runbot: https://drive.google.com/file/d/1kFAYjxWJmTNuNOK2ul684x_H_GAptsjB/view?usp=sharing ### Current behavior: Only shows the first wallet found (fetchCoupons default limit 1) ### Expected behavior: Show all wallets Task: [4572808](https://www.odoo.com/odoo/project/49/tasks/4572808) Forward-Port-Of: odoo/odoo#199907
There was a typo in the history plugin, making an `if` statement useless. This fixes the typo. Backport of https://github.com/odoo/odoo/pull/186917/commits/0269326853abd35e988359e776632b47febf2e60. Forward-Port-Of: odoo/odoo#209946
Original PR description
There was a typo in the history plugin, making an `if` statement useless. This fixes the typo. Backport of https://github.com/odoo/odoo/pull/186917/commits/0269326853abd35e988359e776632b47febf2e60. Forward-Port-Of: odoo/odoo#209946
actual_lastcall was being false because it wasn't set in one case inside `add_lastcalls` method. This commit fixes this issue. Forward-Port-Of: odoo/odoo#209215
Original PR description
actual_lastcall was being false because it wasn't set in one case inside `add_lastcalls` method. This commit fixes this issue. Forward-Port-Of: odoo/odoo#209215
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
When the invoice can't be sent via Peppol, we are adding a footer in the Invoice email. We sent this regardless of the partner Peppol status. This PR narrows the cases when we sent the footer. Another issue is that "we recommend" Odoo, we are speaking in the name of our user. A better phrasing will make things fairer, such as this footer keeps its informative value, without being too pushy. task-4782004 Forward-Port-Of: odoo/odoo#209994 Forward-Port-Of: odoo/odoo#209432
Original PR description
When the invoice can't be sent via Peppol, we are adding a footer in the Invoice email. We sent this regardless of the partner Peppol status. This PR narrows the cases when we sent the footer. Another issue is that "we recommend" Odoo, we are speaking in the name of our user. A better phrasing will make things fairer, such as this footer keeps its informative value, without being too pushy. task-4782004 Forward-Port-Of: odoo/odoo#209994 Forward-Port-Of: odoo/odoo#209432
Forgotten in c632b843 / task 4491333. Task-4703626 Forward-Port-Of: odoo/enterprise#82907
Original PR description
Forgotten in c632b843 / task 4491333. Task-4703626 Forward-Port-Of: odoo/enterprise#82907
user_lang was missing as it was not set in the test setup, which caused an error in the setup because when creating a company it needed a user_lang to be set in this function `_create_dashboard_notes` build_error-161173 Forward-Port-Of: odoo/enterprise#84249
Original PR description
user_lang was missing as it was not set in the test setup, which caused an error in the setup because when creating a company it needed a user_lang to be set in this function `_create_dashboard_notes` build_error-161173 Forward-Port-Of: odoo/enterprise#84249
Before this commit, the test_automatic_invoice_token test would fail with the following traceback: FAIL: TestSubscriptionController.test_automatic_invoice_token Traceback (most recent call last): File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 157, in test_automatic_invoice_token subscription = self._portal_payment_controller_flow() ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/data/build/enterprise/s
Original PR description
Before this commit, the test_automatic_invoice_token test would fail with the following traceback: FAIL: TestSubscriptionController.test_automatic_invoice_token Traceback (most recent call last):…
Before this commit, the test_automatic_invoice_token test would fail
with the following traceback:
FAIL: TestSubscriptionController.test_automatic_invoice_token
Traceback (most recent call last):
File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 157, in test_automatic_invoice_token
subscription = self._portal_payment_controller_flow()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 235, in _portal_payment_controller_flow
self.assertEqual(subscription.invoice_ids.sorted('id').mapped('state'), ['posted'])
AssertionError: Lists differ: ['posted', 'posted'] != ['posted']
First list contains 1 additional elements.
First extra element 1:
'posted'
- ['posted', 'posted']
+ ['posted']
The issue was detected when the test was running on the last day of the
month.
When we were not on the last day of the month, in the controller /my/subscriptions/<int:order_id>/transaction
invoice_to_pay was None because there was only once invoice already paid.
As a result, amount_to_invoice was 0.0 in this code:
amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
a tx with an amount equal to 0 would be created in the controller and
in payment_transaction.py, during the postprocess, a "partially paid tx" would be found as the amount would not match (2.3 and 0.0).
We prefer to fix the test by making sure an amount is set in the parameters of the controller. It will make the flow more coherent and realistic.
\# Explanation
When /my/subscriptions/<int:order_id>/transaction was called the second
time in the test, no amount kwarg was provided. As a result the
following line would be called in the controller:
amount_to_invoice = invoice_to_pay.amount_total if invoice_to_pay else order_sudo.amount_to_invoice
invoice_to_pay is always None and therefore the amount_to_invoice is
equal to order_sudo.amount_to_invoice
When we look,at _compute_amount_to_invoice, we have:
is_invoice_due = (
not order.last_invoice_date
or (order.next_invoice_date <= today and order.last_invoice_date <= today)
)
if not is_invoice_due:
line.amount_to_invoice = 0.0
continue
We will compare when the code run on the 30th of march or on the 31th of
march.
\## 30th of March
next invoice date is 2025-04-30
start date is 2025-03-30
last_invoice_date is 2025-03-30
next_invoice_date <= today is False
last_invoice_date <= today is True
is_invoice_due = (
not order.last_invoice_date
or (order.next_invoice_date <= today and order.last_invoice_date <= today)
)
Therefore is_invoice_due is False and we enter the condition and set the amount_to_invoice equal to 0.0
\## 31th of March
next invoice date is 2025-04-30
start date is 2025-03-31
last_invoice_date is False
next_invoice_date <= today is False (same)
last_invoice_date <= today is False because last_invoice_date is not set
Therefore, is_invoice_due is True and we set amount_to_invoice to the recurring total of the SO.
The issue is occuring because next invoice date is 2025-04-30 in both situations !
2025-03-30 + relativedelta(months=1) is equal to 2025-03-31 + relativedelta(months=1)
In the definition of last_invoice_date, we compare the next invoice date - billing_period to today:
last_date = order.next_invoice_date and order.plan_id.billing_period and order.next_invoice_date - order.plan_id.billing_period
\# When we start the 30th of March:
\# last_date = 30th of april - 1 month = 30th of march
\# When we start the 31th of March:
\# last_date keep the same value because the next_invoice_date is the
same.
start_date = order.start_date or fields.Date.today()
if order.state == 'sale' and last_date and last_date >= start_date:
order.last_invoice_date = last_date <-- 30th of March >= 30th of March (today when we start on the 30th
else:
order.last_invoice_date = False <-- 30th of March is not larger than 31th of March (today when we start on the 31th)
runbot error: 162144
Forward-Port-Of: odoo/enterprise#84542### 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#83333 Forward-Port-Of: odoo/enterprise#80582
The rental_cart_update_duration tour was failing due to a timeout while selecting for the .o_time_picker_select:eq(0) element. This change add a wait step was to ensure the rental options are fully loaded before proceeding. Avoiding flaky behavior caused by timing issues in the UI. build_error-161173 Forward-Port-Of: odoo/enterprise#85393
Original PR description
The rental_cart_update_duration tour was failing due to a timeout while selecting for the .o_time_picker_select:eq(0) element. This change add a wait step was to ensure the rental options are fully loaded before proceeding. Avoiding flaky behavior caused by timing issues in the UI. build_error-161173 Forward-Port-Of: odoo/enterprise#85393
Steps to reproduce - Install Accounting - Go to settings and activate Analytic Accounting - Go to Configuration and create two analytic plans without any analytic accounts - Go to the Profit and Loss report - Activate the two new analytic plans -> the report is messed up in its columns Cause of the issue: When two analytic plans without any analytic account are present, they have the exact same forced_options, leading to the same column_group_key. task-4675686 Forward-Po
Original PR description
Steps to reproduce - Install Accounting - Go to settings and activate Analytic Accounting - Go to Configuration and create two analytic plans without any analytic accounts - Go to the Profit and Loss report - Activate the two new analytic plans -> the report is messed up in its columns Cause of the issue: When two analytic plans without any analytic account are present, they have the exact same forced_options, leading to the same column_group_key. task-4675686 Forward-Port-Of: odoo/enterprise#82231
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#85371 Forward-Port-Of: odoo/enterprise#85296
When user quickly presses the ``Enter`` key multiple times to record a timesheet, A traceback will appear. Steps to reproduce the error: - Go to Timesheets > My Timesheets - Now, Quickly press the ``Enter`` key multiple times to record a timesheet Traceback: ``` ValueError: Expected singleton: timer.timer(1, 2) File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer timesheet.action_timer_start() File "home/odoo/
Original PR description
When user quickly presses the ``Enter`` key multiple times to record a timesheet, A traceback will appear. Steps to reproduce the error: - Go to Timesheets > My Timesheets - Now, Quickly press the…
When user quickly presses the ``Enter`` key multiple times to record a timesheet,
A traceback will appear.
Steps to reproduce the error:
- Go to Timesheets > My Timesheets
- Now, Quickly press the ``Enter`` key multiple times to record a timesheet
Traceback:
```
ValueError: Expected singleton: timer.timer(1, 2)
File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 433, in action_start_new_timesheet_timer
timesheet.action_timer_start()
File "home/odoo/src/enterprise/18.0/timesheet_grid/models/analytic.py", line 460, in action_timer_start
super().action_timer_start()
File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 86, in action_timer_start
self._stop_timer_in_progress()
File "home/odoo/src/enterprise/18.0/timer/models/timer_mixin.py", line 140, in _stop_timer_in_progress
model = self.env[timer.res_model].browse(timer.res_id)
File "odoo/fields.py", line 1228, in __get__
record.ensure_one()
File "odoo/models.py", line 6196, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/enterprise/blob/58348c5f9276e5cb4397f0f73d23b41f5a454868/timer/models/timer_mixin.py#L128-L131 When a user quickly presses the ``Enter`` key,
``timer`` will have multiple records,
So, It will lead to the above traceback.
sentry-6557099219
Forward-Port-Of: odoo/enterprise#73984- In the check report, the amount in numbers are now moved leftward so that it is closer to the beginning of the line 4720121 Forward-Port-Of: odoo/enterprise#85342
Original PR description
- In the check report, the amount in numbers are now moved leftward so that it is closer to the beginning of the line 4720121 Forward-Port-Of: odoo/enterprise#85342
…d not CLOC Before this commit, when approvals created action servers, there were part of the CLOC After this commit, they are not. opw-4784181 Forward-Port-Of: odoo/enterprise#85390
Original PR description
…d not CLOC Before this commit, when approvals created action servers, there were part of the CLOC After this commit, they are not. opw-4784181 Forward-Port-Of: odoo/enterprise#85390
Description of the issue this commit addresses: When multiple lines that are in budget on their own are above budget when summed together, neither the lines nor the budget button show that the budget will be exceeded. This leads to making purchase orders that shouldn't be made. --- Desired behavior after this commit is merged: This commit makes it so that when the lines together will exceed the budget, the budget smart button and all the lines become red as a single line would.
Original PR description
Description of the issue this commit addresses: When multiple lines that are in budget on their own are above budget when summed together, neither the lines nor the budget button show that the budget will be exceeded. This leads to making purchase orders that shouldn't be made. --- Desired behavior after this commit is merged: This commit makes it so that when the lines together will exceed the budget, the budget smart button and all the lines become red as a single line would. --- task-4710838 Forward-Port-Of: odoo/enterprise#84653