Before this commit, py_js was unabled to evaluate expressions
containing "true" or "false" (boolean values, JS syntax), which
seems reasonnable for a python interpreter. However in Odoo, we
often use that syntax in modifiers (e.g. required="true"). For
that reason, we need to add those two keywords in the evaluation
context.
Part-of: odoo/odoo#87522
Before this commit, the makeView test helper processed the given
arch and generated the fields to pass to the View component. This
led us to do a similar work as what is done in the view service,
i.e. duplicate code, or factorize/reuse code.
An alternative is to let the View component fetch whatever it needs
(view arch, fields, search view...). This is the purpose of this
commit. That way, the code of the view service is executed (and
thus tested as well) in each test doing a "makeView".
This commit makes that change, and adapts some tests accordingly
(mainly, tests doing assertions in mockRPC, since we do a get_view
in every test).
Part-of: odoo/odoo#87522
Before this commit, in form views, a call to "getViews" was done
for each field in the div with className "oe_chatter" (i.e.
"message_ids", "message_follower_ids" and "activity_ids"). Those
calls were unnecessary since those fields are displayed with a
custom widget (the Chatter) anyway.
Part-of: odoo/odoo#87522
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
PURPOSE
When opening the event page on the website, there is a service worker in place
that pre-fetches all links in order to be able to work offline.
This commit aims to disable the page tracking for those prefetch requests to
avoid polluting the statistics with "fake" page views.
SPECS
- Add a preparation commit to introduce a "X-Disable-Tracking" header
- Put the header on all requests in the event module that prefetch content
See underlying commit for details.
Task-2476513
closesodoo/odoo#86031
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
In 2 ways:
- by ignoring prefetched pages: indeed some page were reported inaccurately
as being viewed by the user when they were only prefetched.
- by adding the page /event in the tracked page as the page is obviously
important in the event business
Technical notes:
- The prefetched pages are ignored thanks to an header X-Disable-Tracking added
on each prefetch request in the service worker.
- Adding the page /event as a tracked page has increased the number of queries
when browsing the page /event. That's why some query count have been updated in
TestOnlineEventPerformance.
Task-2476513
Part-of: odoo/odoo#86031
In this commit we add a request header X-Disable-Tracking that enables the
client to ask the server not to track a request.
This is useful for example when the client prefetches pages to be able to work
offline. In that case, the prefetched pages must not be considered as viewed
by the user. In such scenario and without such header, it is not possible to
get an accurate page tracking.
Task-2476513
Part-of: odoo/odoo#86031
Cancelling a picking with scrapped and done SM will cancel this SM too.
To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update the quantity of P: 10 in WH/Stock
4. Create a planned delivery order DO with 2 x P
5. Mark DO as todo, Check availability
6. Scrap 2 x P
7. Cancel DO
8. Open the SM of the scrapping
Error: The SM is cancelled. This is incorrect: the move was done, so
there is a quant with 2 x P in scrap location. There is now an
incoherence between quants and SMs report.
OPW-2805604
closesodoo/odoo#89987
X-original-commit: bd3324acc3ec227438d2cb25a1df1e0fca2a2789
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Bug
===
When we called assertMailNotifications in batch, with different
notification status, it might raise an error when it shouldn't.
The reason for that is we check that no mail at all are created, for
the entire batch instead of filtering on the related partner.
`assertNoMail` should only check if no mail are created for the partner
it receive in arguments.
Task-2782150
closesodoo/odoo#89965
X-original-commit: 91be8b1eb2c3592029987524942ae2864988a7d3
Related: odoo/enterprise#26718
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently all iterations share the same dictionary. We have to copy the
default dict in order to have a distinct copy for each id in the loop.
Task-2826303
closesodoo/odoo#89934
X-original-commit: ae145e0909d5f37964eace75053eadf9e8b80c36
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Stopping a threaded odoo server would spam the postgresql logs with
multiple:
<...> LOG: could not receive data from client: Connection reset by peer
Let's avoid being rude and not hang up on postgresql connections
unexpectedly.
closesodoo/odoo#89955
X-original-commit: d0da17b167edee82381b6add573742e1cf663a9c
Signed-off-by: Raphael Collet <rco@odoo.com>
When submitting an Application Form, the name / email / phone number are
not auto-populated.
Step to reproduce:
1. Install "Online Jobs" module
2. Go to /jobs on your website and apply to a job
The form should be auto-populated with the field mentionned before, it isn't.
Solution: From a previous commit [1], the fill-with behavior will replace
the default_values. However, the change was not completed. The
data-fill-with attribute was missing into the XML template.
[1]: https://github.com/odoo/enterprise/commit/fe5a2ffe30b6f5b5d1bd2e64a0e7f11267b34a96
opw-2803166
closesodoo/odoo#89941
X-original-commit: 5739569b2c2a76e3c091c23a12623e8921794834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
Because private fields would automatically add a bunch of fields to
the user's request (in order to do their own post-treatment), unlike
normal behavior `read([])` would be completed to `read(['privacy',
'user_id'])` and would fail to trigger the "select all the fields"
behavior of `BaseModel.read`.
Move the privacy management to a `_read` override instead. Also update
the code to be more linear and straightforward, without a bunch of
intermediate helper function.
This is also a small performance optimisation, although apparently
much more minor for 14 (best case of about 5%) than on 15.0 (where it
seemed to reach 30). The gain is mostly for private events being read
for non-participants: because the non-public fields get neutered
before computation (rather than after), fields are computed on a
neutered basis and thus largely do nothing. This is especially salient
with computations relying on relations (in this case
`attendee_status`), as from an empty starting point they essentially
do not do anything.
This leads to the effort (and cost) of private events being read by
non-participants to be about the same as the cost of public events,
whereas before the change there is a visible overhead. The signal is
quite noisy though.
NOTE: backported the addition of `privacy` to the public fields from
2f4a91c0ce as that is better
behavior and makes the tests more logical (and easier to forward
port probably)
OPW-2831113
closesodoo/odoo#89936
X-original-commit: b0c6f2969596fb715e0a6c62865b5c7dbc0bcc78
Related: odoo/enterprise#26699
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Previously, updating a component that was mounted out of the DOM would
rerender it and patch it. In owl 1, patched was not called when a
component was mounted outside of the document. This caused crashes when
something done in onPatched depended on something done in onMounted (as
mounted is also not called when not it the DOM, which was handled
correctly by the compatibility layer).
This commit fixes that by ignoring requests to render a component that
is not yet in the DOM as a new render will be initiated anyway when
mounting the component in the document for real.
closesodoo/odoo#89935
X-original-commit: fc6a843abe52cfee084ed476f00a12a8ba1d1669
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, when pasting multiples lines a new step per line.
So when performing an undo, only one line was removed instead of the
whole pasted text.
task-2833740
closesodoo/odoo#89932
X-original-commit: 06fb4e3e8377dedb02644779f0077e0d883df918
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when unsing the function `insert()` with data being
an empty string, the function crashed but shouldn't.
task-2833740
X-original-commit: d44302550ddc027d4891ad04bf16c364e171e5ad
Part-of: odoo/odoo#89932
These helpers are used to create the repartition lines and the taxes in
the upgrade script which upgrades the tags on the taxes.
See https://github.com/odoo/upgrade/pull/3137closesodoo/odoo#89912
X-original-commit: 8927003d0c32e81d28ece68e61c1a737bd7532d2
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
As the company is not mandatory on both the employee and the analytical account,
if neither is filled in, it causes the application to crash.
This commit ensures that the currency of the current analytical line's company
is provided when no company is set on the analytic account.
closesodoo/odoo#89957
X-original-commit: e1c3690142236887cac4a4fba4599ada22bbf0ca
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit is a follow-up to https://github.com/odoo/odoo/pull/89707
The above PR fixed most issues with the configuration but since the
default value was not set anymore for `auth_signup_uninvited` a
configuration with no website attached would make the config not
saveable (required field not set).
closesodoo/odoo#89938
X-original-commit: 5fab73f7730a10636642ba96b1fdd7a7455fe6f9
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Ensure the current editor value is set in the Odoo FieldHtml during
`commitChanges` so it can be used by the `urgentSave` when needed.
closesodoo/odoo#89916
X-original-commit: 43dfc8140760497d9f0352897d71ad49b12fd6e5
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
If applied, this commit will fix the following bug by making the
behavior of applying a down payment similar to doing it in sales app
Steps to reproduce:
1- install sales, POS
2- set customer tax t on down payment product and use the product in
POS and sales
3- Create a product p with tax t
4- add p to a new sales order so
from sales:
5-apply a down payment of a percentage per (let's say 100% for clarity)
6- the down payment is calculated correctly and the total amount to
be paid is per * (p.untaxed_price + t * p.untaxed_price)
now from POS:
5- choose SO from the list
6- apply down payment of percentage per
7- the down payment is calcualted incorrectly. the SO is double taxed.
now the amound due is
(per * (p.untaxed_price + t * p.untaxed_price)) * (1 + pos_default_tax)
Bug:
when applying a down payment the full amount is treated as the untaxed
amound and then later the POS tax is added on it.
Fix:
using the untaxed total and also using the down payment product tax
similar to what happens in sales since the 2 flows can be mixed
OPW-2790821
closesodoo/odoo#89915
X-original-commit: 7dbd8d8e6ea5149c0b8d388ebfb1d97e43d47783
Signed-off-by: Masereel Pierre <pim@odoo.com>
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#89905
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This reverts commit fe7d56dc32c71e04b54de9dbd756a48942a832f4.
The original commit created an unwanted side effect that was
being solved here https://github.com/odoo/odoo/pull/89632
But while testing the new PR, it appeared that the initial bug
was no longer there, even without the original fix.
Hence this PR.
closesodoo/odoo#89895
X-original-commit: af01dac8e35fe814b1d42a1620ff766908425b33
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre <jol@odoo.com>
Currently, if user clicks the mass mailing template (theme) and holds
the click while moving the mouse (as if performing drag and drop), a
weird white highlight appears on the preview of the template.
This commit fixes the behavior by setting appropriate background color
instead of the default one of drop-down item, when the template is
focused.
task-2812312
closesodoo/odoo#89893
X-original-commit: e49f55e6f34486f8425653323544838f1a9fbd38
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Without this, `user_has_group` does not work in a frontend context.
The frontend session info seems to have been introduced with minimal
requirements with [1].
It was later populated with more keys, each time when facing a special
need. See [2].
Somehow, the `uid` need was never faced, thus never added, thus
`user_has_group` never worked in the frontend, apparently.
The fact that this method is not working in a frontend context is
something that comes back from time to time without really going
further.
The chance is here taken to fix that once and for all.
Note that we don't want to add the `uid` key in the session frontend
context as that would not be stable friendly, some users might now
relate to that attribute not being set in the frontend context.
This fix is then patching that method to work everywhere.
[1]: https://github.com/odoo/odoo/commit/0980546f4115ff7d072371d1b57d30000d07ce2c
[2]: https://github.com/odoo/odoo/blame/da8d418ff08aa55c7378887c9a5a06a5d12b72c0/addons/website/views/website_templates.xml#L128closesodoo/odoo#89890
X-original-commit: 9aafec4ed94b9f7f2af42970dd14142ee5ca70dc
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The command `/image` used by portal users (in a forum post for example)
throws an access error. This fix removes this command for portal users
until master. In master, the command is reintroduced [here].
Indeed, before the new editor in v15, those restricted users could
insert an image as we were using an "in place" image upload dialog
from summernote resulting in simple base64 image added in the image tag.
This allowed to add image without creating an attachment.
But with the new editor, there is no such base64 image upload, and it
would be too tedious / risky to introduce one in stable.
[here]: https://github.com/odoo/odoo/pull/82612
opw-2648770
task-2811325
X-original-commit: e453d4c119a69f285d9a014babe485492bbe9c40
Part-of: odoo/odoo#89890
This PR prepares the ground for the introduction of the new environment in the discuss
app. For now, the start method adds the advanceTime function to the environment. The issue
is that the new env is not extendable. This change makes a lot of noise hence the prep PR.
task-2582313
closesodoo/odoo#89888
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
With this work we relax the http controller so that it accepts all
requests, including `Content-Type: application/json`. We also enrich
the framework with two new helper methods dedicated to serialaze json
requests and responses:
- `request.get_json_body()`, loads the json content from the request's
body and returns the corresponding python object (usually a dict).
- `request.make_json_response(data)`, dumps `data` to json and makes an
http response out of it.
closesodoo/odoo#86300
Task: 2779837
Signed-off-by: Julien Castiaux <juc@odoo.com>
To reproduce
============
- Create a company with a complete Swiss address (street, city, zip and country).
- Install the l10n_ch modules and install the Swiss plan comptable in the Settings of the Accounting app.
- Go to Accounting > Configuration > Settings > Activate the "QR codes" > Save
- Go to Accounting > Configuration > Journals > Choose the journal for the invoices > In "Advanced settings" verify that the communication type is "Based on invoice" and the communication standard is "Switzerland"
- Go to Accounting > Configuration > Journals > Select your bank journal(s) > Verify that you have set up your bank account number and the name of the bank
- Go to the Contact app > Configuration > Bank Accounts > Choose the one you use for the QR-bills > Edit > In "ISR Client Identification Number" refer a client number and make sure account type is 'IBAN' > Save.
- Verify that you have a complete address on the contact form of the customer (street, city, zip and country).
- create multiple invoices for this client
- try to print QR-bill for these invoices at once -> and assert error is raised
Purpose
=======
the `assert len(outlines_pages) == len(res_ids)` fails because the generated pdf
contains only a single invoice.
this issue is caused by the line `<script>document.body.className += " l10n_ch_qr";</script>` in `swissqr_report.xml`,
when `wkhtmltopdf` generates the pdf from html, it doesn't wait for all javascript to finish before rendering the page,
which lead to not execute the script `<script>document.body.className += " l10n_ch_qr";</script>` for some pages then the final pdf
is missing some pages.
Specification
=============
To solve the issue we removed the javascript block `<script>document.body.className += " l10n_ch_qr";</script>` from the template
and move it to python, by setting the body style when generating the html.
opw-2772396
closesodoo/odoo#89835
X-original-commit: a669b4c5f78aa18b87f5adcfc5acca3ce0a76040
Signed-off-by: abla001 <abla@odoo.com>
This merge fixes several bugs appearing when using mail plugin.
Notably
* do not crash if customer is removed while being used in plugin;
* fix a console error when not logging to the addin;
* add a missing sentence to translate;
* improve partial searches on email;
See sub commits for more details.
Task-2601837
closesodoo/odoo#89848
Forward-port-of: odoo/odoo#85101
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
When you do not have IAP credit, if the partner and the company
do not exist in the Odoo database, you have an empty section.
Now, a message tell you that you need to save the partner to
generate the company (so the section is not empty anymore).
Add the translation for this text.
Task-2601837
X-original-commit: 2951b41ba639fbe6e1bec9ef53ca300369ad5a74
Part-of: odoo/odoo#89848
Bug
===
When we log in with the addin, it will fetch the route `/mail_plugin/auth/access_token`
to know if the module is installed. Because we give no `auth_code` an
error is displayed in the console.
Task-2601837
X-original-commit: 26944c09de32512a8072e00ac73a90c633eecb6c
Part-of: odoo/odoo#89848
Bug
===
1. Open an email in Outlook, and create the contact
2. Go to Odoo and remove the partner
3. Without refreshing the browser tab, click on the "reload" icon of
the addin. A traceback will be raised on the Odoo side
Task-2601837
X-original-commit: bb2e5ce9cf149a5cfd68cf908184c823f882d97d
Part-of: odoo/odoo#89848
Disable checklist and stars when the html field attribute readonly is
true.
task-2832281
closesodoo/odoo#89845
X-original-commit: 7c87495d34713cf4ea82cfeb376097d67862eb2a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Canceled and draft entries are the same color as posted entries. They should be in a different color (grey/blue) in order to be distinguished from other invoices/bills.
Amount Due, a.k.a. amount_residual(_signed), is not 0 for draft and canceled entries. It should be 0 since they haven't been posted yet.
A few tests have to be adapted to reflect this change in spec.
Task=2801521
closesodoo/odoo#88295
X-original-commit: 498a4a52b5fbc5466d8d0652db10563ccba55032
Related: odoo/upgrade#3435
Signed-off-by: Laurent Smet <las@odoo.com>
This commit aims to fix multiple issues with the "Customer Account"
parameter in the backend config.
- Hide the parameter from general and sales settings if website is
installed.
- Properly compute the right value once website is installed, as it was
not using the website's value.
- Fix a traceback when clicking on "Default Access Rights".
TaskId-2825096
closesodoo/odoo#89806
X-original-commit: 8b162f507f881619061d61530cc03b4b4654c1fe
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Prior to this commit there was no way for a `res.config.settings` field
using a `config_parameter` and remove the `config_parameter` aspect.
After this commit, the parameter is ignored if it is falsy.
TaskId-2825096
X-original-commit: b0b62ee3e302b1a1d08d1c8a32bf297380a4f27b
Part-of: odoo/odoo#89806
Commit [1] introduced a way to use pre-configured gradient that included
a change to the util method _areCSSValuesEqual.
Commit [2] added lines of code to compare shadows but unfortunately
broke commit [1].
The changes of commit 2 left a lots of elements in the body of the
document.
Steps to reproduce:
- Install base database
- Find HTML field (e.g. Login as admin => preference => Email signature)
- Select text and click on Text Color
- Click on gradient then custom gradients
- Move the slider around
- Inspect the body element
- Lots of divs are there
[1]: https://github.com/odoo/odoo/commit/a48a30f954afcb6ff3a59c4f32b05fd0c2cfcd2b
[2]: https://github.com/odoo/odoo/commit/212d8ec10bb48e8fd7de3d3ff7660447b968c62aclosesodoo/odoo#89785
X-original-commit: 043dea4d8a46465f2faf3d6b93847dc2eabfde8c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when the selection was not in the editable at the time
of calling the LinkTool, a link was created outside the editable, which
is wrong.
Task-2696969
closesodoo/odoo#89772
X-original-commit: 78decd6a75d6abf06177747f350871fefc84fd5a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the design tab retrieved the current styles
exclusively from the `#design-element` style element. This meant that if
a template included that element to define its own styles, the defaults
were lost for the styles that it didn't define.
This reads the styles from the DOM instead so this is never an issue.
In order for the design tab to have values to read, we initialized the
`#design-tab` element with the css of the page. This was a temporary
workaround. Now that values are read via `getComputedStyle`, we don't
need it anymore.
task-2833420
closesodoo/odoo#89745
X-original-commit: e8f2f71f76f86bae84253374935fd7d14428746d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Aaron Bohy