Tuesday, August 27, 2024
40 changes · saas-17.4
Enhancements to existing features
This update standardizes how several Odoo Enterprise apps read browser cookies, using a cleaner shared request interface. It is an internal improvement that helps keep the platform consistent and easier to maintain, with no expected change to day-to-day user workflows.
Resolved issues and error corrections
This fix prevents the mail system from attempting to send an email again after it has already been sent during test runs. It avoids unnecessary follow-up processing and keeps email handling cleaner without changing normal user-facing behavior.
Original PR description
Since when we are in test the mail is sent before commit, we don't need to re-call send after commit (which won't do anything as the object mail is not outgoing anymore) So we just return after the sent. 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
#### Partner feedbacks - Add small box notification in settings when NAV 3.0 authentication succeeds. - Add warning if the user un-checks the 'NAV 3.0' checkbox in the Send & Print. - Amend module manifest to clarify that we are electronically reporting paper invoices. - Report the *date of payment*, not date of issue of advance invoices as `advancePaymentDate` when issuing the final invoice. In addition, advanceExchangeRate should be the HUF exchange rate used for the payment. - Add a wa
Original PR description
#### Partner feedbacks - Add small box notification in settings when NAV 3.0 authentication succeeds. - Add warning if the user un-checks the 'NAV 3.0' checkbox in the Send & Print. - Amend module…
#### Partner feedbacks - Add small box notification in settings when NAV 3.0 authentication succeeds. - Add warning if the user un-checks the 'NAV 3.0' checkbox in the Send & Print. - Amend module manifest to clarify that we are electronically reporting paper invoices. - Report the *date of payment*, not date of issue of advance invoices as `advancePaymentDate` when issuing the final invoice. In addition, advanceExchangeRate should be the HUF exchange rate used for the payment. - Add a warning if not all advance invoices are paid when issuing the final invoice. - Add more checks in tests that the invoice checks pass when opening the Send & Print wizard. - Make the 'HU Tax Reason' field invisible if the tax has VAT type. #### Bugfixes - connection testing should be done on res.config.settings `create()`, not on `set_values()` because the related fields are written during the create, which is called in a prior transaction to the set_values. This ensures that if the connection cannot be established, the UserError causes the rollback of the transaction before the values are written to res_company. - the parse_error_response method wasn't correctly parsing error results leading to empty error messages Many thanks to: - Eiler Attila (online-erp.hu) - Geza Nagy (oregional.hu) taskid: 3985127 Forward-Port-Of: odoo/odoo#177788 Forward-Port-Of: odoo/odoo#168932
The messaging menu no longer shows an option to enable push notifications on iOS devices where that setting cannot be managed from the web app. This removes a persistent, confusing prompt and improves the user experience for mobile users.
Original PR description
Before this commit, it was showing a "enable push notification" messaging menu item on iOS devices. This item was persistent and could not be removed, because iOS does not allow to enable specifically push notifcation on web apps, except if there are installed as PWA in which case they necessarily authorized push notifications based on OS app preferences.
This fix prevents Odoo from sending an away-status update earlier than needed after a user becomes active again. It reduces unnecessary duplicate presence updates, helping status changes stay efficient without changing the user experience.
Original PR description
Before this PR, the update presence sent when the user switches to away could be sent a bit too early. As a result, two updates would be needed instead of one. Steps: - Initial update presence is sent, let's assume the last activity was 5000 ms ago. - The away update presence should be planned for AWAY_TIMER - 5000. - Click on the page, the new update presence is still planned for AWAY_TIMER- 5000 but it should instead be computed based on the new inactivity period. This is not critical as the early update would plan another update based on the newly sent value. But it can be avoided by using the actual inactivity value to plan the next update presence sending.
The email template editor now correctly shows the translation button when users hover over rich text content fields. This makes it easier for multilingual users to translate email content consistently, matching the behavior already available on other fields.
Original PR description
Steps to reproduce ================== - Install Email Marketing - Enable debug mode - Enable multiple languages - Go to Email Templates - Open any record - Hover over the Subject field => There is a translation button at the end of the line - Hover over the content html field => The translation button is invisible Cause of the issue ================== Recently, the TranslationButton was made invisible if we're not interacting with the related field https://github.com/odoo/odoo/pull/169042 The case was handled for the HtmlField inside web, but not the one from web_editor. opw-4113284
This fix restores the HR module after a recent internal cleanup caused an error in some workflows. It prevents users from encountering a crash related to message handling, improving reliability without changing business features.
Original PR description
Currently, an error is occurring after the commit. Error:- ``` AttributeError: module 'odoo.tools' has no attribute 'decode_message_header' ``` Commit:- https://github.com/odoo/odoo/commit/5057ea17fef01b20161eb18e1f0aa859bc6a3d20 sentry-5658865209
The Point of Sale product info popup now shows on-hand quantity for products that do not have multiple variants. This helps store staff quickly see available stock for simple products without adding confusion for multi-variant items.
Original PR description
Before this commit, the on-hand quantity of products was not displayed in the product info popup. Given that a product can have multiple variants, displaying on-hand quantity directly in the popup was deemed irrelevant. However, this commit introduces a change to display the on-hand quantity in the product info popup for products without variants, enhancing clarity and usability for single-variant products. opw-4133522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small maintenance fix removes an outdated check from a Documents automated tour and corrects a typo. This helps keep validation runs stable without changing how users work with Documents.
Original PR description
We no longer need to add isCheck after this version on a tour we remove the checks and fix a small typo to avoid failing runbots. opw-76050
This change updates internal automated tests for spreadsheet pivot menu behavior so they match the current way record IDs are handled. It helps keep quality checks reliable and reduces the risk of false test failures during future development.
This change updates automated checks for spreadsheet pivot menu behavior so they match the current way item identifiers are handled. It helps keep quality checks reliable and reduces the risk of false test failures during future updates.
Enterprise PR: https://github.com/odoo/enterprise/pull/68087 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing t
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/68087 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the…
Enterprise PR: https://github.com/odoo/enterprise/pull/68087 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to nothing - (Make sure the User Type is Internal User) - Switch to this user - Go to Sales and create a new Quotation, confirm - Click on the 'Create Invoice' button - An access error appears because of 'l10n_cl.account.invoice.reference' ### Cause: The records of `l10n_cl.account.invoice.reference` are only readable by Accounting groups. ### Solution: Make the records of `l10n_cl.account.invoice.reference` accessible to all internal users. This will raise another access error for `l10n_latam.document.type`, so we also need to make them accessible (in community). ### Note: I noticed the access right of `l10n_cl.account.invoice.reference` were giving rights to `account.group_account_invoice` twice, where I think the second time was supposed to be `account.group_account_manager`. I don't know if this is wanted, but it doesn't make sense to have two lines for the same model and user group. I decided to only change `group_account_invoice` to `group_account_manager` so this PR is removing the write, create, unlink rights of `account.group_account_invoice`. opw-4078302 Forward-Port-Of: odoo/odoo#175988
Steps to reproduce: - Install timesheets, project and accounting - Enable "Analytic accounting" in accounting settings - Accounting > Accounting > Analytic items - Goup by Billing type - 2 different 'Materials' Change was made in 3d3f4109a06445b6ce9606770085c763ea206b35. This is ambiguous and clashes with the previously used items in 15.0. https://github.com/odoo/odoo/blob/ec106bfaaede527857a028bf1956b309aad3dc51/addons/sale_timesheet/models/account.py#L17 opw-4080234 --- I confir
Original PR description
Steps to reproduce: - Install timesheets, project and accounting - Enable "Analytic accounting" in accounting settings - Accounting > Accounting > Analytic items - Goup by Billing type - 2 different 'Materials' Change was made in 3d3f4109a06445b6ce9606770085c763ea206b35. This is ambiguous and clashes with the previously used items in 15.0. https://github.com/odoo/odoo/blob/ec106bfaaede527857a028bf1956b309aad3dc51/addons/sale_timesheet/models/account.py#L17 opw-4080234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177933 Forward-Port-Of: odoo/odoo#177388
Added start/stop/restart aliases to the IoT image to simplify the use of systemctl commands. Forward-Port-Of: odoo/odoo#177874
Original PR description
Added start/stop/restart aliases to the IoT image to simplify the use of systemctl commands. Forward-Port-Of: odoo/odoo#177874
Stock quants are not meant to be duplicated. This commit ensures that it is not possible to copy such records. opw-4035690 (cherry picked from commit 044210f6c7c4e539b8ebd41082c737e8bc91fd4e) --- In PR https://github.com/odoo/odoo/pull/172376 it was decided to not completely forbid quant duplication due to potential third party modules that could potentially use this feature. However, we see an increment of customer with an incorrect quantity in past history, or a discrepancy in v
Original PR description
Stock quants are not meant to be duplicated. This commit ensures that it is not possible to copy such records. opw-4035690 (cherry picked from commit 044210f6c7c4e539b8ebd41082c737e8bc91fd4e) --- In…
Stock quants are not meant to be duplicated. This commit ensures that it is not possible to copy such records. opw-4035690 (cherry picked from commit 044210f6c7c4e539b8ebd41082c737e8bc91fd4e) --- In PR https://github.com/odoo/odoo/pull/172376 it was decided to not completely forbid quant duplication due to potential third party modules that could potentially use this feature. However, we see an increment of customer with an incorrect quantity in past history, or a discrepancy in valuation and accounting because of this error. Unfortunately, it is incredibly easy to duplicate the quants by mistake, for example by miss-clicking when trying to export or update the inventory qty to 0 ...  Hence, even if it breaks some third party modules, it is imperative to prevent further quants duplication. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177796 Forward-Port-Of: odoo/odoo#177584
Versions -------- - 15.0+ Issue ----- Commit 9426ee54b927 introduced the \uFEFF character to web_editor as a zero-width non-breaking whitespace. When this gets added to a HTML node, and processed for translation, it throws an "empty document" error. Cause ----- When passed to the `get_text_content` function, the call to `html.fromstring('\uFEFF').text_content()` throws an error. \uFEFF is not technically classified as whitespace, so the `nonspace` function which attempts to prevent p
Original PR description
Versions
--------
- 15.0+
Issue
-----
Commit 9426ee54b927 introduced the \uFEFF character to web_editor as a zero-width non-breaking whitespace. When this gets added to a HTML node, and processed for translation, it throws an "empty document" error.
Cause
-----
When passed to the `get_text_content` function, the call to `html.fromstring('\uFEFF').text_content()` throws an error. \uFEFF is not technically classified as whitespace, so the `nonspace` function which attempts to prevent processing empty documents doesn't catch it.
Solution
--------
Instead of the `isspace` method, use a regex which matches on all whitespace as well as \uFEFF.
opw-3957259
Forward-Port-Of: #171685
Forward-Port-Of: #169122Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423 Where `MANDATORY_BILLING_FIELDS` is a list defined on the class: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136 This is a problem: the value is an object, so if the list is modified during
Original PR description
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`:…
Since [1], the `MANDATORY_BILLING_FIELDS` are now returned through the method `/portal._get_mandatory_fields`: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L421-L423 Where `MANDATORY_BILLING_FIELDS` is a list defined on the class: https://github.com/odoo/odoo/blob/b454a060a41961b7e0c9cc1ee6ec77b5cca1ec75/addons/portal/controllers/portal.py#L134-L136 This is a problem: the value is an object, so if the list is modified during a call, the method will then return that modified list instead of the initial one. For instance, in `l10n_ec_website_sale`, we add some values to that list: https://github.com/odoo/odoo/blob/10b7c27a4fc873c6220d63a0686f484e92ae906b/addons/l10n_ec_website_sale/controllers/portal.py#L14-L17 Then, if we call again `_get_mandatory_fields` with a company that is not EC, we will still have `l10n_latam_identification_type_id` and `vat` in the list of mandatory fields. That is incorrect. Looking at builds on runbot, some of them failed because of that error. This is the case with the FW of [2] on 17.4 which is blocked because of the above issue. Indeed, this commit contains a tour that checkouts a cart with an EC company. And, in 17.4, this flow leads to a call of `_get_mandatory_fields`. As explained, we will therefore add the EC mandatory fields. So, if [2] is part of the code, and if we try to run this: `--test-tags=.test_checkout_address_ec,.test_qr_code_receipt_mx` Where the first test comes from [2] and the second one is an existing test in the code, it will fail: the first test will add some values in `MANDATORY_BILLING_FIELDS`. Then, during the second test, at some point we also check the mandatory fields: the method will return the modified list (i.e., with the EC fields), and we will not have any value for these unexpected fields -> the test will fail [1] 9b9b0ee4c2d8a8a66e5e0456acbb780e5d8d6456 [2] 732b4fbbf3009769708f9c9cba57609d22f2a570 Forward-Port-Of: odoo/odoo#177349
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to re
Original PR description
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to reproduce the issue:__ - add products to your cart - remove one or many products of the stock - try to validate your payment opw-4016059 (upgrade issues) Forward-Port-Of: odoo/odoo#177068 Forward-Port-Of: odoo/odoo#174615
This commit will add some document types but also changed a bit the way we manage document type. We now let the possibility to the user to choose the document type he wants thanks to a manyToOne field to a new model. In this commit, we will also add the italian payment method needed for the edi. For that we added a selection field that can be filled with the payment method of the payment or by manually choosing a value. In the journal of bank, we can add some new payment method, by defau
Original PR description
This commit will add some document types but also changed a bit the way we manage document type. We now let the possibility to the user to choose the document type he wants thanks to a manyToOne field to a new model. In this commit, we will also add the italian payment method needed for the edi. For that we added a selection field that can be filled with the payment method of the payment or by manually choosing a value. In the journal of bank, we can add some new payment method, by default the italian payment method will be MP05. In case of partial payment we choose to take the payment method of the first one. task-3770458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#171795
Issue: Signature command doesn't work in 16.0 and raises an error in 17.0+ Steps to reproduce the issue: - install website - add forum in the website - create a new post in the forum - add signature - (nothing happens in 16.0, error in 17.0) Origin of the issue: ==================== The session in the forum post view doesn't have `uid`. Solution: ======== Use `session.user_id` instead of `session.uid` which works in forum as well as in other apps. opw-4066436 Forward-Port-
Original PR description
Issue: Signature command doesn't work in 16.0 and raises an error in 17.0+ Steps to reproduce the issue: - install website - add forum in the website - create a new post in the forum - add signature - (nothing happens in 16.0, error in 17.0) Origin of the issue: ==================== The session in the forum post view doesn't have `uid`. Solution: ======== Use `session.user_id` instead of `session.uid` which works in forum as well as in other apps. opw-4066436 Forward-Port-Of: odoo/odoo#177414 Forward-Port-Of: odoo/odoo#175573
This reverts commit 31ba553f283af73b9a84ba299ad9b7240e3ab779. After careful consideration, we deemed it overkill and not necessary. It adds extra overhead as most of the time you will be logged anyway and everything will be pre-filled for you. It also creates a lot of unnecessary partner records in case users decide to drop out of the checkout flow and not complete it. Forward-Port-Of: odoo/odoo#177603
Original PR description
This reverts commit 31ba553f283af73b9a84ba299ad9b7240e3ab779. After careful consideration, we deemed it overkill and not necessary. It adds extra overhead as most of the time you will be logged anyway and everything will be pre-filled for you. It also creates a lot of unnecessary partner records in case users decide to drop out of the checkout flow and not complete it. Forward-Port-Of: odoo/odoo#177603
Refactor the `_create_out_svl` and `_create_dropshipped_svl` methods in the `stok.move` model to separate the vals list generation from the `create` call. These new methods facilitate overwrites in custom modules. This split is already present for the `_create_in_svl` method. Forward-Port-Of: odoo/odoo#177590
Original PR description
Refactor the `_create_out_svl` and `_create_dropshipped_svl` methods in the `stok.move` model to separate the vals list generation from the `create` call. These new methods facilitate overwrites in custom modules. This split is already present for the `_create_in_svl` method. Forward-Port-Of: odoo/odoo#177590
UBL rule DK-R-005 limits the options available for the payment means. Currently, we have a hard-coded value of 30 for every invoice, because it is not possible to deduce the right payment means code at the moment. In OIOUBL we hard-code this field to `unknown` as it has the same UBL rule. With this commit we can use a different value for DK partners. In the future we could try to populate it dynamically. See also: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-005/ opw-
Original PR description
UBL rule DK-R-005 limits the options available for the payment means. Currently, we have a hard-coded value of 30 for every invoice, because it is not possible to deduce the right payment means code at the moment. In OIOUBL we hard-code this field to `unknown` as it has the same UBL rule. With this commit we can use a different value for DK partners. In the future we could try to populate it dynamically. See also: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-005/ opw-4080715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177430
### Steps to reproduce - Create 2 products tracked by Lots - Create and "mark as to do" a receipt with two lines: - 1 x Product 1 - 1 x Product 2 - Click on the list icon (details Operation) of the first line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line ####
Original PR description
### Steps to reproduce - Create 2 products tracked by Lots - Create and "mark as to do" a receipt with two lines: - 1 x Product 1 - 1 x Product 2 - Click on the list icon (details Operation) of the…
### Steps to reproduce - Create 2 products tracked by Lots - Create and "mark as to do" a receipt with two lines: - 1 x Product 1 - 1 x Product 2 - Click on the list icon (details Operation) of the first line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line #### > the lot_name has not been saved ### Cause of the issue When calling openRecord, if the parent of the record is dirty (the picking), it is saved and reload before proceeding: https://github.com/odoo/odoo/blob/709ad381120ab7a7b9ff14ec473b410a53f39e28/addons/stock/static/src/views/picking_form/stock_move_one2many.js#L49-L54 This is what happens when you open the second line since you changed the content of the first line. However, when we proceed with this called, the `super.openRecord` will be called on the record on which we started the call with rather than the corresponding record of the reload. So that its change will not be saved. ### Solution: A similar issue has already been solved by commit 127e735 and the same fix can be used by restructuring the code + it allows to reload the record only once. opw-4097653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177080
Backport from 16.1: https://github.com/odoo/odoo/commit/bfa7a47c860452a8b27a942cd50dc61eba72f5cb hinder allocation date_to to precede date_from Purpose: In order to reduce the possibility to make errors, make the end date of the validity period always come after the start date. @Tecnativa TT50433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176808 Forward-Port-Of: odoo/odoo#175841
Original PR description
Backport from 16.1: https://github.com/odoo/odoo/commit/bfa7a47c860452a8b27a942cd50dc61eba72f5cb hinder allocation date_to to precede date_from Purpose: In order to reduce the possibility to make errors, make the end date of the validity period always come after the start date. @Tecnativa TT50433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176808 Forward-Port-Of: odoo/odoo#175841
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model.
Original PR description
Description of the issue/feature this PR addresses: Before this fix, It was not possible to issue a credit note code 61 to be applied to an invoice of type '46' when the vendor was foreign. Typically, credit notes for foreign vendors are code 112; however, code 61 is necessary to reverse a type 46 invoice. After this PR: In the validation included in this PR, we allow this credit note type 61, provided there is a reference to a code '46' invoice, included in the document reference model. This PR corresponds to the odoo/enterprise PR enabling the issuance of type 46 invoices referenced below: this PR replaces: https://github.com/odoo/odoo/pull/166400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166954 Forward-Port-Of: odoo/odoo#166793
Currently there might be a line break after the phone marker in the contact widget. It depends on the document layout and the length of the phone number. After this commit the line break does not happen anymore. (In commit cbcda0b222b17312b9e42e23801a330f0030033f line breaks inside phone numbers were removed.) To reproduce: 1. Ensure Purchase app is installed 2. Settings -> Configure Document Layout - layout: boxed - font: Oswald - paper format: A4 3. Edit some partner t
Original PR description
Currently there might be a line break after the phone marker in the contact widget. It depends on the document layout and the length of the phone number. After this commit the line break does not happen anymore. (In commit cbcda0b222b17312b9e42e23801a330f0030033f line breaks inside phone numbers were removed.) To reproduce: 1. Ensure Purchase app is installed 2. Settings -> Configure Document Layout - layout: boxed - font: Oswald - paper format: A4 3. Edit some partner to have a long phone number (E.g. via Purchase -> Orders (menu) -> Vendors) e.g. use: (870)-931-0505 12 12 12 12 4. Create a request for quotation / purchase order and select the partner from 3 as Vendor 5. Confirm the purchase order 6. Print the purchase order 7. There is a line break after the phone marker in the vendor address opw-3783870 opw-3970768 PR the mentioned commit belongs to: https://github.com/odoo/odoo/pull/166336 Forward-Port-Of: odoo/odoo#175693
Use the delivery date to fill the `FechaOperacion` and fall back to the invoice date if no delivery date is set. Steps: - Make an invoice with delivery_date != invoice_date != today - Send invoice to gouvernment - Download the xml generated - The field `FechaOperacion` is the invoice date instead of the delivery date opw-4072748 Forward-Port-Of: odoo/odoo#174677
Original PR description
Use the delivery date to fill the `FechaOperacion` and fall back to the invoice date if no delivery date is set. Steps: - Make an invoice with delivery_date != invoice_date != today - Send invoice to gouvernment - Download the xml generated - The field `FechaOperacion` is the invoice date instead of the delivery date opw-4072748 Forward-Port-Of: odoo/odoo#174677
Steps to reproduce =================== 1. Install website_sale module 2. Go to any campaign in marketing_automation 3. The kanban card of the activity will have buttons misplaced in the title Issue ================= With commit https://github.com/odoo/odoo/pull/165486/commits/f46e7e8bd6dc205d83a107f62d8b5944caa3d4d5, a style was applied for website_sale form mobile view. The selector also matched marketing_automation's campaign form view which removed the required float property from th
Original PR description
Steps to reproduce =================== 1. Install website_sale module 2. Go to any campaign in marketing_automation 3. The kanban card of the activity will have buttons misplaced in the title Issue ================= With commit https://github.com/odoo/odoo/pull/165486/commits/f46e7e8bd6dc205d83a107f62d8b5944caa3d4d5, a style was applied for website_sale form mobile view. The selector also matched marketing_automation's campaign form view which removed the required float property from the element. After this commit ================= This commit makes the selector in website_sale more specific to match only the desired element. Task-4110902 Forward-Port-Of: odoo/odoo#176920
Versions -------- - 17.0+ Steps ----- 1. Activate a second language on the database; 2. enable debug mode; 3. go to Settings / Technical / Database Structure / Fields; 4. look for the `state` field of the `project.task` model; 5. change the name's translation of the of the `01_in_progress` value; 6. go to a task to select the state. Issue ----- It still shows the original translation. Cause ----- The JS side fetches the translations straight from the .po file instead of loo
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Activate a second language on the database; 2. enable debug mode; 3. go to Settings / Technical / Database Structure / Fields; 4. look for the `state` field of the `project.task` model; 5. change the name's translation of the of the `01_in_progress` value; 6. go to a task to select the state. Issue ----- It still shows the original translation. Cause ----- The JS side fetches the translations straight from the .po file instead of looking for translations stored in the database. Solution -------- The translations of the labels are already stored in `this.props.record.fields[this.props.name].selection`, as used in `super`'s `options` getter. Retrieving these, custom translations do take effect. opw-4009326 Forward-Port-Of: odoo/odoo#177872 Forward-Port-Of: odoo/odoo#176507
Steps to reproduce: ------------------- - Have xlrd >= 2.0 and openpyxl 3.1.2 - Using the base_import module, import an XLSX file with empty cells - You will notice that all empty cells are read as "None" - Click on test, will give this error : "Column debit contains incorrect values (value: None)" Cause: ----- Since (#169245) openpyxl is used instead of xlrd for parsing xlsx files, the empty cells are parsed as None, not as empty string (as it was in xlrd). then this None is cast to t
Original PR description
Steps to reproduce: ------------------- - Have xlrd >= 2.0 and openpyxl 3.1.2 - Using the base_import module, import an XLSX file with empty cells - You will notice that all empty cells are read as "None" - Click on test, will give this error : "Column debit contains incorrect values (value: None)" Cause: ----- Since (#169245) openpyxl is used instead of xlrd for parsing xlsx files, the empty cells are parsed as None, not as empty string (as it was in xlrd). then this None is cast to the string "None", causing issues. Fix: ----- An additional check added to check if the cell is empty (value is None) and set it as empty string. opw-4132402 Forward-Port-Of: odoo/odoo#177770
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to noth
Original PR description
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft…
Community PR: https://github.com/odoo/odoo/pull/175988 A user without any accounting access right set get an error when creating an invoice from a sale order. The user should be able to see the draft invoice when clicking on the 'Create Invoice' from a sale order, as it is the case without the l10n_cl_edi module. ### Steps to reproduce: - Install the 'l10n_cl_edi' module - As admin go to Settings > Manage Users, click on a User and, in Access Rights, change Accounting > Invoicing to nothing - (Make sure the User Type is Internal User) - Switch to this user - Go to Sales and create a new Quotation, confirm - Click on the 'Create Invoice' button - An access error appears because of 'l10n_cl.account.invoice.reference' ### Cause: The records of `l10n_cl.account.invoice.reference` are only readable by Accounting groups. ### Solution: Make the records of `l10n_cl.account.invoice.reference` accessible to all internal users. This will raise another access error for `l10n_latam.document.type`, so we also need to make them accessible (in community). ### Note: I noticed the access right of `l10n_cl.account.invoice.reference` were giving rights to `account.group_account_invoice` twice where I think the second time was supposed to be `account.group_account_manager`. I don't know if this is wanted but it doesn't make sense to have two lines for the same model and user group. I decided to only change `group_account_invoice` to `group_account_manager` so this PR is removing the write, create, unlink rights of `account.group_account_invoice`. opw-4078302 Forward-Port-Of: odoo/enterprise#68087
`portal.CustomerPortal.OPTIONAL_BILLING_FIELDS` is deprecated, we should rather use the method `_get_optional_fields` c.f. the OC-side commit Forward-Port-Of: odoo/enterprise#68679
Original PR description
`portal.CustomerPortal.OPTIONAL_BILLING_FIELDS` is deprecated, we should rather use the method `_get_optional_fields` c.f. the OC-side commit Forward-Port-Of: odoo/enterprise#68679
Problem: The SEPA configuration fields sepa_orgid_id and sepa_orgid_issr are reset when exporting and importing a partner (company) associated with a company. Steps to Reproduce: 1. Configure a "SEPA Credit Transfer (SCT)" for a company. 2. Export the partner related to the company. 3. Re-import the partner. 4. Check the SEPA configuration of the company; it is reset. Solution: To fix this, we need to prevent the SEPA configuration from being reset when it is already set. opw-3981
Original PR description
Problem: The SEPA configuration fields sepa_orgid_id and sepa_orgid_issr are reset when exporting and importing a partner (company) associated with a company. Steps to Reproduce: 1. Configure a "SEPA Credit Transfer (SCT)" for a company. 2. Export the partner related to the company. 3. Re-import the partner. 4. Check the SEPA configuration of the company; it is reset. Solution: To fix this, we need to prevent the SEPA configuration from being reset when it is already set. opw-3981278 Forward-Port-Of: odoo/enterprise#67424
Issue ----- Error when multiple input lines on a payslip are of the same type. Steps ----- [hr_payroll] 1. Create a salary attachment for an employee, type "Attachment of salary", with a monthly amount and total amount A. 2. Create another salary attachment for the same employee, same type and monthly amount and total amount B different from A. 3. Create a payslip for the employee, create a contract with a start date matching the salary attachment date. On "Other Inputs", remove the "A
Original PR description
Issue ----- Error when multiple input lines on a payslip are of the same type. Steps ----- [hr_payroll] 1. Create a salary attachment for an employee, type "Attachment of salary", with a monthly amount and total amount A. 2. Create another salary attachment for the same employee, same type and monthly amount and total amount B different from A. 3. Create a payslip for the employee, create a contract with a start date matching the salary attachment date. On "Other Inputs", remove the "Attachment of salary" line. Create two input lines of type "Attachment of salary", one with amount A and another with amount B. 4. Compute sheet > Confirm > Mark as paid > ** Error ** Cause ----- Generally, input lines of the same type on a payslip will be merged in one input line, but it is not the case if there are multiple salary attachments of the same type matching these input lines. opw-4066851 Forward-Port-Of: odoo/enterprise#68682 Forward-Port-Of: odoo/enterprise#68441
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to re
Original PR description
__Current behavior before commit:__ When you check out your cart with a product not in the stock anymore you have an error message. There is no product name in this message so if you have multiple products in your cart you don't know which one to remove. __Description of the fix:__ Add the product name in the error message, so it's easy to identify which product to remove of the cart. The warning method is linked to sale.order.line so we can access to the product directly. __Steps to reproduce the issue:__ - add products to your cart - remove one or many products of the stock - try to validate your payment __linked to Odoo PR:__ https://github.com/odoo/odoo/pull/174615 opw-4016059 (upgrade issues) Forward-Port-Of: odoo/enterprise#68557 Forward-Port-Of: odoo/enterprise#67423
The version of the csv is now 7.0. Adapt the headers to it, they must now all be present. The values don't seem to have changed, at least the ones required that we provide. task-4131986 Forward-Port-Of: odoo/enterprise#68853 Forward-Port-Of: odoo/enterprise#68796
Original PR description
The version of the csv is now 7.0. Adapt the headers to it, they must now all be present. The values don't seem to have changed, at least the ones required that we provide. task-4131986 Forward-Port-Of: odoo/enterprise#68853 Forward-Port-Of: odoo/enterprise#68796
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - cli
Original PR description
## Issue: When validating a stock picking, in a Mondial relay delivery, if the partner created for it has no parent_id, the code will raise an error. ## Steps to reproduce: - Create a sendcloud delivery method (mondial relay) - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - change the quantity to the same as demand - click on the delivery address - remove the partner's parent_id - add an email and phone number to the partner and save - go back to the picking page and click validate - a traceback will appear ## Solution: - in the `_prepare_parcel_common_data` method, raise a user error if the SO has `access_point_data` and the partner has no parent_id. OPW-4042529 Forward-Port-Of: odoo/enterprise#67074
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity descr
Original PR description
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type…
Before this PR: When we included the ability to create "Facturas de compra" (code 46, needed mainly for the purchase of digital services to foreign vendors), we get schema errors sending these type of invoices to the SII (l10n_cl_reference_doc_type_selection == 46). The use of the tag Exportaciones for document type '46' is not correct. This tag should be used only for foreign customers on Export documents. This case is only for the following codes: '110', '111', '112'. An "Activity description" is mandatory, as it's not an export document. The country customs code must be included in the Nacionalidad tag as well, as the vendor is foreign. Reference: Law Nº21420, and resolution Nº46 (May 13th, 2022) https://www.bcn.cl/leychile/navegar?idNorma=1172303 https://www.sii.cl/normativa_legislacion/resoluciones/2022/reso46.pdf After this PR: These issues are fixed. Community PR: https://github.com/odoo/odoo/pull/166793 Forward-Port-Of: odoo/enterprise#63311 Forward-Port-Of: odoo/enterprise#63244
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment
Original PR description
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment is installed alone, hopefully avoiding to miss the increased query count next time. Forward-Port-Of: odoo/enterprise#67769