This commit:
- moves the "Company Registry Number" from `res_company` to `res_partner` (which might be different from the VAT in some localizations). This must be unique among all partners of the same country.
- allows the search of partner by using their "VAT" or their "Company Registry Number"
Task-id: 2857253
Community PR: odoo#91938
Enterprise PR: odoo/enterprise#27605
Upgrade PR: odoo/upgrade#3570closesodoo/odoo#91938
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
The call to `commit()` can fail during the flush of the environment
and raise an exception before the actual `COMMIT;`, leaving the
cursor unclosed.
This leaked cursor may hold locks that only be released when the GC
collects it. On low-traffic workers like the CronWorker, this can
lock usual database usages.
X-original-commit: 3cb3cec67c28ca147288103adb219e6da8694248
Part-of: odoo/odoo#93993
The table ir_module_dependency was created manually with tracking fields,
but the CRUD was done manually, without the ORM.
Removing the fields that are always null will not have any impact
whatsoever but we should still do it to be correct.
closesodoo/odoo#89268
Related: odoo/upgrade#3455
Signed-off-by: Rémy Voet <ryv@odoo.com>
When attempting to run the Odoo server on macOS Monterey (currently
12.4), it crashes with the following traceback:
```
Traceback (most recent call last):
File "/Users/app/Code/odoo/odoo-bin", line 8, in <module>
odoo.cli.main()
File "/Users/app/Code/odoo/odoo/cli/command.py", line 61, in main
o.run(args)
File "/Users/app/Code/odoo/odoo/cli/server.py", line 179, in run
main(args)
File "/Users/app/Code/odoo/odoo/cli/server.py", line 173, in main
rc = odoo.service.server.start(preload=preload, stop=stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 1342, in start
rc = server.run(preload, stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 553, in run
self.start(stop=stop)
File "/Users/app/Code/odoo/odoo/service/server.py", line 491, in start
set_limit_memory_hard()
File "/Users/app/Code/odoo/odoo/service/server.py", line 83, in set_limit_memory_hard
resource.setrlimit(rlimit, (config['limit_memory_hard'], hard))
ValueError: current limit exceeds maximum limit
```
Actually, this issue is not specific to Odoo but affects Python on macOS
as a whole (see [1] and [2]).
As our memory management is based on Linux - which is our primary
deployment target - and non-POSIX systems were already excluded, this
commit escapes the rlimit modification on non-Linux systems to prevent
this kind of issue.
References:
[1] https://bugs.python.org/issue34602
[2] https://github.com/python/cpython/pull/14546
Related issue:
https://github.com/odoo/odoo/issues/79112closesodoo/odoo#93381
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously, when importing both the default export and named imports
with a trailing comma, we would transpile into an object where the first
keys were the named imports, including any trailing comma, and
concatenating with the default import with a leading comma, this means
that the trailing comma would transpile to two successive commas which
is not valid syntax.
This commit fixes that by putting the default import first, and adding
the named imports after, preserving the trailing comma if any, but
precluding the possibility that we get two commas back to back.
closesodoo/odoo#93693
X-original-commit: 798d2f2c6e8a496f4ce0cd3c4f1609693e692254
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Currently, when creating a new user, even if there are multiple
companies to select from, the "Multi Companies" related fields are
not visible in the form view. However once the record is saved, they
simply appear. This happens because the `companies_count` field based
on which the visibility changes, is a computed one but is not dependent
on any other field, and so while creating a new record, the value is
always zero for our compute field.
This commit improves the behavior by making the compute method
dependent on `company_id` field so that it can be triggered while
creating the record (thanks to default value being set for this field),
and thus shows / hides the company related fields properly.
taskID-2819559
Part-of: odoo/odoo#88738
Create an empty database and start 2 http workers, go on the web app
menu and install website (don't install website via -i). Once website is
installed, you are redirected on `/website/configurator` but the route
does not exist and it fails with a 500 internal server error.
The problem is due to an invalid registry manipulation introduced in the
saas-15.3's httpocalypse. When new modules are installed the registry
must be reloaded in all workers. The function that determine if the
registry must be reloaded and reloads it is `check_signaling`.
When the current registry is up-to-date, it is returned as-is by
`check_signaling`. When it is outdated, `check_signaling` creates and
returns a new fresh registry; it does not nor discard nor change
in-place the previous (outdated) registry, it is up to the callee to
discard the previous registry itself.
closesodoo/odoo#93579
X-original-commit: 23bdcc3fd31e6908ee6737cb74787aefa5d057a5
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
The methods to generate the attributes are called all the time in order
to reset the attribute dictionary. The profiler is modified so as not to
display directives in the log that do not exist on the tag.
Issue: attributes could be generated by directives and not be used (for
example on <t>). These attributes could end up unwittingly on the next
node.
closesodoo/odoo#93216
Issue: opw-2859447
X-original-commit: 38724f106c0747aef475991c894e9ee93c1db967
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Christophe Matthieu (chm) <chm@odoo.com>
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the html is grouping some records together, there is no exactly one document per record.
In that case, the wkhtmltopdf outlines must not be checked.
closesodoo/odoo#93516
X-original-commit: c1faefce79bae6ff6014e7af7f675e98f5091a07
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
When generating a PDF report with an action having 'attachment_use' set and when the pdf of at least one record has been already generated but not all, an error is raised for no reason.
X-original-commit: 7ad19283ea5c89a6629c8433b468d1dac3fdad4d
Part-of: odoo/odoo#93516
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Even though the release process changed a bit, it seems that only the
MINOR version number should be incremented in the master branch until
the next major release.
This avoid confusion when writing upgrade scripts, it should work in any
case and it leaves more room from process improvement.
closesodoo/odoo#93123
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In libmagic implementation, space before an SVG make it detected as SVG.
In odoo implementation, for the same case we don't detect it as SVG.
But in the test `test_guess_mimetype.test_mimetype_svg` we only check
odoo implementation behavior, so the test fail if module python-magic is
installed.
With this fix, the test is only run when python-magic is not installed.
opw-2746934
closesodoo/odoo#93056
X-original-commit: 8e38bfb38a3c1c3888d4f4efa1a13fa4cf6246bb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If you send an email from CRM and the address you are trying to send the
email to is not linked to a partner, a new partner will be created and
it will use the default_ fields in the context which may not be valid
for the partner
Steps to reproduce:
1. Install CRM and open the app
2. Trigger the list view of the pipeline
3. Select any opportunity with the email 'ErikNFrench@armyspy.com' and
click on 'EMAIL' in the top left
4. Give a subject to the email and select the template 'Welcome Demo'
5. Send the email
6. An error is thrown
Solution:
In res.partner's `default_get`, remove the `default_type` from
the default values retreived from the context if it's not a valid type
of res.partner
Problem:
Trying to create a partner with default_type in the context will try to
give this type to the partner but 'opportunity' is not a valid partner
type
opw-2827177
closesodoo/odoo#93025
X-original-commit: 2b023500d1cc2322adbc51dffda4342aba5032ef
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- Refactor the bank reconciliation widget to use more standards views and have a side-by-side kanban/widget views instead.
- Make sure the bank reconciliation widget is doing the same thing as the "reconcile" method on account.bank.statement.line. Then, what you see on the view is exactly what you get on the corresponding journal entry.
- Since the "reconcile" method is gone, clean the matching rules since it's now called only for one statement line at a time. Also, move the auto_validate feature into a CRON to avoid performance issues when opening the widget.
closesodoo/odoo#91448
Task: 2555114
Related: odoo/enterprise#27360
Related: odoo/upgrade#3555
Signed-off-by: William André (wan) <wan@odoo.com>
The `t-cache` directive allows you to keep the rendered result
of a template part. The supplied key must be a tuple. This tuple
can contain recordset in this case the zone will be invalidated
each time the write_date of these records changes.
The `t-nocache` directive makes it possible to force rendering
of a part even if it is in a `t-cache`. The values available in
the `t-nocache` are the one provided when calling the template
(and therefore ignores any t-set that could have been done).
Part-of: odoo/odoo#88276
Issue: The `web.tour` always uses the same date for record creation
or write date. This can add indeterminism regarding the order of
some records. It also prevents to make a comparison with the
write_date or the create_date.
Part-of: odoo/odoo#88276
Before this commit, two lazy values could not always be compared. Indeed,
the comparison did indeed use the value for the self, but not the other.
A normally true comparison was returned as false. Inverting the values
causes the code to pass through the lazy functions of the objects. For
example, if we go through `__lt__` the fact of having reversed the
values means that we will necessarily go through the `__gt__` of the
other.
Part-of: odoo/odoo#88276
Purpose:
- Move PoS settings in general settings to be consistent with the rest
of Odoo (PoS being the only app where settings are split in two locations)
- Clean settings by enabling obvious settings or dropping unnecessary ones.
closesodoo/odoo#84719
Task-id: 2753430
Related: odoo/upgrade#3260
Related: odoo/enterprise#24425
Signed-off-by: Masereel Pierre <pim@odoo.com>
Before this committ:
- Stats buttons were hidden when records are zero
- Some wordings were insignificant
- Existing filters don't allow us to check blocked, blocking and tasks soon in overtime and some other information
- Product form fields need some changes in their order
After this commit:
- All stats button are displayed when records are zero
- Wordings fixed
- New filters added to check blocked, blocking tasks and tasks in overtime soon
- Fields were rearanged
task-2726465
closesodoo/odoo#82253
Related: odoo/enterprise#23257
Related: odoo/upgrade#3185
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Check the PY_COLORS env variable and force colored output even if the
is_a_tty is no true
TT24972
closesodoo/odoo#71685
Signed-off-by: Olivier Dony <odo@odoo.com>
When instrumenting the Chrome Browser and asking to navigate to a
location, it happens that the 10 seconds timeout is exceeded.
This happens particularly when executing qunit tests by navigating to
`/web/tests`. This route has an average loading time around 7 seconds
but when the runbot is loaded, it can exceed 10 seconds.
With this commit, the timeout is set to 15s. It would be better to split
the qunit tests by module in order to avoid the huge assets bundle
generation.
closesodoo/odoo#92699
X-original-commit: 6c0fa6b72bf5d15e8323b81cf930a01d4c0f3291
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Since [1] which tried to fix the data-oe-xpath branding on nodes in some
cases, the branding actually became potentially incorrect on siblings of
a node which is replaced multiple times. E.g.
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
<world class="c"></world>
</hello>
```
Child view 1:
```xml
<xpath position="//world[hasclass('a')]" position="replace">
<world class="new_a"></world>
</xpath>
```
Child view 2:
```xml
<xpath position="//world[hasclass('b')]" position="replace">
<world class="new_b"></world>
</xpath>
```
No problem, two distincts elements are replaced, the system understands
that the `data-oe-xpath` of the third world of the parent view should be
`/hello[1]/world[3]`.
But in this other case:
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
<world class="c"></world>
</hello>
```
Child view:
```xml
<xpath position="//world[hasclass('a')]" position="replace">
<world class="new_a"></world>
</xpath>
```
Child view of the child view:
```xml
<xpath position="//world[hasclass('new_a')]" position="replace">
<world class="another_new_a"></world>
</xpath>
```
The `data-oe-xpath` of the third world of the parent view (in the
resulting view) was wrong: `/hello[1]/world[4]` -> because the system
saw two replacements + the unreplaced second `<world>`, so the index "4"
was computed.
Now the system will understand that the double replacement in fact acts
as a single replacement.
Note: this was also the same with "cross inheriting" (if the "new_a"
`<world>` of the child view was replaced by another child view of the
parent view).
At last, another 4th case was found and worth mentioning because it is
in fact the root cause of the problem. The problem is not actually the
double replacement as mentioned above but simply the replacement of a
root level element of a child view (which is what is basically done in
the last two mentioned cases). In that case, the root level nodes added
by the first child view have already their `data-oe-xpath` branding
computed before they are potentially replaced. Indicating the location
of the replacement in that case was thus only leading to bugs. E.g.
Parent view:
```xml
<hello>
<world class="a"></world>
<world class="b"></world>
</hello>
```
Child view:
```xml
<xpath expr="//world[hasclass('a')]" position="after">
<world class="x"></world>
<world class="y"></world>
</xpath>
```
Child view of the child view:
```xml
<xpath expr="//world[hasclass('x')]" position="replace"/>
```
Before this commit, before the branding is distributed, the result is:
```xml
<hello data-oe-model="ir.ui.view" data-oe-id="1439" data-oe-field="arch">
<world class="a"/>
<?apply-inheritance-specs-node-removal world?>
<world class="y" data-oe-id="1440" data-oe-xpath="/data/xpath/world[2]" data-oe-model="ir.ui.view" data-oe-field="arch"/>
<world class="b"/>
</hello>
```
=> Hence the `data-oe-xpath` of the last `<world>` was computed to
`/hello[1]/world[3]` instead of `/hello[1]/world[2]` after branding
distribution because the ProcessingInstruction marking the node
removal location should not have been added: it could only be useful
to following siblings which are not branded, which is not possible as
the branding added on the second `<world>` of the child view
(`/data/xpath/world[2]`) was computed before any removal.
Tests are added in this commit for the 3 last mentioned cases. As
explained, the last case is actually the same of the 2nd and 3rd ones
but it was decided to keep the 3 tests as it helps to understand the
problems better and, if the code evolves, it could become different
cases (= this is 3 cases which are currently technically equivalent but
these are different functionnal use cases). A test was written for the
first case then removed as it is basically a pure copy of other existing
tests written in [2] (trying to be improved by [1]).
[1]: https://github.com/odoo/odoo/commit/f67832a3ae0d9a3b5b53129132762e6bc1aed874
[2]: https://github.com/odoo/odoo/commit/c077ef05575d9677bce284195683f96c68386788closesodoo/odoo#92589
X-original-commit: d6e0b3d570a4b27f72852eb261660ad09de12eeb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Rationnals
----------
Web servers can serve some resources (e.g. static files) right away
without any interaction with the web application. The network model of
most web servers makes them capable of handling thousands of
simultaneous requests when it comes to intensive IO operations such as
streaming data from a file. The network model of Odoo is different: it
is capable of a lot of processing power but can only serve a handful of
requests at a time, i.e. Odoo (with some help from postgres) is
optimized for CPU operations, not IO.
Some users don't configure their web server, they use a basic
configuration that relay all requests to Odoo. The result is that many
Odoo HTTP Workers can be busy streaming static files instead of
processing other requests. This can lead to a worker starvation, i.e.
all workers are busy streaming files and cannot process new requests.
X-Sendfile
----------
In this work, we add the support for the [X-Sendfile] header family,
they are multiples http headers that can be used by the web application
to communicate with the web server in order to delegate the delivery of
files stored on the file system. Odoo still receives the request but it
does no more stream the file content from within its HTTP worker,
instead it skips the response body altogether and sets the `X-Sendfile`
special header with the path of the file on the filesystem. The web
server intercepts that special header, open the file and stream it.
Using those headers, we can use the best of both the web application and
the web server. The web application is still responsible to locate the
resource and verify the access rights, the web server is still
responsible of streaming the content.
Using X-Sendfile is opt-in via the `--x-sendfile` CLI flag. We set both
`X-Sendfile` (apache) and `X-Accel-Redirect` (nginx). If you are using
apache, make sure `mod_xsendfile` is enabled. If you are using NGINX
you have to add the following location block:
location /web/filestore { # custom path, hardcoded within Odoo
# Prevent access from the outside world, i.e. makes this
# route only accessible via X-Accel. MANDATORY!!!
internal;
# Give access to the filestore using this server's
# permissions. Odoo is in charge of verifying the access
# rights.
alias /path/to/odoo/data-dir/filestore;
}
The Odoo [deployment documentation] has been updated accordingly.
[X-Sendfile]: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/
[deployment documentation]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments
Changes to the API
------------------
To benefit most from X-Sendfile, all APIs related to streaming content
over HTTP has to be adapted. They are: (1) `request._serve_static`,
(2) `ir.http._serve_fallback`, (3) `/web/content` and (4) `/web/image`.
Each used it own way to deliver content: (1) `_serve_static` was using
`send_file` (flask's send_file that as been vendored with odoo 10
years ago and not maintenained since then), (2) _serve_fallback was
handcrafting a `werkzeug.wrappers.Response`, (3) /web/content-image were
using the "binary server" `ir.http.binary_content` API.
I has been decided to remove all 3 APIs and to merge the code inside of
the new `http.Stream` object and the `ir.binary` helper model.
A Stream wraps what is going to be sent to the browser, it can be a path
to a file on the locale filesystem, a blob of raw data or an URL to an
external resource. The Stream also holds various metadata that are
mainly used for caching. The preferred way to create a Stream is via one
of its three factories so that all the metadata are set. The factories
are: `from_path`, `from_attachment` and `from_binary_field`. A stream
instance exposes a single method `get_response()` used to create the
corresponding HTTP response object out of the stream.
Inside of `ir.http` were a few methods that were not related to the http
routing and formed what was called the "binary server". All those
methods have been removed and the feature have been refactored inside of
the new `ir.binary` model. The removed methods are:
- `_xmlid_to_obj`
- `_get_record_and_check`
- `_binary_ir_attachment_redirect_content`
- `_binary_record_content`
- `_binary_set_headers`
- `binary_content`
- `_response_by_status`
- `_get_content_common`
- `_content_image`
- `_content_image_get_response`
- `_placeholder_image_get_response`
The new `ir.binary` abstract model exposes the following utilities:
**`_find_record`**
Find an attachment or a record with a binary-field out of an xmlid or
out of a pair record-model/record-id. Check the access rights and the
access token.
**`_get_stream_from`**
Create a Stream from an attachment or a record with a binary-field.
**`_get_image_stream_from`**
Same as `_get_stream_from` but adapted for images. It sets a sensible
ETag on the stream and has image resizing support.
**`_placeholder`**
Get the image placeholder blob.
Testing
-------
It is possible to test the web server configuration using the
`test_http` module. Install the module then run the unittest using the
`webserver` test-tag. By default it attempts to connect to a web-server
running on `http://localhost:80`, you can change this URL by setting the
`WEB_SERVER_URL` environment variable.
odoo-bin -i test_http --stop-after-init
WEB_SERVER_URL='http://localhost:80' odoo-bin --test-tags webserver --stop-after-init
closesodoo/odoo#88134
Task: 2801675
Related: odoo/documentation#2083
Related: odoo/enterprise#26191
Signed-off-by: Julien Castiaux <juc@odoo.com>
We introduce a new decorator/context-manager to catch some exceptions
and re-raise them as another error. This utility main's purpose is to
hide a route that a user has no access to behind a fake HTTP 404 Page
not Found error.
The utility is at `odoo.tools.misc.replace_exceptions(*exceptions, by)`.
Its usage is as follow:
@route('/some/route', auth='public')
@replace_exceptions(AccessError, AccessDenied, by=NotFound())
def some_route(self):
if not request.session.uid:
raise AccessError("Must be connected to see this route")
...
Or as a context-manager if you don't want to except an entire function:
@route('/some/route', auth='public')
def some_route(self):
with replace_exceptions(AccessError, AccessDenied, by=NotFound()):
if not request.session.uid:
raise AccessError("Must be connected to see this route")
...
Task: 2800772
Close: #90433
Part-of: odoo/odoo#88134
Prepare an informative and nice-looking preview from the main content of the
email body, avoiding buttons/images alt etc.
Links, images, tables are removed.
Whitespace is added after the preview to avoid including the full message in
the preview (with markup).
Tags and attributes are also added to increase compliance with HTML5 standard,
including accessibility.
One additional SQL request is required to fetch the preview sub-template.
Task-2413355
closesodoo/odoo#86266
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Ensure that the value of binary_field_real_user is a record before using
it.
closesodoo/odoo#92441
X-original-commit: 4ccf918c1596ac0ee104774d98d014708f03e901
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Having the parameter stacklevel=2 in warnings.warn() logs the warning
once per location that calls the method with the given warning. This is
what makes sense for warning calls to deprecated methods.
closesodoo/odoo#92411
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When retrying a test, if a deprecation warning has been emitted the
first time, it will not be re-emitted the second time, and will
therefore not be shown in logs. Use warnings.catch_warnings() to reset
the "emission counter" of the warnings.
Part-of: odoo/odoo#92411
odoo/odoo#87522 introduced the concept to automatically
inline tree, kanban and form views under one2many/many2many fields
within form views.
The goal being for the web client to make less `get_views` calls.
However, currently, automatically inlined form views
under one2many/many2many fields leads
to more triggered onchanges than before,
triggering more field computations than before,
potentially leading to performance issues
as more fields are computed than before.
Besides, they are not visible in the tree/kanban view
and their computation can therefore be considered useless.
At worst, it can even causes bugs, by triggering computation
in places they were not used / do not handle correctly,
as explained in
https://github.com/odoo/odoo/pull/87522#issuecomment-1132554918odoo/odoo#91878
This revision reverts the behavior to automatically inline
form views, while keeping the inlining of kanban/tree views.
However, by reverting this, we re-introduce a limitation
of the web client behavior regarding onchanges,
explained in odoo/odoo#91935.
This is therefore not perfect,
but at least the previous behavior is back.
In the future, work will be done to re-introduce the automatically
inlined form view, while solving both issues:
- Do not trigger more onchanges than necessary,
- Solve the limitation of the web client shown in odoo/odoo#91935closesodoo/odoo#91968
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since [1], during the call of `apply_inheritance_specs` in charge of
resolving all the xpath of inheriting views and building the whole
primary view, processing instructions were added to mark the locations
where nodes were removed. Before that commit, another system was in
place where the following node next to the removal was marked via a
meta-oe-xpath-replacing attribute.
The problem with that change is that some of those processing
instructions were actually not removed once the branding was distributed
before the view was served... indeed all processing instructions which
were in the `<head/>` or a t-ignore area were ignored instead of removed.
This was actually already the case with the old system of the attribute
"meta-oe-xpath-replacing" but it was never noticed (as either the
attribute was there but had no effect or was indirectly gone if it
landed on a `<t>` node).
After [1], a bug was reported in 15.0 with the website configurator
where the processing instruction actually made some nonsense appear on
top of the page (at least without the work being discussed at [2] which
makes it so processing instructions act as HTML comments as it should
normally be the case).
[1]: https://github.com/odoo/odoo/commit/f67832a3ae0d9a3b5b53129132762e6bc1aed874
[2]: https://github.com/odoo/odoo/pull/92213closesodoo/odoo#92316
X-original-commit: 4310d012a16f982c2336d084254b5c5617794ee2
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This provides a new API for those operations, in order to make the
distinction between the use cases more explicit. The former API was
using obscure parameter combinations to correspond to various cases.
In the summary below, `fnames` is an iterable of field names. If the
parameter is not given, it means "all fields" in the given context.
Note that method recompute() is now mostly private, as it should not be
used in business code.
# process pending computations and updates
records.env.flush_all() # all fields of all models
records.flush_model(fnames) # the fields of all records of the model
records.flush_recordset(fnames) # the fields of the given records
# process pending computations, became non-public methods
records.env._recompute_all() # all fields of all models
records._recompute_model(fnames) # the fields of all records of the model
records._recompute_recordset(fnames) # the fields of the given records
# invalidate the cache of fields
records.env.invalidate_all() # all fields of all models
records.invalidate_model(fnames) # the fields of all records of the model
records.invalidate_recordset(fnames) # the fields of the given records
Part-of: odoo/odoo#87527
Before this commit, when a view contained a ProcessingInstruction node
`<?XXX YYY?>`, if this was rendered via qweb, it was leading to very
strange results in the form of
```
<<cyfunction ProcessingInstruction at 0x7f538c4902b0>>YYY</<cyfunction ProcessingInstruction at 0x7f538c4902b0>>
```
After this commit, it will lead to "<?XXX YYY?>" being rendered which
will automatically be parsed into an HTML comment if reaching a browser:
```
<!--?XXX YYY?-->
```
Note: this will be rendered only if preserve_comments is set to true.
This was added following [1] which actually led to an issue where some
ProcessingInstruction nodes were rendered by mistake. That was fixed
with [2]. With this commit, that kind of mistake will silently fail
(which may not be good) but will lead to no harm and allows to better
debug such cases (by actually allowing rendering what was in the view).
[1]: https://github.com/odoo/odoo/commit/f67832a3ae0d9a3b5b53129132762e6bc1aed874
[2]: https://github.com/odoo/odoo/commit/de348b3f818adcf2068deb629e612c246a6a4374closesodoo/odoo#92213
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit tries to avoid a traceback when no postgresql connexion is available.
closesodoo/odoo#92195
X-original-commit: 8199daf4bcba76277fed39554863efa3f1585b20
Signed-off-by: Josse Colpaert <jco@odoo.com>
This commit adds a `genproxytoken` command to generate and set an access
token for the proxy mode in the config file.
X-original-commit: 41a7224b46b3b163789257efd4583ef2d74479ba
Part-of: odoo/odoo#92195
To reproduce
============
- make sure to have two contacts with same email (duplicate Mitchell for example)
- in 'Contacts', switch to 'list view', selected any two contacts with the checkboxes, go the the 'Action' menu and select 'Merge'
- Click on 'Skip these contacts', then click on 'Deduplicate the other contacts', then check the 'Email' checkbox and click on 'Merge with manual check'.
- click on 'Skip these contacts'
an Access Error is raised
Purpose
=======
Partner Manager doesn't have the unlink access to `partner.merge.line` model, this access wasn't given because it's often unecessary,
but here it's good example where it's needed.
Specification
=============
to solve the issue we give the unlink access to partner manager.
opw-2851507
closesodoo/odoo#92188
X-original-commit: a6754f3524401c325ae6926ed6984dc1add24f79
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Ricardo Gomes Rodrigues (rigr)