forked from OCA/OpenUpgrade
-
Notifications
You must be signed in to change notification settings - Fork 0
13.0 #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
hhgabelgaard
wants to merge
52
commits into
steingabelgaard:13.0
Choose a base branch
from
OCA:13.0
base: 13.0
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
13.0 #2
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
If there's no double approval, all the previous orders will be ignored. TT42662
[13.0][FIX] pin CI ubuntu to ubuntu-22.04
[13.0][ADD] rename l10n_nl_mis_reports to mis_template_financial_report
…on-date [13.0][OU-FIX] purchase: set date_approve in all the confirmed orders
Apparently `lxml.html.document_fromstring` (and possibly other `lxml.html` loaders) parses byte-strings as latin1 regardless of their actual encoding, maybe because python2, maybe because there's a super legacy html4 parser underlying it. Either way that means ever since loading `static/description/index.html` files was added 10 years ago (4bf6a7e) `_get_desc` has been loading these files in latin1 rather than the utf8 most people would expect. Add an explicit decoding phase to try and load html description files in UTF8. Fall back to latin1 in case there are description files which are genuinely in latin1, or even just some random-ass broken stuff which very much isn't utf8 (the extended-ascii encodings -- of which latin1 is one -- will happily accept and mangle any input as every byte value is valid, utf8 is a lot more structured). Closes #127846 closes odoo/odoo#133708 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
I missed a critical issue in #133708: various users had discovered they could already fix description issues by adding an XML declaration to their document which is very cool (though technically not really valid). What is a lot less cool is that lxml gets *extremely* unhappy when asked to parse *strings* with an encoding declaration, raising a ValueError, so the purported fix breaks on any module which does that, which seems to include a lot of OCA modules. Gate the encoding guessing by bailing if the document has an XML declaration, in which case we just assume the author knows what they're doing and we leave them alone. For extra safety, check the encoding declaration in ascii and utf16. Could also have checked for BOMs, but lxml seems to not care about them overly much (in fact it seems to prefer them decoded which is odd). closes odoo/odoo#133900 Reported-by: @rezak400 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Upgrade (aka migration) scripts are a core part of Odoo, allowing database manipulations for modules during version changes. Any module, including custom ones can run upgrade scripts, even if the `--upgrade-path` flag (and with it, the `odoo.upgrade` sub-module) is not present. Currently only the "standard" modules benefit of easy upgrade script testing. Any custom modules that want to run tests of their upgrades have to import the tests in the usual `tests` folder, which is not ideal. Therefore, to allow TDD and programmatic testing of upgrade scripts in custom modules, the test discovery is here modified to also parse the module's `migrations` and `upgrades` sub-modules for tests. closes odoo/odoo#122569 Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
…3cc20b95e Solved conflicts on: - odoo/modules/module.py
[13.0] update upstream 483cc20
[13.0][MIG] l10n_ch
…ions-mle [13.0][OU-IMP] l10n_es: Handle fiscal positions renaming
The formatting should be done regularly, or the value that will be used will be literally `openupgrade_legacy_13_0_check_number`. TT46186
…nting-sql [13.0][OU-FIX] account_check_printing: Proper SQL string
…ponsible [13.0][OU-ADD] stock_picking_responsible: merged into stock
It was put on renamed_modules.
This one was introduced in 14.0 in Odoo core, but already present in l10n_es_extra_data in 12.0, so let's rename it here for having everything in the same place.
[13.0][OU-IMP] l10n_es: Include REAGyP fiscal position mapping
…ation_widget_partial [13.0][IMP] apriori: merge account_reconciliation_widget_partial
[13.0][ADD] apriori: Change name of quality_control_team to quality_control_team_oca
[13.0][OU-IMP] base: vacuum of transient models
…e_tab-entry [13.0][FIX] account: don't set exclude_from_invoice_tab for type entry
In the analysis, the record point_of_sale.pos_config_main appears to be deleted. It's true that it is not overridden in the 13.0 version. But this record is not deleted, it still exists as it main definition is in the module point_of_sale. In 12.0 the field crm_team_id is added to point_of_sale.pos_config_main and in 13.0 this field rely only on the _get_default function defined in the pos.config model in pos_sale. There is no need to delete point_of_sale.pos_config_main, and there is no need to modify the crm_team_id value of this record. As this may have been modified by the users.
[13.0][OU-FIX] pos_sale: do not delete point_of_sale.pos_config_main
[13.0][IMP] apriori: edi_oca -> edi
[13.0][FIX] website: also use company logo when website.logo is False
[13.0][OU-FIX] mrp: remove_tables_fks requires list
[13.0][IMP] account: assign tag tags of parent taxes to repartition lines
…mplate [13.0][OU-ADD] product_email_template
[13.0][FIX] github workflows actions
[FIX] account: reversed_entry_id migration was reversed
[13.0][OU-FIX] stock: convert responsible_id to company_dependent
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.
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