Skip to content

Conversation

@hhgabelgaard
Copy link

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

MiquelRForgeFlow and others added 30 commits May 12, 2021 16:28
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
…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
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
Signed-off-by legalsylvain
StefanRijnhart and others added 22 commits April 5, 2024 14:13
[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][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
[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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.