- 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>
Before this commit, the ir_model_data_module_name_uniq_index constraints avoid
to duplicate an XML ID.
Now on copy, we add a random suffix to allow the end user to update just the
record id (and rename the name).
closesodoo/odoo#92108
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As by now pretty much all of the internet runs on HTTPS & it is
recommended everywhere let's do so our in our manifest do.
closesodoo/odoo#91281
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Set order is not randomized for integers (integer hash is the integers
itself and doesnt use pythonhashseed)
but the output may be ordered or not depending of the values:
In [2]: list(set(range(126,130)))
Out[2]: [128, 129, 126, 127]
In [3]: list(set(range(130,134)))
Out[3]: [130, 131, 132, 133]
This will lead to different results in query count tests depending on
the current value of the sequence.
The proposed solution is to use an Orderedset. We need to keep in
mind that the initialisation/operation on Orderedset may be slower but
this shouldn't represent any significant overhead in this case.
closesodoo/odoo#91962
X-original-commit: da66b8fc008f97680584e266135b7fa7d3dedeca
Signed-off-by: Rémy Voet <ryv@odoo.com>
If `_get_external_ids` is called in an onchange context on a newid
wrapper, the result map uses NewId keys but the assigned data uses
real ids, which leads to a mis-setting, and usually the call blowing
up immediately as `data['res_id']` is not one of the preallocated dict
entries.
Update the code to better handle this possible difference.
closesodoo/odoo#91957
X-original-commit: 5797fd80a63309269f15bcbe4948d4429a53eec2
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Since Python 3.10, the invalid escape sequence warning use quotes to
display the invalid sequence. Because of that, the filter does not catch
it anymore.
With this commit, they are caught in all supported versions.
Part-of: odoo/odoo#91927
With this commit, the LooseVersion function comes from distutils which
is deprecated [0] in Python 3.10 is replaced by parse_version.
[0]: https://peps.python.org/pep-0632/
Part-of: odoo/odoo#91927
As of werkzeug 2.0, the `posixemulation` compatibility layer for atomic
rename operations is abandoned[1]. In the mean time an atomic,
cross-platform file renaming function was introduced in the stdlib, as of
Python 3.3: `os.replace()`.
By using `os.replace()` instead of `posixemulation.rename()`, we can
ensure compatibility with versions 0.x, 1.x and 2.x of werkzeug.
We've always required Python 3.5+ since the P3 support, so
`os.replace()` is always available.
This is a follow-up of the work for supporting werkzeug 1.x [2]
References:
[1] https://github.com/pallets/werkzeug/pull/1790
[2] vendoring of werkzeug.sessions: odoo/odoo#45931
Part-of: odoo/odoo#91927
When a subtest fails, the failure or error is taken into account and even if
the subtest was silenced the test itself logs an ERROR with the count of
failures.
With this commit, at the first try, the subtest result is not taken into
account.
closesodoo/odoo#91974
X-original-commit: 96ca5bb6d7aeb54dfb8d5453edaf04b2ea903d41
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Parent view:
```
<hello>
<world></world>
<world></world>
</hello>
```
Child view:
```
<data>
<xpath expr="/hello/world[1]" position="replace"/>
</data>
```
=> There are two <world/> in the original view, the first one is removed
by a child view.
In that case, the branding was still distributed on the <hello> element.
This is a problem as it meant that in edit mode you were able to edit
the whole content of that <hello/> element... breaking the xpath made by
the child view.
After this commit, in that case, the branding is rightfully distributed
on the remaining <world/> element (just like it would have been if the
inheriting view had added an element instead of just removing one).
This is a follow-up of the parent commit (of the same PR at [1]).
[1]: https://github.com/odoo/odoo/pull/91015
Related to opw-2811674
closesodoo/odoo#91991
X-original-commit: abd9d7a74c91f4632550a376fe566ac28e64377b
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When branding was added on items which follow an element that is removed
by an inheriting view, the branding was incorrect. Indeed, it supposed
the removed element does not exist in the original view. E.g.:
Parent view:
```
<hello>
<world></world>
<world></world>
<t t-esc="foo"/>
</hello>
```
Child view:
```
<data>
<xpath expr="/hello/world[1]" position="replace"/>
</data>
```
=> There are two <world/> in the original view, the first one is removed
by a child view. The data-oe-xpath set on the remaining <world/>
should still be /hello/world[2] and not /hello/world[1] to target the
right element in the parent view.
This of course induced edition problems where a saved area was not saved
inside the right element of the parent view or, more likely in normally
complex arch, just crashed on save. As an example, with 14.0 enterprise:
- Install website_appointment
- Go to a page with a calendar to schedule an appointment
- Enter edit mode, try to add something in the area *below* the calendar
- Save => crash
Commit [1] already fixed similar problems when an element was *replaced*
by something (especially, when replaced by an element with the same tag
name). This commit actually reviews what was done to fix both problems
(replacement and removal) at the same time. It also makes it so the xml
that `apply_inheritance_specs` produces has no "Element" part impacted
when used with "inherit_branding=True", which seems better... although
the notion of inheriting branding should probably be independant from
this function (maybe something to do in master).
[1]: https://github.com/odoo/odoo/commit/c077ef05575d9677bce284195683f96c68386788
opw-2811674
X-original-commit: 4ab569933464617444f6150793876ff4eba11690
Part-of: odoo/odoo#91991
Since PR #90855, we add extension if mimetypes doesn't match the type.
Since guess_type don't know some extension, we prefer considere all string
of less of 8 char as an extension before to fallback on the mimetypes lib.
With this commit, a filename filename.scss will be considered with an
extension .scss by our own helper instead of a fallback on .bin or .a as
returned by guess_extension of mimetype.
closesodoo/odoo#91905
X-original-commit: ca49c314970f32d051a449b0c0aa1aef30ca9a8b
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
Set `phone` and `mobile` fields on `res.partner` to unaccent=False since phone
numbers are unlikely to have any accent. This will also make it easier
to add indexes on these fields in the future.
Part of task-2832241
closesodoo/odoo#91788
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Christophe Monniez