Friday, November 15, 2024
24 changes · 18.0
Enhancements to existing features
Kitchen preparation cards now show the custom name of a floating order instead of only its tracking number. This helps staff identify orders more clearly and reduces confusion when order names have been changed.
Original PR description
Before this commit: ==================== Only the tracking number was shown on the kitchen card for floating orders. If the user changed the name of a floating order, it could create confusion if the displayed name was different. After this commit: ================== The floating order name will be displayed for floating orders, otherwise, the tracking number will be shown. task- 4274465
Resolved issues and error corrections
List views can now apply a configured column width to action buttons. This gives business teams more control over list layouts, especially where button columns need consistent spacing or alignment.
Original PR description
Before this commit, it was not possible to set the width attribute in a list view arch on `<button>` nodes. This commit allows it. One difficulty was that there's already some magic around button columns. Indeed, adjacent buttons in the arch are gathered in a single column. This doesn't map well with the width logic, as we want to be able to define a width on a button, which will thus define the width of its column. This can only work if the button is alone in its column. For that reason, when a button has a width, we do not group it with its potential adjacent buttons. Task~4307553 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
Miscellaneous changes
Steps to reproduce: 1. Open time off app. 2. Go to overview 3. select calendar view. 4. Employees' names are repeated twice on records. Fix: * Replace the repated employee's name with the name of the time off type. For example, Mitchell Mitchell 3 days would be replaced with Mitchell Paid Time Off 3 days. task-4128789 Forward-Port-Of: odoo/odoo#177422
Original PR description
Steps to reproduce: 1. Open time off app. 2. Go to overview 3. select calendar view. 4. Employees' names are repeated twice on records. Fix: * Replace the repated employee's name with the name of the time off type. For example, Mitchell Mitchell 3 days would be replaced with Mitchell Paid Time Off 3 days. task-4128789 Forward-Port-Of: odoo/odoo#177422
The rental website checkout test now targets the actually selected date instead of a visually highlighted date. This helps keep date selection behavior reliable as related date picker changes are introduced, reducing the risk of future checkout regressions.
Original PR description
This commit fixes a selector targetting the wrong property (datepicker "highlighted" date instead of the "selected" one). This becomes relevant in an incoming commit in community changing the overall selection in date pickers. Community: https://github.com/odoo/odoo/pull/184844 Part of task [3433683](https://www.odoo.com/odoo/project.task/3433683)
This fixes how adjustment values are handled in the Italian point of sale fiscal receipt flow. It helps ensure the fiscal printer receives the expected numeric value, reducing the risk of receipt printing errors for discounts or other item adjustments.
Original PR description
Change the adjustmentType prop type to Number instead of String
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186968
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186968
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email,
Original PR description
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email, you can check in the chatter. This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4260237) opw-4260237 Forward-Port-Of: odoo/odoo#186489
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the butto
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports /…
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the button has been clicked, the dropdown menu disappears behind the header of the report. **Cause:** The buttons in the dropdown menu have z-index:1000 and the thead of the report has the z-index:999, which displays the buttons in front the header of the report. However, when clicked, the button becomes active and its z-index falls to 2, putting it behind the header. opw-4265087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187147 Forward-Port-Of: odoo/odoo#186277
Steps to reproduce the issue: ============================= - Go to any chatter - Open email composer - Add seperator - Send - The seperator doesn't appear Origin of the issue: ==================== The issue was first introduced by [1] where we wanted to simplify the border-width to use only the style of 1 but it doesn't work correctly for `hr` element. We keep all border-with styles as grouping them all in one style can lead to very different ui. opw-4300018 [1]: https://github
Original PR description
Steps to reproduce the issue: ============================= - Go to any chatter - Open email composer - Add seperator - Send - The seperator doesn't appear Origin of the issue: ==================== The issue was first introduced by [1] where we wanted to simplify the border-width to use only the style of 1 but it doesn't work correctly for `hr` element. We keep all border-with styles as grouping them all in one style can lead to very different ui. opw-4300018 [1]: https://github.com/odoo/odoo/commit/3763d0e4c5cd97793721dc3404b403348ff2c2e8 Forward-Port-Of: odoo/odoo#186541
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale`` Steps to reproduce: --- - Install the ``point_of_sale`` module(without demo) - Change the right from ``Admin`` -> ``User`` in ``Point of Sale`` in Users - Now go to ``Dashboard`` and try to open any category Traceback: --- ```ParseError while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5, somewhe
Original PR description
We encounter an error when trying to open any POS category from the ``Dashboard``, if the Administrator is assigned the role of ``User`` for ``Point of Sale``
Steps to reproduce:
---
- Install the ``point_of_sale`` module(without demo)
- Change the right from ``Admin`` -> ``User`` in ``Point of Sale`` in Users
- Now go to ``Dashboard`` and try to open any category
Traceback:
---
```ParseError
while parsing /home/odoo/src/odoo/saas-17.4/addons/product/data/product_demo.xml:5, somewhere inside <record id="base.group_user" model="res.groups">
<field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
</record>
```
This commit will fix the above error by displaying an ``Access Denied`` pop-up for users with the ``User`` role when attempting to open the POS category.
sentry-5717539295
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#181228When a user visits a product page, the product gets marked as "recently viewed" after 8 seconds. This delay is too long, as a user can realistically view the product and navigate away before the 8 seconds have passed (in which case the product isn't marked as recently viewed). In particular, this is problematic when the website contains a "recently viewed products" carousel, where the user expects to see all products they recently viewed (even if they didn't stay on the product page f
Original PR description
When a user visits a product page, the product gets marked as "recently viewed" after 8 seconds. This delay is too long, as a user can realistically view the product and navigate away before the 8 seconds have passed (in which case the product isn't marked as recently viewed). In particular, this is problematic when the website contains a "recently viewed products" carousel, where the user expects to see all products they recently viewed (even if they didn't stay on the product page for 8 seconds). We decided to reduce the delay to 0.5 seconds, which is long enough to prevent the product from being marked as "recently viewed" if the user visits a product page by mistake and immediately navigates away, but short enough to prevent problematic behaviors such as the one mentioned above. opw-4114364 Forward-Port-Of: odoo/odoo#187025
When reversing a move of type 'in/out refund', we create a move of type 'entry' instead of 'in/out invoice' opw-4247643 Forward-Port-Of: odoo/odoo#184909
Original PR description
When reversing a move of type 'in/out refund', we create a move of type 'entry' instead of 'in/out invoice' opw-4247643 Forward-Port-Of: odoo/odoo#184909
Currently if you try to modify the quantity of a combo product from the cart in the kiosk, the price will not update. Steps to reproduce: ------------------- * Open a kiosk * Add a combo product to the order * Go to review the order * Click on the + button > Observation: The price of the order does not change. Why the fix: ------------ In the backend we can see that the parent quantity was changed accordingly but the child products quantity stayed at 1. We were not accessing the ri
Original PR description
Currently if you try to modify the quantity of a combo product from the cart in the kiosk, the price will not update. Steps to reproduce: ------------------- * Open a kiosk * Add a combo product to the order * Go to review the order * Click on the + button > Observation: The price of the order does not change. Why the fix: ------------ In the backend we can see that the parent quantity was changed accordingly but the child products quantity stayed at 1. We were not accessing the right field when checking the child products. opw-4283481 Forward-Port-Of: odoo/odoo#187257
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
Original PR description
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is cal
Original PR description
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when…
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time. - Change the language of the database to a different language. - Repeat the replenish process. - Observe that the schedule date is not calculated correctly. ## Solution: - Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons.. opw-4199660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183552
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#187150 Forward-Port-Of: odoo/odoo#179361
Original PR description
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#187150 Forward-Port-Of: odoo/odoo#179361
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187168 Forward-Port-Of: odoo/odoo#186808
Original PR description
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187168 Forward-Port-Of: odoo/odoo#186808
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice. The bug was introduced on this pr: https:
Original PR description
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification…
**Description of the issue/feature this PR addresses**: Argentinean Localization: Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type must report to afip the customer vat when the invoice has an amount higher than $344487 is validated but because the vat is not reported to afip then it is not allowed to validate the invoice. The bug was introduced on this pr: https://github.com/odoo/enterprise/pull/71562 --> The goal of this pr was to be able to create Factura B for a foreign customer. But prior to this pr the user was allowed to validate an invoice Factura B to a customer "Consumidor Final" without a country set on that customer, with "DNI" identification type, with a vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487 **Video explaining the bug**: https://drive.google.com/file/d/1Qb2oUtT26twjCI-pB6oMGMC9gZ6_EBSz/view **Steps to reproduce**: 1) Log ing with admin user on runbot odoo enterprise 16 or 17 instance, activate developer mode and install l10n_ar_edi module. 2) Take position on company "Responsable Inscripto". 3) Create an electronic invoice "Factura B" for customer "Consumidor Final Anónimo" with an invoice line with quantity 1 and price 500000. Select electronic journal. The Partner doesn`t have country and has "dni" identification type, dni and "Consumidor final" afip responsibility type.   4) Validate the invoice and then you will receive this message:  **Current behavior before PR**: It is not allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. **Desired behavior after PR is merged**: It is allowed to validate Electronic customer invoice Factura B for a customer "Consumidor Final" without country, with "DNI" identification type, with vat and "Consumidor final" afip responsibility type when the invoice has an amount higher than $344487. Ticket Adhoc side: 82498 Task latam side: 1283 Forward-Port-Of: odoo/enterprise#73200
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile i
Original PR description
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used…
Context: Every Behavior in Knowledge was a new App based on the config of the main Odoo App. Among shared resources are registries and services. In particular, the `main_components` registry is used to mount components, and, for the purpose of the following example that registry is used by the `popover_service`. Another thing to note is that the template compilation involves a reference to the App, and all ComponentNode have an app property which is the app that was used to compile its template. Issue: Now all pieces together in a problematic example case: Creating a new popover from a Behavior App involves the `main_components` registry: - Create a PopoverController (position logic (wrapper)). It is created within the main App through the registry, and its lifecycle is managed by the main App Scheduler. - Fill it with a Custom Component (business logic). It is created within the Embedded Component App, and its lifecycle is managed by the Embedded Component App Scheduler. Both schedulers lifecycle handling are not synchronized, and at some indeterministic point one of the Apps will crash during the manipulation of that popover. Solution: Use the new "subroots" OWL feature instead of using sub-apps, so that all templates are created from the same App, and the scheduler is the same for all components. This also has the advantage of not having to re-compile all templates for every Behavior. task-4300215 Forward-Port-Of: odoo/enterprise#73805 Forward-Port-Of: odoo/enterprise#73224
…aration TaskID: 4283466 Forward-Port-Of: odoo/enterprise#73088
Original PR description
…aration TaskID: 4283466 Forward-Port-Of: odoo/enterprise#73088
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account: * Account Name: [any] * Code: 123456789 * Type: Bank and Cash - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx) **Issue:** The
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account:…
**Steps to reproduce:** - Install l10n_mx_reports - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Create an account: * Account Name: [any] * Code: 123456789 * Type: Bank and Cash - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Download "COA SAT (XML)" - Validate the XML on an online SAT document validator (e.g. https://ceportalvalidacionprod.clouda.sat.gob.mx) **Issue:** The validation fails because the XML contains lines with incorrect or missing value for "CodAgrup" attribute. **Cause:** The "CodAgrup" in the "COA SAT (XML)" refers to the code of the account groups. The accepted values are defined in the "Catálogo de Códigos Agrupadores" XSD file. https://github.com/odoo/enterprise/blob/ecce698637dc2ef13dfdb27dfde303a7f1191aaf/l10n_mx_xml_polizas/data/xsd/1.3/CatalogosParaEsqContE.xsd#L4-L1086 The created account [123456789] is put in the root account group with code "1" and a line is added in the "COA SAT (XML)" with this value. However, it is not an accepted value. **Solution:** From the account groups created automatically by MX localization, only the root account groups (i.e. with code "1", "2", "3",...) do not have a valid code for the "COA SAT (XML)". These ones can be ignored. This solution is not perfect as it is still possible to create an account group with an invalid code that is not a root account group. However, handling this use case would require to check that each code is included in the set of valid codes (there is more than a thousand). opw-4209089 Forward-Port-Of: odoo/enterprise#73647
### Steps to reproduce: - Set a main currency and a second one. - Upload a document in the expense module for the second currency - Refresh ### Cause: In the for loop there are more than one possible currency detected so `vals['currency_id']` does not exist but the if statement tries to read this value causing an error. ### Solution: Check if the currency_id is in the vals dictionary. If not, the default currency value will be in the Expense. opw-4307845 Forward-Port-Of: odoo/ente
Original PR description
### Steps to reproduce: - Set a main currency and a second one. - Upload a document in the expense module for the second currency - Refresh ### Cause: In the for loop there are more than one possible currency detected so `vals['currency_id']` does not exist but the if statement tries to read this value causing an error. ### Solution: Check if the currency_id is in the vals dictionary. If not, the default currency value will be in the Expense. opw-4307845 Forward-Port-Of: odoo/enterprise#73660
Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1
Original PR description
Before, we relied on just _l10n_br_get_error_from_response() which checks for the presence of an "error" key in the response. Unfortunately that only seems to catch errors directly raised by Avalara. The government can reject the cancellation for a myriad of reasons [1]. We could hardcode all successful status codes (24 codes), but to be more robust in case the codes change we just look if any XML is returned. The lack of XML response should reliably indicate that the cancellation failed. [1] 4.4. Lista das Regras de Validação in https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=J%20I%20v4eN00E= Forward-Port-Of: odoo/enterprise#73342
We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#73776 Forward-Port-Of: odoo/enterprise#69561
Original PR description
We were misconfiguring some accounts in ec localization: - EDI purchase journal default account opw-4127252 Forward-Port-Of: odoo/enterprise#73776 Forward-Port-Of: odoo/enterprise#69561