Thursday, January 23, 2025
19 changes · saas-17.2
Miscellaneous changes
- 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
There are currently some elements in views that are not reachable on a deterministic way when those views are inherited. That means, to reach them, positional selectors need to be used (e.g. `last()`). That causes inherited views to get broken when there are small changes in element position. A good example of this is [1]: <div class="digital-stamp"> <span>Extra Info</span> </div> Which can't be filtered by: - Class, because there are several `<div>` elements with the
Original PR description
There are currently some elements in views that are not reachable on a deterministic way when those views are inherited. That means, to reach them, positional selectors need to be used (e.g. `last()`). That causes inherited views to get broken when there are small changes in element position.
A good example of this is [1]:
<div class="digital-stamp">
<span>Extra Info</span>
</div>
Which can't be filtered by:
- Class, because there are several `<div>` elements with the same class
- Text content, because when content is translated, selector will fail
To solve the above, this change provides names for several elements, to make possible/easier to reach them on a safely manner.
[1] https://github.com/odoo/enterprise/blob/d6346ef8/l10n_mx_edi/views/l10n_mx_edi_report_invoice.xml#L123
Forward-Port-Of: odoo/enterprise#65180
Forward-Port-Of: odoo/enterprise#63957# 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
**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
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
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
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
To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194605 Forward-Port-Of: odoo/odoo#192104
Original PR description
To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194605 Forward-Port-Of: odoo/odoo#192104
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#194718 Forward-Port-Of: odoo/odoo#190944
**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
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#194705
Forward-Port-Of: odoo/odoo#194141Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform. Authentication: the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFa
Original PR description
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform. This commit implements a way to gather all…
Romania requires its companies to send information of all transports of goods on Romanian territory to a specific web service on their eTransport platform.
This commit implements a way to gather all the necessary data needed to send the eTransport document and the actual sending of this document to the eTransport platform.
Authentication:
the authentication needed to interact with the eTransport platform is the same as (and was already implemented in) the l10n_ro_efactura module. see [eFactura PR](https://github.com/odoo/odoo/pull/144061)
eTransport flow:
- Add the necessary eTransport data to a delivery
- send the eTransport document to ANAF
- the document gets processed by ANAF
- Fetch the status of the document:
- which can result in an error, in which case the flow starts again from the beginning with the corrected data
- or in a success
task-id: 3810735
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#170080Issue: When using the kiosk in versions 17.0 & 17.2, 2 visual issues arise: - when trying to identify manually, the "Go back" arrow is cropped out of its' container - when identified, the user's profile picture is cropped out of the greeting container Steps to reproduce: - Install the attendance module - Go to Kiosk Mode - Identify Manually Cause: For the "Go back arrow", its' position in the container is set to the top left corner (absolute 0;0). The problem is that these coordinat
Original PR description
Issue: When using the kiosk in versions 17.0 & 17.2, 2 visual issues arise: - when trying to identify manually, the "Go back" arrow is cropped out of its' container - when identified, the user's profile picture is cropped out of the greeting container Steps to reproduce: - Install the attendance module - Go to Kiosk Mode - Identify Manually Cause: For the "Go back arrow", its' position in the container is set to the top left corner (absolute 0;0). The problem is that these coordinates are set for the center of the button and not its' top-left end. For the profile pictures, there is some V16 styling still present that wrongly sets the image's absolute position. Notes: I also changed the back button on the PIN screen since it had the same problem. It isn't pretty but everything is visible now...  Ticket: opw-4366047 Forward-Port-Of: odoo/odoo#191234
Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192702 Forward-Port-Of: odoo/odoo#177592
**Problem**: When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - A
Original PR description
**Problem**: When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - An empty `<p>` remains, and the selection is in the editor root. opw-4472173 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193396
### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behav
Original PR description
### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behavior after PR is merged: The routes are now evaluated based on their sequence, ensuring that rules associated with routes of lower sequence are considered first. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @ForgeFlow Forward-Port-Of: odoo/odoo#188846
Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192561 For
Original PR description
Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192561 Forward-Port-Of: odoo/odoo#177659
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, wh
Original PR description
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, which is used to create new partners with the correct email associated with the res.user login. opw-4378487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193495
### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the is
Original PR description
### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for…
### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the issue: Changing the lot on the MO form will trigger the `_onchange_producing` which will in turn `_set_qty_producing`: https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L797-L799 In case the product is tracked by SN this `_set_qty_producing` will set a qty_producing of 1 and the move raws will reserve a quantity accordingly but if the product is tracked by lot or not tracked at all the quantities of the move raw will just be adapted to match the `qty_producing` (that was at 0 from the start): https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L1217-L1227 opw-4418809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192932