Thursday, May 8, 2025
52 changes · saas-18.3
Enhancements to existing features
Live chat session searches now include a filter for conversations that are still ongoing. This helps teams quickly find active customer chats and focus on sessions that may still need attention.
Original PR description
This commit adds a filter for ongoing livechats in the session search task-4776141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unused live chat code that was no longer serving a working purpose and reorganizes related developer files. It has no expected direct impact on users, but helps keep the live chat feature easier to maintain and less prone to future issues.
Original PR description
The `visitorPartner` field was introduced in #141904, which apparently never worked, and the usage is removed in #142010. Also, the typescript related to thread model should be moved to the same folder as this model.
This change removes an internal search index that was not helping VoIP contact lookup performance. It simplifies database maintenance without changing how users work with contacts or VoIP features.
Original PR description
The trigram index on res.partner/t9_name is not useful. The "t9 encoding" reduces the set of possible trigrams far too much for the trigram to be effective in discriminating between large amounts of results. In consideration of the above, this commit removes the trigram index.
The bank reconciliation widget now includes the new description field when setting an account. This gives accounting users more context during reconciliation and helps make account selections easier to understand.
Original PR description
This commit will add the newly introduce field description in this commit: https://github.com/odoo/odoo/pull/205191/commits/61c0ce904a6b32773b55a2e9e123b5c79c0d42b7 in the set account of the bank rec widget task: 4750045
Bank reconciliation can now automatically expand a specific statement line when it is opened from the right context. This helps users get directly to the relevant details with less manual clicking during reconciliation work.
Original PR description
This commit will unfold the statement line depending on a context key task: 4749346
Resolved issues and error corrections
This fixes an automated test for restaurant point of sale order synchronization so it waits for orders to be ready before adding another water item. The change helps avoid false test failures and supports more reliable quality checks for the restaurant POS flow.
Original PR description
The error in the loop appears during the assertion in the last step. ProductScreen.clickLine("Water", 3) is missing.
Before the fix:
After creating the new order with 2 waters and 2 cokes, it clicks directly on clickDisplayedProduct("Water"), which creates an new orderline with only 1 water. So there are 4 lines, not 3... => Error
After the fix:
We wait for the 2 orders to be created and then
clickDisplayedProduct("Water"), which adds a water to the existing line.
runbot-error-id~190618
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
**Problem:** When clicking the button Purchase Matching, in a Vendor Bill, if the vendor is an individual but has a company, the bill will not appear below the Purchase Orders. If the vendor is an individual without a company, the Purchase Matching button will display everything like it should. **Steps to reproduce:** - Make a Purchase Order, the vendor has to be an individual with a company. - Create a bill for the same product and vendor. - Use the Purchase Matching button on the bi
Original PR description
**Problem:** When clicking the button Purchase Matching, in a Vendor Bill, if the vendor is an individual but has a company, the bill will not appear below the Purchase Orders. If the vendor is an…
**Problem:** When clicking the button Purchase Matching, in a Vendor Bill, if the vendor is an individual but has a company, the bill will not appear below the Purchase Orders. If the vendor is an individual without a company, the Purchase Matching button will display everything like it should. **Steps to reproduce:** - Make a Purchase Order, the vendor has to be an individual with a company. - Create a bill for the same product and vendor. - Use the Purchase Matching button on the bill. - The bill is not displayed, but the Purchase Orders are. **Cause of the issue:** https://github.com/odoo/odoo/blob/cc9e7cb92f1a6237a496b9acabd93506a8724a62/addons/purchase/models/account_invoice.py#L143-L144 The partner_id for the Purchase Orders are the current individual vendor, but we are trying to match it with the partner_id of an Account Move Line, which is set to be the commercial partner of the individual, meaning the company, as seen below. https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L481-L483 On the matching table, we use the partner of the Account Move Line, and this is the why filtering on the individual doesn't give any result, if we wanted some we would need to filter on the company. https://github.com/odoo/odoo/blob/45533a1c6a70a3b86cf744a0f950c92d8a99afcf/addons/purchase/models/purchase_bill_line_match.py#L109 **Fix:** The domain was updated to take both the individual and the commercial partner (the company). This ensures that the bill will be found even in we are dealing with an individual that is in a company. opw-4577643 Forward-Port-Of: odoo/odoo#208595 Forward-Port-Of: odoo/odoo#202012
This update fixes a wording issue in the CRM forecast kanban view and restores an automated tour test that verifies the forecast workflow. It helps keep the sales pipeline interface clear for users while ensuring future changes are checked reliably.
Original PR description
The test test_03_crm_tour_forecast has been deactivated in the recent commit 55cccddeb12a2096730e4fadc84c52fa838b1aec It can be restored with a simple fix, being an explicit call to run "click", which is the expected behavior now, since starting from a recent commit, click is not performed by default, but a check of the element existence is performed instead. Said commit is 84feb3035ff3e829d6602a5d3544d64c673358fb Also, the kanban quick create design has changed in recent commit 566824d0fe5764a434bb2b4f899ef864ed6cc56d Small label / selector changes are applied to make the test succeed now, and to prevent the current column label 'Add add next month'. Task-4756945
The Live Chat sessions screen now uses an updated helper action when there are no records to show. This makes the empty-state experience more accurate and helps users take the right next step when reviewing chat sessions.
Original PR description
Purpose of this commit: Update the sessions empty record action helper task-4775661
The chat window now shows a smaller online status indicator so the user avatar remains clear and the header no longer feels crowded. This improves the visual clarity of chat conversations without changing how messaging works.
Original PR description
Before this commit, the size of im status in chat window was too big, making the avatar hard to see and also it overlaps with the bottom of chat window header. This comes from avatar being small, and the IM status is using the default `md` size, which makes it too big. This commit fixes the issue by using `sm` size for better size. The position of IM status as been adjusted as a consequence, and also the around master + "..." typing status have been adjusted to take into account the smaller version of IM status.
This fixes an issue where live chat could fail to initialize when visitor location detection identified a country. The change helps ensure chat rules are evaluated correctly so eligible website visitors can access live chat as expected.
Original PR description
Livechat initialization checks if any rule matches on the page based on the country detected by geoip if any. The "_match" method expects an id, not a recordset which lead to an error when initializating the page. This commit fixes the issue. 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
The Social app demo mode now points to the correct image files, so demo content loads as expected during setup. The needed sample images are also included directly to reduce the risk of future missing-file issues.
Original PR description
How to reproduce: 1. Run the localhost with the `--with-demo` flag. 2. Install the `Social` Module. 3. Now, from the CONFIGURATION > click SETTINGS > check ENABLE DEMO MODE. Issue: - You will see that the demo data is not loaded. Reason: - There is a recent PR (https://github.com/odoo/odoo/pull/206246) which removed the file we are trying to access. Fix: - We update the file path. Task-4765000
This fix updates an automated barcode manufacturing test so it no longer fails unpredictably during validation runs. It helps keep development checks reliable and reduces delays caused by false build failures.
Original PR description
The test `test_barcode_production_create_bom` sometime fails. This commit modifies its tour to avoid random fails. runbot build error: [190620](https://runbot.odoo.com/odoo/runbot.build.error/190620)
Steps to reproduce =================== Create a database with website_slides installed only. Go to Website > Courses > Create or choose a course > Course Page > Add Content Technical ========== Earlier, we were using the ```.data()``` function of jQuery, which parses the string by default. During our recent interaction conversion https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba we started using the ```.dataset``` of JavaScript, which gives the data in the stri
Original PR description
Steps to reproduce =================== Create a database with website_slides installed only. Go to Website > Courses > Create or choose a course > Course Page > Add Content Technical ========== Earlier, we were using the ```.data()``` function of jQuery, which parses the string by default. During our recent interaction conversion https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba we started using the ```.dataset``` of JavaScript, which gives the data in the string form itself. This commit addresses the issue and now we need to parse string data. Task-4735297 Forward-Port-Of: odoo/odoo#206573
Steps to reproduce: - With an AE Company - Enable Multicurrency (USD) - Create an invoice in USD with total 0.00 - Print Issue: Traceback will raise """ odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2] Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision"
Original PR description
Steps to reproduce:
- With an AE Company
- Enable Multicurrency (USD)
- Create an invoice in USD with total 0.00
- Print
Issue: Traceback will raise
"""
odoo.addons.base.models.ir_qweb.QWebException: Error while render the template ZeroDivisionError: float division by zero
Template: account.document_tax_totals_company_currency_template Path: /t/div/table/tr[1]/td[2]
Node: <td class="text-end" t-out="exchange_rate" t-options="{"widget": "float", "precision": 5}"/>
"""
opw-4724401
Forward-Port-Of: odoo/odoo#208396Before this commit, the top corner of a message bubble next to author avatar was always non-rounded, including squashed messages. This non-rounded part represent the arrow of the bubble, to show visually that this user has spoken. This is nice for non-squashed messages, i.e. messages next to avatar and header containing info like user name. For squashed messages, however, they are not next to an avatar, because this is the same as the parented oldest message with same author. The non-round
Original PR description
Before this commit, the top corner of a message bubble next to author avatar was always non-rounded, including squashed messages. This non-rounded part represent the arrow of the bubble, to show visually that this user has spoken. This is nice for non-squashed messages, i.e. messages next to avatar and header containing info like user name. For squashed messages, however, they are not next to an avatar, because this is the same as the parented oldest message with same author. The non-rounded corner can help for direction between self and others messages, but even there color of bubble is good enough, and since these are squashed messages it's easy to deduce the alignment of message. This non-rounded corner doesn't look good on squashed messages, so this commit fixes the issue by making squashed messages fully rounded, without this non-rounded corner. Forward-Port-Of: odoo/odoo#208655
Before this commit, message author avatars had a size of 38px. This made them so big, to other avatars of 32px, which made them too distracting compared to message content. This commit fixes the issue by reducing them to 32px, matching their size to other avatars, giving a better balance with the message bubbles. Some other related changes were made: - Message and composer sidebar width have been reduced. - Discuss app header avatar has its size matched to the new reduced size of message
Original PR description
Before this commit, message author avatars had a size of 38px. This made them so big, to other avatars of 32px, which made them too distracting compared to message content. This commit fixes the issue by reducing them to 32px, matching their size to other avatars, giving a better balance with the message bubbles. Some other related changes were made: - Message and composer sidebar width have been reduced. - Discuss app header avatar has its size matched to the new reduced size of message avatar its start padding has been adjusted to align with avatar in conversation - Avatar size and sidebars have also been slightly reduced in chat window again to give more room for message content Forward-Port-Of: odoo/odoo#208494
When a user is on leave, the DM chat shows header on top with "Back on X". Before this commit, the alert was far too big and has lots of bottom margin. This commit makes the alert much smaller similarly to the "1 unread mark as read" top banner. Forward-Port-Of: odoo/odoo#208881
Original PR description
When a user is on leave, the DM chat shows header on top with "Back on X". Before this commit, the alert was far too big and has lots of bottom margin. This commit makes the alert much smaller similarly to the "1 unread mark as read" top banner. Forward-Port-Of: odoo/odoo#208881
Purpose ======= Fix the confirmation request popup which is displayed after each question in a live session. Specification ============= In a live session answers cannot be edited after each question so every time an attendee submit an answer the form is considered as finished. This triggers the confirmation popup everytime. The confirmation popup is only relevant outside of live sessions to prevent the user doing a certification with only 1 attempt to mistakenly end the survey. Also i
Original PR description
Purpose ======= Fix the confirmation request popup which is displayed after each question in a live session. Specification ============= In a live session answers cannot be edited after each question so every time an attendee submit an answer the form is considered as finished. This triggers the confirmation popup everytime. The confirmation popup is only relevant outside of live sessions to prevent the user doing a certification with only 1 attempt to mistakenly end the survey. Also in live sessions the survey flow is handled by the host and not the attendees. => Removing the confirmation popup for live sessions related: odoo/odoo#176612 Task-4743653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207183
Writing the account code is restricted on l10n_de accounts. Odoo checks that the code we write is different from the old one, and if so it checks of there are already some entries for that accounts. If any of the condition is met, the write is prevented. When we try to map an account from another company to a l10n_de company, the _inverse_code function from the account mapping will try and update the account code in the other company, as the code is company dependent. The issue is that we
Original PR description
Writing the account code is restricted on l10n_de accounts. Odoo checks that the code we write is different from the old one, and if so it checks of there are already some entries for that accounts. If any of the condition is met, the write is prevented. When we try to map an account from another company to a l10n_de company, the _inverse_code function from the account mapping will try and update the account code in the other company, as the code is company dependent. The issue is that we check that the l10n_de code remains the same, even if we are in another, non l10n_de company. This PR adapts the check to l10n_de account to only check the code if we are writing it from the l10n_de company. opw-4711417 Forward-Port-Of: odoo/odoo#208538
Before this commit, when adding an event ticket in a French company to an order, the strikethrough "Old unit price" was displayed even though the price had not been manually modified. After this commit, the "Old unit price" is only displayed when the event price is manually modified. Steps to reproduce: - Install pos_event and l10n_fr_pos_cert - Create a French company - Create a new event - Open the POS - Add the event ticket to the order - The old unit price is displayed opw-476
Original PR description
Before this commit, when adding an event ticket in a French company to an order, the strikethrough "Old unit price" was displayed even though the price had not been manually modified. After this commit, the "Old unit price" is only displayed when the event price is manually modified. Steps to reproduce: - Install pos_event and l10n_fr_pos_cert - Create a French company - Create a new event - Open the POS - Add the event ticket to the order - The old unit price is displayed opw-4761498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208566
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imply that the transaction is not finalized. **Fix:** Hide 'Sign' button after signature va
Original PR description
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imply that the transaction is not finalized. **Fix:** Hide 'Sign' button after signature validation using the `is_signed` field value. This prevents users from signing multiple time the same delivery document. opw-4700124 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208314 Forward-Port-Of: odoo/odoo#206111
<b>Steps to reproduce:</b> 1. Go to Sales > Create New Quotation. 2. Add a customer and a product(e.g., "Acoustic Bloc Screens testingggggggggg"). 3. Go to POS > Open any register. 4. Navigate to Actions > Quotation/Order, select SO. 5. Apply a down payment percentage. 6. Enter the percentage, select Payment > Cash, and validate the payment. 7. Navigate Print full receipt. <b>Issue:</b> Unintended scrolling behavior in the order line section. <b>Cause:</b> Although the container
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create New Quotation. 2. Add a customer and a product(e.g., "Acoustic Bloc Screens testingggggggggg"). 3. Go to POS > Open any register. 4. Navigate to Actions > Quotation/Order, select SO. 5. Apply a down payment percentage. 6. Enter the percentage, select Payment > Cash, and validate the payment. 7. Navigate Print full receipt. <b>Issue:</b> Unintended scrolling behavior in the order line section. <b>Cause:</b> Although the container had the class overflow-y-auto, it wasn't the root cause. The issue occurred with long product names in certain configurations, leading to unintended scrolling behavior. <b>Solution:</b> Added the product-name class to handle content display and prevent unnecessary scrolling. opw-4479286 Forward-Port-Of: odoo/odoo#205659
**Description** - In Saas 18.2, the '[website_url](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_partner/models/res_partner.py#L14)' field in the res.partner is a computed field. However, when a new contact is created via the form view, as the field does not have dependencies so it won’t be automatically calculated. From odoo/odoo@40e0216, computed fields without dependencies are now computed during onchange() instead of returning an initial False value. During the creation proc
Original PR description
**Description** - In Saas 18.2, the '[website_url](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_partner/models/res_partner.py#L14)' field in the res.partner is a computed field.…
**Description**
- In Saas 18.2, the '[website_url](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_partner/models/res_partner.py#L14)' field in the res.partner is a computed field. However, when a new contact is created via the form view, as the field does not have dependencies so it won’t be automatically calculated. From odoo/odoo@40e0216, computed fields without dependencies are now computed during onchange() instead of returning an initial False value. During the creation process, especially within onchange triggers [here](https://github.com/odoo/odoo/commit/40e0216656a6bffaff5b36e413aff23603cc8e72) , while creating a new contact, this can lead to an error if the computation tries to perform a slug operation on a record that hasn’t been saved yet.
- This PR ensures that it gets properly computed by ensuring via condition to avoid performing a slug on a not yet saved record in case of an onchange.
**Steps to Reproduce:(V18.2)**
1. Install the 'website_partner', 'contacts' application in saas-18.2
2. Add 'website_url' field in form view of res.partner
3. Try to create new record in contacts[res.partner].
Reference commits - odoo/odoo@40e0216 , [odoo/odoo@7ba64a8](https://github.com/odoo/odoo/commit/7ba64a8c51f2888b301ee6feae140b02ca4b1b95#diff-4c7613a9ea8e1131502ede128b264e908fd6b074bf886ac475fc73833c8a71a8L16-R19)
similar example for other model livechat - [V18.0](https://github.com/odoo/odoo/blob/18.0/addons/website_livechat/models/im_livechat.py#L13 ), [V18.2](https://github.com/odoo/odoo/blob/saas-18.2/addons/website_livechat/models/im_livechat.py#L16)
**Traceback -**
```
File "/home/odoo/src/odoo/saas-18.2/addons/web/models/models.py", line 1559, in onchange
snapshot1 = RecordSnapshot(record, fields_spec)
File "/home/odoo/src/odoo/saas-18.2/addons/web/models/models.py", line 1645, in __init__
self.fetch(name)
File "/home/odoo/src/odoo/saas-18.2/addons/web/models/models.py", line 1660, in fetch
self[field_name] = self.record[field_name]
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 6349, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1437, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 1603, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-18.2/addons/mail/models/mail_thread.py", line 474, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/models.py", line 4570, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-18.2/odoo/orm/fields.py", line 69, in determine
return needle(*args)
File "/home/odoo/src/odoo/saas-18.2/addons/website_partner/models/res_partner.py", line 18, in _compute_website_url
partner.website_url = "/partners/%s" % self.env['ir.http']._slug(partner)
File "/home/odoo/src/odoo/saas-18.2/addons/website/models/ir_http.py", line 76, in _slug
return super()._slug(value)
File "/home/odoo/src/odoo/saas-18.2/addons/http_routing/models/ir_http.py", line 62, in _slug
raise ValueError("Cannot slug non-existent record %s" % value)
ValueError: Cannot slug non-existent record res.partner(<NewId 0x7466e37336c0>,)
```
opw - [4709146](https://www.odoo.com/odoo/project/70/tasks/4709146)
upg - [2724009](https://upgrade.odoo.com/web#id=2724009&cids=1&menu_id=107&action=150&model=upgrade.request&view_type=form)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206780Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order
Original PR description
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order when the ticket has been sold through the PoS. opw-4584390 Forward-Port-Of: odoo/odoo#208197 Forward-Port-Of: odoo/odoo#204514
MyDATA is a platform created by Greece's tax authority, The Independent Authority for Public Revenue (IAPR), to digitize business tax and accounting information declaration. All companies performing accounting, according to Greek accounting standards, will be required to transmit the information to the myDATA platform beginning in July of 2021. - Customer Invoices Customer Invoice form for Greece companies will now have a few fields required for specifying classification data to be send to
Original PR description
MyDATA is a platform created by Greece's tax authority, The Independent Authority for Public Revenue (IAPR), to digitize business tax and accounting information declaration. All companies performing…
MyDATA is a platform created by Greece's tax authority, The Independent Authority for Public Revenue (IAPR), to digitize business tax and accounting information declaration. All companies performing accounting, according to Greek accounting standards, will be required to transmit the information to the myDATA platform beginning in July of 2021. - Customer Invoices Customer Invoice form for Greece companies will now have a few fields required for specifying classification data to be send to MyDATA. In the Send & Print Wizard, a checkbox "Send to MyDATA"is added, and when activated, Odoo will generate an XML of the selected invoice(s) and send them to the MyDATA API. Any errors detected before and after the send will then be saved in a document object, displayed in the 'myDATA' tab in the move form view. - Vendor Bills In Greece, one's expense is another's invoice. When reporting to MyDATA for our expense classification, we need to fetch the invoice(s) issue by third-party issuer, fill the classification needed and send them back to MyDATA. To implement this behavior, we created a daily cron to fetch xml data from MyDATA related to the designated Greece companies, and create draft vendor bills based on that data. The user can then fill the myDATA classification data needed and send them back to MyDATA via a button in vendor bills view form after confirming the bill. task-id: 3358316 Forward-Port-Of: odoo/odoo#203428
PR https://github.com/odoo/odoo/pull/207213 modified the logic which was used to fetch a new pairing code from iot proxy. It made it so that if the IoT Box doesn't initially have internet access it never fetches a pairing code unless you restart odoo. This PR fixes the logic so that the pairing code is fetched when needed no matter the initial state of the IoT Box Forward-Port-Of: odoo/odoo#208755
Original PR description
PR https://github.com/odoo/odoo/pull/207213 modified the logic which was used to fetch a new pairing code from iot proxy. It made it so that if the IoT Box doesn't initially have internet access it never fetches a pairing code unless you restart odoo. This PR fixes the logic so that the pairing code is fetched when needed no matter the initial state of the IoT Box Forward-Port-Of: odoo/odoo#208755
PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208729 Forward-Port-Of: odoo/odoo#208247
Original PR description
PURPOSE - Integrate the latest set of e-waybill error codes as per the recent government notification. REFERENCES - https://docs.ewaybillgst.gov.in/apidocs/downloads/API-interoperableservices.pdf - https://docs.ewaybillgst.gov.in/apidocs/downloads/Additional_Validations_20241217.pdf Forward-Port-Of: odoo/odoo#208729 Forward-Port-Of: odoo/odoo#208247
Turnstile was completely rewritten in saas-18.2 in https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba This commit adds compatibility for the new way of calling Turnstile. opw-4625786 Forward-Port-Of: odoo/odoo#206418
Original PR description
Turnstile was completely rewritten in saas-18.2 in https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba This commit adds compatibility for the new way of calling Turnstile. opw-4625786 Forward-Port-Of: odoo/odoo#206418
When we install portal as well as account_peppol module and go to My Account, so feature are not working, for e.g. changing country will not change State selection, it is because we have PublicWidget with name `publicWidget.registry.portalDetails` in portal module while we are using same name in account_peppol module which replaces the existing PublicWidget `portalDetails`. To fix this issue we have used `inlcude` feature which will patch existing class `portalDetails` of portal module. Th
Original PR description
When we install portal as well as account_peppol module and go to My Account, so feature are not working, for e.g. changing country will not change State selection, it is because we have PublicWidget with name `publicWidget.registry.portalDetails` in portal module while we are using same name in account_peppol module which replaces the existing PublicWidget `portalDetails`. To fix this issue we have used `inlcude` feature which will patch existing class `portalDetails` of portal module. The issue arise with commit: https://github.com/odoo/odoo/pull/182585/commits/857b9a188c77cef2e3cd8a1c6b3035e7cd8d1305#diff-e0a8e9753f5e3ae55848bc264b7546eb7e187fe77c7500f9ebd97b1edfb23f46 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197979 Forward-Port-Of: odoo/odoo#186388
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue ----- The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description. Cause ----- When creating a task from an order line, it uses the first line of the line name as part of the
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue…
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on confirm; 2. add product to a SO; 3. add description to the line; 4. confirm the order; 5. go to the task. Issue ----- The task only has the SO and service product name as title. This is different from earlier versions, where it would include the first line of the line's description. Cause ----- When creating a task from an order line, it uses the first line of the line name as part of the task name, and adds the rest to the description. Starting from 18.0, the product & description columns are merged in order & invoice views. A side-effect of this, is that the product name will always be present as the first line of the product, and any added description will start from the second line. Consequently, it's no longer possible to add a description to the line that would get used as task name. Solution -------- Use the first two lines of the sale line name to form a task title. opw-4634149 opw-4637902 Forward-Port-Of: odoo/odoo#204112
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption. As we need the payload to be 4096 bytes at most *after encryption* the threshold for body truncation is reduced to around 3990 bytes to account for the fixed overhead of encryption as laid out in the added constants and getters so that they can be adjusted as needed. Additionally there we
Original PR description
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption.…
web push payloads currently get their body truncated when the payload comes out to more than 4096 bytes. However this only keeps the plaintext payload under that limit, not accounting for encryption. As we need the payload to be 4096 bytes at most *after encryption* the threshold for body truncation is reduced to around 3990 bytes to account for the fixed overhead of encryption as laid out in the added constants and getters so that they can be adjusted as needed. Additionally there were some issues with the logic for truncation: - Checking character length against byte length for the comparison, which led to potentially a lot more truncated text than necessary. - Truncation being done with the assumption the text would be encoded in utf-8 when it is actually transformed to json unicode escape sequences (see ensure_ascii argument in json.dumps) again making the truncation inaccurate. - The calculation of body_max_length was incorrect, as it allowed for negative values which sometimes resulted in an empty body. Steps to reproduce: 1. Activate desktop notifications. 2. Fastest way will be to send to an account A (with activated notis), a message through discuss from an account B. 3. Additionally this affects the current flow too: 3.1 When we try to notify a user following a heldesk team. 3.2 We create an alias and set this to that current team. 3.3 We simulate an email to that heldesk team, eg vip-support@test.com opw-3939019 Forward-Port-Of: odoo/odoo#208531 Forward-Port-Of: odoo/odoo#193641
**Steps to reproduce:** - Create new bill and save it manually (still in draft, with no name) - Select bill from the list view and press `Pay` button - Select check payment method - On the new payment page press `Print Check` button - Press `Print` button on the pop-up **Issue:** As task-id 3979071 (https://github.com/odoo/odoo/commit/3ccdd62bb9ce2f623e31f2e82aa1d5b35afe9d95) allowed payment on draft invoices, bills with unset name were throwing an error when printing check payment.
Original PR description
**Steps to reproduce:** - Create new bill and save it manually (still in draft, with no name) - Select bill from the list view and press `Pay` button - Select check payment method - On the new payment page press `Print Check` button - Press `Print` button on the pop-up **Issue:** As task-id 3979071 (https://github.com/odoo/odoo/commit/3ccdd62bb9ce2f623e31f2e82aa1d5b35afe9d95) allowed payment on draft invoices, bills with unset name were throwing an error when printing check payment. **Fix:** Added '/' as default value of the invoice name for check payment which have unposted bills. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4662760) opw-4662760 Forward-Port-Of: odoo/odoo#205005
When user tries to scan Vendor Bill, a traceback will appear. Traceback: ``` File "/home/odoo/src/odoo/saas-18.2/addons/l10n_in/models/res_partner.py", line 219, in _l10n_in_get_partner_vals_by_vat for fname in partner_data: RuntimeError: dictionary changed size during iteration ``` https://github.com/odoo/odoo/blob/ac3924508016178427c7962fa3b8e645e7e03835/addons/l10n_in/models/res_partner.py#L103-L105 Here, this method modifies the ``partner_data`` dictionary (using pop()) whil
Original PR description
When user tries to scan Vendor Bill, a traceback will appear.
Traceback:
```
File "/home/odoo/src/odoo/saas-18.2/addons/l10n_in/models/res_partner.py", line 219, in _l10n_in_get_partner_vals_by_vat
for fname in partner_data:
RuntimeError: dictionary changed size during iteration
```
https://github.com/odoo/odoo/blob/ac3924508016178427c7962fa3b8e645e7e03835/addons/l10n_in/models/res_partner.py#L103-L105
Here, this method modifies the ``partner_data`` dictionary
(using pop()) while iterating over it,
which leads to the above traceback.
To resolve this, the loop now iterates over a list of keys from ``partner_data``.
[ref](https://github.com/odoo/enterprise/blob/6f5e6a43f6149b4a8418d78a457f543de2dcfea3/l10n_in_qr_code_bill_scan/models/account_move.py#L90)
sentry-6586138810
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#208549**purpose of this PR:** using `partner_id.user_id` only returns the salesperson assigned to the partner, which isn’t always the correct user. We now use `partner_id.user_ids` instead to resolve the issue. task-4770457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208437
Original PR description
**purpose of this PR:** using `partner_id.user_id` only returns the salesperson assigned to the partner, which isn’t always the correct user. We now use `partner_id.user_ids` instead to resolve the issue. task-4770457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208437
Currently, an error occurs when a user adds an applicant to the pool and then modifies specific fields such as Email, Phone, LinkedIn Profile, or Degree. **Steps to produce:** - Install the `hr_recruitment` module. - Open any applicant record. - If not already added to a pool, click `Add to Pool`. - Update any of the following fields: `Email`,`Phone`, `LinkedIn Profile`, or `Detail > Degree` and click Save. **Error:** `RecursionError: maximum recursion depth exceeded` **Root C
Original PR description
Currently, an error occurs when a user adds an applicant to the pool and then modifies specific fields such as Email, Phone, LinkedIn Profile, or Degree. **Steps to produce:** - Install the…
Currently, an error occurs when a user adds an applicant to the pool and then modifies specific fields such as Email, Phone, LinkedIn Profile, or Degree. **Steps to produce:** - Install the `hr_recruitment` module. - Open any applicant record. - If not already added to a pool, click `Add to Pool`. - Update any of the following fields: `Email`,`Phone`, `LinkedIn Profile`, or `Detail > Degree` and click Save. **Error:** `RecursionError: maximum recursion depth exceeded` **Root Cause:** At [1], the condition checks if `applicant.pool_applicant_id`exists and the current record is not a pool applicant. However, if the record is its own pool reference, it leads to recursive calls, causing a recursion overflow. [1] https://github.com/odoo/odoo/blob/7129ea7686dcc0327b4f56d1d29e752aba3448ee/addons/hr_recruitment/models/hr_applicant.py#L680 This commit ensures that the recursion check does not trigger when the applicant is equal to its own `pool_applicant_id`, thus preventing an infinite loop. sentry - 6557786828 Forward-Port-Of: odoo/odoo#207214
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#208554
Original PR description
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#208554
Previously, record synchronization was based on the pos.order model, so if the write_date of the order was more recent on the server, it was re-downloaded with its sub-records. The problem was that by changing an orderline, the order object was not necessarily updated, so its write_date remained the same. Now all records and their write_dates are compared, so that records can be re-downloaded independently of their order. Trusted config commands are also re-downloaded. The records compared
Original PR description
Previously, record synchronization was based on the pos.order model, so if the write_date of the order was more recent on the server, it was re-downloaded with its sub-records. The problem was that by changing an orderline, the order object was not necessarily updated, so its write_date remained the same. Now all records and their write_dates are compared, so that records can be re-downloaded independently of their order. Trusted config commands are also re-downloaded. The records compared are only those that can be created from the PoS frontend. Forward-Port-Of: odoo/odoo#208459 Forward-Port-Of: odoo/odoo#208283
When settling an order from the POS, the amount to invoice was not correctly computed. Steps to reproduce: ------------------- * Create a draft sale order with a product * Go to the POS and select the order * Pay for the order * Go to the backend and check the amount to invoice > Observation: The amount to invoice is still the full order amount Why the fix: ------------ We should take into account the PoS payment lines when computing the amount to invoice of an order. opw-460367
Original PR description
When settling an order from the POS, the amount to invoice was not correctly computed. Steps to reproduce: ------------------- * Create a draft sale order with a product * Go to the POS and select the order * Pay for the order * Go to the backend and check the amount to invoice > Observation: The amount to invoice is still the full order amount Why the fix: ------------ We should take into account the PoS payment lines when computing the amount to invoice of an order. opw-4603671 Forward-Port-Of: odoo/odoo#208323 Forward-Port-Of: odoo/odoo#202950
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue
Original PR description
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for…
Currently, an error occurs when changing the internal note of an order in **POS Restaurant** if all food items are removed before updating the order. **Steps to reproduce:** - Open a POS session for the **Restaurant** shop. - Select a table, add the food (e.g., "Cheese Burger") and place the order. - Add an `Internal Note` to the ordered food item. - Remove the food item and click the `Order` button (it shows '-1 Food'). - Observe the error. **Error:** `KeyError: 'qty'` The issue occurs because when all food items are removed, `note_history` does not contain the `qty` key and it attempts to access `qty` from `note` at [1]. This commit resolves the issue by adding an additional check to ensure that 'qty' is in `note` before accessing the `qty` key. [1] - https://github.com/odoo/enterprise/blob/f1615134029860d32b95ade09738549a7bb1632d/pos_preparation_display/models/pos_order.py#L79-L80 Sentry - 6303446407 Forward-Port-Of: odoo/enterprise#84730 Forward-Port-Of: odoo/enterprise#79685
Current behavior before PR: - When showing analytic columns in reports, a filter can be applied from 'Options' menu to show analytic simulations (analytic items not linked to any move). This filter didn't work properly. Desired behavior after PR is merged: - Analytic simulations are integrated in the already existing analytic groupby columns Link to the task : - https://www.odoo.com/odoo/project/967/tasks/4603267 Forward-Port-Of: odoo/enterprise#81183
Original PR description
Current behavior before PR: - When showing analytic columns in reports, a filter can be applied from 'Options' menu to show analytic simulations (analytic items not linked to any move). This filter didn't work properly. Desired behavior after PR is merged: - Analytic simulations are integrated in the already existing analytic groupby columns Link to the task : - https://www.odoo.com/odoo/project/967/tasks/4603267 Forward-Port-Of: odoo/enterprise#81183
To reproduce: ============= 1. have a partner with email test@odoo.com in company1 2. allow to Demo only the company2 3. setup helpdesk team for company2 and enable it on website 4. create a ticket from website with email : test@odoo.com 5. check the ticket will be created with the partner from company1 6. try to open the ticket as Demo user, you will get an access error Problem: ========= `find_or_create` method of `res.partner` model is not taking into account the `company_id` whe
Original PR description
To reproduce: ============= 1. have a partner with email test@odoo.com in company1 2. allow to Demo only the company2 3. setup helpdesk team for company2 and enable it on website 4. create a ticket from website with email : test@odoo.com 5. check the ticket will be created with the partner from company1 6. try to open the ticket as Demo user, you will get an access error Problem: ========= `find_or_create` method of `res.partner` model is not taking into account the `company_id` when searching for the partner. Solution: ========= uses `_mail_find_partner_from_emails` method of `mail.thread` model to find/create the partner with extra domain containing `company_id`. opw-4699518 Forward-Port-Of: odoo/enterprise#84831 Forward-Port-Of: odoo/enterprise#84245
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the gro
Original PR description
Steps --------- 1. Have `accountant` and `account_accountant` installed 2. Set up an online bank -> see Odoofin steps on Knowledge 3. Set another user's access group to `Advanced Billing` for accounting 4. Login as that user and access the accounting app -> Access error for account.online.link Problem --------- Advanced billing should have access to the dashboard due to its role. The group `group_account_readonly` has read access to the model, as suggested by its name. However, the group `group_account_basic` does not have any access. Solution --------- Add 2 access rules on `account.online.link` that allows a Advanced billing user to see (and only see) those records. Note that it does not change anything for `group_account_user` which inherits both from `group_account_readonly` and `group_account_basic`, since it already had readonly access thanks to the first aforementioned. task-4731654 Forward-Port-Of: odoo/enterprise#83889
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the account used in the analytic distribution in "Analytic" group option **Issue 1:** In the "End Balance" column, all the amounts are summed in the total
Original PR description
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic…
**Steps to reproduce:** - Install Accounting - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Accounting / Journal Entries" - Create an entry with some analytic distribution - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Activate "Analytic Group By" in the settings of the report - Add the account used in the analytic distribution in "Analytic" group option **Issue 1:** In the "End Balance" column, all the amounts are summed in the total column instead of being grouped by analytic accounts. It results on a total amount being twice what it should be as the total column of each period is also included in the sum. There is a similar issue with horizontal groups. **Cause 1:** The "End Balance" column is not computed via the SQL as all the data required to compute it are already retrieved. However, the case where there are groups by analytic is not handled. It results on the computation taking the value of a analytic group and also the value of the total group, which doubles the computed amount. **Solution 1:** As it is not possible to identify easily each different group in each period to sum the corresponding values together, the computation of the "End Balance" will be done in the SQL if the groupby analytic is done or if a horizontal group is set. **Issue 2:** - Install l10n_ro_reports - Switch to a Romanian company (RO Company) - Follow the same steps than issue 1 - Select "Trial Balance 4/5 col (RO)" as Report => A traceback is raised: "TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'" opw-4648009 Forward-Port-Of: odoo/enterprise#84800 Forward-Port-Of: odoo/enterprise#84044
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order in the Barcode app. - Go to the settings in the top-right corner to find the 'Sign' button. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imp
Original PR description
**Steps to reproduce:** - Install Sales + Stock apps - Activate `Signature : Require a signature on your delivery orders` in the settings - Create and confirm a quotation with a product. - Go to the delivery order in the Barcode app. - Go to the settings in the top-right corner to find the 'Sign' button. - Sign the document. - 'Sign' button remains visible and active after the document is signed. **Issue:** Delivery document can be signed more than once. The button state seems to imply that the transaction is not finalized. **Fix:** Hide 'Sign' button after signature validation using the `record.signature` field value. This prevents users from signing multiple time the same delivery document. opw-4700124 Forward-Port-Of: odoo/enterprise#84631 Forward-Port-Of: odoo/enterprise#84385
This commit address keyerror `default_pricelist` which is already defined in superclass but not used in the test case. and This commit fixes a `Field error` in the `test_postpaid_next_invoice_date` test case in the `sale_subscription` module. The error was caused by referencing an invalid field name (`tax_id`) on the `sale.order.line` model during the creation of a sale order. The correct field name, `tax_ids`, has been used instead. build_error-181599 Forward-Port-Of: odoo/enterprise#84
Original PR description
This commit address keyerror `default_pricelist` which is already defined in superclass but not used in the test case. and This commit fixes a `Field error` in the `test_postpaid_next_invoice_date` test case in the `sale_subscription` module. The error was caused by referencing an invalid field name (`tax_id`) on the `sale.order.line` model during the creation of a sale order. The correct field name, `tax_ids`, has been used instead. build_error-181599 Forward-Port-Of: odoo/enterprise#84016
Here we don't really care about the state, we replaced it by just checking that there is only one payment and to the "agrolait" partner since it has a valid mandate. build_error-163134 Forward-Port-Of: odoo/enterprise#84005
Original PR description
Here we don't really care about the state, we replaced it by just checking that there is only one payment and to the "agrolait" partner since it has a valid mandate. build_error-163134 Forward-Port-Of: odoo/enterprise#84005
There's been quite a lot of refactoring of demo-data and stuff so now the setup may have been changed in the background Here we don't really care about the state, so we can replace it by just checking that there is 2 payments and to the "agrolait" partner and "china_export" partner build_error-163133 Forward-Port-Of: odoo/enterprise#84007
Original PR description
There's been quite a lot of refactoring of demo-data and stuff so now the setup may have been changed in the background Here we don't really care about the state, so we can replace it by just checking that there is 2 payments and to the "agrolait" partner and "china_export" partner build_error-163133 Forward-Port-Of: odoo/enterprise#84007
Steps to reproduce the bug: - Go to mps: - Select one or more records - Click on Action > Export - Export Problem: A traceback is raised with the following error: “Error: Invalid props for component 'RPCErrorDialog': 'model' is not a string or null” This is caused by a missing “model” parameter when opening the export dialog. The regression was introduced by commit 1e4e40c, which removed the “resModel” from the dialog context. https://github.com/odoo/odoo/commit/1e4e40
Original PR description
Steps to reproduce the bug:
- Go to mps:
- Select one or more records
- Click on Action > Export
- Export
Problem:
A traceback is raised with the following error:
“Error: Invalid props for component 'RPCErrorDialog': 'model' is not a string or null”
This is caused by a missing “model” parameter when opening the export dialog. The regression was introduced by commit 1e4e40c, which removed the “resModel” from the dialog context.
https://github.com/odoo/odoo/commit/1e4e40cf78fe8151dffdcb19df2688787084732c#diff-e58d49a1707841d2176f1d2a177911255094f0b5795ced0a86be963681e53dcdL277-R275
opw-4720190
Forward-Port-Of: odoo/enterprise#83915BUR-REE and inhouse id can not coexist in the xml scheme Forward-Port-Of: odoo/enterprise#84797
Original PR description
BUR-REE and inhouse id can not coexist in the xml scheme Forward-Port-Of: odoo/enterprise#84797
A mismatch between backend and frontend caused the time displayed in the grid to be incorrect. The cell value was doubled due to a frontend-only calculation, but the actual data was correct on the backend. Refreshing the page fixed the display issue. Steps to reproduce: ------------------- * Open the view form of a timesheet cell (🔍) * Start the timer in the Hours Spent column * Go back to My Timesheets * Stop the timer > Observation: timer displayed was previous_timer * 2 + new_tim
Original PR description
A mismatch between backend and frontend caused the time displayed in the grid to be incorrect. The cell value was doubled due to a frontend-only calculation, but the actual data was correct on the backend. Refreshing the page fixed the display issue. Steps to reproduce: ------------------- * Open the view form of a timesheet cell (🔍) * Start the timer in the Hours Spent column * Go back to My Timesheets * Stop the timer > Observation: timer displayed was previous_timer * 2 + new_timer Why the fix: ------------ 'stopTimer()' waits for the orm call 'action_timer_stop' to return a value that will be added to the current cell value. opw-4701396 Forward-Port-Of: odoo/enterprise#84658 Forward-Port-Of: odoo/enterprise#84416
Steps to reproduce the bug: - install sales - install subscription - remove any access right to sale from the logged in user - copy a product Traceback is thrown because the product_subscription_pricings have a problem in the access rules as they require sales app access. The user with no sales app can still create a product but not copy it. This is a bug because the user when creating can't set the pricings, so he can create without them but even without them being set he can't copy.
Original PR description
Steps to reproduce the bug: - install sales - install subscription - remove any access right to sale from the logged in user - copy a product Traceback is thrown because the product_subscription_pricings have a problem in the access rules as they require sales app access. The user with no sales app can still create a product but not copy it. This is a bug because the user when creating can't set the pricings, so he can create without them but even without them being set he can't copy. opw-4563733 Forward-Port-Of: odoo/enterprise#84675 Forward-Port-Of: odoo/enterprise#80938