Syncing from upstream odoo/odoo (staging.saas-18.3) #33743
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Current behaviour: When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. a8204fc Expected behaviour: The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: 1. Go to Contacts 2. Create a new contact 3. Set country as Malaysia, and choose a state 4. Go to Invoice, create one 5. Select new malaysian contact 6. State code in address instead of name Fix: Added a custom address_format in res_country_data.xml opw-4762300 closes #213617 X-original-commit: 7499e8d Signed-off-by: John Laterre (jol) <jol@odoo.com> Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
- now transporter gst number is not required if vehicle_no is present and mode of transportation is by road - vehicle number can be left empty if transportation_doc_no is set however transporter gst is required for that case task-4807693 closes #213553 X-original-commit: e05383a Signed-off-by: Josse Colpaert (jco) <jco@odoo.com> Signed-off-by: Meet Bariya (meba) <meba@odoo.com>
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0] The issue occurs because the retention tax is not filtered due to a missing `filter_to_apply` parameter. opw-4771567 closes #213619 X-original-commit: 8fd1848 Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com> Signed-off-by: Louis Gobert (loug) <loug@odoo.com>
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 closes #213612 X-original-commit: 4f27e61 Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com> Signed-off-by: Petr Nazin (nape) <nape@odoo.com>
This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 closes #213655 X-original-commit: 53b29a1 Signed-off-by: Julien Mougenot (jum) <jum@odoo.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
**Problem:** When setting a customer for an order in the restaurant, it wasn't recorded unless a product was ordered with it. If all we it is add a client in an already existing order, the client won't be recorded and will not be set after we leave the page. **Steps to reproduce:** - Choose a table, create a new order and put a product in it, ordering it is not required. - Go to another table, or just quit the command. - Go back in the initial order, set a client and go to the *orders* tab without doing anything else. - The order won't have a client, and going back to the order itself, the client is not set. **Why the fix:** The order wasn't read as having changed, so no data was saved. When we set it at first or with a product, it was concidered changed enough for it to be saved. But when changing the customer and only the customer, it wasn't reported to the pending orders. opw-4818110 closes #213650 X-original-commit: e3921a8 Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com> Signed-off-by: Arthur Nanson (artn) <artn@odoo.com>
Currently the signature of function `_notify_by_email_prepare_rendering_context`
in `account_peppol` is not compatible with all ways to call the super function.
This can lead to code breaking when `account_peppol` is installed (although
it works fine without).
This is fixed in this commit.
Detail:
In module `mail` the (super) function has signature
```python
def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,
model_description=False,
force_email_company=False,
force_email_lang=False):
```
Currently in `acccount_peppol` the signature is
```python
def _notify_by_email_prepare_rendering_context(self, message, **kwargs):
```
The super function can be called as follows while the function in `account_peppol` can not.
```python
_notify_by_email_prepare_rendering_context(self, message, msg_vals)
```
opw-4846106
closes #213688
X-original-commit: e5273c5
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
- When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with ticketbai using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). - The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [see this article for reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.html) - Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19',and `TipoFactura` to `06` as per TicketBAI specifications. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd opw-4532600 closes #213672 X-original-commit: 1cca873 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com> Signed-off-by: Devmitra Vedbandhu Sharma (dvsh) <dvsh@odoo.com>
Improve the error message when the response is HTTP 403. Currently, the content is empty for such errors, making it difficult to identify the source of the problem for users. Step to reproduce: - Try to send an invoice with wrong credentials. - The error message is empty, making it hard to understand what went wrong. Also added the missing .pot file. opw-4823950 opw-4628908 closes #213725 X-original-commit: 7a7687e Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com> Signed-off-by: Louis Gobert (loug) <loug@odoo.com>
- Install l10n_it_edi. - Install l10n_it_edi_withholding - Uninstall l10n_it_edi_withholding - Attempt an install of l10n_it_edi_withholding The following error appears: Invoice and credit note distribution should each contain exactly one line for the base. When uninstalling l10n_it_edi_withholding, the account.tax data are not unlinked which causes issues when _l10n_it_edi_withholding_post_init tries to _load_data with them. This commit prevents already existing account tax from being loaded from data during the installation. opw-4798659 closes #213681 X-original-commit: 8a8d95f Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com> Signed-off-by: Guillaume Teboul-Tornezy (gute) <gute@odoo.com>
Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As a result, the `-50%` margin shifts the video offscreen. Solution: Set both `left` and `right` to `0` in `.o-position-absolute` to ensure proper centering. Remove `margin-left: -50%` to prevent misalignment in non-editor contexts. Steps to reproduce: - Go to Contacts > "Gemini Furniture". - Add a video in the "Website Partner Full Description" field. - Save and open the partner on the website (`partners/gemini-furniture-11`). - Return to the Contacts page. → The video appears shifted 50% to the left. opw-4752567 closes #213648 X-original-commit: 5ecc631 Signed-off-by: Walid Sahli (wasa) <wasa@odoo.com>
…artner Description of the issue/feature this PR addresses: The system enforced a strict check that the delivery carrier partner must be located in Romania. This was limiting for companies that work with international carriers or operate across borders. Current behavior before PR: Delivery carriers not based in Romania triggered an error and could not be used in the delivery process. Desired behavior after PR is merged: Delivery carriers can now be located in any country. This provides greater flexibility in managing logistics and integrating international shipping partners. closes #213439 Forward-port-of: #212476 Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Currently, an error occurs when clicking the AI icon to calculate the probability of CRM leads. Steps to Reproduce: - Install the crm module. - Go to Leads > List View > Click "New". - Click on the AI (automated probability) icon. ValueError: Expected singleton: crm.lead() This error occurs when the user clicks on the AI icon to calculate the probability of CRM leads. Since the record does not exist [1], the system raises an error. This commit will fix the above issue by not preparing tooltip data when `resId` in the record is not available. [1] https://github.com/odoo/odoo/blob/d3b4d1e8d35eebbc015f5ead02f249e8ae5267d8/addons/crm/models/crm_lead.py#L2763 sentry-6657175088 closes #213179 Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
… item name This error occurs when attempting to create a submenu item under a menu item. Steps to reproduce: - Go to menu items. - Click New > In Submenus click Add a line TypeError: unsupported operand type(s) for +: 'bool' and 'str' This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the complete name for the submenu item, the menu(parent menu) item's name is False, which causes the error. https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/odoo/addons/base/models/ir_ui_menu.py#L56 This commit ensures that if the parent menu item record has not been saved and its name is False, an empty string is used in its place. sentry-6368548342 closes #213657 X-original-commit: 4317cc7 Signed-off-by: Raphael Collet <rco@odoo.com>
Commit 8847342 changed `sortedColumn.measure` that was the field name `'expected_revenue'` to the fully qualified measure id `'expected_revenue:sum'` However, the spreadsheet client-side upgrade forgot to change that. As a consequence, the sorting was just ignored. closes #212941 Task: 4818107 X-original-commit: 4d769cc Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com> Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Update the quantity to 1 in "WH/Stock"
- Create a putaway rule:
- From "WH/Stock" to "WH/Stock/Shelf1"
- Create a manufacturing order:
- Select any product to produce
- Add a component:
- 1 unit of P1
- Confirm and validate the MO
- Unbuild the order
Problem:
A stock move for P1 is created from "Virtual Location/Production" to
"WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not
called on the `stock.move.line` linked to the move.
In previous versions (e.g., v17), this issue didn't occur because the
quantity was directly set on the move. This triggered a write on
the `stock.move` model, which in turn called `_set_quantity`. Since
no `st
10000
ock.move.line` was linked at that point, a new one was created,
and its quantity was set via `_set_quantity_done`, which itself
called `_apply_putaway_strategy`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133
This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186
However, starting from v18, some code was refactored to clean up
unnecessary conditions. The `else` block was removed, and now,
regardless of the product type, the quantity is not set directly on
the move anymore. Instead, a `stock.move.line` is created using
`_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197
But `_apply_putaway_strategy` is not called in this flow.
Bug introduced in v18.0, commit:
79d9dd7
opw-4830952
closes #213614
X-original-commit: 856cf27
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that will get logged in the invoice. No exceptions raised in Odoo. The process can continue. Faulty invoices are marked; others work. Apart from that, there's also the fix to support the specific case outlined above. @moduon MT-7949 OPW-4344661 This needed adapting in the fw-port. This error had already been fixed in 18.0, but we still want to avoid the UserError. closes #212851 X-original-commit: 14b439b Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
The code to create foreign taxes (and tax groups) from another country's chart template had a bug in it (discovered during the change of tax accounts in 18.0). The process works as follows, given we are a US company wanting to map taxes from the BE localization: 1. We loop over all BE taxes and create a mapping from each account used in a BE tax's repartition lines to a (new) account in the US company, created based on the account in the BE repartition line. 2. We create tax groups in the US company, copied from the BE localization, but their accounts replaced by looking them up in the mapping we created in the previous step. In the second step however, instead of mapping the account from the original BE tax group, we were mapping the last account encountered in step 1. This was incorrect. This commit fixes that. task-3763030 Part-of: #213027 Related: odoo/enterprise#87034 Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable, but non-trade. That way users can easily reconcile bank transactions with the tax authorities. task-3763030 closes #213027 Related: odoo/enterprise#87034 Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
When a loyalty program is already applied in a sale order, the same loyalty program could also be triggered in the POS. Steps to reproduce: ------------------- * Create a simple loyalty program with a discount of 10% on order that is applied automatically if the total of the order is more than 1$ * Create a sale order with a product of 10$ and apply the loyalty program * You will have a disount of 1$ in the sale order * Open the PoS and settle the order * A new discount will appear in the PoS with a discount of 0.9$. > Observation: You now have 2 discounts coming from the same program Why the fix: ------------ We now adapt the `_programIsApplicable` function to check if the program was already used in the sale order. If it was, we ignore the program in the PoS. opw-4381890 closes #213646 X-original-commit: 6ce03c6 Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com> Signed-off-by: Robin Engels (roen) <roen@odoo.com>
This aggregation expression used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses term from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. closes #213761 Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Steps to reproduce 1: - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes Issue 1: Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. Solution 1: Invert the sign of the tax grids in the refund section. Steps to reproduce 2: - Create an invoice for a Tanzanian customer without VAT Issue 2: The default fiscal position will be "International", instead of "Domestic". A domestic fiscal position for customer without VAT is missing. Solution 2: Add a "Domestic individual" fiscal position that is the same as the "Domestic" one except for the VAT that is not required. opw-4840609 closes #213673 X-original-commit: 24b52cf Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit, LED status was managed from within Odoo. This could lead to issues: for example, when we stopped Odoo on the iot box, the leds stay in constant green (last used) colour despite odoo not running. We now use a systemd service, separated from the Odoo service, that continues running even if Odoo stops. closes #212415 Task: 4813935 X-original-commit: ac1137c Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com> Signed-off-by: Louis Travaux (lotr) <lotr@odoo.com>
Versions -------- - 17.0+ Steps ----- 1. Create a Stripe transaction; 2. check server logs. Issue ----- The `client_secret` value gets logged, Stripe documentation says this value should not be stored or logged[^1]. [^1]: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-client_secret Cause ----- Currently we're just raw-logging the processing values. Solution -------- Add a `_get_specific_secret_keys` method to `payment.transaction`, to be used when logging processing values that may contain secret information. Also mute the logger when redirecting to `/payment/status` from Stripe, as the `client_secret` would otherwise be logged by `werkzeug`. opw-4818301 closes #213695 X-original-commit: 1a25738 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com> Signed-off-by: Levi Siuzdak <sile@odoo.com>
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: e96d3aa closes #213771 X-original-commit: 7076d59 Signed-off-by: Romain Estievenart (res) <res@odoo.com> Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when opening a conversation in chat window, it always show a small flicker at opening. This happens because there's a template part to show start message text `"Welcome to #channel"` at the very beginning of conversation. This must be shown only at the very beginning, but when opening a conversation in a chat window, there's a short period of time when the component is not fully loaded and mounted. This `"Welcome to #channel"` start message text was not conditionally awaiting mounted and loaded thread component. closes #213784 Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When an unknown reaction is hovered (old emojis not present in emoji data anymore for example), shortcode can not be found and a crash occur. This commit fixes the issue. closes #213794 Signed-off-by: Didier Debondt (did) <did@odoo.com>
This commit adds a default index on the order of `crm.lead`. It will support the `web_search_read` that are done in the kanban view. closes #213793 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com> Co-authored-by: ryv-odoo <ryv@odoo.com>
- Add an options `keepCommands` inside `serializeForORM` method in order to keep the record dirty, so the next call to `serializeForORM` will again return the commands to apply for the ORM. closes #213361 Task-id: 4848882 Related: odoo/enterprise#87193 Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Since refactoring of avatar widget, the name of the dirver is not displayed anymore in the kanban view. closes #213803 Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
In our [previous commit][1], there were still a few missing bits: - We forgot to check for the `reconcile` option on the accounts set on a tax group. - The Bolivian 57A6 localization had its receivable and payable accounts mixed for the tax groups. We reversed them and created a new one. - The 0% tax group for Spain had its receivable and payable accounts reversed. We changed them as well. [1]: 925f8cb task-3763030 closes #213052 X-original-commit: 609e552 Signed-off-by: Olivier Colson (oco) <oco@odoo.com> Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
The shot value chartJs plugin would show the same value for a waterfall chart than a bar chart (the value of the top of the bar), instead of the correct value for a waterfall chart (the difference between the top and the bottom of the bar). Also the odoo_pyramid_chart would show negative values for the values of the left of the pyramid, instead of the absolute value. closes #213860 Task: 4812692 X-original-commit: d070597 Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bt_gitbot