Some tests sometimes require some more queries to be finished.
Task ID-2444908
closesodoo/odoo#65379
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add the currency symbol for the monetary tracking field to better
represent the change of a monetary field.
The currency will be fetch from the currency defined in the
monetary field or on the record's company in case there is not.
For example, if we have a record with a monetary field displaying
"$ 500". If we modify the currency and the value to have "450 €",
the message containing the tracking values will display:
"500 € -> 450 €".
We only use one field to track the currency of a monetary field.
Indeed, in the case where the currency is changed with the value
of a monetary field, only the new currency is tracked. We focus
on the fact that the more important thing is the new value.
Furthermore, when modifying a currency of a monetary field, the
user can already see the new currency before saving the changes.
This allows him to adapt the value of the field if he needs it.
(N.B. we assume that this case will happen very rarely)
Using only one field takes also into account that there are
millions of record for this model and adding a new field would
take a lot of memory.
odoo/odoo#61999odoo/upgrade#2060
task-2387268
This should be a smarter and properly reliable version of #42071: in
that, the runner requests a port, closes it, and gives the port to
Chrome. However this apparently turns out to be less reliable than
hoped for and the port we just released can immediately be picked up
by somebody else (the original PR assumed the allocation of ephemeral
ports would be random or FIFO but that may not be the case, especially
inside containers).
This uses the same technique of requesting port 0 so the OS allocates
one, but it's Chrome requesting & immediately connecting so there
should be no race condition possible, and we keep the property that as
long as ephemeral ports are available Chrome will be able to open one
without conflicts or overlaps.
This leaves the issue of *retrieving* the port chrome got. Thankfully
it turns out we use a custom user-data-dir in which case Chrome writes
the port it got to `$DATA_DIR/DevToolsActivePort`[0]. Despite the
file's name it *also* contains the path for the devtools endpoint so
we need to only read the first line (rather than be able to read and
intify the entire thing).
Wait up to 10s before giving up entirely, and wait 100ms between each
check for the file's existence: on my machine without significant load
the file appears after 80 to 150ms, waiting up to 90ms seems ok (it's
not like we're in a super hurry as tours tend to be pretty long).
Other paths explored before moc used his eyes and brain and found out
about DevToolsActivePort:
* Chrome prints ws URL on the stderr, however because we don't know
how much garbage Chrome might send there we need to send it to a
continuous sink otherwise Chrome *might* end up blocking on its
stderr because we're not reading from it. This turns out to be a bit
of a mess of processes or additional threads.
* xdo suggested we check what ports Chrome listens on using something
like netstat/ss (turns out `psutil` has support for that OOTB),
which worked great except on WSL (where it didn't work at all), and
the future-proofness was a bit questionable as Chrome might add
other servers in the future.
* fme suggested using socket activation support[1] and passing in the
port we'd opened without closing it, which would really have been
ideal, however it turns out it was removed a few months later when
chrome added pipes support[2], which was a pain to realize as chrome
doesn't exactly do any useful error reporting (so unknown options
just disappear into a void to be never seen or heard of ever).
* And while the pipes system[3] has *serious* positive attributes
(even lower initialization overhead, we could remove the websocket
dependency, also avoids wasting sockets though that's not too much
of an issue here) it would require rewriting a lot more than just
the initialization as it uses its own logical protocol
(NUL-terminated JSON). TBF most of the messaging stuff is properly
contained into just a few `_websocket` methods but still...
[0] https://bugs.chromium.org/p/chromium/issues/detail?id=624837#c4
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=624837
[2] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3#message-ab7415a7db7b94787300d987216e9ce60db47bc2
[3] https://chromium-review.googlesource.com/c/chromium/src/+/954405/3
opw-2378464
closesodoo/odoo#65195
X-original-commit: b679d97a83f1ac898ee0916e92a5b440702bdcdf
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Co-authored-by: Xavier Dollé <xdo@odoo.com>
Co-authored-by: Christophe Monniez <moc@odoo.com>
before this commit: listview buttons on row can be clicked twice due to which
action may trigerred multiple times.
after this commit: listview row button handler is debounce with 500 miliseconds
so that even if user clicks same button multiple time too quickly action is not
trigerred multiple time.
task-2391298
closesodoo/odoo#62217
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
1. Go to Project App
2. Open and edit a task
3. Click on Customer => search more
5. Click on "Filters"
6. Click on "Group by"
=> The "Filters" and "Group by" dropdown are open at same time => bug
Since odoo/odoo@e4f87710e1, we added a way
to prevent bs and owl dropdown to be open in the same time.
But when the web-editor is present, the CSS selector used to match the
opened modal ("search more" in this case) conflicts with the DOM created
by the web-editor (modals identified by the classes: .web-editor,
.note-picture-dialog, .note-link-dialog, .note-help-dialog).
To avoid this conflict, this commit uses a more restrictive CSS selector
to match only the first (active) opened modal (as web-editor doesn't
attach its modals at the root of the body).
closesodoo/odoo#65358
X-original-commit: 7cb24db622b231b89558755d9c0e7d899fc994bf
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
This commit of merge fix multiple issues in the dynamic routing.
Fix RequestUID error in 308 redirect
Support MissingError / unexisting ID in 308 redirect
Correctly rewrite url on rendering by url_for for non editor user
Related to opw-2420562
closesodoo/odoo#65349
Forward-port-of: odoo/odoo#64397
Forward-port-of: odoo/odoo#64328
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When using the windows installer in French language, the `Hôte` label
used to configure postgresql server does not display correctly.
The LangString documentation does not specify how to use the special
characters but after some tests, specifying a BOM for the nsi file seems
to be the way to go.
closesodoo/odoo#65370
X-original-commit: 3d0871d1d5895f0f04175f2633344f2f1b05a081
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Increase the distinction between a journal entry linked to a bank
statement line and another one linked to a payment by adding a smart
button linked to them.
Also improve the navigation from the Bank And Cash view to directly
open the linked bank statement line or payment.
Task id #2448618closesodoo/odoo#65316
Signed-off-by: William André (wan) <wan@odoo.com>
2021-02-01 16:58:25 +00:00
Jeremy Kersten"Romain Derie <rde@odoo.com>""Jeremy Kersten <jke@odoo.com>"
Basic tests & tests of the 3 fixes of #64328
Be sure that we have a beautiful error page and not a black/white error
Be sure that slug_matching with 308 redirect works as expected and don't
raise a RequestUID exception.
closesodoo/odoo#64889
X-original-commit: 3af11f0b6db0efb6c912b25bcd04d2cbe9a07d57
Co-authored-by: "Romain Derie <rde@odoo.com>"
Co-authored-by: "Jeremy Kersten <jke@odoo.com>"
Before this commit, a 308 on a route with a modelconverter for a model
that have a seo_name field will crash with an exception:
Cannot iterate on RequestUID
Another simplest solution was to use a with_user(SUPERUSER_ID) but in this case
it bypass the security set and display the name of the record even if not yet
published.
How to reproduce:
Create a 308 from /shop/<product> to /mag/<product>
Unpublish product 10
Try to access /shop/product-10
You have an unmanaged '500 internal error"
because slug_matching -> build -> to_url -> slug with a record with Requestuid
as env._uid.
X-original-commit: 4ac2cab96655a3c5e673b0a04be5599dba507850
Before this commit the Dynamic Products snippet was displaying a message
box instead of its content until its template and product category were
selected.
After this commit the Dynamic Products snippet is automatically
configured on drop with the first available template and the first
available product category. The message box only appears if no product
category exists yet. Also an "All Products" category was added as first
element of the list to make the snippet usable before categories are
defined.
task-2439295
closesodoo/odoo#65342
X-original-commit: db3ced474e44b5a8188f0d77521bfcaee2575060
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When a user on website sends livechat feedbacks:
- Good -> send an average smiley 😐
- Average -> send ?? instead of smiley
This is because in e4a4ffb value of good (😊) was changed from 10 to 5,
and value for average (😐) was changed from 5 to 3, but it was not
reflected in one part of the code.
opw-2447246
closesodoo/odoo#65338
X-original-commit: 45ea88e58d2a834da4c5ad8ff656481ac1f9ab5d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In backend, we may want to use tags for advanced use cases like reporting,
filtering, aggregating in spreadsheet, ... However right now we cannot
define tag categories dedicated for 'internal use only'.
Similar to eLearning, this commit introduces facility to decide whether or
not to show the tag categories on the website. It is based on website.published
mixin. is_published field will be used for taht purpose. ACLs are updated
accordingly. If the category is hidden from the website then it is used for
internal purpose only.
In order to make all the events menu together, this commit moves the
'Event Tags Categories' menu after 'Event Stages'.
COM PR odoo/odoo#63485
UPG PR odoo/upgrade#2088
Task Id-2300230
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This patch complements the previous one by ensuring that any
`cache_invalidated=True` flag inherited from the master process
(pre-fork mode) cannot trigger a cache clear.
This could occur when the first request is served, because the flag was
never clear in the master process, which never server any request.
At the end of `check_signaling()`, the local cache has either been
cleared because a (real) increment of the cache sequence was detected,
or it is considered still valid. The final state of the
`cache_invalidated` flag should reflect this, by being `False`.
closesodoo/odoo#65346
X-original-commit: 3585c2c38955ece4292da77de7173fb31a6992ba
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
During loading, the registry clears all `ormcache` data multiple
times, in order to ensure consistency with the newly loaded module
data.
Since 083c70bbb6, this was done by
calling `self.clear_caches()`, with the side-effect
of signalling to all other worker processes that the cache
*needs* to be invalidated, which is actually untrue.
If the other workers have any reason to reload their own registries,
they will also clear their own cache in the process - there is no
need to forcefully invalidate it globally.
One could think that combining the pre-fork mode with the `-d <db>`
parameter would mitigate this issue, by making all workers inherit from
a fully loaded registry, In reality it doesn't work, because they also
inherit from the `cache_invalidated=True` flag, that was never cleared
in the master process. So despite having a fully loaded registry, the
newly forked workers will signal a cache invalidation upon serving
their first request.
Further, in a multi-tenant setup with large numbers of databases,
registries may be recycled and loaded much more frequently than
new workers are starting, due to the limited registry LRU, amplifying
this effect a bit.
~~
This patch directly clears the cache LRU without going through
`clear_cache()`, avoiding setting the `cache_invalidated` flag of the
registry, and thus not signalling to other workers.
This is similar to what was being done before 083c70bbb6,
where the LRU was dropped like all other lazy properties.
X-original-commit: 87aef4e3a36d92462454f51960abf7215c5ab7f1
- Go to Point of Sale > Configuration > Settings & enable "Cash Rounding"
- Configure POS:
* Enable Invoicing
* Enable "Cash Rounding" and "Only on cash methods"
* Select 0.05 HALF-UP Rounding Method
- Start POS session
- Select a Product and change its Price to a value that should be rounded (i.e. $ 16.51)
- Select a Customer
- Proceed to Payment
- Enable Invoice
- Select Bank Payment method
- Validate
No rounding is applied as expected, but the rounding line still appears on printed Invoice.
opw-2449222
closesodoo/odoo#65345
X-original-commit: d207a0fbe63c40eb879964ae6fb6c742d276fa5e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In order to make a wow effect right after DB install we enrich the base
company based on the given email address or company website at install.
In order to achieve that goal we use the partner_autocomplete service from
IAP. It uses free credits that are offered to new clients on saas platform.
Only the fields that are not filled yet are enriched to avoid erasing user
entered data, except logo. Indeed as partner_autocomplete is probably installed
as a core app (mail -> iap -> partner_autocomplete auto install chain) it is
unlikely that people already updated their company logo.
We consider that having a call to IAP consuming a token is ok for a standard
use case, especially that
* if no iap service is configured call to IAP won't add much timing;
* on Odoo SaaS free credits are given and company is enriched;
* on custom SaaS with custom iap service, at db creation probably no
credits are given and call will simply give no results back;
We decided to call IAP asynchronously at client web load. Session combined to
a boolean field on company model allows to do this call only once per company.
Doing this allows to avoid adding yet another post init hook. It also eases
behavior tweak through inheritance.
This call is limited to admin for obvious security reasons as well as
performance reason (limiting calls to external providers). As call will be
done once per company generally admin is the first person to log into the
its newly created Odoo.
In addition to enriching companies on the fly, we also enrich companies
when creating them. It allows to have an enrich on companies existing
before using autocomplete, and have results of enrich directly at create
for companies created after installing this module.
LINKS
Task ID-2322455
PR odoo/odoo#64600
PR odoo/upgrade#2086
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
In addition to enriching companies on the fly, we also enrich companies
when creating them. It allows to have an enrich on companies existing
before using autocomplete, and have results of enrich directly at create
for companies created after installing this module.
LINKS
Task ID-2322455
PR #64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In order to make a wow effect right after DB install we enrich the base
company based on the given email address or company website at install.
In order to achieve that goal we use the partner_autocomplete service from
IAP. It uses free credits that are offered to new clients on saas platform.
Only the fields that are not filled yet are enriched to avoid erasing user
entered data, except logo. Indeed as partner_autocomplete is probably installed
as a core app (mail -> iap -> partner_autocomplete auto install chain) it is
unlikely that people already updated their company logo.
We consider that having a call to IAP consuming a token is ok for a standard
use case, especially that
* if no iap service is configured call to IAP won't add much timing;
* on Odoo SaaS free credits are given and company is enriched;
* on custom SaaS with custom iap service, at db creation probably no
credits are given and call will simply give no results back;
We decided to call IAP asynchronously at client web load. Session combined to
a boolean field on company model allows to do this call only once per company.
Doing this allows to avoid adding yet another post init hook. It also eases
behavior tweak through inheritance.
This call is limited to admin for obvious security reasons as well as
performance reason (limiting calls to external providers). As call will be
done once per company generally admin is the first person to log into the
its newly created Odoo.
LINKS
Task ID-2322455
PR odoo/odoo#64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
In this commit we move iap functions onto a small tool model. It allows to
hide some details in a sub model. It also allows to define a mock that will
be used in tests afterwards.
LINKS
Task ID-2322455
PR #64600
PR odoo/upgrade#2086
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
Steps:
- As admin, go to Settings > Users & Companies > Users
- Edit Mark Demo (demo)
- In Human Resources > Attendances, select Manual Attendance or blank
- As demo, go to My Profile
- Click the smart button showing the hours worked for the last month
- Remove all filters
Bug:
The demo user, who hasn't the rights to see the other employees
attendances, can see them.
Explanation:
Every user must have the right to read attendances in order to see their
own attendances. Not giving the users the read rights in the security
record rule prevents the record rule from being applied when reading
attendances. This makes the read access rights the only rule and allows
everyone to see the attendances of the others.
This commit also fixes the default selected employee when going to the
attendances tree view on these paths:
- User
- Employee
- User > Employee
In fact, sometime, `active_id` is the ÌD of the user and not of the
employee. This leads to incorrect results since another employee's
attendances are shown.
Finally, this commit prevents users from creating attendances from other
apps since only attendance officers and above can have access to the
creation form within the Attendances app.
opw:2440117
closesodoo/odoo#65334
X-original-commit: b3247c81200200590d669b76a58d06e6adf66d69
Signed-off-by: backspac <backspac@users.noreply.github.com>
Bug
===
Since e598e74648 the action button "Launch"
in the mailing form view was renamed. Therefor, the mass mailing tour is
broken and need to be updated.
Task 2446835
closesodoo/odoo#65300
X-original-commit: ef0f483612316fbf354bd27a4573ec3292b94328
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As Fedora 32 was the current release when Odoo 14.0 was released, this
should be the supported version.
Also, a few old libs were still in mentioned in the packaging files.
They flew under the radar because they never broke the packaging.
This is not the case anymore, those libs disappeared from the Fedora
repos.
It seems that pyparsing is not used anymore since 5a1c06a19 and thus can
be safely removed from `requirements.txt` too.
pychart is not used anymore since 3425752ea.
While at it, remove mix of tabs and spaces in package.dffedora, also add
missing packages to avoid installation at test time.
Now that I started down the slippery slope, also removed some `-dev`
packages in package.dfsrc as wheel's are available.
Finally, the rpm install script now detects the python ABI version in
order to avoid update this file at each ABI change in Fedora.
Fixes#63719closesodoo/odoo#65288
X-original-commit: a8deb1dd433e3a1690d593e83ade6af46326a26b
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
add home/door fields in children form views to allign it
with the full form view so that the user can
edit these fields from the quick child form without having
to leave and open the full form
Task-2423694
closesodoo/odoo#65201
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
with this commit we are updating sequence of onboarding tours
task-2444153
closesodoo/odoo#65244
X-original-commit: a928beccb09f4db4234356e5e4f7bdf090ecc964
Related: odoo/enterprise#16026
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Replace the hardcoded year in the footer by the year dynamicaly
fetch from the current date.
task-2431308
closesodoo/odoo#65243
X-original-commit: f4663c69df03c9219cc613164b03e5860956b837
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Fix recently added lead assignment tests, notably about query counters
and random behavior of lead merge.
SPECIFICATIONS
Split performance tests from unit tests. Performance tests should be
reproducible. Currently there are too much varying query counters.
Fix lead merge process done during assign. As duplicate leads are merged
final opportunity could not fit team domain anymore. This is a side effect
of lead deduplication. In this case this is linked to priority field that is set
to the value of the "final" opportunity, whatever the value of other leads
merged into it. We think that priority is a field that should be managed
more carefully. We choose to set it as the highest value found in leads
merged.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When merging leads final priority is currently the one of the lead considered
as the master lead. This is based on ``_sort_by_confidence_level`` who sorts
on confidence but not on priority.
We think final priority should be the highest one from merged leads. Indeed
if a top priority lead is merged into a low priority one we should not loose
the priority information. It is better to keep the final lead with an high
priority and let salesmen move it downwards.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose of this commit is to make clearer how final opportunity value are
computed or chosen when merging leads. Functionally nothing should change
with this commit.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose is to test internals of lead merge method, notably about values
of final opportunity. That way we ensure future changes will be reflected
in tests and regressions will be avoided.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Purpose is to split assign tests related to results (leads being assigned,
with deduplication, compared to team and member domains) from tests related
to performance (query counters).
Assign process is a random process: randomizing teams leads to searching,
assigning and de-duplicating leads in various order. As a lot of search
are implied during assign process query counters may vary from run to run.
"Heavy" performance test included here ranged from 6K to 6.3K queries. Either
we set high counters maximum which makes those tests less useful. Either we
avoid random if possible which is what we decided to do by setting the seed
of random in tests.
SPECIFICATIONS
For results oriented tests remove query counters. Those tests should simply
ensure results of assign process, notably that even with random choice between
team and users we always have leads assigned with right domain and counts.
For performance oriented tests using query counters set random seed to have
a reproducible scenario and have less random in query counters.
LINKS
Task ID-2446759 (lead merge priority field management)
Task ID-2446883 (query counters fix)
PR odoo/odoo#65016
Bug
===
Since 569d35bc2d a fix have been provided
to fix the vertical position of the emoji widget in mobile view.
But the fix have been done in a wrong way and we should use the Odoo CSS
class instead to detect mobile (and not a bootstrap media query).
Task 2253851
closesodoo/odoo#65070
X-original-commit: 72f7acded30cd49c210faefbec195e7b6d13dacb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We should open the cashdrawer when paying with a non cash payment
method if change should be returned to the customer.
Use case: The customer wants to pay 10€ more with his card to get 10€
in cash in return.
closesodoo/odoo#65331
Taskid: 2449312
X-original-commit: c324c024d4c5e013b2405b509e91337bd3dc4dc7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Before this commit, when the user with no access right to Timesheet App
wants to see the tasks in a project and sale_timesheet module is
installed, the user has a traceback saying remaining_hours field is not
find in the parent view of
`sale_timesheet.view_task_form2_inherit_sale_timesheet`.
This traceback is raised because the
`hr_timesheet.view_task_form2_inherited` is not used if the user has no
access right to Timesheet App and then remaining_hours field is not
defined for this user because this field is appeared in the view in
hr_timesheet module.
This commit revises the views inherited from the project.task model to
give the user without access rights in Timesheet the possibility to see
the tasks in any project he can see.
opw-2429662
closesodoo/odoo#65000
X-original-commit: d63614035c84d0c0ab564102c65541d1b2b08277
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this commit, dropzones were created around invisible elements
(e.g. the snippet popup). So we had 2 dropzones instead of one at some
locations.
After this commit, we avoid creating dropzones around elements that
must not have dropzones.
task-2312878
closesodoo/odoo#65230
X-original-commit: ad56d50e3da000cacdc70d9230cad308d03680bf
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Create a product with variants attributes that NEVER create variants.
Configure Variants to add some extra-prices to some variants.
In POS settings activate "Product Configurator" and
"Advanced Pricelists", add the public pricelist and one that applies 5% to
the product.
Open a session and select the product created (say price = 1$)
Select the attributes, the extra-price is added to the product (say the
total price now is 2$).
Change pricelist from public to 5% and the order line will show our
product = 0.95, not taking the extra-prices into account (so not 1.9,
i.e. 5% of the 2$ that were formerly displayed)
opw-2439445
closesodoo/odoo#65222
X-original-commit: 323d2937f1470a85ba9ee5e46595baef426ee3f3
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Before this commit, the only way to add an event was using a long tap.
After this commit, a short tap will be added.
So to summarize on Mobile there is two methods to add an event using the
calendar: short tap and long tap.
For month/year views when a user tap on a "Free Zone" (no event)
the view is changed in the "day view" for this clicked day.
Task ID: 1891957
closesodoo/odoo#64615
Related: odoo/enterprise#15785
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit add the support to simulate a "TAP" (touch) using coordinate.
This utils will be used in a future commit in web_enterprise to be able
to test some specific case for FullCalendar.
Task ID: 1891957
Since commit odoo/odoo@ebce7719b6
the disableQuickCreate parameter was lost during the process.
Note: there is no steps to reproduce as this feature was never used.
Related Task ID: 1891957
Office Outlook doesn't take into account the [style] attribute, and it
doesn't manage width/height in percent value.
This commit set width/heigth attribute in pixels and also always set the
width/height in style attribute (keeping them in the original unit and
setting them to auto if not present).
This is a reintroduction of 2015 commit bdf58adb46
opw-2447756
closesodoo/odoo#65218
X-original-commit: c51762a790d6fefd97e6c818bfaa9307180dd5b5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
By making this tree non-editable, clicking on the rows opens the
corresponding form, and gives access to more information and better
navigation.
closesodoo/odoo#65214
X-original-commit: 995bcf5a96fc1ae2be1ddccbf3a8eb7ba42c923c
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Currently, Chrome show a scrollbar when the placeholder is multilined.
Overflow hidden will avoid the scrollbar and we place a nowrap on the
placeholder text to avoid the multiline.
task-2416058
closesodoo/odoo#65213
X-original-commit: dfbbb18f39f5e546bb8bea34e395bdf1c1b49dab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Thibault Delavallée