To reproduce the issue:
1. Go to 'res.country.state.csv' in base
2. state_ch_sh is "Shaffhausen"
Error: should be "Schaffhausen"
State code is still SH because
ISO 3166 code for this state is CH-SH
OPW-3199628
closesodoo/odoo#114202
X-original-commit: 245804aabb5cd8b3a84b2a4836b188ec9fb144e1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
LE is most commonly used today.
opw-3188129
closesodoo/odoo#114094
X-original-commit: e901ee541407b70fee8bad0d6adc80e0726079d2
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
The date format set on the Norwegian language is not kept when we click
on date fields
Steps to reproduce:
1. Install Sales
2. Install and switch to Norwegian language
3. Open Sales and create a new quotation
4. Click on the 'Quotation Date' field
5. The date format is changed from '%d. %b %Y' to '%Y/%m/%d'
Solution:
Change the default Norwegian date format to a valid static format
The format used comes from babbel[^babbel], double checked with the
Norwegian locale[^nb.js]
[^nb.js]: https://github.com/odoo/odoo/blob/16.0/addons/web/static/lib/moment/locale/nb.js#L25
[^babbel]: https://www.babbel.com/en/magazine/how-to-write-the-date-in-norwegian
Problem:
The old date format didn't pass the `isValidStaticFormat` test of the
date picker, so the default format 'yyyy/MM/dd' was used instead
opw-3191605
closesodoo/odoo#113926
X-original-commit: c27226e13392207811b61aceb3c77d1e9fcc180d
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
The test-file is used by some dev to run all test classes from a file.
But test-file is always post install and doesn't always have the same
behaviour of a normal test execution.
This commits modifies the module test tags behaviour to be able to
give a file.
closesodoo/odoo#113850
X-original-commit: 5aff8cf22ab0cbac7a9a3cebf39860f55617f79e
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Odoo Test environments requires to modify many parts of the unittest
TestCase, Suite and Result.
The main initial reason is to **avoid to postpone result at the end of
the test suite**, because even if it is convenient to have all errors
visible after the tests in some case, odoo logs adds information during
the execution that can be useful to debug when a test fail, to have
context for an error. (see **OdooTestResult**)
We are also fixing the stack trace comming from a unittest and since
there is no proper way to hook inside the TestPartExecutor, a dirty hack
injects anoter result on the outcome to manage the error and complete
the stack trace. This was also a way to avoid to postpone subtest logs
at the end of the test case (see _ErrorCatcher)
`_feedErrorsToResult` was used to test the test suite behavior since
there are many customization and this is quite fragile, especially if
unittest changes behavior in other python version.
**Python 3.11** introduced python/cpython#664448d8 That, in a way, goes
in the same direction of the changed introduced with _ErrorCatcher:
immediately feed errors to resut instead of postponing it. But this also
removes `_feedErrorsToResult` that was used to test this behaviors, as
well as other ones.
Since odoo should remain multi-version, this amount of changes on the
initial behavior become to complicate to keep cross-version and the
(already in our mind for a while) solution to **vendor unittest** will
help to simplify most of our test code base.
This commit modified the vendored unittest files to simplify them as
much as possible to suite our needs.
Since the runner is still the unittest one, we need to inherit from
unittest.Testcase in order to have the right type.
This also means that we still have access to all TestCase methods
without overriding them all. This is convenient for assertion methods as
an example but the initial idea is to vendor our own version of TestCase
to avoid having trouble to adapte our miscommunications to future python
versions. A trade-off must be done to chose what should remain in our
code base. The idea is to keep logic closely linked to our changes in
our code base, mainly around the run method, but also addClassCleanup
wich need to be vendored for python 3.7, but assertions methods are
independent. Any logic can be moved fom unittest to our
vendored version in the future if needed.
X-original-commit: 9a5d1ea54be49e4cc8208c33e76a6bbd2414d5d0
Part-of: odoo/odoo#113850
Vendor some unitest file before modifying them in next commit
Chosen files are suite, case, and result since they are working together
and are the most modified classes in odoo.
mock, signals, runner and utils will still be imported from unittest.
X-original-commit: 742d165b9a1bff23deb736dee6b266c76f3ce727
Part-of: odoo/odoo#113850
As the public user, browse the website where you usually should see some
profile pictures (e.g. inside the forum). All the images are wrongly
replaced by the grey avatar placeholder.
When using `ir.binary._find_record` it was checking the access rights
and raising `AccessError` early even if the record was
`website_published`.
closesodoo/odoo#113526
X-original-commit: 0611fb437b699588317919e72ccfa1c41f1245bc
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The aim of this commit is to make more warning and error dialogs behave
like the "oh snap" dialog of form views.
task-id=3126594
closesodoo/odoo#112276
Related: odoo/enterprise#37593
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
company_id is not in the group with phone, which makes it unaligned and weird looking, you can
see that especially when HR is installed and adds a boolean with a longer label.
this commit closesodoo/odoo#111567.
task 3127608
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In the partner form, when you change the state of the partner address and the country remains the same, it still triggers an update on the country field.
This change makes sure that the country is only updated when it has actually changed.
task-3143841
closesodoo/odoo#111230
Related: odoo/enterprise#36386
Related: odoo/upgrade#4277
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Creating a new partner with no company selected should raise the
same VAT partner warning if there is any other partner **in any**
company with the same VAT.
closesodoo/odoo#113649
X-original-commit: 97bf59848e6e0dabda28db4b6fc1cc20844f0b97
Signed-off-by: William André (wan) <wan@odoo.com>
A set iteration was creating a random number of queries on some tests.
This was noticed in TestEventPerformance were a random additionnal query
could appear in default_get depending on _get_description and
_get_default_stage_id order.
This commit uses a list to get a deterministic order. It looks like
the set was not useful anyway.
closesodoo/odoo#113563
X-original-commit: 13572df256ccc6351588851d385c381ace155e0d
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue: The start day is Monday and should be, for 'en_US', Sunday as it
is the case in the dashboard view in accounting (see appendix).
Cause: The query uses the `date_trunc('week', date)` which in Postgres
retrieves the first day of the week as Monday (ISO week).
Solution: Create an offset in the query depending on the first day of
the locale variable.
Note: the `web/tests/test_read_progress_bar.py` has been modified: since
the default language is 'en_US' there will be an offset of one day. To
make it less confusing, I used only two anglo-saxons countries so the
day offset is not the variable tested. (for this matter, pleaser refer
to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
opw-2747066
closesodoo/odoo#93053
Related: odoo/enterprise#29539
Signed-off-by: Raphael Collet <rco@odoo.com>
Selecting a recipient for which there exists no partner trigger a partner form
dialog creation. For some model (ex.: crm.lead), some default values can be
prefilled from the current record. This is what we do here by calling a generic
mechanism that allows each model to define default value for related partner.
Note that we don't provide a more detailed form to the user because some will
otherwise feel obligated to fill it out entirely.
Technical note: As there is no need for a custom form per model from which the
data are extracted to populate the related partner, the simplified partner form
(view_partner_simple_form) is just augmented with additional invisible field by
modules that add fields to partner and need to populate them automatically from
values of another model.
Technical note: In TestCRMLead.test_message_recipient_partner_auto_creation, we
test that the _message_get_suggested_recipients returns the correct default
values to copy some fields from the lead to the partner to avoid the user to
reenter them. But we don't test specifically that it also work when using mail
composer and template (which generate the partner) because it has already been
tested when introducing the mechanism. Although, we verify that it should
behave the same because we verify that the default values returned by
_get_customer_information, that is used in mail template when using the
composer, are the same as the ones returned by _message_get_suggested_recipients
which is tested here.
Task-3024050
Part-of: odoo/odoo#105111
In an edge case the content of the field has already been
prefetched as sudo during the read of another field as sudo,
therefore it doesn't try to read the field as the normal user
closesodoo/odoo#88134
Signed-off-by: Julien Castiaux <juc@odoo.com>
The ofxparse module explicitly uses an html parser instead of xml but
since bs4 4.11.0, this triggers a warning.
closesodoo/odoo#113354
X-original-commit: e81ed97c9c54c69c68c54c69b4d3d80ed0515ae8
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Babel 2.10 (provided in Debian Bookworm) changed the `medium` format at
least for fr_FR and zh_CN.
This commit adapts the tests in order to work with both versions of
Babel. A custom format is used as our unit test is made to test that our
formating methods works, not the way the Babel formats.
X-original-commit: b77eb98bbf6bc937efb7941802c0794ae3622094
Part-of: odoo/odoo#113354
Install a database with many langs, arab, french, english, ... Keep
english as the default lang. Start a shell and validate a sale-order
using the superuser. On the web client, the sale order has been
validated in arab instead of in english.
In 16.0 the `context_get` method was changed to ensure there was always
a lang set in the returned context. It used the following fallback
order: context > request. The solution was partial because in case there
was no request to extract a lang from, no lang was set on the context.
In a recent 16.0 fix (f2523c4a), the mechanism was changed to fix the
previous problem. The fallback order became: context > request > first
installed lang. This solution is sub-optimal because the first installed
lang isn't always the best pick. e.g. when you have a mostly english
company but that arab is installed for some website pages, arab is
selected instead of english (the langs are alphabetically sorted)
In this work, the fallback order is changed once again:
1. The lang set on the user's profile if activated
2. The best lang extracted from the user's browser if activated
3. (new) The lang of the user's current company if activated
4. (new) English if activated
5. The first lang (ordered by ISO code) if any
6. English
The 3rd should cover most of ill-cases. For the 4th step, we assume that
english is prioritaty to other installed langs when no lang standout.
closesodoo/odoo#113186
X-original-commit: 03134bf7cb1e3d63f3be435fbc734e6198ca029b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The field is updated in SQL but not in cache. Also remove hacks in the
business code to prevent potential issues from this behavior.
closesodoo/odoo#113119
X-original-commit: 8bb660c985c7a1349cae1bf58dc5bf7981bd9058
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, the connection pool works greedily regarding the
number of connections opened. Once a new connection is needed, it is
added to the pool and never closed unless the maximum number of
connections is reached.
We introduce 2 changes. First, we do not cycle on the available
connections anymore. We take the first one available and let it at its
position in the list. It opens the possibility to use
`idle_session_timeout` introduced in PostgreSQL 14.
Moreover, we introduce a garbage collection of the unused connections.
If the connection has been unused for more than `MAX_IDLE_TIMEOUT`
seconds, it is closed and removed from the pool.
This makes easier to overcommit `--db-maxconn` when running in worker
mode. We can set a value which is large enough for the websocket
requirements without the WorkerHttp having a large number of useless
opened connections.
closesodoo/odoo#113110
X-original-commit: 9fcf3de6a9f10d4171bb48feb65fd789db19d4c6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.
closesodoo/odoo#113039
Task: 2759019
X-original-commit: c3745be816b1bf9ecd38184307452f93326ef36f
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
According to the method documentation, `Field.write` should return
the subset of record actually write.
But it is not respected at every return, it is not used at all and it generated extra completixy for nothing.
Then remove every return values.
closesodoo/odoo#111108
Signed-off-by: Raphael Collet <rco@odoo.com>
The `_update` of `_RelationalMulti` return a bool but the
others `_update` methods doesn't return anything.
It is actually not used. Also, the `_update` is always called with
a recordset as `value`, then the first part of the method is useless.
Part-of: odoo/odoo#111108
`convert_to_cache` of the `Selection` field type, check that the
column_type is 'int4'. But nowadays (since
a0e05e2ab9), a `Selection` field can
only be a Varchar type.
Part-of: odoo/odoo#111108
`handle_error`'s docstring states that it returns a `Response`, but in most case `HttpDispatcher.handle_error` returns an `HTTPException`.
After discussion, the implementation is correct, `handle_error` should be documented to return a WSGI Application (a callable taking an `environ` and a `start_response` callable) instead.
closesodoo/odoo#112889
Forward-port-of: odoo/odoo#112690
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Werkzeug 1.0 colorised some outputs on POSIX IFF `click` was
installed.
Since 2.0 (pallets/werkzeug#2012) werkzeug unconditionally colorises
the log on POSIX. This is annoying when using output redirection (let
alone logging to a non-stream), as werkzeug will dump ANSI color codes
to the non-term stdout and thus the logfile.
Werkzeug provides no official knob to control this behaviour, but it
does have a secret flag which is normally used to check if colorama is
available on windows (so the ANSI codes are not output if colorama
won't be interpreting and stripping them on the way out). Since
`werkzeug.serving` is available in pretty much all versions, we can
just (un)set this flag if not logging to a tty, and versions 2+ should
pick it up and disable colorisation.
closesodoo/odoo#112829
X-original-commit: 7c9f883dc508a7a8a45bf7bf7e900da0be9b34be
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
Add a record in the "Contacts & Addresses" tab of a contact.
Issue:
There are missing spaces in the information display.
Cause:
The kanban view compilation removes the spaces
(and line breaks) between the different tags.
Solution:
Add spaces on the template.
opw-3131806
closesodoo/odoo#112667
X-original-commit: 7bada7fc942cee0bcfd6447665640ee29a4b5752
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
How to reproduce
================
1. Create a user with lower privileges then admin
2. Add a new company and a new contact of that company in the contact
app at the sametime
3. Manually save
This will result in a write access denied
opw-3127591
closesodoo/odoo#112595
X-original-commit: 93a37df79fc30c2f9ac31d60dc897452851fd5bd
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Since Python 3.11, sampling from a set deprecated, the population must
be a sequence.
This commit applies the suggested fix.
Also, the filtering of the deprecation warning about sampling from set
can be disabled when the python version is not 3.9. This warning was
wrongly triggered since 3.9 because recordsets are bot a sequence and a
set.
This was fixed in python 3.10, see https://bugs.python.org/issue42470closesodoo/odoo#112450
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since python/cpython#18544, unittest mock is not able to properly find
the "odoo.tools.config".
When trying to patch the `options` dictionnary, it leads to
`AttributeError: module 'odoo.tools.config' has no attribute 'options'`
In order to have the tests
working in python <= 3.11, we have to import the config module and patch
the options in place.
Part-of: odoo/odoo#112450
When python expression is evaluated in odoo form an action or qweb, we
are checking the opcodes generated by the evaluation of this code. We do
such a verification, because the code from actions and templates can be
written by someone having not access to the server and we don't want to
let them perform actions out of the scope of their database.
In python 3.11, some opcodes from previous versions of Python have been
renamed, grouped or sepcified. There are also new ones that have been
introduce.
In this PR, we are whitelisting the new ones that are needed by odoo to
properly work in this version of Python.
Part-of: odoo/odoo#112450
Antoine (ande)