This commit improves the general feel when creating or displaying base automations
The improvement relies mainly on correctly labelling the fields
task-id-3450200
closesodoo/odoo#135932
Related: odoo/enterprise#47609
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The first intention of this commit was to remove ´@extend´ but
it actually makes sense to remove ´.oe_left´ and ´.oe_right´ classes.
Since grid we can avoid "float" elements (see .oe_subtotal_footer)
and we only have to remove this class.
For the other case, we have to use ´.float-start' and ´float-end´
to replace ´oe_left´ and ´oe_right´.
closesodoo/odoo#139199
Related: odoo/enterprise#49211
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The current used version of wkhtmltopdf manages is frozen to 0.12.5
because some features used by odoo are only available in this version
using a patched qt.
Anyway, it become difficult to keep this version up to date, especially
with Ubuntu Jammy and updates of the dependencies used by wkhtmltopdf.
More than that because of qt related issues, wkhtmltopdf maintenance
will end soon.
Adding a test to check some caracteristics of pdf reports may be usefull
to check that current version is still working, and eventually to find
an alternative solution.
This test checks that pdf reports contains the expected headers and
footers elements with the correct page number (2 record of 2 pages)
This also check that the pdf is in the expected A4 format.
Future test may check other formats, margins, layout,
page size/pagebreak combination, (table of content?), ...
This test may also check performances and existing limitations.
closesodoo/odoo#136626
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In the context of branches, you need to be able to select taxes of
an ancestor company on an invoice/bill, even when you don't have access
to the ancestor company.
In order to do that, we relax the restriction when searching with a
`parent_of` or `child_of` on a related field, so that it also includes
ids of related field records you don't have access to. This should not
be a problem, since in the end the search will return records of a
model restricted by its own access rules.
task-3503204
closesodoo/odoo#138942
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Once a branch company has some data associated with it, it can't be
deleted anymore. Since the branches could only be opened in a dialog,
it was also impossible to archive them.
In order to allow (un)archiving a branch, we added a stat button on the
company form to show the branches in a list view, where people can
(un)archive them.
task-3503204
Part-of: odoo/odoo#138942
Following 116879e17e81657f48a7d11780d8d30715ecc68f a few improvements were needed to make it more
complete.
task-3484125
closesodoo/odoo#137522
Related: odoo/enterprise#48563
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, the status bar field could be displayed in 2 ways:
- in small screens: as a dropdown
- in larger screens: as an inline list of buttons
This commit centralizes both of these approaches into a dynamic display
that fits the available space:
- the current stage is always displayed;
- previous stages are displayed behind or contained in a dropdown if not
enough space;
- next stages are displayed behind or contained in a dropdown if not
enough space.
Task 3336856
closesodoo/odoo#124267
Related: odoo/enterprise#48706
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
To avoid developers to update the dict of `_events`
in their overrides, to not alter by mistake
the default behavior.
Using a frozendict will force them to create a copy
of the dict.
closesodoo/odoo#123261
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
This commit is a preparation for the new page from template feature.
In order to make it possible for new page templates to be customizable
at several levels from themes, it was decided to create several layers
of primary templates.
Those templates are build from the descriptions found in manifest files
under the new `new_page_templates` key.
The same principle is also applied for configurator pages (described in
manifest files under the `snippet_lists` key) because we noticed that
some of the changes that were made in themes for some blocks were not
supposed to impact the "drag'n'drop" version of the block, but only
the version used inside the pages generated by the configurator. (E.g.
connecting shapes between blocks)
The manifest entries now have the following structure:
```py
'snippet_lists': {
'somepagename': ['s_block_name', ...],
},
'new_template_pages': {
'somecategoryname': {
'sometemplatename': ['s_block_name', ...],
},
},
```
This commit finds those entries in the manifests and creates the
following primary templates:
- `s_block_name`: already exists, this is the block that is drag and
dropped using the website builder
- `configurator_s_block_name`: specialization of `s_block_name` used in
all pages generated by the configurator
- `configurator_somepagename_s_block_name`: specialization of
`configurator_s_block_name` for that specific page
- `new_page_template_s_block_name`: specialization of `s_block_name`
used in all new page templates
- `new_page_template_somecategoryname_s_block_name`: specialization of
`new_page_template_s_block_name` used in new page templates of that
specific category
- `new_page_template_somecategoryname_sometemplatename_s_block_name`:
specialization of `new_page_template_somecategoryname_s_block_name` for
that specific template
For the template pages defined in `website` it also creates primary
templates that assemble `t-snippet-call`s of the most specific block
templates. Those templates are named
`new_page_template_sections_somecategoryname_sometemplatename`.
task-3381714
Part-of: odoo/odoo#126719
The issue with the t-cache (discribeds with a test in previous commit)
is that the key/value can be anything. It can be based on other t-cache
(assets in the example) but could be anything else.
The proposed solution will clear the t-cache when ANY other cache is
cleared. This is similar to the behaviour when the t-cache was
introduced (single ormcache)
Also sligly improve logging to precise what was cleared
closesodoo/odoo#138647
X-original-commit: aa69fa9f8efed0da45c601e5d57ce252446e376f
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
State code is shown instead of state name
in company details for Thailand companies.
opw-3493307
closesodoo/odoo#138576
X-original-commit: 6a47980364e4ceeb5a77b4f7e2f2a9475872275e
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Test HTML being inserted for the utils tests was not cleaned at the end
of the tests.
X-original-commit: 092cee52b343665ea3ca90e4f4aa302318a763b5
Part-of: odoo/odoo#138549
Prior to this commit, lazy-loaded bundles weren't pregenerated,
potentially causing non-deterministic test failures when the
generation process took too long. Plus, each Python test loading these
bundles necessitated their regeneration.
With this commit, the lazy-loaded bundles are now included in the
pregenerated bundles.
task-3493014
runbot-24842
closesodoo/odoo#134464
Related: odoo/enterprise#46985
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
before this commit, if profiling is enabled in the db,
and on trying to validate a sale order, a traceback is
shown
* enable profiling
* confirm a quotation
traceback:
Failed to render QWeb template : <div style="margin: 0px;
padding: 0px;">
<p style="margin: 0px; padding: 0px; font-size: 13px;">
introduced in: https://github.com/odoo/odoo/commit/016f26a9315c693bdeb894725898c2cf725d8989
here the options['ref'] is coming as the email template
body and it is failing on try to do int of options['ref']
after this commit, no traceback wont be shown on
confirming sale order, when profiling is enabled
closesodoo/odoo#138357
X-original-commit: 01548aff72b031389a7563948bb12bc3abb07bfc
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This commit renames calendar's attribute quick_add to quick_create
to be more consistent with other views.
closesodoo/odoo#138042
Related: odoo/enterprise#48677
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the PR [1], quick_add can be both a boolean and an id:
0 = without quick create
1 = with quick create and simple dialog
other number = with quick create and custom form view dialog
This is not great to have both behavior in a same attribute so this
commit split them back in two attributes as it was before [1].
It's easier to understand when we want a quick create and which view
to use in the dialog.
[1]: https://github.com/odoo/odoo/pull/122923
Part-of: odoo/odoo#138042
The summary is a short char field. It should not contain carriage
returns.
The description is the longer text field.
Remove unnecessary spaces in both.
Automatically dedent the description to avoid this issue poping up
again in future modules.
closesodoo/odoo#138214
Related: odoo/enterprise#48695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Purpose of this commit is to try to detect and log 'email_from' invalid
values when sending emails based on outgoing 'mail.mail'. This implies
checking the returned messages when having a generic Exception when sending
the emails, as we distinguish two use cases that raise through a simple
raise: missing from and invalid from.
New failure types 'mail_from_missing' and 'mail_from_invalid' are also
added at 'mail.notification' and 'mailing.trace' level, as other failure
types.
Task-3547653 (Mail: Add error type for wrong email_from)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#138202
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This reverts commit 4573ca0c83eb63785016f4389a5157efb21fa9a4.
Because now, `display_name` is implicitly on every form (last breadcrumb
item). Then it will be queried by `onchange` calls. When we create a
new record, `_rec_name` can be `False` and the display_name will be a
technical one: '<model_name>,<NewId0x...>' which is uglier than the
previous situation showing 'New'.
Part-of: odoo/odoo#138061
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
Install auth_oauth and via the /web/login, click the "Log in using
Odoo.com" button. You are redirected on odoo.com which ask you for your
odoo.com login and password. When the login form on odoo.com is
submited, you are redirected back on your local database.
The problem is that, in case a new account was created on-the-fly, then
the login fails with a cryptic error. The actual error is that
`request.env.user._is_internal` fails because `user` is an empty
recordset where it should had been the just-authenticated user.
The problem is an inconsistent transaction state between the cursor of
the request, the cursor used with `auth_oauth` (which created a new
user) and the cursor used with `authenticate` (which authenticated the
new user). Yes, there are 3 cursors. The newly created user just isn't
present in the transaction of the request's cursor.
Here is the lifetime of the 3 cursors:
* request.env.cr, it begins when the http request enters Odoo, it is
commited when a http response exits Odoo.
* /auth_oauth/signin, it begins roughly at the beginning of the
controller, it is commited once after the user is created (so before
the authenticate transaction begins but AFTER the request transaction
begun), it is commited again when the controller exits.
* authenticate, begins when authenticate is called, is commited when it
returns.
Because the request transaction started before, it cannot access user
created by /auth_oauth/signin.
Because the route is `auth='none'`, if system administrators append the
`auth_oauth` module via `--load` (cli) or `server_wide_modules` (odoorc)
then the controller can be accessed without database. This is the reason
for the explicit registry/cursor/environment inside this controller, we
needed to make sure we are connected to a database, we cannot rely on
request.
The new approach used in this work is to benefit from `ensure_db()`, the
function that is used by various web `auth='none'` controllers such as
/web and /web/login. It makes sure that the database we want to connect
to is already present on the request, otherwise it repeats the request
but this time connecting it to the database. Using this approach we can
have a `auth='none'` controller whose request.env is guaranteed to be
connected on the right database. We can avoid to create explicit new
registry/cursor/environment within the controller and just use request's
ones.
Because the /auth_oauth/signin controller now simply use the request
transaction, the above point:
> Because the request transaction started before, it cannot access user
> created by /auth_oauth/signin.
just doesn't stand anymore as the user is created within the same
transaction. The extra `cr.commit()` must still be present for
`authenticate` to see the newly created user.
opw-3421701
closesodoo/odoo#138051
X-original-commit: e165568f9795af213c8467a7f17948ed781b0799
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Now that the Debian 12 ("Bookworm") is out with Python 3.11 as the
default, it's time to update our requirements.
Reminder of the constraints for our requirements:
We try choose the smallest version from the Ubuntu/Debian corresponding
package (python3-...).
Also, if we find that one of the package was patched by the
Debian/Ubuntu maintainer, we choose the version from which the patch is
coming.
So, before this commit, the version were choose between Debian 11 and
Ubuntu 22.04. With this commit, we can simplify the requirements because
of a better matching between "Jammy" and "Bookworm".
About the choice of the python version:
* Ubuntu 22.04 ("Jammy") provides 3.10
* Debian 12 ("Bookworm") provides 3.11
* Some features that only exists in 3.9 will be needed in a near future
* 3.9 is a small release
Part-of: odoo/odoo#136904
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
at checkout use the invoice address as billing address instead of
main address if the invoice one is defined. Add the functionality to
add new billings addresses at checkout.
task-3258835
Part-of: odoo/odoo#118428
Postgres 15.0 has started enforcing a [long-standing
recommendation][secure-schema] of the `public` schema not being
`CREATE`-granted to every user, as in users which are neither
administrators nor owners of the database can not create DDL objects
(tables, views, ...) in the schema.
As Odoo [recommends using a non-admin non-owner user][configuring]
this would be the normal deployment mode of a production Odoo system,
following which Odoo would be unable to initialize the database and
install new modules.
Although the official recommendation is to create a schema with the
same name as and owned by the low-access user, the threat model does
not really affect Odoo as it always connects to the database with the
same user (or close enough). Odoo's behaviour is much closer to usage
pattern 5.9.6 ¶ 3:
> the database has a single user or a few mutually-trusting users
It also would not really work, as one could create and possibly
initialize the database with one user (e.g. using the command line),
then per [guide][configuration] run Odoo using a different user, which
would not be able to see the schema created for the first user and
thus would have to perform their own setup in an unrelated
schema (which it would have to create first). Resulting in an unused
full installation (with the modules and configuration the original
creator wanted) and a separate empty installation at best.
Thus implement the setup for 5.9.6 ¶ 3:
> grant privileges to create in the public schema
[configuring]: https://www.odoo.com/documentation/16.0/administration/install/deploy.html#configuring-odoo
[secure-schema]: https://www.postgresql.org/docs/15/ddl-schemas.html#DDL-SCHEMAS-PATTERNSclosesodoo/odoo#116172
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Motivations:
* `sequence` is not super intuitive for new devs
* It makes "useless" noise in data files
* It is redundant when what we want to see in the file is the same as
what we want to see on the user screen.
Do you understand anything related to sequences in here?
https://github.com/odoo/odoo/blob/15.0/addons/l10n_lu/data/account_tax_report_line.xml
Explicit is not always better than implicit.
* It is not implicit like using `id` it is natural and visual and saves
a lot of chore for adding and maintaining sequences.
Implementation
* It is optional, with the option set on root xml tags
Part-of: odoo/odoo#85750
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
*: tools
Steps to reproduce the bug:
- Add an image on the website.
- Replace it by a "jpeg". Note that the mimetype of the image is
"image/webp" at the upload since [1].
- Add a shape on the image.
- Save and Edit.
-> If you check on the available "Format", the mimetype of the
"original" is "webp" but it should be "jpeg".
Before this commit, there were two types of mimetype data attribute:
- `mimetype`: the current mimetype of the image.
- `originalMimetype`: the mimetype of the image without a shape.
Before [1], it was also the mimetype of the original image. However,
since [1], the user has the possibility to change the mimetype of the
image so the "originalMimetype" attribute does not always refer to the
mimetype of the original image anymore.
To resolve the problem, another data attribute has to be introduced.
Here is a summary of the mimetype related attribute:
- `mimetype`: the current mimetype of an image.
- `originalMimetype`: the mimetype of the image before a shape has
been applied. It is needed when removing a shape to recover the correct
mimetype.
- `mimetypeBeforeConversion`: the mimetype of the original image. It is
needed in order to be able to change the format of an image and come
back to the original one.
In the case of an uploaded "jpeg" image on which a shape has been
applied, `mimetypeBeforeConversion` is "image/jpeg", `originalMimetype`
is "image/webp" (since [1]) and `mimetype` is "image/svg+xml".
The `loadImageInfo()` has been adapted to also handle the case of an
image that has already been loaded but that does not have the
`mimetypeBeforeConversion` attribute (for example all the images that
were uploaded on the website before this commit). In this case, the
mimetype attribute is kept and not set to the original one as the user
could have changed it.
[1]: https://github.com/odoo/odoo/commit/0449fe85cb0e1d639a4e1aeba26e90906f79254d
task-3449866
closesodoo/odoo#137424
X-original-commit: 730588b802506844e6ca54df312333bfd8df1d52
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When enable, this new feature adds the possibility to set a PDF header, footer and some product
documents to the quotation report.
These PDF can contains forms that'll then be filled using Odoo database.
This replace the previous sale quotation builder feature.
task-3249142
closesodoo/odoo#133773
Related: odoo/upgrade#5168
Related: odoo/documentation#5863
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
Decorator 5 changed the default decoration method from a transparent
exec-ing to wrapper functions. This makes the decorators visible to
the profiler, and breaks one of the profiler tests as the stack traces
now differ between using decorator 4 and decorator 5. Amongst other
concerns, this is an issue because debian bookworm has updated
decorator to 5 (.1.1), and the next ubuntu LTS (which should be 24.04
hopefully codenamed Nefarious Nematode) will do the same (Ubuntu has
been providing decorator 5 since 23.04).
5.1 added a `decoratorx` function which corresponds to the old
exec-based `decorator`, however it doesn't have a `decorate`
version. So we have to flag the wrappers, instead of decorate-ing the
original method with them. This seems to have the same semantics so
why we were using `decorate` is not entirely clear why we were not
doing that previously (neither
b1e83fd7b8 nor #25383 really provide
explanations). Possibly because pylint is a dum-dum and requires
ignoring one of its rules?
Implement in 14 since it doesn't hurt even though the test in question
does not exist yet.
closesodoo/odoo#137323
X-original-commit: 52e92904eca3cdeaee734b0a83e2d3fb463e8b56
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Introduces a hierarchical structure of some menus. Reasons:
1. Allows testing the child-parent relation of specifically those menus
that do not have `parent` or `parent_id` attribute in the source xml
using standard menus. It's likely a rare use case, but that's precisely
what we currently need in https://github.com/odoo/upgrade/pull/5163
2. Provides a unique example usage of menus written in this manner
as opposed to using the `parent` attribute
closesodoo/odoo#136069
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The mail server mostly doesn't use the intrinsic features of
`PyOpenSSLContext`, instead it pretty much just uses the underlying
`OpenSSL.SSL.Context`, just through the wrapper.
The only thing it actually uses from `PyOpenSSLContext` is
`load_cert_chain`, and since we are using a keyfile and are not using
a password this is equivalent to *two* function calls. Just perform
those two calls directly, remove all the indirections, and remove the
unnecessary import.
Bonus content: since 2.0 `load_cert_chain` reraises the inner errors
as `ssl.SSLError` which we don't handle, so we avoid this extra issue.
This was discovered because from 2.0.0 to 2.0.4 the
`contrib.pyopenssl` module was marked as deprecated (it was
undeprecated in 2.0.5) but regardless its use is an unnecessary
complication here.
closesodoo/odoo#137198
X-original-commit: e534bbed78a80d1ba0c8edd22e039e5cfb50e613
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
- `Response.charset` is deprecated since 2.3, `Response.set_cookie`
accesses the currently-extent internal `_charset` directly until
this too gets removed in Werkzeug 3.0. Add a `_charset` to
`FutureResponse` so this does not crash.
- Bytes response headers are deprecated since 2.3, and will get
removed in 3.0, passing bytes in websocket is completely unnecessary
happenstance which is trivially fixed.
closesodoo/odoo#137145
X-original-commit: 66e3040d4ad9e03aabefebd4799f699ad30fca45
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Add a computed m2m field giving allowed models for the action. It allows to
avoid choosing the wrong models when designing server actions.
Remove a test that has no use: it checks a model_id field is available on
server action view while we don't want to display it as it is imposed by
the rule itself.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Fix name compute method:
* correctly call super in batch;
* correctly filter records;
* remove dependency on context key (which was missing in triggers);
In this commit we also consider the name update should always be done even
outside of automated rules context. Having a whole compute method relying
on a context key does not makes sense. As server actions are technical
records, having the name always being correctly updated is better.
Task-3527758 (Base Automation Refactor Fiximp)
Part of Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137133
Babel's named / implicit formats (short, medium, long, ...) come from
the CLDR, which can get tuned as debates get settled, cultures shift,
etc... as a result using these formats can break tests on any babel or
even CLDR release (technically nothing stops distros from updating
their bundled babel with new CLDR data).
b77eb98bbf6bc937efb7941802c0794ae3622094 previously did some
mitigation of this issue, but even if they're not yet in distros
further Babel updates (e.g. 2.12) already affect some of the patterns
we're using.
Proactively mitigate this issue more by only using explicit datetime
patterns (and time patterns, date is fine because it retrieves the
pattern from the lang rather than default to babel patterns) in the
date/time formatting tests. This means only specific terms still vary,
and those should be a lot more stable / reliable than e.g. futzing
with separators and minor formatting issues.
closesodoo/odoo#137181
X-original-commit: 3547e980428cc1dd11c8e82446e7d7f824b9f6f8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Lucas Perais