Wednesday, May 22, 2024
19 changes · master
Enhancements to existing features
The Point of Sale product list now shows a helpful placeholder when appropriate, making the screen clearer for users. The receipt email confirmation message was also updated to sound more complete and reassuring after an email is sent.
Original PR description
Before this commit: ========== - There was no placeholder in the products list view for POS. - The email notice message on an email sent was "Email sent" in the Receipt screen. After this commit: ========== - There is a placeholder in the products list view for POS. - The email notice message on an email sent is "Email is sent successfully." in the Receipt screen. task-3356235
Product category records have been renamed and unused categories removed across several Odoo business apps. This keeps demo and test data more consistent, reducing confusion for teams working with products, sales, accounting, rentals, manufacturing, and related workflows.
Resolved issues and error corrections
The mail app now prevents message seen indicators from appearing in standard discussion channels where they are not supported. This avoids confusing duplicate indicators and keeps read-status cues limited to chat conversations where they are intended to work.
Original PR description
Before this commit, the seen indicator were displayed in the channels of type 'channel'. This was not intentional, and actually caused a UI issue where the seen indicator was visible on all messages…
Before this commit, the seen indicator were displayed in the channels of type 'channel'. This was not intentional, and actually caused a UI issue where the seen indicator was visible on all messages before the last message relevant to display the seen indicator. Step to reproduce: - As Mitchell Admin, post 2 messages in `#general` - As Marc Demo, post a single message in `#general` => Mitchell Admin sees the seen indicator on both of his messages, instead of 1 (feature enabled) or 0 (feature disabled). The 2 indicators happen because the channels is considered as not elligible for seen indicator feature. Because of this, field `Thread.lastSelfMessageSeenByEveryone` is unset, which also sets `Message.isMessagePreviousToLastSelfMessageSeenByEveryone` to `false` and thus makes all fields elligible to display the seen indicator. This commit fixes the issue by showing the seen indicator only when the thread of channel supports seen indicator, that is chat channels. https://github.com/odoo/enterprise/pull/62750 Before <img width="1512" alt="before" src="https://github.com/odoo/odoo/assets/6569390/f71f0ad4-0953-4d1c-bd06-b5820e005f42"> After <img width="1512" alt="after" src="https://github.com/odoo/odoo/assets/6569390/bea87d4b-bd24-4769-8109-f82b641fe74f">
Miscellaneous changes
This pull request appears to be an early proof of concept affecting Odoo's web interface navigation and action handling. The provided description does not specify the exact business outcome, so the expected impact is likely limited until the proposal is clarified.
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
Original PR description
**This commit adapts the changes of product category cleaning** - Renaming the records for product category and removing the one's not required. (For eg. - `product_category_5` to `product_category_office`) **Affected version** ~ master **Task**: 3941328
This fixes an issue where read/seen indicators could appear incorrectly on multiple messages in general discussion channels. WhatsApp chat channels are also marked correctly so users still get the expected seen status where the feature is supported.
Original PR description
Before this commit, the seen indicator were displayed in the channels of type 'channel'. This was not intentional, and actually caused a UI issue where the seen indicator was visible on all messages…
Before this commit, the seen indicator were displayed in the channels of type 'channel'. This was not intentional, and actually caused a UI issue where the seen indicator was visible on all messages before the last message relevant to display the seen indicator. Step to reproduce: - As Mitchell Admin, post 2 messages in `#general` - As Marc Demo, post a single message in `#general` => Mitchell Admin sees the seen indicator on both of his messages, instead of 1 (feature enabled) or 0 (feature disabled). The 2 indicators happen because the channels is considered as not elligible for seen indicator feature. Because of this, field `Thread.lastSelfMessageSeenByEveryone` is unset, which also sets `Message.isMessagePreviousToLastSelfMessageSeenByEveryone` to `false` and thus makes all fields elligible to display the seen indicator. This commit fixes the issue by showing the seen indicator only when the thread of channel supports seen indicator, that is chat channels. ===== This enterprise commit adapts whatsapp code to properly flag whatsapp channels as supporting the seen feature. Tests were passing due to bug on `'channel'` channels. https://github.com/odoo/odoo/pull/165883
Since https://github.com/odoo/odoo/commit/67b4ec4ba431adb4090aa8629d2a556dbf8df54a, l10n_fr is installed before base_setup. The issue is that it creates a demo company that has EUR currency. While the default stays USD. As there are 2 currencies, the group multi_currency is given by default to users. The test trying to check that it's not given by default will then fail. We will have more occurences of this in the future, as more payroll modules will arrive. To solve the issue, we jus
Original PR description
Since https://github.com/odoo/odoo/commit/67b4ec4ba431adb4090aa8629d2a556dbf8df54a, l10n_fr is installed before base_setup. The issue is that it creates a demo company that has EUR currency. While the default stays USD. As there are 2 currencies, the group multi_currency is given by default to users. The test trying to check that it's not given by default will then fail. We will have more occurences of this in the future, as more payroll modules will arrive. To solve the issue, we just test on a different group. Linked to runbot error 58147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163778
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
Original PR description
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
#### [FIX] account,sale: credit_to_invoice in multi-company Currently the credit_to_invoice includes sales orders from all allowed companies. But it should only include sales orders from the active company. (Since a single sales order belongs to only 1 company) #### [FIX] account: flush in _credit_debit_get of model res.partner Function _credit_debit_get uses a raw SQL query, but does not flush the used tables to the DB before. Without this commit some of the tests in the following c
Original PR description
#### [FIX] account,sale: credit_to_invoice in multi-company Currently the credit_to_invoice includes sales orders from all allowed companies. But it should only include sales orders from the active…
#### [FIX] account,sale: credit_to_invoice in multi-company
Currently the credit_to_invoice includes sales orders
from all allowed companies.
But it should only include sales orders from the active company.
(Since a single sales order belongs to only 1 company)
#### [FIX] account: flush in _credit_debit_get of model res.partner
Function _credit_debit_get uses a raw SQL query,
but does not flush the used tables to the DB before.
Without this commit some of the tests in the following commits of this PR will fail
(since some of the invoice lines are not flushed yet).
#### [FIX] account,sale: credit limit in multi-currency setup
The partner credit limit (warning) may not be computed correctly in a
multi-currency setup.
Note that the partner credit is always in company currency.
1) Consider a draft invoice. To determine the warning amount
the current amount in document currency (not company currency)
is added to the current partner credit (roughly speaking).
2) To compute the credits from sales orders of the partner
(credit_to_invoice) we just add the amount_to_invoice
from each sales order of the partner.
But this field is in the currency of the order
and thus may be different from the company currency.
To fix these issues currency conversions were added for both cases.
#### [FIX] account,sale: credit limit warning
Currently the amount of the partner credit warning
on invoices is not computed correctly in some cases.
1) There are Sales Order credits
and we create an invoice independent of any of SO
2) We create an invoice from a Sales Order with
an amount greater than the Sales Order.
For (1) the problem is that we substract the current
amount of the invoice from the sales order credits
(since we need to do this in the sales order to invoice flow)
But in case the invoice does not come from a sales order
this is wrong.
For (2) the problem is that the `amount_to_invoice` of a
Sales Order may be negative. This can happen if we invoice
more than the sales order amount.
E.g. we can end up with one invoiced order with -100 and
one uninvoiced order of 100. In the sum this would leave us
with "nothing to invoice" (100 + -100 = 0).
Reproduce (1):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create a Sales Order for customer of 200
and deliver it
- The total partner credit is now 200
- Create an Invoice (not from the Sales Order)
for customer 'Test' (without any lines at first).
- There should be a warning that the total amount
due is 200 (since it exceeds the limit of 100).
- Add a line of 200 to the Invoice
(any value ≤ 200 will do).
- The total amount due in the warning is still 200
but it should be 400 (200 + 200)
- Change the line to 800 (any value > 200 will do)
- The total amount due in the warning is now 800
but it should be 1000 (200 + 800)
Reproduce (2):
All monetary values here are in company currency.
- Ensure that the partner credit is 0:
i.e. remove all Sales Orders and Invoices.
- Activate 'Sales Credit Limit' in the settings
and set the 'Default Credit Limit' to 100
- Create a new customer; here 'Test'
- Create 2 Sales Orders for customer of 200 each
and deliver it
- The total partner credit is now 400
- Create an Invoice from exactly one of the Sales Orders
(full amount or downpayment does not matter here)
- There should be a warning that the total amount
due is 400 (since it exceeds the limit of 100).
- Modify the invoice (any line from the sales order)
s.t. it has a total of 400
- Confirm the invoice
- The amount_to_invoice of the Sales Order is now -200.
The sum of the amount_to_invoice of the Sales Orders is 0.
- Create a new invoice without any lines.
- There is a warning that the total amount
due is 400 (= 200 + -200 + 400 ; SO + SO + invoice).
But it should be 600 since the "overinvoiced" SO
should just be counted with amount_to_invoice 0.
Forward-Port-Of: odoo/odoo#165147
Forward-Port-Of: odoo/odoo#162770Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 PR Enterprise: https://github.com/odoo/enterprise/pull/62434 Forward-Port-Of: odoo/odoo#165371
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 PR Enterprise: https://github.com/odoo/enterprise/pull/62434 Forward-Port-Of: odoo/odoo#165371
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odo
Original PR description
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odoo/odoo/blob/17.0/addons/delivery/models/sale_order.py#L139 since we can edit the quantity of the order lines then there is not point of not calculating the estimated weight each time. **Desired behavior after PR is merged:** With removing this condition the weight will get updated each time we open the shipping cost wizard. opw-3908453 Forward-Port-Of: odoo/odoo#166015 Forward-Port-Of: odoo/odoo#164928
When searching an action, ones can use the XML ID; the path or the ID of the action. If the XML ID or the path is used, and the action is not found, a missing error is raised. Contrariwise, if the ID of the action is used, and the action is not found, an empty record is returned. This difference of behaviour, when treating a not found action, could cause some errors. For instance, the JS code expects to receive always an error to show the corresponding notification, when receiving an empty re
Original PR description
When searching an action, ones can use the XML ID; the path or the ID of the action. If the XML ID or the path is used, and the action is not found, a missing error is raised. Contrariwise, if the ID of the action is used, and the action is not found, an empty record is returned. This difference of behaviour, when treating a not found action, could cause some errors. For instance, the JS code expects to receive always an error to show the corresponding notification, when receiving an empty record instead, this empty action is used to continue to execute the code and other errors are raised. Now, if the record is not found, we always raise an error. 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#165350
Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348
Original PR description
Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestro
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestroy` is called; 5. timer isn't canceled because it hasn't started yet; 6. `onWillStart` continues; 7. a timer is added for a destroyed component. Solution -------- Use Owl's `status` function to ensure the component hasn't been destroyed before adding a timer. opw-3815398 Forward-Port-Of: odoo/enterprise#62110
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers t
Original PR description
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers the recompute. opw-3848817 Forward-Port-Of: odoo/enterprise#62431 Forward-Port-Of: odoo/enterprise#61908
# Issue: In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback. # Reproduce: - Go in debug mode - Accounting > Configuration > Accounting Report > Partner Ledger > Options - Set Prefix Groups Threshold to 2 - Go in
Original PR description
# Issue:
In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback.
# Reproduce:
- Go in debug mode
- Accounting > Configuration > Accounting Report > Partner Ledger > Options
- Set Prefix Groups Threshold to 2
- Go in Accounting > Reports > Partner Ledger
- Try to open a journal items on a "Grouping Line"
# Task:
opw-3916555
Forward-Port-Of: odoo/enterprise#62774
Forward-Port-Of: odoo/enterprise#62360Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Community PR: https://github.com/odoo/odoo/pull/165371 Forward-Port-Of: odoo/enterprise#62434
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Community PR: https://github.com/odoo/odoo/pull/165371 Forward-Port-Of: odoo/enterprise#62434
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-O
Original PR description
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-Of: odoo/enterprise#62674 Forward-Port-Of: odoo/enterprise#57346
When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Po
Original PR description
When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Port-Of: odoo/enterprise#62756
Since you don't need the group 'hr.group_hr_manager' to access the value of the yearly cost and you have it displayed in the view list. We remove the group in the view form Forward-Port-Of: odoo/enterprise#62892
Original PR description
Since you don't need the group 'hr.group_hr_manager' to access the value of the yearly cost and you have it displayed in the view list. We remove the group in the view form Forward-Port-Of: odoo/enterprise#62892