Tuesday, June 25, 2024
45 changes · saas-17.1
Resolved issues and error corrections
This fixes an issue where the Point of Sale setting for larger scrollbars no longer showed the larger scrollbar after a recent code change. Businesses using touch screens or devices where larger scrollbars improve usability will see the option work as intended again.
Original PR description
After a refactor, enabling the option for large scrollbar did not display it as expected. opw-3998526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
[IMP] l10n_pk: improve pakistan's tax structure - Restructure the tax and tax group. - Adding new taxes - Adding tax tags to all the taxes - Create two new tax report Reason: Enhance the user-experience in pakistan Task-3871597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164128
Original PR description
[IMP] l10n_pk: improve pakistan's tax structure - Restructure the tax and tax group. - Adding new taxes - Adding tax tags to all the taxes - Create two new tax report Reason: Enhance the user-experience in pakistan Task-3871597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164128
the fix replaces the `\xa0` with ` ` for html translated values and keeps the consistent logic as odoo/odoo#110148 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#170692
Original PR description
the fix replaces the `\xa0` with ` ` for html translated values and keeps the consistent logic as odoo/odoo#110148 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#170692
Problem: A recent commit (below) added carriage return characters to the .pot file for new `deleteConfirmationMessage` popup. Since the value of the string itself doesn't contain these characters, we'll never see a translation for this popup. Purpose: Revert .pot msgid back to its previous state. FW commit /pull/162106/commits/50f9df296c44d3c86bc251a67944bb0ce36a154e opw-3954024 Forward-Port-Of: odoo/odoo#169688
Original PR description
Problem: A recent commit (below) added carriage return characters to the .pot file for new `deleteConfirmationMessage` popup. Since the value of the string itself doesn't contain these characters, we'll never see a translation for this popup. Purpose: Revert .pot msgid back to its previous state. FW commit /pull/162106/commits/50f9df296c44d3c86bc251a67944bb0ce36a154e opw-3954024 Forward-Port-Of: odoo/odoo#169688
It may happen that user will try to blacklist a number that he already unblacklisted (archived blacklist record). Before that attempt was ignored. With this commit we simply blacklist the number again (so we unarchive existing record) ### [Reproduce] - Install mass_mailing_sms - Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses) - Blacklist a number N - Unblacklist number N - Go back to Blacklisted Phone Numbers - Blacklist a number N (a
Original PR description
It may happen that user will try to blacklist a number that he already unblacklisted (archived blacklist record). Before that attempt was ignored. With this commit we simply blacklist the number again (so we unarchive existing record) ### [Reproduce] - Install mass_mailing_sms - Open Blacklisted Phone Numbers (Email Marketing / Configuration / **Bla**cklisted Email Addresses) - Blacklist a number N - Unblacklist number N - Go back to Blacklisted Phone Numbers - Blacklist a number N (again) -> BUG: no effect opw-3700268 Forward-Port-Of: odoo/odoo#170297 Forward-Port-Of: odoo/odoo#158923
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef5
Original PR description
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were…
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- Backport of: https://github.com/odoo/odoo/commit/53885e41867653ad45ca3aef55886c280240b76a In phone_validation, before formatting, phone_parse is called, https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L72 old brazilian mobile numbers would be invalid, and raise an error. https://github.com/odoo/odoo/blob/bdfb802293d9a3eebb378a15ed65f48b7c3182b2/addons/phone_validation/tools/phone_validation.py#L51 Now if the number is invalid, we force format in international, to force apply patched metadata, before re-trying to parse. opw-3861847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170287 Forward-Port-Of: odoo/odoo#169134
-Before this commit, when user has no expense at all and in mobile view of expense, it will display term "Or" alongside with "Snap pictures of your receipts..." -After this commit, remove term "Or". Description of the issue/feature this PR addresses: Current behavior before PR:  Desired behavior after PR is merged:  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#170460
Steps to reproduce the issue: - Create a storable product “P1” with a BoM: - Component: Select any component - Work order: OP1: 60 minutes in workcenter “Assembly Line 1” - Go to workcenter “Assembly Line 1”: - Specific capacities: P1, capacity: 1, setup: 10 minutes - Alternative workcenter: “Assembly Line 2”: - Specific capacities: P1, capacity: 1, setup: 5 minutes - Create a manufacturing order “MO1” to produce 1 unit: - Date: May 10, 2024, 08:00:00 -
Original PR description
Steps to reproduce the issue:
- Create a storable product “P1” with a BoM:
- Component: Select any component
- Work order: OP1: 60 minutes in workcenter “Assembly Line 1”
- Go to workcenter “Assembly Line 1”:
- Specific capacities: P1, capacity: 1, setup: 10 minutes
- Alternative workcenter: “Assembly Line 2”:
- Specific capacities: P1, capacity: 1, setup: 5 minutes
- Create a manufacturing order “MO1” to produce 1 unit:
- Date: May 10, 2024, 08:00:00
- Create a manufacturing order “MO2” to produce 1 unit:
- Date: May 10, 2024, 08:00:00
Issue:
- After confirming and planning MO1, the expected duration is 70 minutes.
- After confirming and planning MO2, the expected duration is 75 minutes
instead of 65.
The setup time of workcenter Assembly Line 1 for specific product is not
reduced from the expected time.
opw-3904023
Forward-Port-Of: odoo/odoo#170353
Forward-Port-Of: odoo/odoo#165128Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching. This commit fixes that by parsing the dataAttribute to float. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f2380
Original PR description
Since [1], `opacity` needs to be a number as defined in ColorPlaette's props definition. However, in the ColorpickerUserValueWidget, when the props is passed to the ColorPalette component, it is given from the dataAttributes, which are strings. This leads to a crash in debug mode as the types are miss-matching. This commit fixes that by parsing the dataAttribute to float. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997#diff-c4e4c8cbbe59c3e61eba1cdcfd8f23809818a0b78c118d84606a1ab5d7bf1203 task-4001189 Forward-Port-Of: odoo/odoo#170092
Steps: - Install sale and razopay app. - Set-up razorpay provider. - Create quotation. - Pay that quotation via razorpay and save payment details. - Duplicate that quote and pay it via already saved method. Issue: - Creating duplicate token when paying via token. Cause: - Since [PR] we are creating token in odoo when razorpay give token_id in notification_data and tokenization is enabled on razorpay and in some case when we pay quote via token it return token in notification_data an
Original PR description
Steps: - Install sale and razopay app. - Set-up razorpay provider. - Create quotation. - Pay that quotation via razorpay and save payment details. - Duplicate that quote and pay it via already saved method. Issue: - Creating duplicate token when paying via token. Cause: - Since [PR] we are creating token in odoo when razorpay give token_id in notification_data and tokenization is enabled on razorpay and in some case when we pay quote via token it return token in notification_data and since we forgot to check if transaction is already connected to token or not it always create new token :( Fix: - Add condition to check if transaction is connected to token or not and only create token if transaction is not connected to token. Additionally pass entity_data in token creation method so it pass proper data when we don't find `id` in `notification_data`. [PR]: https://github.com/odoo/odoo/pull/159250 Forward-Port-Of: odoo/odoo#170112
In this commit: =============== Added config settings for the shiprocket. Task- 3657635 Forward-Port-Of: odoo/odoo#154119
Original PR description
In this commit: =============== Added config settings for the shiprocket. Task- 3657635 Forward-Port-Of: odoo/odoo#154119
In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions. 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#169683 Forward-Port-Of: odoo/odoo#164909
Original PR description
In 92ed88a770893f57dcceff99d9239f130aa6112d, we added a fix and tests on hr.expense & hr.expense.sheet state fields. This commit forward ports these tests as they are interesting to keep in later versions. 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#169683 Forward-Port-Of: odoo/odoo#164909
Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback. By updating the country of the company by the one of the chart template, the issues will not happen again. task: 3945833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166896
Original PR description
Before this commit, when creating a company and directly installing a chart template without putting a country first, the installation of the chart template was giving a traceback. By updating the country of the company by the one of the chart template, the issues will not happen again. task: 3945833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166896
Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected behavior: --- The survey colors should be the same as the website theme. Steps to reproduce: --- 1. Go to the website 2. Click on Edit > Theme 3. Change the background color to black 4. Save then go to Survey 5. Select a survey 6. Remove the background image if there is one 7. Click
Original PR description
Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected…
Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected behavior: --- The survey colors should be the same as the website theme. Steps to reproduce: --- 1. Go to the website 2. Click on Edit > Theme 3. Change the background color to black 4. Save then go to Survey 5. Select a survey 6. Remove the background image if there is one 7. Click on Test 8. Survey's background color is grey Cause of the issue: --- Introduced by https://github.com/odoo/odoo/blob/90c6e52f15277d44cbecdd5f6a70391551fb72bd/addons/survey/static/src/scss/survey_templates_form.scss#L22 A box-shadow is used to make a "translucent white overlay" Which lighten the background color if there is no image Fix: --- Only lighten the background if there is a background image opw-3834397 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169903 Forward-Port-Of: odoo/odoo#161942
The diff introduced here https://github.com/odoo/odoo/pull/170267 was absolutely not wanted. It needs to be removed opw-3787201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170636
Original PR description
The diff introduced here https://github.com/odoo/odoo/pull/170267 was absolutely not wanted. It needs to be removed opw-3787201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170636
This commit fixes a bug where there would be a traceback occuring when the user would either create a favorite with a name that already exists or one with an empty name by pressing enter instead of save. The crash occurs because the keydown event is not passed to saveFavorite and in these cases, saveFavorite will invoke stopPropagation on an undefined event. Solution: pass the event to saveFavorite. Forward-Port-Of: odoo/odoo#170551 Forward-Port-Of: odoo/odoo#170320
Original PR description
This commit fixes a bug where there would be a traceback occuring when the user would either create a favorite with a name that already exists or one with an empty name by pressing enter instead of save. The crash occurs because the keydown event is not passed to saveFavorite and in these cases, saveFavorite will invoke stopPropagation on an undefined event. Solution: pass the event to saveFavorite. Forward-Port-Of: odoo/odoo#170551 Forward-Port-Of: odoo/odoo#170320
Current behavior: In the journal items of a PoS session, Debit and Credit mismatch for the bank Steps to reproduce: - Install "Point of Sale", "Accounting" apps - Create a company and set the currency to something different than USD (eg. EUR) - Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template" - Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD) - Go to Accounting -> C
Original PR description
Current behavior: In the journal items of a PoS session, Debit and Credit mismatch for the bank Steps to reproduce: - Install "Point of Sale", "Accounting" apps - Create a company and set the…
Current behavior: In the journal items of a PoS session, Debit and Credit mismatch for the bank Steps to reproduce: - Install "Point of Sale", "Accounting" apps - Create a company and set the currency to something different than USD (eg. EUR) - Set the company and go to Accounting settings and set the "Fiscal Localization" to "Configurable Chart Template" - Go back to your company settings and set again the currency (for an unknown reason, it changes back to USD) - Go to Accounting -> Currencies -> USD -> Add a rate line and set a rate different to 1 Unit per EUR (eg. 1.2) - In Accounting, go to Journals -> Bank -> set the currency to USD -> do the same for Cash - Add a Journal named "PoS" -> set its type to "Miscellaneous" -> set the short code to "POS" -> set the currency to USD - Go to POS -> Payment Methods -> Create "Cash" -> set the journal "Cash (USD)" and the account "<some number> Account Receivable (PoS)" - Create a "Bank" payment method -> set the journal "Bank (USD)" -> Set the Outstanding Account "<some number> Outstanding Receipts" -> set the Intermediary Account "<some number> Account Receivable (PoS)" - Create a shop - In the shop settings, set the default journal to "POS(USD)" then add "Cash" and "Bank to "Payment methods" - Start a shop session and sell a product paid by bank - Close the session -> set the bank count to the price of 2 products - Go to "Order" -> "Sessions" -> last session -> "Journal Items" - The "PBNK" line doesn't have Debit and Credit equal Cause: The diff_amount used for the line calculation is in USD and not in the company currency opw-3905691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168731
Steps: - Install the project - Enable use custom enable server from general settings. Set an alias domain - Create a new project - Wizard pops up Issue: - Default value of alias domain is not set. Cause: - alias_domain_id is related to alias_id and it is not present in the view. Fix: - Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field. - Additionally the same field is been to added to form view as well. task-3744319 Forwar
Original PR description
Steps: - Install the project - Enable use custom enable server from general settings. Set an alias domain - Create a new project - Wizard pops up Issue: - Default value of alias domain is not set. Cause: - alias_domain_id is related to alias_id and it is not present in the view. Fix: - Issue is been fixed by adding a field in wizard view as alias domain was getting fetched on that field. - Additionally the same field is been to added to form view as well. task-3744319 Forward-Port-Of: odoo/odoo#154681
The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field. It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests. The missing dependency is added in this commit. enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262 Forward-Port-Of: odoo/odoo#170475
Original PR description
The field `max_tax_lock_date` is not always computed correctly. This is since the compute function does not depend on the `tax_lock_date` field. It should not happen in production since the `tax_lock_date` and the check of `max_tax_lock_date` should not happen in the same transaction. But it can still cause issues in tests. The missing dependency is added in this commit. enterprise PR (fixing a test): https://github.com/odoo/enterprise/pull/65262 Forward-Port-Of: odoo/odoo#170475
**Reproduce issue:** - Drop and drop a form snippet - Set a field as a multiple checkbox - Toggle on option 1 - Set a space at the end of option 1 so "option 1 " - Blur the input **Result:** You will find, Option 1 is no more selected. The root cause of this issue appears to be the unexpected trimming of the HTML input box. By default, HTML trims leading and trailing spaces, as well as considers multiple inner spaces as a single space. Consequently, inconsistencies arise between
Original PR description
**Reproduce issue:** - Drop and drop a form snippet - Set a field as a multiple checkbox - Toggle on option 1 - Set a space at the end of option 1 so "option 1 " - Blur the input **Result:** You will find, Option 1 is no more selected. The root cause of this issue appears to be the unexpected trimming of the HTML input box. By default, HTML trims leading and trailing spaces, as well as considers multiple inner spaces as a single space. Consequently, inconsistencies arise between the input value, ID, and display name. This commit trims the value from the initial to maintain consistency. As a result, `option 1`, `option 1 `, ` option 1`, and `option 1` will all be trimmed and considered the same. task-3254884 Forward-Port-Of: odoo/odoo#170365 Forward-Port-Of: odoo/odoo#128692
### Current Behavior: - Go in the project app, click on a project and click on a task - Change the stage of the task The duration spent in the previous stage is displayed in the new stage. Note: if you refresh the page the bug will disappear. ### Cause of the issue: The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https
Original PR description
### Current Behavior: - Go in the project app, click on a project and click on a task - Change the stage of the task The duration spent in the previous stage is displayed in the new stage. Note: if…
### Current Behavior: - Go in the project app, click on a project and click on a task - Change the stage of the task The duration spent in the previous stage is displayed in the new stage. Note: if you refresh the page the bug will disappear. ### Cause of the issue: The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L45-L60 To be sure that these trackings will be correctly retrieved, the model used by the query are even flushed. However, these mail tracking values are only created at the end of the sql transaction because the `_track_finalize` method is part of the precommit hooks of the transaction and is hence only run during the general sql flush: https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/sql_db.py#L134-L138 https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/tools/misc.py#L1215-L1221 As such, the mail tracking values generated by the old value of the stage will only be accessible at the end of the transaction and will not be available during the computation duration_tracking run for the project task in its final stage. Leading to an incorrect computation of the field during onchanges: https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L62-L64 ### Fix: In order for the the mail tracking values generated by the old stage to be present during the final computation of our duration_tracking we trigger the `_track_finalize` precommit hook on the records for which it should be run at the end of the transaction before the execution of our query. opw-3837359 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161688
Summary ----- When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved. Steps to Reproduce ----- 1. Set a strong currency for the company (e.g., USD) 2. Add a weak currency in the currencies (e.g., IQD) 3. Create
Original PR description
Summary ----- When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the…
Summary
-----
When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved.
Steps to Reproduce
-----
1. Set a strong currency for the company (e.g., USD)
2. Add a weak currency in the currencies (e.g., IQD)
3. Create an expense with a high amount (e.g., 1,000,000 for the IQD/USD pair)
4. Set the weak currency for the expense
5. Observe the overly rounded amount in the weak currency
Cause
-----
The error comes from the exchange rate being rounded too much and too early.
Fix
-----
Modify "digits" attribute of the "currency_rate" field to increase precision.
Note
-----
Some inaccuracy remains, but expenses rarely exceed 1000 USD for companies using weak currencies, so the number of issues should be reduced.
opw-3684727
Forward-Port-Of: odoo/odoo#167606Commit [1] made it so that, in grid mode, a video alone in its column would take the whole width/height of the column, just like was already the case for images since commit [2]. However, it did not adapt the part of the code that checks whether the image is alone in its column (which then adds the `.o_grid_item_image` class to the column). That check only happens when toggling the grid mode. This commit makes sure that, upon toggling the grid mode, the check is also run for video-only columns
Original PR description
Commit [1] made it so that, in grid mode, a video alone in its column would take the whole width/height of the column, just like was already the case for images since commit [2]. However, it did not…
Commit [1] made it so that, in grid mode, a video alone in its column would take the whole width/height of the column, just like was already the case for images since commit [2]. However, it did not adapt the part of the code that checks whether the image is alone in its column (which then adds the `.o_grid_item_image` class to the column). That check only happens when toggling the grid mode. This commit makes sure that, upon toggling the grid mode, the check is also run for video-only columns. Steps to reproduce: - Drop a Text - Image snippet - Set it to full-width - Replace the image with a video - Toggle grid mode - Save => the video takes more space than it should, it sticks out further than its section. Note that the same bug may still happen if you use a text column, toggle grid mode, and only after that place a video or an image and remove any text from the column: because the check isn't run after toggling, the proper class is not set, and the size of the image/video doesn't match what would be expected. [1]: https://github.com/odoo/odoo/commit/b54b34e6c34f435b2923e7b571b2bb2e4e9e0f08 [2]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a opw-3959262 Forward-Port-Of: odoo/odoo#170444 Forward-Port-Of: odoo/odoo#170262
Steps: ========== - Install the point_of_sale and Razorpay payment provider modules. - Create an online payment method for the Razorpay payment provider. - Add the created payment method to the shop. - Open the shop, place an order, and use the Razorpay payment method. - Scan the QR code for payment and complete the payment with public users. Issue: ========== - An error occurs stating 'Email must be a valid email address,' causing the task to be blocked. Cause: ========== - The
Original PR description
Steps: ========== - Install the point_of_sale and Razorpay payment provider modules. - Create an online payment method for the Razorpay payment provider. - Add the created payment method to the shop. - Open the shop, place an order, and use the Razorpay payment method. - Scan the QR code for payment and complete the payment with public users. Issue: ========== - An error occurs stating 'Email must be a valid email address,' causing the task to be blocked. Cause: ========== - The email for public users is not found. FIX: ========== - Add an empty email address option for public users. task-3992084 Forward-Port-Of: odoo/odoo#169974
This traceback occurs when the user tries to activate stripe through onboarding without installing `website_payment`. To reproduce this issue:- 1) Install `sale` 2) Now switch to a new company by creating a `new company` 4) With the new company try to `activate the stripe` from the `sales Onboarding` 5) A traceback occurs Error:- ``` ValueError: Invalid field 'website_id' on model 'payment.provider' ``` As you can see `website_id` field is defined in `website_payment` at [1]
Original PR description
This traceback occurs when the user tries to activate stripe through onboarding without installing `website_payment`. To reproduce this issue:- 1) Install `sale` 2) Now switch to a new company by creating a `new company` 4) With the new company try to `activate the stripe` from the `sales Onboarding` 5) A traceback occurs Error:- ``` ValueError: Invalid field 'website_id' on model 'payment.provider' ``` As you can see `website_id` field is defined in `website_payment` at [1], but it is used in the `payment` module [2]. Which leads to the above traceback when `website_payment` is not installed. [1] https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/website_payment/models/payment_provider.py#L12-L16 [2] https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/payment/models/res_company.py#L48-L53 sentry-5504774122 Forward-Port-Of: odoo/odoo#170550 Forward-Port-Of: odoo/odoo#169953
Forward-Port-Of: odoo/enterprise#65399
Original PR description
Forward-Port-Of: odoo/enterprise#65399
This commit allows the user the password provided by IAP during the first connection. A new wizard has been added for this. task-id: 3857241 IAP: https://github.com/odoo/iap-apps/pull/790 Forward-Port-Of: odoo/enterprise#60645
Original PR description
This commit allows the user the password provided by IAP during the first connection. A new wizard has been added for this. task-id: 3857241 IAP: https://github.com/odoo/iap-apps/pull/790 Forward-Port-Of: odoo/enterprise#60645
### Issue: The VAT lines in tax reports do not populate correctly. ### Steps to reproduce: - Activate l10n_es module - Go to Accounting > Reporting > Statement Reports > Tax Report - Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)' - In the report, only Spain and partners without countries have a NIF number ### Cause: A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain. In addition, other lines
Original PR description
### Issue: The VAT lines in tax reports do not populate correctly. ### Steps to reproduce: - Activate l10n_es module - Go to Accounting > Reporting > Statement Reports > Tax Report - Select a 'Generic Tax Report' and click on 'VAT Record Books (XLSX)' - In the report, only Spain and partners without countries have a NIF number ### Cause: A line of code is only populating the NIF field in the report if the partner has no country or if the country is Spain. In addition, other lines related to the NIF are not populated as they should. ### Solution: Add conditions to populate the NIF lines as the specs demands it. Specs: https://sede.agenciatributaria.gob.es/static_files/AEAT/LSI.xlsx (second point) opw-3918623 Forward-Port-Of: odoo/enterprise#63923
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- See community commit Adding extra tests in test_whatsapp opw-3861847
Original PR description
Current behaviour: --- Brazilian phone numbers are not managed correctly following the 2016 changes in Brazil. (Adding a 9 to mobile phone numbers) Cause of the issue: --- Phonenumbers metadata were patched to add 9 in mobile numbers, however, when E164 is selected, phone numbers aren't formatted, thus patched metadata not being applied. See format_number in phonenumbers "Early exit for E164 case" Fix: --- See community commit Adding extra tests in test_whatsapp opw-3861847 Forward-Port-Of: odoo/enterprise#65336
See commit Forward-Port-Of: odoo/enterprise#62470
Original PR description
See commit Forward-Port-Of: odoo/enterprise#62470
This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied. The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button. task-3692048 | Light mode (`:focus` state) | Dark mode | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img al
Original PR description
This PR fixes a contrast issue on a primary button within the sign module due to a `text-white` class applied. The default button utility classes already provide a good contrast, meaning that adding extra class is not useful. To fix the issue, we simply remove the class from the button. task-3692048 | Light mode (`:focus` state) | Dark mode | |--------|--------| | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/b73a2fe7-f802-4461-9015-16a2f4b46d92"> | <img alt="image" src="https://github.com/odoo/enterprise/assets/128030743/8354c78f-6525-4aef-9057-fdb706b3cd0d"> | Forward-Port-Of: odoo/enterprise#64801
This module is for a shiprocket-cash-on-delivery option for e-commerce users. - Payment provider for shiprocket cash on delivery - Payment method for shiprocket cash on delivery Co-authored-by: Jitendra Prajapati <jipr@odoo.com> task - 3657635 related community PR: https://github.com/odoo/odoo/pull/154119 Forward-Port-Of: odoo/enterprise#56663
Original PR description
This module is for a shiprocket-cash-on-delivery option for e-commerce users. - Payment provider for shiprocket cash on delivery - Payment method for shiprocket cash on delivery Co-authored-by: Jitendra Prajapati <jipr@odoo.com> task - 3657635 related community PR: https://github.com/odoo/odoo/pull/154119 Forward-Port-Of: odoo/enterprise#56663
Problem --- In the accounting dashboard, when going to Bank > Payments draft and cancelled payments are not filtered out by default. This makes the amount displayed on the kanban card inconsistent with the sum of the payments that are shown by default. opw-3978180 Forward-Port-Of: odoo/enterprise#65274
Original PR description
Problem --- In the accounting dashboard, when going to Bank > Payments draft and cancelled payments are not filtered out by default. This makes the amount displayed on the kanban card inconsistent with the sum of the payments that are shown by default. opw-3978180 Forward-Port-Of: odoo/enterprise#65274
With this commit: https://github.com/odoo/odoo/pull/166896/commits/90088bd97ec096fa8c360868e3a1addef91bd4ce We automatically add the country of the chart template to the company if the company does not have one by default. This change had a side effect that in the context of the test "TestPeSales," the boolean field l10n_latam_use_documents on the journal was now set to True. The consequence of that was that the constraint _check_l10n_latam_documents was breaking since this constraint chec
Original PR description
With this commit: https://github.com/odoo/odoo/pull/166896/commits/90088bd97ec096fa8c360868e3a1addef91bd4ce We automatically add the country of the chart template to the company if the company does not have one by default. This change had a side effect that in the context of the test "TestPeSales," the boolean field l10n_latam_use_documents on the journal was now set to True. The consequence of that was that the constraint _check_l10n_latam_documents was breaking since this constraint checks that for the posted moves that use documents, the move must have a document type and a document number. task: 3945833 Forward-Port-Of: odoo/enterprise#64991
**Before this PR:** There were no test cases written for the following three GST treatments: deemed export, composition and UIN holder. **After this PR:** Test cases have been added for the deemed export, composition and UIN holder GST treatments. **task**-3892511 Forward-Port-Of: odoo/enterprise#63333
Original PR description
**Before this PR:** There were no test cases written for the following three GST treatments: deemed export, composition and UIN holder. **After this PR:** Test cases have been added for the deemed export, composition and UIN holder GST treatments. **task**-3892511 Forward-Port-Of: odoo/enterprise#63333
Currently the tax lock date is not checked correctly in a test when posting a move. This problem is solved in the related community PR. This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date. community PR: https://github.com/odoo/odoo/pull/170475 Forward-Port-Of: odoo/enterprise#65262
Original PR description
Currently the tax lock date is not checked correctly in a test when posting a move. This problem is solved in the related community PR. This commit ensures the test does not fail after the community fix. To do this we just remove and re-introduce the tax lock date. community PR: https://github.com/odoo/odoo/pull/170475 Forward-Port-Of: odoo/enterprise#65262
This will add a rule for the "Crédit d'impôt salaire social minimum" to the Luxembourg loca. Task: 3970762 Forward-Port-Of: odoo/enterprise#65178 Forward-Port-Of: odoo/enterprise#64257
Original PR description
This will add a rule for the "Crédit d'impôt salaire social minimum" to the Luxembourg loca. Task: 3970762 Forward-Port-Of: odoo/enterprise#65178 Forward-Port-Of: odoo/enterprise#64257
When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles. In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates. Steps to reproduce the issue: 1. Log in as "Admin". 2
Original PR description
When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model…
When we introduced dynamic templates in Knowledge, we merged the models `knowledge.article` and `knowledge.article.template` and introduced a new field `is_template` in the `knowledge.article` model to distinguish the templates from the regular articles. In the `website_helpdesk_knowledge` module, we forgot to exclude the templates from the search domains. As a result, the helpdesk frontend view can list and search within templates. Steps to reproduce the issue: 1. Log in as "Admin". 2. Install `website_helpdesk_knowledge` module. 3. Go on the Helpdesk module. 4. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card. 5. On the dropdown menu, click on the "Settings" option. 6. On the "Help Center" section, click on the "Knowledge" option. 7. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option. 8. Save the changes. 9. Go on the Website module. 10. On the website navbar, click on "Customer Care" nav bar. 11. The interface should list article templates. => TO BE: The system should not list any templates. To fix that issue, we will simplify the search domains and exclude the templates from the search results using the `is_template` field. Reference: https://github.com/odoo/enterprise/pull/48691 task-3987469 Forward-Port-Of: odoo/enterprise#64468
This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc). If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](ht
Original PR description
This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point…
This PR fixes the mobile responsiveness inside the reconciliation in `account_accountant`. The width of the elements was too small and the `overflow` value broke the layout on mobile view. The point is to make the data at least readable on mobile, but this could be improved in the near future (eg. less data shown to user, displayed another way like a list-group, etc). If barcode is installed, the buttons are half-hidden under the control-panel. This is fixed in this [Enterprise/#63271](https://github.com/odoo/enterprise/pull/63271). task-3358275 Related to task-3326263 | Before | After | |--------|--------| | <img width="408" alt="Screenshot 2024-05-27 at 14 19 32" src="https://github.com/odoo/enterprise/assets/108661430/56ac88f0-22e4-498c-a5f2-ea9ef9316a80"> | <img width="407" alt="Screenshot 2024-05-27 at 14 31 49" src="https://github.com/odoo/enterprise/assets/108661430/be2bdb9a-c1de-4280-bf07-2d5257d74c3d"> | | | <img width="408" alt="Screenshot 2024-05-27 at 14 32 00" src="https://github.com/odoo/enterprise/assets/108661430/fecb7a25-04c3-48d0-a555-67c2a4aa45d4"> | Forward-Port-Of: odoo/enterprise#45256
Forward-Port-Of: odoo/enterprise#65133 Forward-Port-Of: odoo/enterprise#64969
Original PR description
Forward-Port-Of: odoo/enterprise#65133 Forward-Port-Of: odoo/enterprise#64969
Forward-Port-Of: odoo/enterprise#65312
Original PR description
Forward-Port-Of: odoo/enterprise#65312
**Current behavior:** Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation. **Expected behavior:** These extra lines will get the o_faulty class. **Steps to reproduce:** 1. Create a picking in the Inventory app, mark it as to-do 2. In the Barcode app, go to the picking and scan the product 3. After scanning the original demand quantity, scan it again 4. See that it
Original PR description
**Current behavior:** Excess lines which are created during a barcode picking flow do not get the o_faulty class which distinguishes them as not being planned during the picking's creation. **Expected behavior:** These extra lines will get the o_faulty class. **Steps to reproduce:** 1. Create a picking in the Inventory app, mark it as to-do 2. In the Barcode app, go to the picking and scan the product 3. After scanning the original demand quantity, scan it again 4. See that it doesn't get the o_faulty class **Cause of the issue:** The lineIsFaulty() method is checking defunct properties to determine whether they should get this css class. **Fix:** Update the check so it uses an existing property. opw-3904661 Forward-Port-Of: odoo/enterprise#65200 Forward-Port-Of: odoo/enterprise#63285
We are unable to update the 'create date' and 'write date' through the ORM method. Therefore, I used a patch. task-4004191 Forward-Port-Of: odoo/enterprise#65151
Original PR description
We are unable to update the 'create date' and 'write date' through the ORM method. Therefore, I used a patch. task-4004191 Forward-Port-Of: odoo/enterprise#65151
When sending the organisation number to the sweden blackbox, we only accept numbers. At the moment, the organisation number in the company should be: XXXXXX-XXXX. So we have to remove the dash in order to be able to send the number to the device. Forward-Port-Of: odoo/enterprise#65061
Original PR description
When sending the organisation number to the sweden blackbox, we only accept numbers. At the moment, the organisation number in the company should be: XXXXXX-XXXX. So we have to remove the dash in order to be able to send the number to the device. Forward-Port-Of: odoo/enterprise#65061
Steps to reproduce: 1. Open the split tool, select a few pages, and create an expense for instance 2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred Technical reason: When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value. After this commit: No traceback will occur and if it can't
Original PR description
Steps to reproduce: 1. Open the split tool, select a few pages, and create an expense for instance 2. Once the pages are gone, navigate with the keyboard 3: Traceback occurred Technical reason: When we navigated using the left arrow, it couldn't find the documents we were targeting. In the '_focusNextPage' function, inside 'PdfManager' it was attempting to access elements like 'arr[-2]', which resulted in an 'undefined' value. After this commit: No traceback will occur and if it can't find the previous or next selected page, it focuses on the first page by default. Task-3874151 Forward-Port-Of: odoo/enterprise#62244