Daily updates from Odoo
Wednesday, October 9, 2024
92 changes
15 changes
Features or functions removed from Odoo
A redundant internal selector option in the web testing tools was removed because it duplicated existing functionality. This keeps the codebase cleaner with no expected impact on business users or normal application behavior.
Original PR description
This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *
Original PR description
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document **Issue:** The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes. opw-4034659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182730 Forward-Port-Of: odoo/odoo#179289
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 42040
Original PR description
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 4204048 Forward-Port-Of: odoo/odoo#181809
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
Original PR description
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corre
Original PR description
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the…
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corresponding lines should be the inverse of those which are generated by this action when the product's on-hand quantity is positive. **Steps to reproduce:** 1. Enable automatic accounting, create a stored product whose category has `FIFO` costing and `real_time` valuation 2. Create an in move for the product so it gets some cost assigned to it 3. Create an out move for more of the product than is currently in stock (so it's on-hand qty becomes negative) 4. Change the product category's `cost_method` to average/AVCO 5. Observe the journal items created by this action in the accounting application -> see that the stock valuation account is credited in both of the created moves **Cause of the issue:** The replenishing move's debiting/crediting accounts are currently adjusted if the associated SVL's quantity is non-positive, but the preceding emptying move's accounts are not. This results in the mismatch. **Fix:** Similarly adjust the emptying move accounts as was done to the replenishing move in commit: f7e3ada opw-4127737 Forward-Port-Of: odoo/odoo#182304
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182181 Forward-Port-
Original PR description
Steps to reproduce: - have two companies A and B - create a new partner - create a new payment term for Company A - In Company A, set the customer's payment term the newly created one - Configure aliases for invoice in company A and B - Make sure the default company for OdooBot is COmpany A - Send an email to company B Issue: Access Error Cause: payment_term is pre-compute and the company context is the one of OdooBot opw-4103229 Forward-Port-Of: odoo/odoo#182181 Forward-Port-Of: odoo/odoo#178829
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries
Original PR description
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the…
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries to enter in edit mode, the `FacebookPageWidget` public widget is destroyed and the system tries to disconnect `this.resizeObserver`. As it is not defined, the system fails in the `destroy()` method. Steps to reproduce the second bug: - Add an "Image-Text" snippet on the website. - Add a "Text-Image" snippet under the "Image-Text" one. - Save and edit. - Drop a "Facebook" snippet on the "Image-Text" snippet. - Move the "Facebook" snippet on the "Text-Image" snippet. - Click on the undo button. -> Two iframes are on the Facebook snippet. The problem is that since [1], the editor observer is not deactivated when removing the iframe in the `destroy()` method of the `FacebookPageWidget` widget. Finally, this commit also adds back the `frameborder` and `allowTransparency` attributes on the iframe (removed due to [1]) and sets the width and height in the style attribute. Although the `frameborder` and `allowTransparency` attributes are deprecated, this commit adds them back in case a potential customization relies on it. [1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25 task-4220972 Forward-Port-Of: odoo/odoo#182810 Forward-Port-Of: odoo/odoo#182134
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
Original PR description
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
Original PR description
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767
Original PR description
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182767
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Original PR description
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but afte
Original PR description
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but after the `inline` process of the template we convert rgba colors to hex color with `rgbToHex` because some email engines doesn't support rgba. As a result, we will have a black div that covers the background image in the sent email. Solution: ========= Rever the change. task-4070400 Forward-Port-Of: odoo/odoo#177174
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182743 Forward-Port-Of: odoo/odoo#180758
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182743 Forward-Port-Of: odoo/odoo#180758
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
Original PR description
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons - **Validity**: Today's date for example - Conditional rule with a **Minimum Purchase** of 0.00 - Start a new POS session. Add a product and click **Payment**. - **Validate** the order. - In the receipt shown, notice how the text show **_'Valid until: no expiration'_** althoug
Original PR description
### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons…
### Steps to reproduce:
- Install **pos_loyalty** module
- Go to **Point of Sale** app > **Products** > **Discount & Loyalty**
- Create a **New** program with:
- **Program Type**: Next Order Coupons
- **Validity**: Today's date for example
- Conditional rule with a **Minimum Purchase** of 0.00
- Start a new POS session. Add a product and click **Payment**.
- **Validate** the order.
- In the receipt shown, notice how the text show **_'Valid until: no expiration'_** although a Validity date is defined!
### Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78
opw-3838427
Forward-Port-Of: odoo/odoo#170295
Forward-Port-Of: odoo/odoo#16063318 changes
Enhancements to existing features
Upsell order pages now show discount information even when the discount is negative. This gives customers clearer, more consistent pricing details and improves related customer-facing notes.
Original PR description
**Before this PR:** Previously, in the upsell order portal view, if the discount was less than 0, the discount field was hidden. This led to confusion as users could not see the applied discounts. **After this PR:** This improvement enables the discount field to be visible for upsell orders even if the discount is negative. The change ensures that users have clearer information because all discounts, positive or negative, are displayed consistently. task-4033128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This update reorganizes and cleans up the manufacturing shop floor interface code, including dialogs, popups, controls, and employee panels. It should make the shop floor experience easier to maintain and support without introducing major functional changes for users.
Miscellaneous changes
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
Original PR description
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
Just add a fixed checkDelay at 50ms to make the tour go faster. By default, checkDelay is 750ms. Forward-Port-Of: odoo/enterprise#71517
Original PR description
Just add a fixed checkDelay at 50ms to make the tour go faster. By default, checkDelay is 750ms. Forward-Port-Of: odoo/enterprise#71517
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](
Original PR description
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842) Forward-Port-Of: odoo/enterprise#71407 Forward-Port-Of: odoo/enterprise#71379
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occu
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 Forward-Port-Of: odoo/enterprise#71355 Forward-Port-Of: odoo/enterprise#69760
Steps to reproduce =============== 1. Go to knowledge as an admin and add some articles in the workspace with visibility for members 2. Log in as demo and search through hidden articles -> Only demo articles are visible and hidden articles are not visible. Issue =============== From the commit https://github.com/odoo-dev/enterprise/commit/c73484ba1c26a63fd8e5659d2feb25604c99bc3e only favorite articles were returned in the search initially. After this commit =============== This c
Original PR description
Steps to reproduce =============== 1. Go to knowledge as an admin and add some articles in the workspace with visibility for members 2. Log in as demo and search through hidden articles -> Only demo articles are visible and hidden articles are not visible. Issue =============== From the commit https://github.com/odoo-dev/enterprise/commit/c73484ba1c26a63fd8e5659d2feb25604c99bc3e only favorite articles were returned in the search initially. After this commit =============== This commit will show all (max is 40) hidden articles for an empty search. Task-4141105 Forward-Port-Of: odoo/enterprise#69407
Because of odoo/enterprise@aba680d65ae22f829f7e21e85df1dc86995ec460 it was not possible anymore to create related fields to one2many's in studio. It was just a little mistake in the way the in-expression assignation was written task-4150539 Forward-Port-Of: odoo/enterprise#71482
Original PR description
Because of odoo/enterprise@aba680d65ae22f829f7e21e85df1dc86995ec460 it was not possible anymore to create related fields to one2many's in studio. It was just a little mistake in the way the in-expression assignation was written task-4150539 Forward-Port-Of: odoo/enterprise#71482
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning'
Original PR description
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales…
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning' in Settings > Planning - Go to Project > : Menu > 'Timesheet and planning analysis' - Under the Measures dropdown, add all columns You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet. opw-3918082 Forward-Port-Of: odoo/enterprise#71491 Forward-Port-Of: odoo/enterprise#71425
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **
Original PR description
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **[FIX] l10n_uy_edi: Create Uruware account help** Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly. **[FIX] l10n_uy_edi: Send and Print after Post** Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted. Forward-Port-Of: odoo/enterprise#70351
Since the entries are optional for payments [^1], the bank reconciliation widget was not working anymore because it was relying heavily on the fact that there are journal entries created. This commit introduces support for payments without entries by: * looking at payments instead of journal entries when relevant * not unfolding the batch payments anymore, cancelling/rejecting payments can be done through the batch payment form view * removing the payment rejection wizard, same reason [
Original PR description
Since the entries are optional for payments [^1], the bank reconciliation widget was not working anymore because it was relying heavily on the fact that there are journal entries created. This commit introduces support for payments without entries by: * looking at payments instead of journal entries when relevant * not unfolding the batch payments anymore, cancelling/rejecting payments can be done through the batch payment form view * removing the payment rejection wizard, same reason [^1]: https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892 Forward-Port-Of: odoo/enterprise#70778
This commit adapt the api of plugin resources to match the changes made in community. Forward-Port-Of: odoo/enterprise#70560
Original PR description
This commit adapt the api of plugin resources to match the changes made in community. Forward-Port-Of: odoo/enterprise#70560
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
Original PR description
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
In this commit: === - We consolidated these into a single, generic module: pos_urban_piper, designed to support all delivery providers integrated via Urban Piper. - Additionally, we introduced support for new delivery providers, including Careem, Talabat, Postmates, JustEat, EatEasy, Deliveroo, HungerStation, HungryPanda, DoorDash, Mrsool, Cari, ChowNow, Noon Food, Glovo, and Grubhub, and implemented their entire order flow management. Forward-Port-Of: odoo/enterprise#71215
Original PR description
In this commit: === - We consolidated these into a single, generic module: pos_urban_piper, designed to support all delivery providers integrated via Urban Piper. - Additionally, we introduced support for new delivery providers, including Careem, Talabat, Postmates, JustEat, EatEasy, Deliveroo, HungerStation, HungryPanda, DoorDash, Mrsool, Cari, ChowNow, Noon Food, Glovo, and Grubhub, and implemented their entire order flow management. Forward-Port-Of: odoo/enterprise#71215
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed i
Original PR description
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in…
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed in the list view instead of calling that rpc once. This commit moves that behavior in industry_fsm module since `get_create_edit_project_ids` method will only return fsm projects when the industry_fsm module is installed. Without that module, no project ids will be returned and so it is not really needed to do a rpc call for nothing. This commit also improves the changes to make sure the rpc call is made only once in the list view. Note: that behavior is not managed in the list view of All Timesheets since it would need to add a custom js class. It will be done in 18.0. task-4221621 Forward-Port-Of: odoo/enterprise#71434 Forward-Port-Of: odoo/enterprise#71183
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment method, so, if I receive a payment in any payment method and I register a payment, only a payment complement must be generated. Fixed the next case: 1. Generate a customer invoice with payment method: 99 - To define 2. Generate a second customer invoice with payment method: 01 - Efectivo 3. R
Original PR description
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment…
It has removed the `l10n_mx_edi_payment_method_id` from the batch key and avoids group payments with different payment methods. Any SAT reason indicates that must be grouped the payments by payment method, so, if I receive a payment in any payment method and I register a payment, only a payment complement must be generated. Fixed the next case: 1. Generate a customer invoice with payment method: 99 - To define 2. Generate a second customer invoice with payment method: 01 - Efectivo 3. Register a payment for the invoice 1 and 2 in cash In this case, only a payment complement for the total amount related to the 2 invoices must be generated. Note 1: If the user wants to generate 2 payment complements, 1 by each payment method, can select the records and register 2 payments. Note 2: The key was introduced here: https://github.com/odoo/enterprise/commit/b2dd65b9a9c054570d5796a81f2c390c4d8cb6c4#diff-8fbd6620744df804292d8f4158343ef05564035bed962f68bd5ef931d1cb9d70R29 but without any reference that indicates why this was necessary. Forward-Port-Of: odoo/enterprise#71306 Forward-Port-Of: odoo/enterprise#56628
This is the second part of the pr renaming `customerCount` to `customer_count`. Why the fix: ------------ After the refactoring https://github.com/odoo/odoo/commit/2a5f1abf2e98ee09fa7a912b87d71879b5ff260b, we use the same field structure as in python. Therefore, when we load/create a pos order we use `this.customerCount` is undefined since in python the field is called `customer_count`. https://github.com/odoo/odoo/blob/ae0b903b753decab1592df09a1e3cf1baa55f566/addons/pos_restaurant/static/
Original PR description
This is the second part of the pr renaming `customerCount` to `customer_count`. Why the fix: ------------ After the refactoring https://github.com/odoo/odoo/commit/2a5f1abf2e98ee09fa7a912b87d71879b5ff260b, we use the same field structure as in python. Therefore, when we load/create a pos order we use `this.customerCount` is undefined since in python the field is called `customer_count`. https://github.com/odoo/odoo/blob/ae0b903b753decab1592df09a1e3cf1baa55f566/addons/pos_restaurant/static/src/overrides/models/pos_order.js#L8 By changing `this.customerCount` for `this.customer_count` we not only retreive the correct field when loading an order in the session but we also send the correct information to the backend. opw-4182891 Community: https://github.com/odoo/odoo/pull/182529 Forward-Port-Of: odoo/enterprise#71362 Forward-Port-Of: odoo/enterprise#71328
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of:
Original PR description
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of: odoo/enterprise#71399 Forward-Port-Of: odoo/enterprise#69581
58 changes
Enhancements to existing features
Google Calendar integration credentials can now be customized more easily for specific customer setups. The authentication process also includes the customer's database identifier, helping Odoo handle calendar connections more reliably behind the scenes.
Original PR description
This commits changes the import of `_get_client_secret` which was being done directly to the function and now imports the whole class instead for making the service more overridable. Additionaly, it also adds the current customer's DB uuid in the authentication flow using it internally. task-4199388
This update makes the Microsoft Calendar connection setup easier to adapt for customer-specific needs. It also includes the customer's database identifier during Microsoft authentication, helping Odoo manage the sign-in flow more reliably behind the scenes.
Original PR description
This commits changes the import of `_get_microsoft_client_secret` which was being done directly to the function and now imports the whole class instead for making the service more overridable. Additionaly, it also adds the current customer's DB uuid in the authentication flow using it internally. task-4199388
The inventory overview layout has been tightened by reducing margins around dashboard elements. This makes the stock overview more compact, helping users see more information on screen with less scrolling.
Original PR description
Before:  After:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Knowledge app’s automated tour checks now run with a shorter waiting time. This speeds up internal validation without changing what users see or how the app works.
Original PR description
Just add a fixed checkDelay at 50ms to make the tour go faster. By default, checkDelay is 750ms.
Resolved issues and error corrections
This fix prevents an automated test for public Discuss call pages from failing unpredictably when background updates arrive before the join response. It improves test stability without changing the user-facing calling experience.
Original PR description
Before this commit, it was possible that a bus message containing a `mail.message.rtc.session` record update reached the client before the response to the `/mail/rtc/channel/join_call` route. Since the condition for the test step is that there is a call (triggered by the presence of a rtc session) while the condition for the error thrown is that there is no `selfSession` (which is obtained as the response of the http request), one condition could be satisfied without the other.
This fixes a problem where Odoo's data population process could stop after encountering limited database permissions. The process now recovers cleanly and continues, improving reliability for environments with restricted database privileges.
Original PR description
## Bug Following ba17d5df1cc6b360598d492046d06a66e0d11dda, a try/except was added to handle the lack of privileges to switch the replication mode of the database to ignore the check on Fkey during the bulk insertion. This fix ignored the fact that when Postgres throws an exception, the cursor is in an aborted state and is closed. Therefor the cursor needs to be reset/rollback to usable state to continue with the `populate` as intended by the user. ## Fix On the first model we try to `populate`, if an exception is raised due to `InsufficientPrivilege`, we rollback the cursor and update a flag so we skip on subsequent models. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes automated website sale loyalty tests run faster and more reliably by checking that page elements are ready before continuing. It helps reduce false test failures without changing the customer-facing shopping experience.
Original PR description
In this commit, we decrease checkDelay to make the tours faster. We add intermediate steps to ensure elements are in DOM before to continue the tour. 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
New lots or serial numbers for serial-tracked products are now initialized with the product's cost. This helps keep stock valuation accurate from the moment a lot is created, reducing accounting discrepancies.
Original PR description
Creating a new lot/serial of a product tracked by serial should be initialised with the product cost. 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 Peppol registration flow now shows a clear user-facing error if a required phone number validation component is not installed. This prevents confusing technical crash messages and helps administrators understand what needs to be installed to continue.
Original PR description
Before this commit, when we tried to import the module phonenumbers which might not be installed on the computer. We got a traceback. Now we raise an error if it could not be imported informing the user to import it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The dashboard edit shortcut now opens the specific dashboard the user selected, instead of always editing the currently active one. This prevents users from accidentally changing the wrong dashboard and makes dashboard management more reliable.
Original PR description
The newly added button shortcut to edit a dashboard would only always open the active dashboard edition and not the one we clicked on. Task-4236307 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix moves a self-ordering point of sale demo file into the proper demo data section. It helps ensure demo content is handled only as sample data, reducing the chance of it being loaded in regular installations.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes automated website checks that were occasionally failing for timing-related reasons. It helps keep website editing and navigation features stable by ensuring tests wait for changes to apply before continuing.
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
When the user tries to activate Portuguese (BR) language, a traceback will appear. Traceback: ``` OSError: Syntax error in po file (line 340): unescaped double quote found File "odoo/tools/translate.py", line 1757, in _get_code_translations p = CodeTranslations._read_code_translations_file(fileobj, filter_func) File "odoo/tools/translate.py", line 1744, in _read_code_translations_file reader = TranslationFileReader(fileobj, fileformat='po') File "odoo/tools/translate.py"
Original PR description
When the user tries to activate Portuguese (BR) language, a traceback will appear. Traceback: ``` OSError: Syntax error in po file (line 340): unescaped double quote found File…
When the user tries to activate Portuguese (BR) language,
a traceback will appear.
Traceback:
```
OSError: Syntax error in po file (line 340): unescaped double quote found
File "odoo/tools/translate.py", line 1757, in _get_code_translations
p = CodeTranslations._read_code_translations_file(fileobj, filter_func)
File "odoo/tools/translate.py", line 1744, in _read_code_translations_file
reader = TranslationFileReader(fileobj, fileformat='po')
File "odoo/tools/translate.py", line 735, in TranslationFileReader
return PoFileReader(source)
File "odoo/tools/translate.py", line 790, in __init__
self.pofile = polib.pofile(source.read().decode())
File "polib.py", line 130, in pofile
return _pofile_or_mofile(pofile, 'pofile', **kwargs)
File "polib.py", line 78, in _pofile_or_mofile
instance = parser.parse()
File "polib.py", line 1348, in parse
raise IOError('Syntax error in po file %s(line %s): '
```
https://github.com/odoo/odoo/blob/11cbd44ada7526849f884b5b16c52a8965d10708/addons/l10n_br/i18n/pt.po#L340
Here, ``"Alagoin"Alagoinha"`` is used instead of ``"Alagoinha"`` as msgstr.
So, it will lead to the above traceback.
sentry-5963927752
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSpreadsheet unit tests now correctly recognize messages written by the current user. This improves confidence in spreadsheet-related messaging features, especially editing messages authored by the signed-in user.
Original PR description
self-authored messages were not properly detected in spreadsheet unit tests, due to lack of `@web/session` data for the current user. `@web/session` in unit test require explicit patch in order to retrieve the `store.self` data for the good working of Discuss code, especially for features that are conditionally enabled based on the currently authenticated user, like message edition that works on self authored messages. <img width="457" alt="Screenshot 2024-10-09 at 11 33 13" src="https://github.com/user-attachments/assets/e3eff763-e58b-45fe-98c5-58374dd576d6">
The website editor now shows the correct left and right move arrows when repositioning showcase block columns. This removes confusion for editors and makes arranging showcase content behave as expected.
Original PR description
Since [1] when the layout of the `s_showcase` block has been revamped, the selectors of the `SnippetMove` option wrongly match the new external column layout of the block. Because of this, up/down arrows appear instead of left/right arrows. This commit restores the horizontal `SnippetMove` on the external columns of the `s_showcase` block. [1]: https://github.com/odoo/odoo/commit/fe52cb6780ab253e45f40607b1a192aab19fb3a2 task-4206919
The planning calendar now correctly reflects an employee's contract end date without showing an additional shaded day. This prevents managers from mistakenly thinking an employee is still covered by a contract for an extra day when planning shifts.
Original PR description
Steps to reproduce:
- Create a employee with running contract.
- Open planning app.
- Create a planning for him.
- Move through gantt date to employee' contract end date.
Issue:
- You can see there there as extra date being shown white which means he is
contract for visual indication but not in backend.
Fix:
- Handling timezone issues.
task-3815229The dashboard edit shortcut now opens the specific dashboard the user selected, rather than always opening the currently active dashboard. This prevents confusion and ensures users can edit the intended dashboard directly.
Original PR description
The newly added button shortcut to edit a dashboard would only always open the active dashboard edition and not the one we clicked on. Task-4236307
Miscellaneous changes
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_sa_edi_pos** * Switch to the **SA Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Enterprise PR: https://github.com/odoo/enterprise/pull/70505 Forward-Port-Of: odoo/odoo#182232 Forward-Port-Of: odoo/odoo#181068
Commit [958b41c4] added support to block third-party cookies, but some flows on mobile did not work properly. Steps to reproduce (on Chrome): - Enable the Cookies Bar in the settings and check "Block tracking 3rd-party services" - Add a Cover block (or another block) - Set a YouTube video as background of the block - Open an incognito window - Resize it so that it displays the page in the mobile version - Refresh the page => AssetsLoadingError: The loading of https://www.youtube.com/ifr
Original PR description
Commit [958b41c4] added support to block third-party cookies, but some flows on mobile did not work properly. Steps to reproduce (on Chrome): - Enable the Cookies Bar in the settings and check "Block tracking 3rd-party services" - Add a Cover block (or another block) - Set a YouTube video as background of the block - Open an incognito window - Resize it so that it displays the page in the mobile version - Refresh the page => AssetsLoadingError: The loading of https://www.youtube.com/iframe_api failed [958b41c4]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 opw-4202306 Forward-Port-Of: odoo/odoo#181764
Since [1] when the "Stretch" option was added on shape, upon changing that option the ImageTools XML is re-rendered to make sure the available widths in the "Format" option are up to date, but that operation is not awaited. Because of this, the widgets might not be available yet during `updateUI`, which leads to an error. This commit fixes this by awaiting the calls to `_onImageCropped`. No problem was identified for the second call, but the missing `await` is added by this commit anyway.
Original PR description
Since [1] when the "Stretch" option was added on shape, upon changing that option the ImageTools XML is re-rendered to make sure the available widths in the "Format" option are up to date, but that operation is not awaited. Because of this, the widgets might not be available yet during `updateUI`, which leads to an error. This commit fixes this by awaiting the calls to `_onImageCropped`. No problem was identified for the second call, but the missing `await` is added by this commit anyway. Steps to reproduce: - Edit a website page - Drop a "Columns" block - Select first image - Apply shape on image (e.g. Tear) - Activate "Stretch" - Set "Animation" to "On hover" - Save - Edit - Disable "Stretch" => An error dialog was displayed [1]: https://github.com/odoo/odoo/commit/c66ae88eaa275d1b87693f329d3b2622c0534c33#diff-ffb61e86e6b8297ef8997f9c605de14de896b54161c032d88a80bbaeac4f89beR6657 opw-4192761 Forward-Port-Of: odoo/odoo#182711
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182573 Forward-Port-Of: odoo/odoo#178909
task-4219465 Forward-Port-Of: odoo/odoo#182712
Original PR description
task-4219465 Forward-Port-Of: odoo/odoo#182712
Currently, a traceback occurs when the user removes the company while creating a PO with a multi-company environment. To reproduce this issue: 1) Install Purchase order 2) Switch to multi-company environment 3) Create a PO and remove the company value from other information Error:- ``` ValueError: Expected singleton: res.currency() ``` When the user removes the company, its value becomes False. This leads to an empty currency record set as the currency fetches from the comp
Original PR description
Currently, a traceback occurs when the user removes the company while creating a PO with a multi-company environment. To reproduce this issue: 1) Install Purchase order 2) Switch to multi-company environment 3) Create a PO and remove the company value from other information Error:- ``` ValueError: Expected singleton: res.currency() ``` When the user removes the company, its value becomes False. This leads to an empty currency record set as the currency fetches from the company. https://github.com/odoo/odoo/blob/97de468e6943b1a13998503deb436eaa38cdaafe/addons/purchase/models/purchase_order.py#L226-L230 It leads to the above traceback sentry-5939949508 Forward-Port-Of: odoo/odoo#182500
This commit fixes a bug where the search input would only work when it was hovered. This was caused by the navigation hook used by the dropdown which would focus the items on hover, loosing the focus of the search input in the process. Task: 4207756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182118
Original PR description
This commit fixes a bug where the search input would only work when it was hovered. This was caused by the navigation hook used by the dropdown which would focus the items on hover, loosing the focus of the search input in the process. Task: 4207756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182118
Steps to reproduce: 1. In the Chilean localization, create a new invoice with a discount. 2. Confirm and send. The behavior: The Discount Amount is displayed under the Discount Percentage, and vice versa. Why this was the case: The Discount table header was placed after the Price Unit header (`th_priceunit`), and its data was displayed after the Discount Percentage (`th_discount`). OPW-4112378 Forward-Port-Of: odoo/odoo#179127
Original PR description
Steps to reproduce: 1. In the Chilean localization, create a new invoice with a discount. 2. Confirm and send. The behavior: The Discount Amount is displayed under the Discount Percentage, and vice versa. Why this was the case: The Discount table header was placed after the Price Unit header (`th_priceunit`), and its data was displayed after the Discount Percentage (`th_discount`). OPW-4112378 Forward-Port-Of: odoo/odoo#179127
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#178931 Forward-Port-Of: odoo/odoo#174750
Original PR description
Fixed some missing / incorrect translations of account names in the chart template. Forward-Port-Of: odoo/odoo#178931 Forward-Port-Of: odoo/odoo#174750
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
Original PR description
Lots of contact information has been changed and some banks has been sold their bisiness portfolio over the years. In some cases the telephone and email links were in the wrong order. Some of the banks were merged or under Sanctions. (Sberbank, IC, MKB, Budapest, Commerz, FHB... ) Original credits to `kerteszgergo`: odoo/odoo#108301 Forward-Port-Of: odoo/odoo#181547
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corre
Original PR description
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the…
**Current behavior:** Changing the cost method of a product's category when that product has a negative on-hand quantity will result in illogical account move's being created during the empty/replenish mechanism which revalues the inventory. Specifically, the stock valuation account will be credited twice, once in each move, the stock input account debited in the emptying move, and the stock output account debited in the replenishing move. **Expected behavior:** The moves and their corresponding lines should be the inverse of those which are generated by this action when the product's on-hand quantity is positive. **Steps to reproduce:** 1. Enable automatic accounting, create a stored product whose category has `FIFO` costing and `real_time` valuation 2. Create an in move for the product so it gets some cost assigned to it 3. Create an out move for more of the product than is currently in stock (so it's on-hand qty becomes negative) 4. Change the product category's `cost_method` to average/AVCO 5. Observe the journal items created by this action in the accounting application -> see that the stock valuation account is credited in both of the created moves **Cause of the issue:** The replenishing move's debiting/crediting accounts are currently adjusted if the associated SVL's quantity is non-positive, but the preceding emptying move's accounts are not. This results in the mismatch. **Fix:** Similarly adjust the emptying move accounts as was done to the replenishing move in commit: f7e3ada opw-4127737 Forward-Port-Of: odoo/odoo#182304
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167565 Forward-Port-Of: odoo/odoo#153993
Original PR description
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#167565 Forward-Port-Of: odoo/odoo#153993
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
Original PR description
The Issue: Before this commit, assigning a URL to the page triggered the write function. Within this function, the get_current_website function returned a different website than the one in the test. As a result, the rest of the code applied to this incorrect website instead of the appropriate one. The Fix: Pass the correct website within the context runbot-54617 Forward-Port-Of: odoo/odoo#177598 Forward-Port-Of: odoo/odoo#176032
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
Original PR description
This commit will change the name of some account group. task:4186654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180719
Before these changes, the total price of the invoices was displayed in the kanban view without considering whether it was an outgoing or incoming payment. This can cause confusion for the user when charging customers.  After these changes, the total is displayed with the symbol so that users can easily differentiate the type of invoice, just as it is done in the tree views.  After these changes, the total is displayed with the symbol so that users can easily differentiate the type of invoice, just as it is done in the tree views.  cc @Tecnativa TT50987 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182549 Forward-Port-Of: odoo/odoo#181424
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
Original PR description
odoo/enterprise#69056 Forward-Port-Of: odoo/odoo#178173
Steps to reproduce ================== 1) Create a Bill of Materials 2) Select a product 3) Add an operation 4) Save 5) Click on the Show Instructions button 6) Create three instructions [A, B, C] 7) Go back to the instructions list 8) The order is [A, B, C] 9) Swap the last two instructions (move the third one before the second one) 10) The order should now be [A, C, B] 11) Create a new instruction D 12) Go back to the instructions list 13) The order should be [A, C, B, D] 14) M
Original PR description
Steps to reproduce ================== 1) Create a Bill of Materials 2) Select a product 3) Add an operation 4) Save 5) Click on the Show Instructions button 6) Create three instructions [A, B, C] 7)…
Steps to reproduce ================== 1) Create a Bill of Materials 2) Select a product 3) Add an operation 4) Save 5) Click on the Show Instructions button 6) Create three instructions [A, B, C] 7) Go back to the instructions list 8) The order is [A, B, C] 9) Swap the last two instructions (move the third one before the second one) 10) The order should now be [A, C, B] 11) Create a new instruction D 12) Go back to the instructions list 13) The order should be [A, C, B, D] 14) Move the fourth one one slot up 15) The order should be [A, C, D, B] 16) Go back to the BOM 17) Click again on the Show Instructions button 18) The order has now changed and is [A, D, C, B] Cause of the issue ================== The quality.point model has no default value for the sequence field. Instructions are created from a form view -> There is no context as to which sequence we should choose the be the last one. We pass no value for the sequence field when creating a record -> NULL is what's actually saved in the database. When the webclient reads the records, it receives 0 instead of NULL for the sequence value. Here are the ordered values by sequence at step 8: ``` +------+----------+ | name | sequence | |------+----------| | A | <null> | | B | <null> | | C | <null> | +------+----------+ ``` Step 9: The webclient reorders [A, C, B] with no offset Step 10: ``` +------+----------+ | name | sequence | |------+----------| | A | 0 | | C | 1 | | B | 2 | +------+----------+ ``` Step 13: ``` +------+----------+ | name | sequence | |------+----------| | A | 0 | | C | 1 | | B | 2 | | D | <null> | +------+----------+ ``` Step 14: The webclient reorders [D, B] with no offset Step 15: ``` +------+----------+ | name | sequence | |------+----------| | A | 0 | | D | 0 | | B | 1 | | C | 1 | +------+----------+ ``` Currently these are the cases where we reorder every record: - If the sections outside the edited range are not sorted - If we are inside the modified range and adjacent records have the same sequence Since the webclient has no idea if a value is null or not, we don't reorder every record in step 14 Solution ======== Since there is no easy way to guess if a record has a NULL value, we reorder every record if the initial list is not strictly ordered. Limitations =========== This doesn't properly handle cases were there are multiple pages, or if there is a domain applied. This is already the case without NULLs. Alternate solutions =================== Return the record from the server ordered as if NULL was equal to 0 ------------------------------------------------------------------- A lot of usecases actually depends on this behaviour and we can't change that. Set a default on the field -------------------------- We can't choose a default value that would always result in new records being the latest one. With Int.MAX, we can't resequence as this simply increments the existing sequence. This doesn't handle existing records having a NULL value. A new field type fields.Sequence() ---------------------------------- This can't be done in stable and we would need to migrate existing data opw-4032273 Forward-Port-Of: odoo/odoo#182440 Forward-Port-Of: odoo/odoo#181380
The computation of ODOO.BALANCE with year offsets was wrong as we would apply the offset once to query the debit data and TWICE when querying the credit data, making the computation of the delta completely meaningless. Task-4207414 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#182559 Forwa
Original PR description
The computation of ODOO.BALANCE with year offsets was wrong as we would apply the offset once to query the debit data and TWICE when querying the credit data, making the computation of the delta completely meaningless. Task-4207414 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#182559 Forward-Port-Of: odoo/odoo#181256
Before this commit, due to the commit https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd, when the user goes to list view of timesheets, he could be disconnect due to a many rpc calls made to get the projects for which we only allow to create and edit task (because some fields could be required). This commit moves most of changes made in https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd in enterprise since only with hr_timesheet module
Original PR description
Before this commit, due to the commit https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd, when the user goes to list view of timesheets, he could be disconnect due to a many rpc calls made to get the projects for which we only allow to create and edit task (because some fields could be required). This commit moves most of changes made in https://github.com/odoo/odoo/commit/a5e27d8f6fad33f9dcd6121b42d4698009627bfd in enterprise since only with hr_timesheet module installed, we will never get a project for which we don't want to allow the quick create on task_id field. Impacted versions: 17.0+ task-4221621 Forward-Port-Of: odoo/odoo#182733 Forward-Port-Of: odoo/odoo#182303
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Original PR description
In #171244, we prevented users from modifying account codes on German CoAs, as part of changes for GoBD compliance. However, when the user exports and re-imports an entire CoA in Excel, `write` is still called on the account code, even if it doesn't change. With this commit, we don't raise if the code doesn't actually change. Back-port of #181234 task-4192627 Forward-Port-Of: odoo/odoo#182821
Similar issue than the one fixed here [^1], if a spreadsheet already contained a pivot with some pivot-view related context, it would be used to load the pivot model inside spreadsheet. This becomes a bigger issue in later versions where we added extented granularity. [^1]: https://github.com/odoo/enterprise/issues/44075 Task: 4129333 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I ha
Original PR description
Similar issue than the one fixed here [^1], if a spreadsheet already contained a pivot with some pivot-view related context, it would be used to load the pivot model inside spreadsheet. This becomes a bigger issue in later versions where we added extented granularity. [^1]: https://github.com/odoo/enterprise/issues/44075 Task: 4129333 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#182612 Forward-Port-Of: odoo/odoo#177428
When installing an industry from the database, the list of dependencies to install is displayed in the dialog box. This is not clear nor necessary for the user and is therefore removed. Also, a message better alerts the user about loading demo data on a database. task-4096849 Forward-Port-Of: odoo/odoo#182783 Forward-Port-Of: odoo/odoo#180035
Original PR description
When installing an industry from the database, the list of dependencies to install is displayed in the dialog box. This is not clear nor necessary for the user and is therefore removed. Also, a message better alerts the user about loading demo data on a database. task-4096849 Forward-Port-Of: odoo/odoo#182783 Forward-Port-Of: odoo/odoo#180035
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on the last day of the month > Save - Management > Allocations > New - Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan - Set the start date to today - 0 days of allocation for 'Time off type' of your choice > Validate - My time > Dashboard > Use 'Balance at the mm/
Original PR description
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on…
Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'
The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.
The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid re-computations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.
This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.
Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.
opw-4192703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#181115Since [1] when miscellaneous trackers were disabled until cookies are accepted, `s_map` generates its URL if the `iframe` is not inside the document. Unfortunately, it does it before adding the `iframe` to the element and this results in an error. This commit reorders the operations so that the `iframe` source is set only once the element has an `iframe`. Steps to reproduce: - Edit an event - Make sure to disable the event's sub-menu - Drop an `s_map` into the event's `description` fiel
Original PR description
Since [1] when miscellaneous trackers were disabled until cookies are accepted, `s_map` generates its URL if the `iframe` is not inside the document. Unfortunately, it does it before adding the `iframe` to the element and this results in an error. This commit reorders the operations so that the `iframe` source is set only once the element has an `iframe`. Steps to reproduce: - Edit an event - Make sure to disable the event's sub-menu - Drop an `s_map` into the event's `description` field - Save => The `s_map` snippet failed upon `start`. [1]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1#diff-21d1f66e41f1c6b04a9c11edf6d4ff7d9773b0bf0b4f77c8cecea173f0c0db19R22 opw-4171564 Forward-Port-Of: odoo/odoo#182765
- In any APP (We would use CRM for the example); - On a multi-record view (Kanban, List, or other); - Click the action menu; - Click on “Import records” dropdown; - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, an exception was raised, and the default multi-record view was loaded. This occurs because, the client action base import required a model (found in the context) that was lost when reloading. Now,
Original PR description
- In any APP (We would use CRM for the example); - On a multi-record view (Kanban, List, or other); - Click the action menu; - Click on “Import records” dropdown; - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, an exception was raised, and the default multi-record view was loaded. This occurs because, the client action base import required a model (found in the context) that was lost when reloading. Now, the model is put in the query string of the URL (as active_model), in that way, when reloading, the client action base import will have the needed model. Note that, this is also the behavior of the stock TraceabilityReport client action [1]. opw-3959254 [1] : https://github.com/odoo/odoo/commit/8b3deab679bfee844ccd84c7f4f6f831921365d3 Forward-Port-Of: odoo/odoo#182744
Steps to reproduce: 1. Open the course content. 2. Exit the full screen. 3. Try to comment on the content. 4. The Send button on comments not working Technical Reason: In portal_chatter_post, a ValidationError was shown in the terminal: "Only a single review can be posted per course." This occurred because it was checking the 'res_id' in the 'slide.channel' model while being in the 'slide.slide' model. After this Commit: The send button on the comment should work properly on the cont
Original PR description
Steps to reproduce: 1. Open the course content. 2. Exit the full screen. 3. Try to comment on the content. 4. The Send button on comments not working Technical Reason: In portal_chatter_post, a ValidationError was shown in the terminal: "Only a single review can be posted per course." This occurred because it was checking the 'res_id' in the 'slide.channel' model while being in the 'slide.slide' model. After this Commit: The send button on the comment should work properly on the content. Task-4213443 Forward-Port-Of: odoo/odoo#182732 Forward-Port-Of: odoo/odoo#182153
before this PR: In a multi-company environment, the GST E-Invoice (India) option appears for all companies, regardless of the company's country after this PR: on Journal, GST E-Invoice (India) option appears for only Indian companies Forward-Port-Of: odoo/odoo#182690 Forward-Port-Of: odoo/odoo#181153
Original PR description
before this PR: In a multi-company environment, the GST E-Invoice (India) option appears for all companies, regardless of the company's country after this PR: on Journal, GST E-Invoice (India) option appears for only Indian companies Forward-Port-Of: odoo/odoo#182690 Forward-Port-Of: odoo/odoo#181153
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
Original PR description
Problem: The snailmail_cost field was not being computed because the compute method was not being called. Note: this will only work for newly created `account_followup.manual_reminder`. Steps to reproduce: - Enable "SnailMail" in Settings. - Navigate to Accounting > Follow-up Reports. - Open a report. - Follow up on the report. - Observe that the stamps count is 1, even if the partner has multiple follow-up contacts. opw-4160083 Forward-Port-Of: odoo/enterprise#71530
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When creating an invoice with the following amounts: - line 1: 505.0, tax_16 - line 2: 495.0, tax_16 - line 3: 475.0, tax_16 - set tax_16.price_include to True The CFDI result of the invoice when generated using "round globally" method on either normal or global sending will be rejected by the
Original PR description
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When…
This commit adds an additional step when aggregating the values for sending invoice CFDI, and ensures the final result to be within the allowed maximum rounding error of `0.01`. Purpose: When creating an invoice with the following amounts: - line 1: 505.0, tax_16 - line 2: 495.0, tax_16 - line 3: 475.0, tax_16 - set tax_16.price_include to True The CFDI result of the invoice when generated using "round globally" method on either normal or global sending will be rejected by the mexican authorities. This is caused by an inherent flaw of how Odoo calculates line amounts. The `compute_all` method in taxes rounds all the lines in cfdi_values to 2 digits precision in the final result, resulting in a loss of precision when calculating the total amounts. The mexican authorities requires us to make sure that: 1. the sum of the base/tax amounts in the lines (Conceptos) matches the total 2. the rounding of the total base and tax amount to be within 0.01 rounding error In the provided example, in Odoo, we will generate a total of 1271.54 base amount and 203.46 tax amount. This is not acceptable by the mexican government because 1271.54 * 0.16 equals 203.4464, which when compared with our result of the tax amount exceeds the maximum allowed rounding error. To fix this, we have to sacrifice our correctness and generate amounts that will have disrepancies whenever we need it (for global rounding method). We will now re-calculate the base and tax amounts in `cfdi_values` based on the total amount and generate new amounts with 6 digits precision, and apply that on each line of Conceptos. The 2 digit rounding precision limit on `Importe` and `ValorUnitario` XML will be changed to 6 digits to make sure we pass the first requirement, as the mexican authorities will also calculate their total and check if it matches our total. Due to this change, all of the test files than contain this element needs to be udpated too. task-id: 4071712 Forward-Port-Of: odoo/enterprise#69801 Forward-Port-Of: odoo/enterprise#68319
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_pe_edi_pos** * Switch to the **PE Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Ta
Original PR description
Currently, some localizations are not able to invoice if a combo product was bought. Steps to reproduce: ------------------- * Install **l10n_pe_edi_pos** * Switch to the **PE Company** * Go to the **Point of sale** App * Go to the products * Select a combo product * Navigate through all the products that can be selected in the combo and apply a tax on each * Open shop session * Add the combo product to the order * Validate and invoice the order > Observation: Invalid Operation: Taxes need to be assigned on all invoice lines Why the fix: ------------ Combo products do not have the possibility to be assigned a tax, as they are not supposed to. Taxes are computed for each product chosen and applies on that product. We can treat the parent combo line as the note or sections we would put on a quotation. opw-4090946 Community PR: https://github.com/odoo/odoo/pull/181068 Forward-Port-Of: odoo/enterprise#71143 Forward-Port-Of: odoo/enterprise#70505
Steps to reproduce =============== 1. Go to knowledge as an admin and add some articles in the workspace with visibility for members 2. Log in as demo and search through hidden articles -> Only demo articles are visible and hidden articles are not visible. Issue =============== From the commit https://github.com/odoo-dev/enterprise/commit/c73484ba1c26a63fd8e5659d2feb25604c99bc3e only favorite articles were returned in the search initially. After this commit =============== This c
Original PR description
Steps to reproduce =============== 1. Go to knowledge as an admin and add some articles in the workspace with visibility for members 2. Log in as demo and search through hidden articles -> Only demo articles are visible and hidden articles are not visible. Issue =============== From the commit https://github.com/odoo-dev/enterprise/commit/c73484ba1c26a63fd8e5659d2feb25604c99bc3e only favorite articles were returned in the search initially. After this commit =============== This commit will show all (max is 40) hidden articles for an empty search. Task-4141105 Forward-Port-Of: odoo/enterprise#69407
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occu
Original PR description
Problem: When multiple warehouses are selected in the products list page filter, clicking the Forecast button on the product page causes a traceback due to not handling multiple selected warehouses. This is part of this https://github.com/odoo/odoo/commit/f24ee4af8fb2fd21db703d87b9e6c06f6166ed98 Steps to reproduce: - Create two warehouses. - Go to Inventory > Products. - Add a filter for Warehouse 1 or Warehouse 2. - Open a product page. - Click the Forecast button. - Traceback occurs. opw-4149904 Forward-Port-Of: odoo/enterprise#71355 Forward-Port-Of: odoo/enterprise#69760
When having account_3way_match installed, the number and sum of bill to validate is not consistent with the bills displayed when clicking on the link. With this commit, we adapt the query to be consistent with `view_account_invoice_filter` which has been override. Steps: - Create 3 draft bills, $200 each: 1. invoice_date_due < today, release_to_pay != 'yes 2. invoice_date_due >= today, release_to_pay == 'yes' 3. invoice_date_due >= today, release_to_pay != 'yes' - Go to journal dashboard ->
Original PR description
When having account_3way_match installed, the number and sum of bill to validate is not consistent with the bills displayed when clicking on the link. With this commit, we adapt the query to be consistent with `view_account_invoice_filter` which has been override. Steps: - Create 3 draft bills, $200 each: 1. invoice_date_due < today, release_to_pay != 'yes 2. invoice_date_due >= today, release_to_pay == 'yes' 3. invoice_date_due >= today, release_to_pay != 'yes' - Go to journal dashboard -> On the vendor bill journal, we display 3 bills to validate and $600, although when clicking on the link we display only bills 1 and 2 opw-4182523 Forward-Port-Of: odoo/enterprise#71274 Forward-Port-Of: odoo/enterprise#70388
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning'
Original PR description
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales…
Steps to reproduce: - Create a product with the following settings: -- Product Type: Service; Invoicing Policy: Based on Timesheets -- Create on Order: Project & Task; Unit of Measure: Days -- Sales Price: 120 (Use != 100 when using Mitchel Admin) - Create a quotation for this product and confirm it - Created Task > Timesheets tab > Record 4 hours - Go to Planning > New > Create a 1 day shift for Mitchel Admin - Link that shift to the project created by your SO - Enable 'Project Planning' in Settings > Planning - Go to Project > : Menu > 'Timesheet and planning analysis' - Under the Measures dropdown, add all columns You will notice that the measures for revenue and margin are computed as though the unit price corresponds to 1h even though our product uom is Days. This makes the computations for revenues and margins completely wrong. This happens because the module converts all values into hours without accounting for the fact that the SOL unit price is not necessarily by the hour. This happens regardless of the 'Encoding Method' setting of Timesheet. opw-3918082 Forward-Port-Of: odoo/enterprise#71491 Forward-Port-Of: odoo/enterprise#71425
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **
Original PR description
**[FIX] l10n_uy_edi: Do not check latam document number** When an invoice sent to DGI returns errors (e.g., wrong partner or other data issues), users can reset it to draft and make corrections. However, changing the partner triggers a validation error because the invoice lacks a valid latam document number (only provided by DGI after processing). To avoid this, resetting the invoice to draft clears the invoice name, allowing users to fix any errors without triggering the validation. **[FIX] l10n_uy_edi: Create Uruware account help** Improved the helper to remove "admin email" (since it no longer applies) and updated translations accordingly. **[FIX] l10n_uy_edi: Send and Print after Post** Fixed an issue where the send and print wizard was triggered before the invoice was posted, causing errors. The wizard now only runs after the invoice has been successfully posted. Forward-Port-Of: odoo/enterprise#70351
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](
Original PR description
According to the documentation of the new Modelo 303 BOE export, the new fields that will be used for the declarations starting in 10/2024 or Q4/2024 "can only be completed from periods 10 and 4Q of 2024 and subsequent years". As such, we left the fields "empty" using the space character (like in other places). However, now that the new AEAT submission page is ready, it seems they expect us to fill the new fields with zeroes instead of leaving them empty. This commit fixes that. [opw-4222842](https://www.odoo.com/odoo/all-tasks/4222842) Forward-Port-Of: odoo/enterprise#71407 Forward-Port-Of: odoo/enterprise#71379
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
Original PR description
- In order to have more detail of the product used in the invoice, many companies place information in the label of the invoice line, we prioritize the name field to be displayed in the description tag of the xml. Forward-Port-Of: odoo/enterprise#70694
* test_whatsapp odoo/odoo#178173 Forward-Port-Of: odoo/enterprise#69056
Original PR description
* test_whatsapp odoo/odoo#178173 Forward-Port-Of: odoo/enterprise#69056
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed i
Original PR description
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in…
Before this commit, the changes made in community to call `get_create_edit_project_ids` method to know which projects we only allow to quick create a task on `task_id` field in `account.analytic.line` model (timesheets model) introduced a performance issue in the list view because the `TaskWithHours` component doing the rpc call inside `onWillStart` hook is mounted on each row displayed on the list view, this is, the number of rpc call to that method will be the number of the records displayed in the list view instead of calling that rpc once. This commit moves that behavior in industry_fsm module since `get_create_edit_project_ids` method will only return fsm projects when the industry_fsm module is installed. Without that module, no project ids will be returned and so it is not really needed to do a rpc call for nothing. This commit also improves the changes to make sure the rpc call is made only once in the list view. Note: that behavior is not managed in the list view of All Timesheets since it would need to add a custom js class. It will be done in 18.0. task-4221621 Forward-Port-Of: odoo/enterprise#71434 Forward-Port-Of: odoo/enterprise#71183
Previous behavior: - Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies. New behavior: - Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills. OPW: 4210068 Forward-Port-Of: odoo/enterprise#71446 Forward-Port-Of: odoo/enterprise#70225
Original PR description
Previous behavior: - Late bills were determined by comparing `supprd` with the `return period`, which led to inaccuracies. New behavior: - Late bills are now identified by checking if the `bill date` is earlier than the `return period start date`, ensuring more precise classification of late bills. OPW: 4210068 Forward-Port-Of: odoo/enterprise#71446 Forward-Port-Of: odoo/enterprise#70225
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of:
Original PR description
This commit adds a QR code (barcode) to the meixo delivery guide PDF (cartaporte). It is a legal requirement according to the filling guide point 4, but other than that, it is the one thing cops will scan to check if the document is real or not. The QR code is generated by taking the idccp, Salida, and LLegada data and insert them as a parameter to an URL pointing to the mexican service to display the data of the published version of the document. task-id: 4142920 Forward-Port-Of: odoo/enterprise#71399 Forward-Port-Of: odoo/enterprise#69581
1 change
Enhancements to existing features
This update reflects the official 2022 name change of the Republic of Turkey to the Republic of Türkiye. The change updates the country name across Turkish localization modules and their descriptions in the Odoo system to maintain accuracy and compliance with the country's official designation.
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#70304