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
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>
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 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>
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>
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
*: 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>
Louis Wicket (wil)