[t169692] Update MPC core#38856
Open
BT-tkarpinski wants to merge 722 commits into15.0.project_MU_627from
Open
Conversation
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away. Reference: https://www.strongabogados.com/tax-id-spain.php opw-3891248 closes odoo#168052 Signed-off-by: Laurent Smet (las) <las@odoo.com>
Syncing from upstream odoo/odoo (15.0)
People tend to install every new shiny release of Python but fail to realise that it usually takes a month or two before Odoo is made compatible with that shiny new version. In the meantime there is a surge of issues / tickets with bugs related to the new python version, wasting time of a lot of people (at least mine). Hardcode the officially maximum supported python version and emit a warning when the current python is more recent than that. We'll change the variable the next time we support a new python version. closes odoo#168911 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Current behaviour: When sending an email through Email Marketing, the icon is right in the preview, but wrong in the received email. Steps to reproduce: 1. Install mass_mailing 2. Create a new mailing 3. Select a template with a twitter icon 4. The icon is the new one 5. Click on Test 6. Open the email 7. Wrong icon Cause of the issue: Twitter icons have been overriden in fontawesome_overridden.scss However this css is not loaded when writing the src in fontToImg in convert_inline.js Fix: Same fix as for tiktok, forcing a custom font and changing the icon code to match the font (ie: one icon is F099 in FA but E800 in the custom font) opw-3963437 closes odoo#170942 Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Commit [1] changed removed trailing `<br>` in firefox when inserting text to address a issue in commit [2], where a table couldn't be removed if a `<br>` was its `lastLeaf`. However, it turns out that `<br>` element is necessary in Firefox to make text ending with a collapsed white-space visible. This commit reverts [1] and provides an alternative solution to the original problem. [1]: 0cb2604 [2]: c41487c task-4045305 closes odoo#172957 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
In some places, unlink() and mapped() are used on the result. To avoid error, let's return empty recordset. closes odoo#173454 Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce: - Create a storable product. - Create a picking with it and validate. - Try to change the product type to consumable. Not allowed because there is a move done. - Archive the product. - Try to change the product type. No user error is raised... Excepted behaviour: It should not be possible to change the product type even if the product is archived, as it causes inconsistencies. closes odoo#173526 Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
As observed in odoo#173442, the commit odoo@6336366 has introduced a bug for search panel filters that are based on many2many that are not groupable. Indeed, the computation of the domain image is done via _search_panel_domain_image that uses read_group and for many2many that are not groupable it is not allowed to use read_group. We fix that bug by computing the domain image via a search_read when the many2many is not groupable. opw-4055494 closes odoo#173538 Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Previously, the amount sent to Mollie always had 2 decimal places. However, Mollie supports 0 decimal places for amounts in ISK and JPY so it failed for payments in those currencies. This fix adjusts the decimal places sent to Mollie according to the currency. opw-4011259 closes odoo#173595 Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Users without administrative rights were unable to refund transactions because the call to `_send_refund_request` was made without `sudo`. This commit adds both the necessary `sudo` to bypass the access rights check on the transaction's payment acquirer and a manual access rights check on the transaction itself to prevent abusing RPC calls. opw-4033356 closes odoo#173663 Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In the list view of Chart of Accounts, the only available tags in the field Tags are the ones applicables to Accounts. task-4016899 closes odoo#173691 Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
tldr: The init function should not be used in this case for creating records, doing so results in errors.The content of this init function can be safely moved to the post-init hook The problem: In saas~17.2, creating a company with a country can result in the installation of its accompanying localisation. If it is a European country, this will trigger the installation of base_vat too. If project_timesheet_holdiays is installed this can result in the installation of base_vat failing. The init method described on res_company in project_timesheet_holidays is triggered when the res_partner model is extended, for instance, in base_vat when adding fields. The registry will contain these fields, but the accompanying fields will not yet have been written to the db. When the project and task are created, a chain of dependencies result in the company's partner being read. In turn, a query is issued using fields from the registry that aren't yet written to the DB, resulting in an SQL error. Solution: Move the content of this method to the post-init hook. This is safe to do and works the same way. closes odoo#173719 Task-id: 4060907 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Move some utility methods from ReconciliationCommon to InvoicingCommon that helps to create taxes, tax's tags, invoices. Part-of: odoo#127077 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
…x tags wizard After updating taxes, we didn't update already existing journal entries tags to map correctly into new reports. We let the user change his data which can be very time consuming. To tackle that we introduce a new wizard accessible in accounting settings in which user can set a date from which we will update tags on his journal entries for him, so that they are synchronized with current taxes configuration. Note: initial script is part of support tools' scripts, written by Brice (bib), slightly modified for this wizard's purpose. task-3330327 closes odoo#127077 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Description of the issue/behavior this commit addresses: The restrictions on fiscal positions using a foreign VAT are too restricitve, this commits addresses the issue by allowing new scenarios. Desired behavior after this commit is merged: This commit allows to use a foreign VAT with only a country group which will automatically set the corresponding country on the FP. For example, you can now use a Belgian VAT number on the country group Europe and therefore use that fiscal positions for all countries in Europe which do not have their own. On a fiscal position with a foreign VAT, this commit allows the user to set a country which is not the country linked to the foreign VAT. For example, if you are belgian, you have a warehouse in France and export goods to Germany, you can create a fiscal position with a french foreign vat and germany as country. This commit also allows a lot more "duplicates". You can set multiple FP inside the same country depending on the states/foreign vat you set it up with. task-3088020 closes odoo#133749 Related: odoo/enterprise#61969 Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Steps to reproduce: - Create a product that is a kit in company A and not in company B - Try updating quantity on hand in company B Bug: since [1] it's not possible to update kit quantites directly but is_kits is not company dependant Fix: is_kits depends on the selected companies opw-3946361 [1]:https://github.com/odoo/odoo/pull/161124/files closes odoo#169063 Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Currently, when website snippets were translated and they had special characters in them, they would be escaped before adding them as the `data-name` attribute of the snippet, which escaped them again. When the snippet would be selected, the sidebar would get that `data-name` attribute and use it as the title, resulting in the characters still being escaped. This commit fixes that by not escaping the name beforehand, but only when used in raw HTML. closes odoo#173808 Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce: - Install `l10n_fr_invoice_addr` - Switch to french company - Change "Colors" in "Document Layout" settings - Go to an invoice and click the "Preview" button Because of the inconsistent HTML tags used, the invoice styling wouldn't get applied to the columns added by `l10n_fr_invoice_addr`. This commit improves consistency with the pre-existing HTML hence fixing that issue See: odoo#172497 task-4056046 closes odoo#173299 Signed-off-by: William André (wan) <wan@odoo.com>
Before Commit: On switching the checkbox direction from left to right and pressing tab, the checkbox would shift to the left while the text appeared on the right, and vice versa for RTL languages. After Commit: Commit [1] added the positioning of checklists in Right-to-Left (RTL) languages. Previously, only the direct child li elements of ul were styled because of the use of the child combinator selector (>), as the dir attribute was only applied to the outermost ul element. This commit ensures uniform styling across various languages, including RTL languages. [1]: bb9c4b3 task-3828737 closes odoo#160909 Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Context: when visiting the `/partners` url, the user has access to the
"silver", "gold" and "platinum" grades. However, when generating the
sitemap, the `/partners/grade/bronze-4` url is part of it but trying to
access it leads to a 404 server answer. Another problematic behavior is
that if the user deactivates a grade ("gold" for example), the grade is
still accessible from `/partners` (but the `/partners/grade/gold-2` url
is not on the sitemap anymore).
This can be explained as:
- When visiting the `/partners` url, the `partners` route searches for
grades from `request.env['res.partner']`. By doing so, it ensures that
grades are linked to at least one partner; this explains why the
"bronze" grade (not linked to any partner) is not shown at the
`/partners` url and why the deactivated "gold" grade is still
accessible (as a partner is still related to it).
- When the user tries to reach a `/partners` route, a 404 server answer
is returned if no partners are found for the route (e.g.
`/partners/grade/bronze-4`).
- When generating the sitemap, the system is searching for grades from
`env['res.partner.grade']`. Due to it, inactive grades (e.g. "gold") are
not shown on the sitemap and grades that are not linked to a partner
(e.g. "bronze") are shown on the sitemap.
The goal of this commit is to:
- Correct the `/partners` route so that it does not show inactive
grades.
- Generate the sitemap coherently from what is done in the `/partners`
route.
In the end, the `/partner` route only shows company website published
partners linked to active website published grades. The user has then
the possibility to filter the partners by grades or by country.
opw-3992340
closes odoo#170582
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
stdnum library incorrectly sets zeep Transport timeout, resulting in some requests hanging for 15 minutes. With this monkeypatch the timeout will be set correctly. The monkeypatch is a full copy of the original code except for adding operational_timeout to the Transport. The monkeypatch can be removed when arthurdejong/python-stdnum/issues/444 is resolved and the version is upgraded Related zeep github issue: mvantellingen/python-zeep#140 This fix was already commited but reverted due to an unexpected side-effect: Original commit: 11062f6 Revert: de9df2b The issue originated from a dependency issue in the zeep library in Ubuntu 22.04. The python3-platformdirs dependency is missing in there, yet it is used in that version of zeep. This missing dependency used to be hidden by the chains of try ... except ImporError of stdnum That means that it's another import from the chain that was used. So to reduce the possibility of introducing a similar bug and catch such errors, the full code was copied. See odoo#173359 for a full explanation of why the full code is copied even though some libraries are not in the requirements. opw-3980718 Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Check if the user selected the carrier for storable/consumable products before proceeding to payment. Backport of [35ea9bf](odoo@35ea9bfb) opw-3861697 closes odoo#173847 Signed-off-by: Julien Launois (jula) <jula@odoo.com>
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 closes odoo#174208 Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Before this commit, the '/' create a weird space in the error message. closes odoo#173375 Task: 4041892 Enterprise: odoo/enterprise#66767 Related: odoo/enterprise#66767 Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>
In no-demo tests, there is no link tracker, so the expected length is not max+1 but 3. Follow up of e5b88d3 Task-3502174 closes odoo#173303 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Description of the issues this commit addresses: As from the first of september 2024, Finland will raise 24% taxes to 25.5%, those rates are currently not available in Odoo. Desired behavior after this commit is merged: New 25.5% taxes are available in Finland OSS tax mapping is done for other countries to Finland The mapping from Finland to other countries is deliberately left for later as we don't want the mapping to 25.5% to tkae place before the 09/01/24. task-4010731 closes odoo#171414 Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Steps to reproduce: - Install account_accountant. - Create a journal with a type other than miscellaneous. - For the created journal, select a default account - Now change the journal type to Miscellaneous. Issue : - When changing the journal type to Miscellaneous from any other type, the default_account_id remains unchanged in the database. Functionally, the default_account_id should be removed for Miscellaneous journals, as this field isn't visible in the front-end, so customers aren't aware if it still contains data. opw-4072696 closes odoo#178494 Related: odoo/enterprise#70486 Signed-off-by: John Laterre (jol) <jol@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Context: A pesky bug has been flying under the radar since at least Odoo 15.0. When passing `email_from=False` to the _find_mail_server, we will always have an early return at: https://github.com/odoo/odoo/blob/f05626e14264cf3bb477c86ad82439726d778c8f/odoo/addons/base/models/ir_mail_server.py#L668C1-L676C1 This comes from the fact that we can generate False == False => True comparisons while filtering the `ir.mail.server` records, by : * `email_from_normalize` is False (since `email_from` was also False) and mail server has no from_filter = > email_normalize(m.from_filter) == email_from_normalized => False == False * `email_from_domain` is False (since `email_from` was also False) and mail server has a full email address in the from_filter field => email_domain_normalize(m.from_filter) == email_from_domain => False == False Both edge-cases leads to the first email server config to always be selected for the SMTP connection, even if a valid mail server exist matching for example the default notification email (i.e. notifications@custom.domain). This can lead to notification emails failing on DB having multiple outgoing email servers setup, where the SMTP server does sender verification (Outlook, Gmail – you can only send as a specific sender email). Proposed fix: We wrap the first checkpoint in an if block with email_from. Logically if email_from is already False, we should skip to the second checkpoint (matching notifications default email) and only later try to fall back to the first `ir.mail.server` record (while also triggering the warning log). Added test for edge-case How to reproduce: Any workflow triggering an automatic notification email as Odoobot, while having the `email` field set to `False`. 1) Setup DB with website_sale installed 2) Set `email` field of Odoobot `res.partner` (by default id = 2) to False 3) Setup at least two outgoing email servers (`ir.mail.server`) with the first having no `from_filter` and the second one matching the default notifications email address (default = notifications@mycompany.example.com) 4) So to the Ecommerce shop and buy any random product and finalizing the transaction. → Triggered notification email will always be sent by mail server id = 1, even if it should match id = 2 in this case OPW-4140192 closes odoo#178340 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Syncing from upstream odoo/odoo (15.0)
Steps : - Set the company of the first pricelist in list view to false - Create a product and set it's company and the go to extra price tab and group by product - Now when adding a new, opens form view, try saving the record Issue : Returns a warning message now allowing to save Cause : The company for pricelist that is default selected and the product have different companies Fix : Updated the action so that it does not open form view as the pricelist tree view is multi-edit opw-3943830 closes odoo#171032 Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Syncing from upstream odoo/odoo (15.0)
This field isn't required. However, if not supplied, Odoo fails to notify *all* invoices in a cron run, without speaking about it. Not good. @moduon MT-5819 closes odoo#163792 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Syncing from upstream odoo/odoo (15.0)
In a database with a large ir_attachment table, the performance of the query for gathering asset attachments is poor. We're backporting the query conditions from commit 1b9ac0e, which resulted in a 30x speed improvement on a database with approximately 1M ir_attachment records. TT51109 closes odoo#182724 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Filter name match with a field name and when you use search_default_sale_order_id the records are grouped by sale_order_id. https://github.com/odoo/odoo/blob/5b63d6f8e75df06b8a83c93b15c7d3451eb9dbbc/addons/sale_project/models/sale_order.py#L95 The problem is that when clicking from the sales order form view on the smartbutton tasks, the tasks are grouped by sales order instead of by stage, which is the expected grouping. The original filter is maintained by removing the context during stable releases, to avoid inheritance problems in case the filter name has been used to extend views. closes odoo#181139 Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Steps to reproduce ====================== Go to the user profile. Click on tags. You will be redirected to the courses instead of redirecting to the tags. Technical ========== Click event is there on the whole card as our tags are inside the card so the click event of a parent is triggering instead of the child. and we are redirected to the course page. After this commit ================== We will be redirected to tags when clicking on tags. Task-4203676 closes odoo#181499 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Syncing from upstream odoo/odoo (15.0)
Open web shop Add item to cart To to checkout Enter Customer details Add as country Hungary and vat 12345678-1-11 Confirm Error The VAT number [HU12345678111] does not seem to be valid. Note: the expected format is HU12345676 or 12345678-1-11 or 8071592153 This occurs because, when converting the domestic vat to the EU format, (with the leading country code) all digits are kept opw-3815478 closes odoo#165740 Signed-off-by: Ruben Gomes (rugo) <rugo@odoo.com>
Syncing from upstream odoo/odoo (15.0)
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. We also clean obsolete test parts and documentation. Follow-up of odoo#140102 Task-3502174 closes odoo#176074 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Syncing from upstream odoo/odoo (15.0)
Before this commit we are not able to move expense to a reconciled account in a future period because posting future entries are delayed so we can't reconciled journal items on the fly. * create new company 'test' * switch on it * install French accounting (l10n_fr) * check 'Show Full Accounting Features' to gives access to accounting feature on your user access tab * create vendor bill and post it * go to the 'Journal Items' tab and click on cut-off button and set following fields in the wizard: * *Recognition Date*: next month * *Accrued Account*: '486000 Charges constatées d'avance' * Adjusting Amount: as you want 50% for example * *Journal* : Miscellaneous Operations * click on create journal entries button Journal entries should be created. Fixes odoo#94390 closes odoo#184765 X-original-commit: cc0060e Signed-off-by: William André (wan) <wan@odoo.com>
Syncing from upstream odoo/odoo (15.0)
The test depended on a module that was not in the depends. closes odoo#184578 Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Syncing from upstream odoo/odoo (15.0)
Same issue as odoo#126323 but with CSV, TXT and other types of files. This basically overrides the default decoding charset of the email python module to use utf-8 by default. As mentioned in the PR above, utf-8 is a superset of the ascii encoding and this should not cause other issues. opw-4237114 opw-4245261 closes odoo#184295 Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Syncing from upstream odoo/odoo (15.0)
closes odoo#184060 Signed-off-by: Josse Colpaert (jco) <jco@odoo.com>
Syncing from upstream odoo/odoo (15.0)
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
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