Thursday, January 23, 2025
50 changes · 18.0
Enhancements to existing features
CRM settings now include a link to Ringover, a partner browser extension for VoIP calling. This makes it easier for users to discover and set up calling integration from the most relevant app area.
Original PR description
We now partner with Ringover to provide VOIP capabilities using a browser extension for integration. We add a link to that extension in the "integrations". This is done in CRM because this is the most relevant app for VOIP usage. task-4488082
The Shopee sales module now includes its own app icon. This makes the module easier to recognize in Odoo and improves the visual consistency of the app list.
Original PR description
This commit introduces the app icon for the `sale_shopee` module. task-4492921
Resolved issues and error corrections
The scheduler now reports progress as it completes key background tasks for inventory, point of sale, and expiry alerts. This makes long-running automated maintenance easier to monitor and helps administrators understand whether scheduled work is moving forward.
Original PR description
This commit makes use of the ir.cron.progress feature in the stock scheduler. The first approach is to simply count how many tasks have been completely done among the 5 currently available
* stock
- trigger orderpoints
- merge quant & delete 0 quant
- reserve confirm stock move
* point_of_sale
- close session
* product_expiry
- make alerts on expired lots
They will be split in 5 different crons later to be able to count exactly the remaining records number to manage in each sub tasks.
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-prMiscellaneous changes
Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection periodically. In the case that a connection outlives the transaction wraparound[^2] mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain references to transactions that have already been deleted by the system's (or a manual) `VACUUM`[^3] as it has its own transaction validit
Original PR description
Adds a configuration that can be used to mitigate PostgreSQL transactional errors with long-living connections and the `LISTEN/NOTIFY`[^1] functionality by re-establishing the database connection…
Adds a configuration that can be used to mitigate PostgreSQL
transactional errors with long-living connections and the
`LISTEN/NOTIFY`[^1] functionality by re-establishing the database
connection periodically.
In the case that a connection outlives the transaction wraparound[^2]
mechanism of postgres, the `LISTEN/NOTIFY` internal queue might contain
references to transactions that have already been deleted by the
system's (or a manual) `VACUUM`[^3] as it has its own transaction
validity mechanisms (roughly comparing transaction ids).
This can be reproduced by:
- Triggering a wraparound _AND_ cleaning of pg_xact between the cron's
`LISTEN` + `COMMIT` and its recyling.
- Having done at least one `NOTIFY` during that time period (?).
- Try to `LISTEN` to the same channel on the same database (transcation
id must be < than the first connection's transaction id).
The following is an example error message:
```
ERROR database odoo.service.server: Worker (3194772) Exception occurred, exiting...
Traceback (most recent call last):
File "/home/user/odoo/service/server.py", line 1089, in run
self.start()
File "/home/user/odoo/service/server.py", line 1235, in start
self.dbcursor.commit()
File "/home/user/odoo/sql_db.py", line 480, in commit
result = self._cnx.commit()
^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedFile: could not access status of transaction 1194816979
DETAIL: Could not open file "pg_xact/0473": No such file or directory.
```
[LISTEN/NOTIFY code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c)
[Connection being kept](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L2167-L2191)
[See more](https://www.postgresql.org/message-id/flat/VE1PR03MB531295B1BDCFE422441B15FD92499%40VE1PR03MB5312.eurprd03.prod.outlook.com#7e36d1fdca921b5292e92c7017984ffa)
[^1]: https://www.postgresql.org/docs/current/sql-notify.html
[^2]: https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
[^3]: https://www.postgresql.org/docs/17/sql-vacuum.html
Forward-Port-Of: odoo/odoo#194822
Forward-Port-Of: odoo/odoo#194141Messages that start a sub-thread now keep their intended formatting when users open and participate in that thread for the first time. This prevents HTML formatting from appearing as plain text, improving readability in Mail discussions.
Original PR description
Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to…
Before this commit, when a user accesses a sub-thread of channel made from a message for the 1st time, the format of the message body shows html as textcontent rather as inner html. Steps to reproduce: - Post a message as user A - Create a thread from this message as user B - User A accesses this sub-thread and posts a new message -> User A sees 1st message with bad formatting This happens because on sub-thread join, the data of sub-thread info are fetched, and since the sub-thread is created from a message, the channel info data also contains the message data. This data was inserted without `html: true`, leading to message body being inserted in a non-trusted way in JS models, causing this formatting issue. This commit fixes the issue by flagging the insert with `html: true`, as this is from trusted origin and content is trusted, so the message body is inserted to be used properly in message component. Note that this behaviour applies to html fields, which message body is. The insert `html: true` is assessed for data on all targeted html fields. task-4506489
This fixes an issue in the Mail chatter where choosing a mention after replacing selected text could trigger an error. The editor now refreshes its selection correctly, making mention insertion more reliable for users composing messages.
Original PR description
**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls…
**Problem**: When typing `@` in a non-collapsed selection (`a[b]`) and selecting an item from the mention list, the selection state becomes stale. This happens because `handleObserverRecords` calls `updateHints`, which relies on `getSelectionData`. However, `this.activeSelection` retains the outdated selection due to conditions like `documentSelectionIsInEditable` and `!this.activeSelection.anchorNode.isConnected` being `false`. As a result, `this.activeSelection` reflects `a[b]` while the DOM selection has already updated to `a[]`, leading to invalid offsets. **Solution**: Call `this.dependencies.selection.focusEditable();` during `onSelect` to ensure the selection is updated to reflect the editor state rather than the mention state. **Steps to Reproduce**: 1. Open the chatter. 2. Add some text. 3. Select a portion of the text. 4. Type `@`. 5. Select an item (person) from the mention list. 6. Observe a traceback error. opw-4498165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Closing a Point of Sale session no longer incorrectly shows a warning that another user is closing it. This avoids unnecessary page reload prompts and makes the end-of-day closing flow smoother for store staff.
Original PR description
- The `login_number` can be a string so we need to use "==" to avoid unexpected behaviour. - This fix an issue where each time you close a PoS session a popup appears with the message "The session is being closed by another user. The page will be reloaded". This was caused by the comparison of a string and an integer. task-id: 4485659 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This corrects an upgrade script that was producing inconsistent view definitions when converting older tree views to list views. It helps ensure system upgrades apply cleanly and avoids malformed configuration in updated installations.
Original PR description
since the pr https://github.com/odoo/odoo/pull/189883, the file updates made are not consistent: 'list<editable="bottom">'.
This fixes an issue where employee logins in Point of Sale could trigger a console error after locking and re-entering a session from the payment screen. Cashiers can now resume the session more reliably without encountering that disruption.
Original PR description
Before this commit: - Enable the "Log in with employees" - Log in as any employee, add a product, and go to the payment screen - Lock the session - Enter the session again This sequence of actions would result in an error in the console. opw-4435559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where certain loyalty reward product rules could fail to load because the system read them in the wrong format. Loyalty promotions using true/false conditions should now work reliably in Point of Sale without triggering errors.
Original PR description
Before this commit, `domain['reward_product_domain']` was being evaluated with `ast.literal_eval` while containing JSON-style booleans (`true/false`). That caused a `ValueError` because `true/false` are invalid in Python syntax. With this commit, we now use `json.loads` to parse the domain string, which correctly handles JSON booleans without error. opw-4458627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how imported vendor bills are classified as manually edited, so users are only prompted to enable automatic posting when the system has correctly detected repeated unchanged bills. It also prevents localization-related background processing from incorrectly marking bills as edited, improving reliability for companies using Egyptian e-invoicing features.
Original PR description
In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he…
In b1046c8156ee3d3699d5b229720134cc3b2532d4, we introduced a new feature to allow autoposting of bills. When a user does not modify the imported bill for 3 consecutive times, we ask the user if he wants to activate the feature. To detect whether the user has modified the imported bill or not, we use a new field `is_manually_modified` which is always set to `True` when the bill is edited except for automatic flows (OCR, CRON, email). test_autopost_bills will fail when the l10n_eg_edi_eta module is installed. This is due to fact that calling import_facturx will end up calling _extend_with_attachments, which in turn changes the value of l10n_eg_eta_json_doc_id.raw which triggers the computes that depend on it. This is why we add the context key before calling _extend_with_attachments. Moreover, in the same function, a savepoint is created, triggering a flush that triggers the recomputes. A savepoint is created without the context, therefore we flush right before we create the savepoint. runbot-110629
[1] adds a settings entry in CRM for ringover As this was done in stable the .pot file should have been updated [1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859
Original PR description
[1] adds a settings entry in CRM for ringover As this was done in stable the .pot file should have been updated [1] f2a384dd3b8ac2d358a9d8ea3fcec577b3e86859
The Viva Wallet payment webhook is now correctly marked as able to update records. This prevents unnecessary warning messages in logs while keeping payment processing behavior unchanged.
Original PR description
Since #584a172, controller endpoints can specify `readonly=False` if they are expected to write to the DB. The webhook endpoint for Viva Wallet was previously not specified this way, which leads to a warning being logged. This commit simply adds `readonly=False` to the webhook endpoint to prevent the warning. task-4472274 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where opening the Gantt view for restaurant appointments could use the wrong underlying record type. This prevents potential loading errors and helps staff access appointment scheduling views reliably.
Original PR description
Before this commit, opening the calendar event Gantt view called the `calendar.event` model, but the `appointment.type` ID was passed. This mismatch could lead to an error when attempting to load the view. opw-4493685
This update adjusts an internal test so it matches how follow-up reporting works in version 18.0, where the partner ledger is used. It helps prevent false test failures while still checking that the right accounting lines are recovered.
Original PR description
The test breaks https://github.com/odoo/odoo/pull/184482 In 18.0, partner ledger is used for the followup. Keep the test as it still assess we recover the lines correctly.
This fixes a payroll accounting test setup issue that could appear when Belgian payroll was installed before Australian payroll. The change ensures contract creation uses the correct payroll structure information, making the test reliable across localization combinations.
The Executive Summary report now uses the correct revenue line when calculating net profit margin. This helps businesses see a more accurate profitability percentage after recent Profit and Loss report changes.
Original PR description
The REV line was introduced in 18.0 when revamping the P&L, here: https://github.com/odoo/enterprise/commit/cbe74884b937f630cf1d2ccf475a04e70b6f4669 Following this change, this line should be used in the formula of the Net profit margin of the Executive Summary, as stated here https://www.investopedia.com/terms/n/net_margin.asp
Saudi payroll bank details are now managed only from the relevant bank or bank account form, avoiding duplicate editing places. The settings page now warns users when required bank information is missing, helping prevent payroll configuration mistakes without blocking setup unnecessarily.
Original PR description
Task URL: https://www.odoo.com/odoo/project.task/4184694 Changes: - Remove fields l10n_sa_bank_account_id, l10n_sa_bank_establishment_code, & l10n_sa_sarie_code from res.config.settings so that it can only be edited in the bank/bank acc. form view. - Show warning if one of the fields (l10n_sa_bank_id, l10n_sa_bank_establishment_code, l10n_sa_sarie_code) is not set. - Adjust width for l10n_sa_bank_account_id
Accounting reports with period-based date selectors now handle jumps of more than 365 years correctly. This prevents incorrect dates when users navigate very far backward or forward in reports such as tax reports or profit and loss statements.
Original PR description
In accounting reports that use periods (like the tax report or profit and loss), the date selector is broken when you try to go back or forward for more than 365 years. The reason is that it was computing the resulting year by looping over the number of years to go back/forward, and each time adding or subtracting the number of years as days. When over 365, it would go back/forward more than 1 year per iteration. This commit fixes the issue. [task-4410887](https://www.odoo.com/odoo/project.task/4410887)
Steps to Reproduce: • Install the Time Off app. • Create a new user and corresponding employee without any group in Time Off. • Create a new time off request with a start date < today's date. • Attempt to change the date, which results in a validation error. Issue: - Users are unable to modify time off requests, even if they are not yet approved. Fix: - Added a check to ensure that modifications are allowed for time off requests that are not in an approved state. task-4236572
Original PR description
Steps to Reproduce: • Install the Time Off app. • Create a new user and corresponding employee without any group in Time Off. • Create a new time off request with a start date < today's date. • Attempt to change the date, which results in a validation error. Issue: - Users are unable to modify time off requests, even if they are not yet approved. Fix: - Added a check to ensure that modifications are allowed for time off requests that are not in an approved state. task-4236572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194747 Forward-Port-Of: odoo/odoo#190944
The name search on the account field (account.account on account move line) looks for frequently used accounts for the partner. When no search text is provided, the name search suggests accounts that were previously used. When there are no frequent accounts, the name search returns nothing. To reproduce - create a vendor bill - select a partner that has never been billed - add a line - click the account many2one field dropdown Since no account options are available, the dropdown flas
Original PR description
The name search on the account field (account.account on account move line) looks for frequently used accounts for the partner. When no search text is provided, the name search suggests accounts that were previously used. When there are no frequent accounts, the name search returns nothing. To reproduce - create a vendor bill - select a partner that has never been billed - add a line - click the account many2one field dropdown Since no account options are available, the dropdown flashes open and quickly disappears. Forward-Port-Of: odoo/odoo#193999
Current behavior before PR: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. Desired behavior after PR is merged: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started. task:4187739 Forward-Port-Of: odoo/odoo#191
Original PR description
Current behavior before PR: When multiple types of lists were selected and the deleteBackward operation was performed, the list type remained unchanged. Desired behavior after PR is merged: When deleteBackward is pressed with multiple types of lists selected, and all selected content is removed, if the anchor node's list item is empty, that list item type will change to match the type of the list where the deleteBackward operation started. task:4187739 Forward-Port-Of: odoo/odoo#191915 Forward-Port-Of: odoo/odoo#180687
This commit add few data on the report_invoice for Mauritius localization. task-4379202 Forward-Port-Of: odoo/odoo#190723
Original PR description
This commit add few data on the report_invoice for Mauritius localization. task-4379202 Forward-Port-Of: odoo/odoo#190723
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182986 Forward-Port-
Original PR description
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182986 Forward-Port-Of: odoo/odoo#178829
In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. The [previous fix] only solved one case. We make them translatable again here so they can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [previous fix]: https://github.com/odoo/odoo/commit/e7381c3a09014567a8bdb0802c6964cc35ffddd2 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of:
Original PR description
In the Tasks' and Tasks Analysis' chart and pivot views, some default measures were not translatable after [this commit]. The [previous fix] only solved one case. We make them translatable again here so they can be localized. [this commit]: https://github.com/odoo/odoo/commit/e82567f9d5842bd95fe01ba3b9f54a65437e313f [previous fix]: https://github.com/odoo/odoo/commit/e7381c3a09014567a8bdb0802c6964cc35ffddd2 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/odoo#193517
Before this commit: =================== - The purchase tour was failing because the tour's JavaScript used an incorrect class selector (targeting 'partner_id'), which prevented it from locating the intended DOM element. Consequently, the sequence of actions was interrupted, causing the tour to break midway. After this commit: =================== - The issue has been resolved by updating the tour to use the correct and unique class selector. This ensures the tour accurately tar
Original PR description
Before this commit: =================== - The purchase tour was failing because the tour's JavaScript used an incorrect class selector (targeting 'partner_id'), which prevented it from locating the intended DOM element. Consequently, the sequence of actions was interrupted, causing the tour to break midway. After this commit: =================== - The issue has been resolved by updating the tour to use the correct and unique class selector. This ensures the tour accurately targets the intended element, allowing it to proceed without interruptions. As a result, the purchase tour runs successfully and achieves its intended purpose. TaskId: 4268662 Forward-Port-Of: odoo/odoo#194681 Forward-Port-Of: odoo/odoo#184735
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quot
Original PR description
We update quote detection for gmail and outlook: - gmail has simple wrapper divs with explicit classes - outlook has a mix of div ids and simple pattern-based quoting (everything under "<hr><div id="divRplyFwdMsg"/> seems to be considered a quote) Previously gmail just used blockquote, which still works but does not capture "On xx:xx:xx X <X@gmail.com> wrote:" headers, which are caught for outlook. Previously outlook had a wrapper div around divRplyFwdMsg which would set data-o-mail-quote-container on it, and propagate to children. However it seems that outer div was either removed or is not always present, a heuristic is thus needed. task-4381505 Forward-Port-Of: odoo/odoo#194615 Forward-Port-Of: odoo/odoo#192875
Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one. This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecate
Original PR description
Peppol migration creates more issues than it solves. A lot of users issue migration requests to move to another SMP but later discover that the SMP they wanted to migrate to does not support migration keys. This creates a state that we need to handle manually. Most SMP do not support migrating away and force users to deregister and reregister again on another one. This commit adds a fix in stable for that issue by removing the button from the res_config_settings_buttons and adding a deprecated warning when the user tries to call the `button_migrate_peppol_registration` method. task-4394408 Forward-Port-Of: odoo/odoo#194171 Forward-Port-Of: odoo/odoo#193794
**Steps to reproduce:** 1) Select the QR Codes option in settings (IN Company) 2) Do not enter an upi id in the company profile. 3) Go to invoice and preview/print the invoice. 4) Show that QR code without upi id and upi logos visible. **Cause:** - The condition of the upi id is not properly set to hide the block if upi is not set. **Fix:** - With this PR, the upi QR code and upi logos will not be visible if the upi id is not set. **task**-4426634 Forward-Port-Of: odoo/odoo#19206
Original PR description
**Steps to reproduce:** 1) Select the QR Codes option in settings (IN Company) 2) Do not enter an upi id in the company profile. 3) Go to invoice and preview/print the invoice. 4) Show that QR code without upi id and upi logos visible. **Cause:** - The condition of the upi id is not properly set to hide the block if upi is not set. **Fix:** - With this PR, the upi QR code and upi logos will not be visible if the upi id is not set. **task**-4426634 Forward-Port-Of: odoo/odoo#192068
Previously, when some printers were connected to the PoS, the synchronisation of the order was slow because we were waiting for the response of each printer. Now we don't wait for the response of the printer, we just send the order to the printer and we continue the process. Forward-Port-Of: odoo/odoo#194690
Original PR description
Previously, when some printers were connected to the PoS, the synchronisation of the order was slow because we were waiting for the response of each printer. Now we don't wait for the response of the printer, we just send the order to the printer and we continue the process. Forward-Port-Of: odoo/odoo#194690
Our "supported" method filtering detected printers had a condition introduced in v17 which was too strict and filtering out the STAR printers, so they were never detected anymore. This PR fixes this issue related PR: #174436 Forward-Port-Of: odoo/odoo#190367
Original PR description
Our "supported" method filtering detected printers had a condition introduced in v17 which was too strict and filtering out the STAR printers, so they were never detected anymore. This PR fixes this issue related PR: #174436 Forward-Port-Of: odoo/odoo#190367
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#193732 Forward-Port-Of: odoo/odoo#192208
Original PR description
When a product has a fixed tax, there should be a separate downpayment line for the fixed tax amount. Steps to reproduce: ------------------- * Create a fixed tax of 1€ * Assign this tax to any product * Create a sale order with this product * Open PoS and make a downpayment of 10% > Observation: There is only one downpayment line with the total amount of the product and the fixed tax combined. opw-4252104 Forward-Port-Of: odoo/odoo#193732 Forward-Port-Of: odoo/odoo#192208
### Issue: The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically: The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the si
Original PR description
### Issue: The current descriptions and naming of the `Date` fields (`date_begin`, `date_end`) and the `Timezone` field (`date_tz`) can be confusing in the form view of the event model. Specifically: The timezone used for converting the form dates to the database is determined by the context and not by the `Timezone` field present on the form. However, this `Timezone` field determines the timezone used for displaying the event's date/time on the website. This change tries to clarify the situation. opw-4323142 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193587 Forward-Port-Of: odoo/odoo#190867
-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead 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:
Original PR description
-This commit remove custom properties 'nodestroy' to avoid warning like this: `odoo.addons.web.controllers.utils: Action 'Customer Invoice' contains custom properties 'nodestroy'`. Passing them via the `params` or `context` properties is recommended instead 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#161814
Description of the issue/feature this PR addresses: Current behavior before PR: The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed. Desired behavior after PR is merged: The "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 --- I confirm I have si
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: The "Old unit price" text in the POS products screen is not showing properly when the l10n_fr_pos_cert is installed. Desired behavior after PR is merged: The "Old unit price" text will be showing up properly using simular code to what is on https://github.com/odoo/odoo/blob/a0ab0ce39bf4cba5e90eae109bcd006b39e31c6c/addons/l10n_fr_pos_cert/static/src/xml/OrderReceipt.xml#L14 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184840
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo
Original PR description
After merging of this PR [1], video tab will not be visible in media dialog in report as `allowCommandVideo` is false. But this will override `noVideos` option from `params` to false if `allowCommandVideo` is true and video tab will be visible even if `noVideos` is `true`. This PR makes sure that `noVideos` property from `params` should be checked if `allowCommandVideo` is true. [1]: 187251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192838
This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/odoo#194343
Original PR description
This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/odoo#194343
The Issue: Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest. The Fix: To resolve this, we ensure the function selects the correct website by explicitly passing it in the context. runbot-64729 Forward-Port-Of: odoo/odoo#189705
Original PR description
The Issue: Prior to this commit, invoking _get_frontend resulted in the get_current_website function returning a different website than the one specified in the MockRequest. The Fix: To resolve this, we ensure the function selects the correct website by explicitly passing it in the context. runbot-64729 Forward-Port-Of: odoo/odoo#189705
Steps to reproduce: - Add a "Call To Action" block on the homepage > Save it as a custom snippet. - Add a new page > Drop the saved custom block on it > Drop Also another "Title" block. - Translate the custom block in the new page > At this point, the translation is fine. - Go to "Edit" mode > Edit the other block ("Title") > Save. - The translations for the custom "Call To Action" is lost. Starting from [1], the translation of custom snippets was supported and when dropping a save
Original PR description
Steps to reproduce: - Add a "Call To Action" block on the homepage > Save it as a custom snippet. - Add a new page > Drop the saved custom block on it > Drop Also another "Title" block. - Translate…
Steps to reproduce:
- Add a "Call To Action" block on the homepage > Save it as a custom
snippet.
- Add a new page > Drop the saved custom block on it > Drop Also
another "Title" block.
- Translate the custom block in the new page > At this point, the
translation is fine.
- Go to "Edit" mode > Edit the other block ("Title") > Save.
- The translations for the custom "Call To Action" is lost.
Starting from [1], the translation of custom snippets was supported and
when dropping a saved custom snippet in a page/view, the snippet will
copy its translation from the saved view (see:
`_copy_custom_snippet_translations()`). This code will always update the
terms in the translation dictionary, even when the page has its custom
translation for them.
The goal of this commit is to fix this behavior by only allowing the
update of a term translation when the page has no custom translation
for it.
[1]: https://github.com/odoo/odoo/commit/d3426b7714012e833caae10281cfb8433223299a
opw-3930862
opw-4141290
Forward-Port-Of: odoo/odoo#194234
Forward-Port-Of: odoo/odoo#177960Tour bubble points to every New button in kanban. Fixed it to only point at New button in crm lead kanban view. Task-4377574 Forward-Port-Of: odoo/odoo#190937
Original PR description
Tour bubble points to every New button in kanban. Fixed it to only point at New button in crm lead kanban view. Task-4377574 Forward-Port-Of: odoo/odoo#190937
Steps to reproduce: - Go in time off app -> overview - Search on name Issue: When searching on name, the search does not work. This is due to the name being computed and not stored. Directly related to the [recent changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214) Fix The field has now a search method on the different component of the name separetly. opw-4351362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forwa
Original PR description
Steps to reproduce: - Go in time off app -> overview - Search on name Issue: When searching on name, the search does not work. This is due to the name being computed and not stored. Directly related to the [recent changes](https://github.com/odoo/odoo/commit/7a65a1b6ac34f214) Fix The field has now a search method on the different component of the name separetly. opw-4351362 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188433
Scenario: - have non IBAN bank account for an employee - generate payment slips - create for payment slip a Payment Report of type CSV => An error is raised because the employee doesn't have a valid IBAN bank account Issue: We verify in all cases that the employee accounts are valid IBAN, but we should only check if they are IBAN if this is a SEPA report. Fix: Move the code to only do it in case we are generating a SEPA report. Note: without the fix, the added tests fail
Original PR description
Scenario: - have non IBAN bank account for an employee - generate payment slips - create for payment slip a Payment Report of type CSV => An error is raised because the employee doesn't have a valid IBAN bank account Issue: We verify in all cases that the employee accounts are valid IBAN, but we should only check if they are IBAN if this is a SEPA report. Fix: Move the code to only do it in case we are generating a SEPA report. Note: without the fix, the added tests fails with: > UserError: Invalid IBAN for the following employees: John when generating the CSV payment report. opw-[4371726](https://www.odoo.com/web#id=4371726&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#76230
The uninstallation of this test module, which is a standard step during upgrades, requires the removal of the test product `product_fire_insurance`. This product is referenced by sale orders and invoices and deferred invoices created dynamically and have no xmlids, blocking the removal of the record. This commits adds the xmlids to the dynamically created orders and moves so they can be removed as well during the module uninstallation. The target sale orders are those created via 'copy' and whe
Original PR description
The uninstallation of this test module, which is a standard step during upgrades, requires the removal of the test product `product_fire_insurance`. This product is referenced by sale orders and invoices and deferred invoices created dynamically and have no xmlids, blocking the removal of the record. This commits adds the xmlids to the dynamically created orders and moves so they can be removed as well during the module uninstallation. The target sale orders are those created via 'copy' and when doing upsell and renew for subscriptions. The target moves are the regular invoices for the sale orders and their deferred moves. Forward-Port-Of: odoo/enterprise#77587 Forward-Port-Of: odoo/enterprise#76813
- add `alert alert-warning` as classes instead of adding style color to unify the warning visual Task: 4432816 Forward-Port-Of: odoo/enterprise#77596 Forward-Port-Of: odoo/enterprise#77161
Original PR description
- add `alert alert-warning` as classes instead of adding style color to unify the warning visual Task: 4432816 Forward-Port-Of: odoo/enterprise#77596 Forward-Port-Of: odoo/enterprise#77161
# Issue Account Manager permission is required to access the payment journal. # Expected In previous and later versions of Odoo this permission was given by ‘account.group_account_user’. # FIX This PR removes XPATH because original groups of the [Base View](https://github.com/odoo/odoo/blob/16.0/addons/account/views/account_payment_view.xml#L234) are capable to see Journal Entries/Items. Removing `account.group_account_readonly` via account_accountant module inheritance is unnecessary
Original PR description
# Issue Account Manager permission is required to access the payment journal. # Expected In previous and later versions of Odoo this permission was given by ‘account.group_account_user’. # FIX This…
# Issue Account Manager permission is required to access the payment journal. # Expected In previous and later versions of Odoo this permission was given by ‘account.group_account_user’. # FIX This PR removes XPATH because original groups of the [Base View](https://github.com/odoo/odoo/blob/16.0/addons/account/views/account_payment_view.xml#L234) are capable to see Journal Entries/Items. Removing `account.group_account_readonly` via account_accountant module inheritance is unnecessary and it's more restrictive. If some restriction wants to be applied, should be done in Base View. # Additional Context/Explanation This PR was done 3 months ago https://github.com/odoo/enterprise/commit/06e95b281dc000e5f3904b6051fe81afe8db3989 on v18, but the XPATH overrides the original group removing the `account.group_account_readonly`, which has enough permissions to see Journal Entries (even with a Menu Item). Reasoned with @hupo-odoo on https://github.com/odoo/enterprise/pull/76802#issuecomment-2586509116 that we need to get rid of the xpath instead of backport the functionality. ## Explaining briefly involved groups: - `account.group_account_invoice`: You can see payments (with menu) and invoices, but you can't see journal entries on a menu. - `account.group_account_readonly`: You can see Journal Entries/Items menu and Payments. - `account.group_account_user`: Inherits from `account.group_account_readonly`. - `account.group_account_manager`: Inherits from `account.group_account_user`. # Available Forward Ports ## v17: account_accountant xpath: https://github.com/odoo/enterprise/blame/17.0/account_accountant/views/account_payment_views.xml#L8-L10 base view: https://github.com/odoo/odoo/blob/17.0/addons/account/views/account_payment_view.xml#L242 ## v18 account_accountant xpath: https://github.com/odoo/enterprise/blame/18.0/account_accountant/views/account_payment_views.xml#L8-L10 base view: https://github.com/odoo/odoo/blob/18.0/addons/account/views/account_payment_view.xml#L232 --- MT-8088 @moduon @edlopen @hupo-odoo @yajo @rafaelbn please review if you want :) OPW-4465140 Forward-Port-Of: odoo/enterprise#77129
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount
Original PR description
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: -------------------…
Currently, simple pos users can see the due amount of the customers, unless the customer wasn't loaded and we need to search for a customer that isn't loaded. Steps to reproduce: ------------------- * Create a new customer, make a sale order and invoice it. This will set an amount due for that customer * Connect to the shop with a user that has the `point_of_sale.group_pos_user` but not the `account.group_account_readonly` group * Open customer list > Observation: You can see the amount due for multiple customers * Search for the customer created * Select search more > You can't see the amount due for that customer Why the fix: ------------ Since simple pos users are allowed to see the amount due for the loaded customer, there is no reason they shouldn't see it as well for a customer they need to load. Commit allowing simple pos users to see (and settle) customer accounts: https://github.com/odoo/enterprise/commit/37fa4d5f4ed7c7d77f73395a53b7b3ab7006afc4 When loading the pos session `_loader_params_res_partner` is called first and later is called `_get_pos_ui_res_partner`. It is in the function `_get_pos_ui_res_partner` that the amount due is compted if the user does not belong to the group `account.group_account_readonly`. https://github.com/odoo/enterprise/blob/a35a4755cdf86bcfeda0aca6c06397748ba27362/pos_settle_due/models/pos_session.py#L22-L28 However when we load a customer that wasn't previously loaded, only `_loader_params_res_partner` is loaded. And since the users does not belong to the group `account.group_account_readonly`, the field witll not get loaded. We now compute the amount due with the same logic as in `_get_pos_ui_res_partner`. opw-4141955 Forward-Port-Of: odoo/enterprise#77247 Forward-Port-Of: odoo/enterprise#73671
The tool tip is being replaced with a more concise message. task-4437887 Forward-Port-Of: odoo/enterprise#77436 Forward-Port-Of: odoo/enterprise#76474
Original PR description
The tool tip is being replaced with a more concise message. task-4437887 Forward-Port-Of: odoo/enterprise#77436 Forward-Port-Of: odoo/enterprise#76474
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Management / Asset Models" - Create an asset model **Issue:** Upon save, the following UserError is raised: "You cannot add or remove bills when the asset is already running or closed." **Cause:** A check has been added to prevent adding bills to a running asset. The check is excluding draft assets but not asset models that are assets in "model" state. **Issue:** Exclude asset models from the chec
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Management / Asset Models" - Create an asset model **Issue:** Upon save, the following UserError is raised: "You cannot add or remove bills when the asset is already running or closed." **Cause:** A check has been added to prevent adding bills to a running asset. The check is excluding draft assets but not asset models that are assets in "model" state. **Issue:** Exclude asset models from the check. opw-4479698 Forward-Port-Of: odoo/enterprise#77472
This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/enterprise#77416
Original PR description
This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/enterprise#77416
Before this commit, created moves were not done in batch making the amount of queries go up uselessly. This commit makes that creation in batch and adapts the query counters in tests. task-4299915 Forward-Port-Of: odoo/enterprise#77287 Forward-Port-Of: odoo/enterprise#73145
Original PR description
Before this commit, created moves were not done in batch making the amount of queries go up uselessly. This commit makes that creation in batch and adapts the query counters in tests. task-4299915 Forward-Port-Of: odoo/enterprise#77287 Forward-Port-Of: odoo/enterprise#73145