Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
closesodoo/odoo#163433
X-original-commit: d06a22991cd604e46d6392f6394b2b0e6a4ae673
Signed-off-by: William André (wan) <wan@odoo.com>
Some options have been renammed a long time ago but there was no
mechanism to warn the user should those option be still present in its
configuration file.
Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and
`geoip_database` in their configuration, those two options have been
renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and
saas-16.1 c59750d824 but no deprecation warning / automatic failover
were provided.
closesodoo/odoo#163193
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options`
in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
closesodoo/odoo#163123
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The module `l10n_nl_reports_sbr` requires
- `zeep.wsdl.utils.get_or_create_header`
- `zeep.ns.*`
- `zeep.wsse.*`
In addition, it requires the `session` to be already
set during the creation of the client.
The module `l10n_pe_edi` requires `requests.Response` as possible
output for service
```py
result = client.service.sendBill
if result.status_code != 500:
...
```
Can be tested with
`--test-tags external_l10n:TestEdiSunat`
opw-3887309
opw-3884785
opw-3885630
opw-3870707
opw-3888951
opw-3885636
opw-3885392
opw-3885383
opw-3889366
opw-3888841
The API of zeep changes according to the version of zeep.
We want to limit the number of used methods and attributes
of the zeep client by our developers.
Hence, we provide our own zeep Client limited to the
attribute and method we really need.
In addition, a timeout for GET/POST requests
should be applied by default when creating a new Client,
which is not the case by default.
We override that behavior to always provide a default timeout,
and an easier API for developers wanting to change
the default timeout.
Before it was needed to import `Transport` from `zeep`,
instanciate that `Transport`, with a timeout and optionally
a session, and then pass that transport instance to the creation
of the Client.
We provide a way to directly pass these timeout parameters
through the Client constructor.
In addition, we serialize the returned values of Zeep service operation
calls, to make sure we return simple types in methods of models
e.g. bools, integers, string, ...
Monkey-patching C types is not straightforward.
It relies on changing the attributes or methods in memory
at the right address with the exact right size.
This requires the greatest caution.
A simple mistake can mess up the memory used by the Python interpreter,
and for instance lead to `SegmentationFault` exceptions
or unforeseen behaviors.
However, being able to patch C type is a very powerful tool.
With great power comes great responsibility.
`patch_c_type` is implemented with the greateast caution.
The Python C-API documentation has been thoroughly followed
and understood.
In addition, this patch has been battle tested in real
conditions.
In the end, this allows to patch unwanted behaviors
from types implemented in C.
Co-authored-by: Denis Ledoux <dle@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Mathieu Walravens <wama@odoo.com>
Prior to this commit, some attributes such as "data-tooltip" were not
exported in /static/src/ templates, while "label" was only exported in
them.
This commit adjusts the code to use the same list of translated
attributes everywhere, fixing the problem and making it less likely to
happen again.
Task-3872895
closesodoo/odoo#162250
X-original-commit: 6c272a432cea29fa98d9f2a3e4f454214099f3e6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
`_UNSAFE_ATTRIBUTES` was changed from a `list` to a `set` in odoo/odoo#151989.
odoo/odoo@cde2781591
Reset it to a `list` as before, by retro-compatibility concerns,
in case developers used features not working on `set`.
For instance:
- `_UNSAFE_ATTRIBUTES.append`
- `_UNSAFE_ATTRIBUTES.extend`
- `_UNSAFE_ATTRIBUTES + ['foo']`
The opportunity is taken to add `_co_code_adaptive`,
which is a new attribute added from Python 3.11,
hence available from Ubuntu Noble.
Firstly added as `_co_quickened` in
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7b153de6cdd
Then renamed to `_co_code_adaptive` in
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b981ff26262b6
The opportunity is also taken to move `mro` out of the `Python 2 functions` section,
as `mro` is available in Python 3, hence making the comment confusing.
Part-of: odoo/odoo#151989
In ubuntu noble, some timezone where removed leading to errors when
trying to assign/access them.
This was partially fixed in the code by removing all references to old
timezones but one issue remains: if a database contains timezones that
are not defined in the os, the resolution will fail and break at runtime
This patches proposes to alter timezone to fallback on the new canonical
timezone if the timezone was removed.
This list was generated by checking all symlink in /usr/share/zoneinfo
in ubuntu 22.04 that disapeared in ubuntu 24.04
This solutions will work when moving a database from one server to
another, even without migration.
The all_timezone is not modified on purpose to avoid breaking existing
logic. This list may be used to define if a timezone is known by
postgress, define selection fiels, .... we don"t want to increase the
list in those case.
Some other logic using all_timezone may need to be updated but This
will be done in master.
Part-of: odoo/odoo#160842
In latest versions of werkzeug, the `werkzeug.urls` module has been
reduced to remove feature present in urllib.parse. This commit vendored
the old version to avoid breaking compatibility with older versions of
odoo on ubuntu Noble, without adapting the whole codebase. This
should/may be removed in stable by adaptaing eveything to urlib.
This version of the lib was minimalized to avoid redondunce with feature
still present in werkzeug.urls. Some unused features in odoo are still
vendored for ease but are not exposed on the werkzeug.urls for now.
Part-of: odoo/odoo#160842
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#160842
In `ir.model.data` model, there is no SQL constraint which is
ensuring that the `name` field can not contain `.` (dot)
So when loading the translations to database if the xmlid's `name`
contains dot then `xmlid.split('.')` will split it more than 2 parts.
Which will cause issue during saving it to database as it is expecting
2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts
with `maxsplit=1`
closesodoo/odoo#160228
X-original-commit: a1ae06f499b183db69b7e763a2803a079f540a77
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Adds the possibility to give formatLang() a 'rounding_mode' (any Decimal rounding mode)
and an amount_rounding ('decimals', 'units', 'thousands', 'millions' and 'lakhs').
'amount_rounding' will display the amount in the given unit. For example, 10456 in 'thousands' will be 10.
task-3626894
closesodoo/odoo#151314
Related: odoo/enterprise#55218
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently an empty section is not considered empty text.
As the web editor sometimes uses them, it is relevant to consider
them when asking whether some html will appear empty.
Currently, even completely removing the website description of an
exhibitor in website_event_exhibitor from the backend does not make
the 'missing description' tooltip appear in the front-end
task-3607615
closesodoo/odoo#154097
X-original-commit: 7dc376d4d2d2b4000de0da7573c30e4508f32318
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>
In previous versions the max size of a domain was bounded by psycopg
memory limits. With the new SQL formatting mechanism the limit is bound
by the maximum recursion limit in Python side. The purpose of this patch
is to restore previous behavior.
In 16.0:
```
>>> def make_dom(N):
... return [*('|' for x in range(N-1)), *(('login', '=', 'admin') for x in range(N))]
...
>>> u.search(make_dom(9984))
res.users(2,)
>>> u.search(make_dom(9985))
Traceback (most recent call last):
File "<input>", line 1, in <module>
u.search(make_dom(9985))
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 1520, in search
return res if count else self.browse(res)
File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5140, in browse
if not ids:
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 217, in __bool__
return bool(self._result)
File "/home/odoo/src/odoo/16.0/odoo/tools/func.py", line 28, in __get__
value = self.fget(obj)
File "/home/odoo/src/odoo/16.0/odoo/tools/query.py", line 210, in _result
self._cr.execute(query_str, params)
File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 321, in execute
res = self._obj.execute(query, params)
psycopg2.errors.SyntaxError: memory exhausted at or near ""login""
LINE 1: ...((("res_users"."login" = 'admin') OR ("res_users"."login" = ...
```
in 17.0 without this patch
```
>>> u.search(make_dom(1480))
res.users(2,)
>>> u.search(make_dom(1481))
<shortened output ...>
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 86, in <genexpr>
if isinstance(child, SQL):
File "/home/odoo/src/odoo/17.0/odoo/tools/sql.py", line 85, in code
child = stack[-1].send(child)
RecursionError: maximum recursion depth exceeded
```
This issue was observed in upgrades in multiple instances. Example: MRP
produces an OR domain with 2K terms for warehouse sub-locations that
fail.
closesodoo/odoo#153394
Signed-off-by: Raphael Collet <rco@odoo.com>
To reproduce:
- Put your fiscal year to the 30th of December (yes it's unlikely)
- Create an asset
- Compute depreciations
=> they are created for the 31th of December
It comes from the `get_fiscal_year` in `date_utils` which considers it as the case of the 28th of February
opw-3704466
closesodoo/odoo#153528
X-original-commit: cd0bb178441790e7e33c0d1c01b7ade82d4ab8c0
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
If translation of '__export__' module record's source and translated value in
'en_US' language is different. In that case, record's value of en_US lang is
translated value. Also in most of the case export module records are set as
noupdate false due to this while upgrading the database to version 16 from lower
version, the record's value is changed to their source value for 'en_US' lang.
To avoid this problem of updating a record's value, this PR will not considering
'__export__' module records for translation updates. Hence,'__export__' module's
records translation remain same as per original database.
Task : 3626386
closesodoo/odoo#148757
X-original-commit: 29341902bd6b6b7ff84eede2651251f6d2ce2faa
Signed-off-by: Raphael Collet <rco@odoo.com>
Add support for `HALF-EVEN` and `HALF-DOWN` as value
for `rounding_method` argument of `float_round()`.
closesodoo/odoo#152227
Signed-off-by: Raphael Collet <rco@odoo.com>
Slot params are dynamic content, similar to props, and are not
translated.
There is no point in adding untranslated content to the .pot files; so
this commit prevents the content of slot params from being exported for
translation.
Task-3718993.
closesodoo/odoo#152606
X-original-commit: b839faf09be259ffdccf9d872e646e4ebe4a8bcb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
When we update an inline translated element (like `<span>`) for the base
language `en_US` we should update the modifiers attributes for all
languages.
For example when updating from (16.0)
https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/views/ir_ui_view_views.xml#L127-L129https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/i18n/fr.po#L7233-L7235
to (17.0)
https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/views/ir_ui_view_views.xml#L126-L128https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/i18n/fr.po#L12087-L12089
The base term, `en_US`, is updated since the text matches but the
attributes of the translated terms, `fr_FR` for example, are not
updated. Later when the PO file is loaded in non-overwrite mode the
translated terms for `fr_FR` is not updated. This causes all sort of
issues during an upgrade for inline-translated terms -- like `<span>`.
More so since the recent change that converts domain-based attributes
into inline Python expressions.
In this patch we propagate modifiers attributes from inline-translated
items in the new base term into all translated terms when the base term
is updated. In that way we ensure the attributes are correct in all
languages even if later the loading of their corresponding PO file
doesn't update the term.
For a detailed example, let's see what happens when loading the view
above during an upgrade 16->17, right at the first load of the XML file
at https://github.com/odoo/odoo/blob/b1461d28/odoo/fields.py#L1864
```
(Pdb) p old_term
'<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">This view has no previous version.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">This view is not coming from a file.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">You need two views to compare.</span>'
(Pdb) p closest_term
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[old_term]
defaultdict(<class 'dict'>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
As we can see the new term will get an updated value for its `invisible`
attribute, while also removing `attrs`. The translated terms will be
still keep the old modifier though.
Now later when the fr_FR.po file is loaded we reach this point
https://github.com/odoo/odoo/blob/b1461d28/odoo/tools/translate.py#L1442
```
(Pdb) p term_en
'<span invisible="reset_mode != \'soft\'">This view has no previous version.</span>\n <span invisible="reset_mode != \'hard\'">This view is not coming from a file.</span>\n <span invisible="reset_mode != \'other_view\'">You need two views to compare.</span>'
(Pdb) p translation_dictionary[term_en]
defaultdict(<function DeepDefaultDict at 0x7fc9640cdfc0>, {'fr_FR': '<span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'soft\')]}">Cette vue n\'a pas de version antérieure.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'hard\')]}">Cette vue ne provient pas d\'un fichier.</span>\n <span attrs="{\'invisible\': [(\'reset_mode\', \'!=\', \'other_view\')]}">Vous avez besoin de deux vues pour comparer.</span>'})
```
Thus the translated values are NOT updated, keeping the _wrong_
modifiers. This is later fixed during the upgrade in a clumsy way.
C.f. the warnings like this one in runbot:
```
Incomplete conversion for view(id=77, lang=fr_FR) at
<span attrs="{'invisible': [('reset_mode', '!=', 'soft')]}">Cette vue n'a pas de version antérieure.</span>
```
Note that such warnings are gone in current PR CI.
The root issue here is that when the fr_FR translation is loaded the
terms are not updated due to a combination of factors:
1. The text content of the term didn't change
2. There is no override flag set for translations
Option 2 is not a valid option during upgrades because we want to keep
custom translations. We could instead of the current patch tweak how
option 1 works and perhaps make the closest term more restricted. This
would lead to the update of the whole translation though while the
actual issue here is _just_ the modifiers. Moreover if the translations
are out of sync the translated terms will still keep the wrong values
that could still be essential for the correct functioning of the record
they belong too (view archs -- for example).
Finally this is a more extreme case (16.0):
https://github.com/odoo/enterprise/blob/1e63b4a8/sale_subscription/views/sale_order_views.xml#L142
In this case during the upgrade we fix the modifier value (refer to
runbot warning above -- it's the same script that fixes it) and set
```
invisible="(subscription_management == 'upsell') or (recurrence_id == False)"
```
for translations, which is wrong. The correct value is (17.0):
```
invisible="not plan_id or subscription_state == '7_upsell'"
```
https://github.com/odoo/enterprise/blob/530ba3ad/sale_subscription/views/sale_order_views.xml#L136closesodoo/odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
`get_text_content` will transform contiguous space chars into single
spaces, plus translate special HTML elements
```
>>> " ".join(html.fromstring(f"a\n b & c").text_content().split())
'a b & c'
```
In order the correctly verify if a term is text-only we need to use the
HTML parser. Note that to be resilient against bad XML, but valid HTML,
we cannot use the default XML parser.
Part-of: odoo/odoo#150152
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
When a model_terms translated field is overridden to a model translated field.
Its terms in the po files should be ignored otherwise calling field.translate
which is boolean will cause error.
opw-3644158
closesodoo/odoo#148518
X-original-commit: 50b314ff3c5d5003ad570d29a05bacd832d70362
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
PDF written with scribus (and some other software) have a problem when filling fields: the output
does not work as expected. The replaced value is there, but hidden behind a blue overlay, shown
only when clicking on it.
We now show the field value and ensure filled fields are read only.
Additionally, some readers only allow a single value per field name. Even if the values were
different on the documents, only one would be shown. We now rename the fields to ensure they are
different when they have different values.
task-3626047
closesodoo/odoo#145163
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The default is 25000 rounds, which is too low nowadays.
An off-the-shelf laptop takes ~400ms for a single hash at 600k rounds.
closesodoo/odoo#147202
X-original-commit: e200e96bfbb9cc29771b3727231e2f9a9ae01825
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Steps to reproduce:
- install the e-commerce module
- in General settings, add and switch French -or any- language
- Go to website
- Under e-commerce > product in the menu bar
- click on any product
- click on go to website smart button
- click on edit button to edit the website page
- choose any block to insert, You can notice the message (DROP BUILDING BLOCKS HERE TO MAKE THEM AVAILABLE ACROSS ALL PRODUCTS) stays in English
Investigation
- The message is not add to website_sale.pot file, as the message string passed to an attribute not an actual string inside a tag.
opw-3573881
closesodoo/odoo#145755
X-original-commit: 9a595cd19fba3a68dacd5159d0b04102bc76cadf
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
Steps:
- Create a ticket with a customer ( it will the email)
- Answer to the mail with Outlook Desktop( a multiple lines break)
- Look at the response in the discuss frame.
Issue:
In the frame there is much more lines break than in the original mail
Cause:
The format of outlook desktop mail before sanitizing looks like this
```
<div class="WordSection1">
<p class="MsoNormal">Test<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Two break lines<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
```
So when parsing it transforms the ``<o:p></o:p>`` in ``<p></p>``
which adds more lines break when displayed.
Solution:
Remove empty ``<o:...>`` and ``</o:...>`` tags which are specific to outlook desktop before.
opw-3089550
closesodoo/odoo#144931
X-original-commit: a3e9db87277771c9801f24a5f52aa73b98a0d879
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior before PR:
When you send an email at the receivers end you will see ' ' shown before you open the mail and it disappears once you open the email
Desired behavior after PR is merged:
Corrected and now the ' ' character doesn't appear where I replace it in the HTML template with its equivalent character
Test changes:
The test case that was there was comparing static strings with the HTML entities where my solution is removing those entities so I change the strings to be after escaping those HTML
opw-3481781
closesodoo/odoo#144648
X-original-commit: 1fcd45f19c2d6900ad5d1848a988ab0ae5f287a8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The test added in 09a4762b will fail randomly, because of the nondeterministic
os.walk access. This commit removes this nondeterminism in the pot.
closesodoo/odoo#143918
Signed-off-by: Raphael Collet <rco@odoo.com>
Some auto-generated field labels don't make sense for translators. For example
field: needed_terms_dirty label: "Needed Terms Dirty"
After this commit, if the field.export_string_translation is False, we don't
export their labels when export translations.
closesodoo/odoo#142329
Signed-off-by: Raphael Collet <rco@odoo.com>
When Odoo is installed with the latest version of the PostgreSQL client (postgres-client or postgres-client-16) and running in Docker (possibly other environments as well but not reproduced so far), executing `pg_dump` via `exec_pg_command` fails with
Database backup error: Postgres subprocess ('/usr/bin/pg_dump', '--no-owner', '--file=/tmp/tmpmnqiktog/dump.sql', '15TEST') error 1
This seems to be because `os.devnull` is being opened in *read* mode which is incorrect (as it's written to). It's not entirely clear if older `pg_dump` simply ignored the non-writable stdout or if docker adds some restrictions which cause the failure.
Either way this can be solved by either opening `os.devnull` in write mode or switching to the `DEVNULL` constant. While the function is deprecated in 16.0 (7f14631fe8) and removed in master (ae3056f3f4fca82c6aee69bf201532e14829c45e) the latter is not a huge change and it a touch cleaner.
fixes#139687closesodoo/odoo#143198
Forward-port-of: odoo/odoo#142987
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When 'getadresses' fails at parsing some input and give us a result like
'gmail.com' (see previous commit adding test cases) we fallback on using
'email_re' which is better at finding email addresses in a global string.
We use it only in this specific case as fallback mechanism to rely on
'getadresses' when possible.
Task-3572208
X-original-commit: odoo/odoo@8e61a3b690
Part-of: odoo/odoo#141856
In the 'Accounting Settings' of 'Fisical Year', When the User tries to set
'February' as a month and the 29th as a Day and Save it, It will allow the user
to save but when the User opens the spreadsheet dashboard in the terminal,
same error will be generated.
Steps To Produce:-
1) Install the 'spreadsheet_account' module
2) Go to Settings -> Accounting
3) In the 'Fiscal Periods' of 'Fiscal Year', In 'Last Day' select
'February' month and set 29 as a Day
4) Go to the Accounting module, Customer->Invoices
5) In the 'Favorites', Select 'Insert Link in a Spreadsheet'.
6) Open Spreadsheet, Click on the 'Dashboard' Tab
The Error will be generated in Backend(Terminal)
Applying these changes will resolve this issue.
sentry - 4079962029
closesodoo/odoo#140011
X-original-commit: 1323829d3b5e134300f326f86c887f1cad6119f4
Signed-off-by: Laurent Smet (las) <las@odoo.com>
[Here](https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/odoo/tools/translate.py#L1645) If 'en_US' is exist in new_values then as a default language 'en_US' translations are loading due to that translation of default language gone lost
OPW -3482255
original translation look like this
if default language is dutch for example then instead of dutch language english's translations are there
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
```
arch_db look like this
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this dutch</p>
</t>
</t>
```
closesodoo/odoo#139111
X-original-commit: 542851c50182f32327f9cd3607081515899ddb76
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Sanchit Gupta (sagu) <sagu@odoo.com>
Now that some field attributes like invisible are given by Python expressions
and that those can involve some set operations, we have to ensure that
the views can be validated if they use such operations. We do that and
add a test.
closesodoo/odoo#139451
Signed-off-by: Géry Debongnie <ged@odoo.com>
When the user tries to modify the view with an invalid xpath expression,
an XPathSyntaxError traceback will appear.
Steps to produce:
1. Install the Accounting module.
2. Settings > Technical > UI > Views > Open any view
3. Invalidate expr syntax and try to save, thus an error will be generated.
Error: XPathSyntaxError: Invalid expression
This commit handles XPathSyntaxError by raising ValidationError
instead of a traceback.
sentry-4377014622
closesodoo/odoo#139435
X-original-commit: 2af583d0b803b3334b871002e447d3211eb09bc2
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Before this commit escape was needed to use a Markup object as a
parameter, hence loosing the fallback mechanism in translations
>>> escape(_("Order %s has been confirmed")) % Markup("<a>%s</a>") % order.name
Markup("Order <a>SO42</a> has been confirmed")
Now it is possible to explictly give a Markup object to the gettext call
>>> _("Order %s has been confirmed", Markup("<a>%s</a>") % order.name)
Markup("Order <a>SO42</a> has been confirmed")
Part-of: odoo/odoo#139316
Currently, bulk-importing translations for non-module loaded data is hard
1. PO file import works fine, but exporting a PO template for non-module loaded
data is near impossible (since PO exports will only export entire modules)
2. Import of translated values during csv/excel file import is not supported
This commit fix the issue by improve 1 which reuses the translation export
wizard for modules to export translations for non-module records. So that user
can export translations for selected records with a domain and import the po
file after translating
[DEBUG MODE] Settings -> Translations -> Export translations -> Export Type
("model") -> Select `Model to Export` and `Model Domain` -> Export
The framework will
1. create external ids for records without external ids
2. export translations for stored translated and inherited translated fields
closesodoo/odoo#138531
Task: 3463505
Signed-off-by: Raphael Collet <rco@odoo.com>
The new method should be used to generate an SQL object that represents
how to order by a field in an SQL query. We introduced the auxiliary
method _order_field_to_sql() so that one can specify some SQL for
ordering by a given field with a simple method override.
Part-of: odoo/odoo#138019
For very large bits of SQL code with potentially repeated terms, it is
useful to use named parameters instead of positional parameters:
sql = SQL(
"SELECT %(column)s FROM %(table)s WHERE %(column)s IS NOT NULL",
table=SQL.identifier("foo"),
column=SQL.identifier("foo", "bar"),
)
Part-of: odoo/odoo#138019
yosa-odoo