Previously, importing the default export on the same line as the named
exports was not supported, this commit adds support for that in order to
allow removing duplicate imports.
before:
import something from "path";
import { A } from "path";
after:
import something, { A } from "path";
Part-of: odoo/odoo#84530
The issue has been introduced by 1fe4b0cc1981382cc3d944ec44276f0aee90945d.
A simple example is an element with attribute "string" like
<field name="foo" string=" "/>
When the translation process is parsing the value of the attribute as
some HTML fragment html.from_string(" "), it raises an exception. This
was not a problem before the commit above, but it now is. For instance,
updating the view "event.view_event_form" triggers the error.
closesodoo/odoo#84144
X-original-commit: 5ffc1704162d8918985964b08f4b2b49e6054958
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Christophe Simonis <chs@odoo.com>
When comparing existing translations to new source value
html tag would invalidate existing translations.
The html tags used for styling (coloring, italic, ...) should not
invalidate the translation as the meaning of the text as not changed.
Changed the logic to compare translations based on textual content only.
+ add some tests.
task-2667950
closesodoo/odoo#83895
X-original-commit: 1fe4b0cc1981382cc3d944ec44276f0aee90945d
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: xmo-odoo <xmo@odoo.com>
QWeb is the primary templating engine used by Odoo. It is an XML
templating engine and used mostly to generate XML, HTML fragments and
pages.
To create new XML template, please see :doc:`QWeb Templates documentation
<https://www.odoo.com/documentation/15.0/developer/reference/frontend/qweb.html>`
In **input** you have an XML template giving the corresponding input
etree. Each etree input nodes are used to generate a python function.
This fonction is called and will give the XML **output**.
The ``_compile`` method is responsible to generate the function from the
etree, that function is a python generator that yield one output line at a
time. This generator is consumed by ``_render``. The generated function is
orm cached.
In the graphic below you can see theresume of the call of the methods
performed in the IrQweb class.
Odoo
┗━► _render (returns MarkupSafe)
┗━► _compile (returns function) ◄━━━━━━━━━┓
┗━► _compile_node (returns code string array) ◄━━━━━━━┓ ┃
┃ (add technical directives: t-inner-content, t-tag) ┃ ┃
┣━► _directives_eval_order (defined directive order) ┃ ┃
┃ ┃ ┃
┣━► _compile_directives (recursive) ◄━━━━┓ ┃ ┃
┃ ┣━► _compile_directive ┃ ┃ ┃
┃ ┃ ┗━► t-if ━━► _compile_directive_if ━┫ ┃ ┃
┃ ┃ ┗━► t-foreach ━━► _compile_directive_foreach ━┫ ┃ ┃
┃ ┃ ┗━► t-* ━━► ... ━┛ ┃ ┃
┃ ┃ ┗━► t-inner-content ━━► _compile_directive_inner_content ◄━━━━┓ ━┛ ┃
┃ ┃ ┗━► t-tag ━━► _compile_directive_tag ━┫ ┃
┃ ┃ ┗━► t-call ━━► _compile_directive_call ━┫ ━━━┛
┃ ┃ ┗━► t-out ━━► _compile_directive_out ◄━┓ ━┫
┃ ┃ ┗━► t-field ━━► _compile_directive_field ━┛ ┃
┃ ┃ ┃
┗━━┻━► _compile_static_node ━┛
Part-of: odoo/odoo#81024
The `check` decorator in `sql_db.py` was on a lot of `Cursor` methods.
It checks if the cursor is close before be using a the method.
Remove it because:
- It is completly redundant because `psycopg2` do already the job
to check the cursor before usage.
- It complicated the call stack and lead to a small overhead of
highly use methods (can be more than 1% of the execute call)
- Also the nature of
the Error isn't correct: raise `OperationalError`
(https://www.psycopg.org/docs/module.html#psycopg2.OperationalError)
instead of `InterfaceError`
(https://www.psycopg.org/docs/module.html#psycopg2.InterfaceError).
Part-of: odoo/odoo#80961
The possible index names have been renamed "btree", "btree_not_null"
(instead of "not null") and "trigram" (instead of "gin").
Task 2742526
Part-of: odoo/odoo#83274
It's not entirely clear whether `@synchronized` is even useful, but
keep it for now. `locked` is just the default instance of
`@synchronised`.
- rewrite `@synchronized` using `decorator`, don't fold everything
into a single call as there's a potential for parametric conflict
- remove the independent `locked` in `sql_db.py`
- convert `lru` to `locked`
- move `Registry` over to `locked` where applicable
closesodoo/odoo#82718
Signed-off-by: Raphael Collet <rco@odoo.com>
Rely on country.address_view_id instead of hacking the view on the fly. The
address layout (street VS street_name street_number street_number2) depends now
on the country of the user, not on the installed localisation. (it's now
configurable per country)
Unified street format to "Chaussee de Namur 40 - Appt 12"; the
configurable ones where actually wrong by country.
Allow street split without base_address_extended; all EDIs can now be
used with or without base_address_extended.
Merged base_address_city into base_address_extension, to avoid creating bridge
modules for no reason. Uses city_id instead of city if the country of the user
defines it AND if enforce_cities is set on this country.
Improved post_init script for large databases.
Split of street removed on res.company. (not required by any l10n)
[IMP] l10n_cn_city,l10n_nl,l10n_cl,l10n_co,l10n_pe: base_address_extended improvements
l10n_cn_city defined cities but did not provide a means to edit the city_id, so enforce_cities
l10n_nl only requires street names and numbers and thus does not need to depend on base_address_extended
l10n_cl should not depend on base_address_extended as none of the features are used
l10n_pe improve the view
l10n_co remove base_address_city dependency - move to l10n_co_edi
closesodoo/odoo#81710
Related: odoo/enterprise#23108
Related: odoo/upgrade#3129
Signed-off-by: Laurent Smet <las@odoo.com>
When setting the password in the database manager the config is saved
automatically in a odoorc file.
This can be problematic, especially when testing locally, with
specific options.
Going in the database manager and creating a new database or changing
admin pasword will save all those options.
This commit proposes to only save the admin_passwd when modified.
Part-of: odoo/odoo#82874
Avoid to base64 encode, then decode to process assets and images for a ~25% speed improvement.
Change image processing tool to work on images, rather than base64 encoded strings.
Performance is ~25% faster on assets & images:
/web/assets/...frontend.min.css: 13ms to 7ms, base64 enc/dec: 2 -> 0
/web/image/XML_ID: 10ms to 8ms, base64 enc/dec: 3 -> 0
/web/image/res.users/2/avatar_128: 40ms to 20ms, base64 enc/dec: 6 -> 2
closesodoo/odoo#82851
Related: odoo/enterprise#23537
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Both of the native `magic` libraries can trigger an allocation error
if the buffer being sniffed is large. This results in nothing useful
for the user and just triggers and exception when trying to create
large attachments (in the hundreds of MBs).
Fix by implementing the workaround suggested in
ahupp/python-magic#82, under the assumption that it should also work
fine for Debian's python-magic.
The pure-python trivial version of odoo should not have this issue, as
it does not normally copy the source buffer in full, it just seeks and
slices the buffer, and occasionally parses it as a zip (but does not
normally load everything in memory).
Task-2722110
closesodoo/odoo#83190
X-original-commit: 94fc66452f28a8c64b4077d6cc2dd17ea1f00aa6
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Let's imagine this data
```xml
<record model="my.model" id="1">
<field name="name">parent</field>
<field name="children_ids">
<record model="my.model" id="1.1">
<field name="name">child</field>
</record>
</field>
</record>
```
Loading this data the first time, everything works fine.
But if we update it, this is what happens:
* load `my.model,1`: write on `name=parent` and `children_ids=None`
* load `my.model,1.1`: write on `name=child` and `parent_id=my.model,1`
The write on `children_ids=None` can unlink all the children if the
field is declared as `ondelete=cascade`
That will leade in all the records to be deleted and recreated, but
without keeping links with other documents.
For instance, when upgrading the `account` module, all the
`account.account.tag` are removed from `account.move.line` because when
the `account.tax.report.line` are updated, all the tags are deleted and
recreated.
closesodoo/odoo#82793
X-original-commit: de00316fa42173f3a5c394458bb4418e59e298cd
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
Co-authored-by: jva-odoo <jva@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Since auto-retry, real errors will lead to doubled errors on runbot.
This can be noisy and hard to understand.
This commit will help with this by using a lower log level on the first
execution. Log 25 are kepts.
closesodoo/odoo#80378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before when we do `reserved(records)`, it iterates in a reverse
order of `records`. Unfortunately, the `__reserved__` method don't
exist explicitly in BaseModel then Python fallback on
its own implementation using `__getitem__` and `__len__` (coming from Sequence): https://github.com/python/cpython/blob/3.10/Lib/_collections_abc.py#L1047-L1049
Because it uses __getitem__, it breaks the prefetch of the recordset.
Example:
-------------
```
partners = self.env['res.partner'].browse(1, 2, 3, 4, 5)
for partner in reversed(partners):
partner.name
```
will generate 5 SQL requests to fetch data (one by record)
Then create our own `__reversed__` and handle the prefetch correctly
(like `__iter__`). Now in the example it will correctly generate only
1 SQL request because of the prefetch.
task-2687953
closesodoo/odoo#79622
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
First step to stream QWeb templates: removing the two post
processing operations applied on rendered templates. This
should slightly speed up the rendering of every page.
1/ Don't remove empty lines after rendering, but fix the root
cause of: view inheritancies and QWeb compilation that don't
add extra empty lines.
2/ handle page break in the two reports that uses it, rather
than processing every view produced.
closesodoo/odoo#82244
Related: odoo/enterprise#23328
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
closesodoo/odoo#82238
X-original-commit: 5164739b835445fa11b2efc53e2ff839a4bad10a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Those were not accounted for, leading to fstrings passing through
unflagged.
Also update the SQL checker to be stricter but smarter:
The previous version would "fail open", unknown nodes would be allowed
through hence f-strings not being flagged when they started appearing
in arg0 position, should now fail-closed, anything that's not allowed
is forbidden.
This flags a few more cases, all of which seem acceptable upon review.
However the previous version would also only resolve arg0 (in case it
had a `NAME`, to see if that resolved to an acceptable form of
query-building). The new version performs resolution during
`_check_concatenation` and should thus allow e.g. format strings to be
separate variables (though not e.g. module-level constants, yet
anyway).
In resolution, replace the ad-hoc process by astroid's built-in
`lookup` which seems to provide the same information. Slightly more in
fact, as it yields every assignment in case of e.g. conditionals, but
making use of that would require a lot more changes in the checker so
leaving the behaviour as-is for now.
It's important to *not* use `ilookup` here, because ilookup is not
"iterable" but "inferring", and we don't want values, we want
expression ASTs for analysis.
NOTE: previous improvements as well as fixes to existing code were
only implemented in 14.0, hence this being merged in 14.0 not 13.0
despite 13.0 still being supported.
closesodoo/odoo#81721
X-original-commit: 376ccf0944dae1bc53ae9c5385977c4e6b23e083
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
There is an issue when exporting pdf using edi documents created before
the PDF/A commit. With the subtype now included, the system would try
to use the subtype given by the ir.attachment which would not be formated
as expected by the pdf file format.
The attachment may get neutered by the ORM, so we may have to force
the mimetype when embedding it.
This fix in two parts will allow to force a subtype when adding an
attachment into a pdf, as well as parse the subtype of ir.attachment
to give them the right format.
xxx/xxx should become /xxx#2Fxxx
opw-2714040
closesodoo/odoo#81898
X-original-commit: 880d7a1c8474a3bee4fd05474788fbd4a63f4ae7
Signed-off-by: Laurent Smet <las@odoo.com>
When the system broadcasts an email response to document followers,
if the config parameters `mail.force.smtp.from` or
`mail.dynamic.smtp.from` are defined, it will rewrite the `From`
address to avoid spoofing the sender's domain.
**NOTE**: As of 15.0, this is based on the `from_filter` setting on the
corresponding ir.mail_server, rather than the abovementioned config
parameters, but the rest of the discussion stands.
For example, if the `mail.catchall.domain` is set to `example.com` and
an email response comes from:
"John D" <john@doe.com>
it will rewrite it to:
"John D (john@doe.com)" <notifications@example.com>
This will make sure the system never sends outgoing email for an external
domain, as it has no authority for doing so, and that could
break mail filtering/authentication rules (SPF, DMARC, etc.)
During this "encapsulation rewrite step", both the original Sender name
and their email are preserved, and put into the quoted "name" field of
the rewritten address. It seems sensible to preserve as much information
as possible about the original sender.
Unfortunately, the inclusion of the Sender email in the final name makes
it appear to some inbox providers as if the message is trying to
deceptively impersonate another person (as many phishing schemes would).
As of November 2021 GMail at least does this, and will hide the name in
the UI when it happens. It will keep only the rewritten email, which is not
very useful in the case of a notification (even though it's more
technically correct, of course).
This patch removes the original email from the rewritten notification,
keeping only the name, considering that the email is not the most
important part, and it's better to have one of the two than none.
So after the patch, the rewritten address is now:
"John D" <notifications@example.com>
When there is no name in the original address, we keep only the local
part of the email, to avoid the same display issue. The recipient will
have to identify the sender based on the context / past messages.
closesodoo/odoo#81807
X-original-commit: 3c65ec5a8191a392980ceb0a8c584767eae405f1
Signed-off-by: Olivier Dony <odo@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
After this commit, the js_transpiler will support exported hoisting
function. So it will be possible to define a hoisting function and
exported in an @odoo-module.
Example of exported hoisting function which wasn't supported before
this commit:
```
hoisted();
export function hoisted() {
...
};
```
closesodoo/odoo#80965
X-original-commit: 40ef9f7aeac8048cce8f002c84181abc64bcbe87
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Bug
===
The arguments of the lambda function might be the same as other
variables in the QWeb. In that case the template rendering will crash.
To avoid this issue, we encapsulate the name of the argument to be sure
it's not the same as other variable in the QWeb engine (so the name of
the argument can no longer make the QWeb rendering crash)
Task-2674716
Closes#78392.
Forward-port of 96b09b127028e5c9a83c89acce86e1b6df904c6f
Some data are formatted as a tree structure with a relation of parent.
We are adding meaning to the structure:
* This improves readability and allows to fold/unfold records in
editors.
* This could be done before using `eval`, but this allows to have an
xml_id for those records. It also allows to update the records without
having to rewrite on the parent x2many field.
Part-of: odoo/odoo#76675
Since
https://github.com/odoo/odoo/commit/ebf8d67485f7f71f6eb51762298cf50c5835ee08
design-themes repo is not excluded from the cloc count.
The module website_animate that was used as beacon to identify
the folder that contains the design-themes as been merged into website.
We need a new one, theme_common seems a reasonable candidate
closesodoo/odoo#79512
X-original-commit: f493b43462b7db14bb7f2b444c189f284acb1a1d
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.
Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.
You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.
You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.
You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')
You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.
You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).
Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.
We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.
+ fix some lint diff for ci style in master
closesodoo/odoo#78556
X-original-commit: d9ce0507960f247e1187baf7bd8399f90be237aa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When using a profiler manually inside the code, and longpolling uses
this part of the code, an error will appear on runbot since gevent
server cannot be profiled properly.
This fix mitigate the issue by disabling the profiler automatically in
this case.
Part-of: odoo/odoo#78514
As per the logging documentation, it is fine to send arguments that are
not string. Logging takes care of stringifying and injecting the
arguments in the message template.
closesodoo/odoo#78172
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Magic return image/svg instead of image/svg+xml if file starts with <svg
+ refactor the import/else to if/else to avoid pylint error:
function already defined line 137 (E0102) at odoo/odoo/tools/mimetypes.py:181
That raises an error during CI/runbot
closesodoo/odoo#77193
X-original-commit: b76f13853a25a93307db2bcafb6a83ad75b92244
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This pr proposes an auto retry mechanism for tests. This shouldn't
impact normal testing: tests are not supposed to fail, but the growing
number of tests and pull requests can lead to some bottleneck when a
staging fails because of a random error. This mechanism should help to
reduce splits/the need to retry a failed pr.
This branch have been tested with the nightly multi build, creating 40
identical build without test-tags to disable know random errors.
This multi build is used to detect test failing randomly, this is an
excellent candidate to detect the effect of the retry.
On average, with the current base of this pull request, there is between
10 en 15 failures over 40 build.
With the auto retry mechanism, only 1 build failed over 40 builds since
the same error was triggered twice.
This is simply because with the retry mechanism, an error that has a
probability of p to fail randomly will still have a probability of p² to
fail with the retry mechanism. A error that occurs 10% of the time
should only appear 1% of the time with one retry. In most of the case,
the retry is sucessfull: https://runbot.odoo.com/runbot/build/10053257
The current solution to allow to enable this mechanism only in some
cases (staging) is to check an environment variable
"ODOO_TEST_FAILURE_RETRIES" that defines a number of retry.
This will allow to retry more than once if an error still occurs to ofen
with the autoretry.
The mechanism will run multiple time the same test on the same
test_case, meaning that some modification on self may impact the second
execution. The following code is an example of how this could be
problematic, but also a good example to test the auto-retry mechanism.
```python
class TestRetry(HttpCase):
def test_fail(self):
self.t = getattr(self, 't', 0) + 1
if True or self.t == 1:
import logging
_logger = logging.getLogger('test_a')
with self.assertLogs(level="ERROR"):
_logger.error("This shouldn't be log at all")
with mute_logger('test_a'):
_logger.error("This shouldn't be logged (mute)")
_logger.error("This should be log")
```
As we can see here the error logs are also managed, and emit at a lower level the first time, butany log higher than 25 will make the test "failed" and the autoretry mechanism will be triggered. The second time, everything is logged normally. We also need to replace Traceback by _Traceback to avoid being catched by runbot Traceback detection regexes.
The inspiration here commes from the assertLogs, that replace all handlers. The mute_logger had to be adapted to use the same strategy, so that quite_logger won't detect logs catched by mute_logger or assertLogs.
closesodoo/odoo#76336
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since commit bbb1a8f151, module's upgrade script can also be added
into special 'upgrades' folder as an alternative to the old 'migrations'
folder.
As those upgrade scripts are not maintained from version to version, we
should not count them as maintenance.
OPW-2536046
closesodoo/odoo#76334
X-original-commit: 28a303a67935dc5566cc0d1fe2be157736691968
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
By activating the profiler debugger, the two qweb options is added. The
qweb templates that need to be rendered are compiled into a new function
to add instructions for saving data.
`Add qweb directive context`
It's a sub-option of "Record sql" or "Record traces", add some context on
thread at current call stack level. This context stored by collector
beside stack and is used by Speedscope to add a level to the stack with
this qweb directive information.
```
directive=t-call='website.layout', xpath=/t/t
t_call_content
directive=t-foreach='5' t-as="'a', xpath=/t/t/div/div
directive=t-esc='website.search([])', xpath=/t/t/div/div/t
execute
```
`Record qweb`
Add profiling data used by ProfilingQwebView widget. In the `ir.profile`
form view, the widget display the duration and number of sql of every qweb
directives with the xml of templates. Every xml is recorded to be
consulted even if the user change the xml templates.
```xml
<t t-call="website.layout">
<div>
<div t-foreach="5" t-as="a">
<t t-esc="website.search([])"/> <!-- will display 5 separate requests -->
</div>
</div>
</t>
```
closesodoo/odoo#74712
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This hook automatically generates custom tooltips (instead of
native ones) for all elements with the "data-tooltip" attribute
set, inside the component using it. The optional attribute
"data-tooltip-position" can be used to enforce a specific tooltip
position.
This commit also makes the WebClient use this hook.
Part-of: odoo/odoo#73311
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Refactor the Environments object into a Transaction object, which is
bound to one cursor, and is no longer shared among several cursors.
The following methods/properties have been changed:
- Environment.envs no longer works (because of the design change);
- Environment.manage() is deprecated (no longer useful);
- Environment.reset() is now an instance method;
- env.clear_upon_failure() is deprecated in favor of cr.savepoint().
closesodoo/odoo#75598
Related: odoo/enterprise#20451
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
As the descriptions of the donation snippet will be in hidden inputs,
we added the possibility to translate these inputs in translate mode.
PR-63133
task-2398403
Part-of: odoo/odoo#63133
Since de077243 the iter(False) will occur when trying to render a
speedscope output with `use_context=False` since the context given in
parameter of `stack_to_ids` won't be an iterable.
This simple fix avoid this by always giving an empty iterable
in this case.
closesodoo/odoo#75851
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
This commit improves the UI of the mail group module (backend and portal
view), fix some bugs and clean the code.
Bug 1
=====
If a user click 2 times on a confirmation link, an error is raised.
Bug 2
=====
A bug about the website snippets has been fixed;
- Add the snippet to a group in which you are member
- Change the group of the snippet to a group in which you are not member
- The snippet still show "Unsubscribe"
Bug 3
=====
In the portal view, when messages are filtered by month, messages which
are created in the last day of the month appear also in the next month.
Specification
=============
UI
--
Show the Allow / Ban buttons whatever is the state of the message, so
the user can ban / whitelist a message even if there's no pending email.
When we receive an email, remove the "Mailing List" footer. This was a
big issue because when some users reply many times, the footer was
duplicated on each answer.
Improve the form view of the mail group:
- On non-moderated group, show all messages instead of only pending
message
- Show the guidelines stuff on non-moderated groups
Improve the portal view
- show the attachments under every message (not only on opened message)
- improve the template to confirm the subscription of the user
- improve the portal view for mobile device
- do not show rejected messages, even for admin
- do not show the button "X replies" when the mode is not thread
Technical
---------
Split the route "/groups/subscription" into "/group/subscribe" and
"/group/unsubscribe"
Correctly quote the parent email for the emails sent by web version of
Outlook (with the HTML id "divRplyFwdMsg").
ACLs
----
Now only administrators or responsible / moderators can write / unlink
the group.
Fix an ACL issue on the group member where the responsible of a
non-moderated group could not access the members of the group.
Members with same email
-----------------------
Improve the behavior when multiple members have the same email address
(this situation is possible because there's no unique constraint on the
email field of the <res.partner> model.) We now return the most
appropriate member for the given email address and partner.
When unsubscribing by clicking on the confirmation link that we received
by email, remove all members with the same email address.
Links
=====
Task-2599676
See odoo/odoo/pull/73640
closesodoo/odoo#73640
Related: odoo/upgrade#2774
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The initial behaviour of ExecutionContext was to
- add the context for the current level of the stack on enter
- remove the context at this same level on exit.
When two ExecutionContext are nested at the same stack level:
- the first one adds it's context;
- the second one overrides the current context;
- the second one removes it at the end;
- the first one fails to remove the context at the same level a second time.
def call():
with ExecutionContext(foo=1):
with ExecutionContext(bar=2):
execute()
In this case we could imagine to combine both Execution managers in one:
def call():
with ExecutionContext(foo=1, bar=2)
execute()
But the semantics is different: ExecutionContext should add one level to
the stack, instead of two. In the first example above, we expect two
additionnal levels:
call
foo=1
bar=2
execute
A simple solution would be to transform the value of the context at some
level to a list of dict, but this would make the copy more difficult.
The decision was taken to change the context storage strategy, going
from a dict where the keys are the level to a tuple of tuples where the
first element is the level.
{3: {foo: 1}, 4: {bar: 2}} => ((3, {foo: 1}), (4, {bar: 2}))
The first benefit is to allow multiple contexts at the same level. The
second one is that we don't need to copy the data structure, since
tuples are immutables and the dicts are coming from kwargs. This means
that saving the context is faster, and the tuple is shared between
multiple samples. This is interesting if we assume that we do more
samples than exec_context mutations.
closesodoo/odoo#75687
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit proposes a mechanism to manually add a frame before a
blocking c-call and triggers it before calling libsaas.compile.
closesodoo/odoo#75519
X-original-commit: f836ff3a67d446cd8b3ab2cf573fab649153e6da
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Samuel Degueldre