When using account.root (through account.account().root_id or
account.move.line().account_root_id) in read_group, we can have
inconsistent results because of how account.root is defined.
account_root is a view with the id field computed out of account codes,
but there can be the same account for several companies, so we can have
several same ID for different rows => this is not expected by the ORM
who expects one record by ID => in result, we get for example the values
in the pivot table of journal items be multiplied by the number of
companies if we group by "Account Root".
With this changeset, we add a small optimisation in ORM so if a group by
is ordered by a many2one, if the order of the many2one is "id" we don't
add a left join for ordering.
note: without the change, the added tests failed:
- in account, with 1000 as balance, and 2 as number of root with id=90090
- in test_read_group with a query containing a left join to o2m table
- in test_new_api with a query containing a left join to o2m table
opw-2282699
opw-2289440
opw-3288390
closesodoo/odoo#143257
X-original-commit: 674bdd1ac2cf9a4a3748b85f71ebbd01137485ce
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Scenario:
- add doc_count field in project.project view
- create new project
Issue: error and can't create new project
> File "addons/project/models/project.py",
> line 190, in _compute_attached_docs_count
> psycopg2.errors.SyntaxError: syntax error at or near ")"
> LINE 6: AND res_id IN ()
Fix: only do the query if there is non-NewID IDs
opw-3584925
closesodoo/odoo#142074
X-original-commit: 4d9a5cedef9459f0e86f16631170f2dc965d0a3b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- go to a model in technical
- create a new field and set "Related Field" to id
=> error "Unknown field name 'id' in related field 'id'" because we
get the field in self.model which is not present in the form view.
Fix:
Fallback to self.model_id.model as was the case before 16.0 commit:
76f699ca0b
Note: without the change, the added tests fails with:
Warning Unknown field name 'id' in related field 'id'
AssertionError: False != 'integer
opw-3138440
closes#112495closesodoo/odoo#140583
X-original-commit: aa406352541abd8bbf188da84fc4e370029ffc12
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
From an internal feedback, someone reported that the code added:
e2ec9e6c86949f5781d03a7dbb1065ef8af3196a
might cause an issue in case of several sale order linked to the same
invoice line.
With this changeset, in this case we will have the same behavior as
before, eg:
- one sale order line (SOL1) has amount_total 700
- one sale order line (SOL2) has amount_total 1400
if the invoice line linked to both line has price_total:
* 700 => amount_to_invoice of: SOL1 will be 0, SOL2 will be 700
* 1400 => amount_to_invoice of: SOL1 will be -700, SOL2 will be 0
* 2100 => amount_to_invoice of: SOL1 will be -1400, SOL2 will be -700
opw-3437237
closesodoo/odoo#133498
X-original-commit: 15a90c9f6cbf5a1750fafee994fda4b6ec2ebc14
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- edit the current document layout and use is_html_empty method in it
- it works in Preview Document, when printing any report, ...
=> it breaks when opening document layout wizard by clicking on
"Configure Document Layout"
Reason: is_html_empty was added to _get_rendering_context, but the
preview instead the document layout wizard doesn't use this method.
Fix: add is_html_empty in the context
opw-3433583
closesodoo/odoo#133122
X-original-commit: 5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- edit a mass mailing while in debug mode
- switch to codeview
- do a change
- click on save
Issue:
The body_arch is updated (making it seems like our change are taken into
account), but the body_html is not and the outdated version will be sent.
Solution:
With this change, when we commit the changes and have the codeview
opened, we will first update the wysiwyg editable to the current
codeview value, before updating body_html.
related to opw-3103549
closesodoo/odoo#132129
X-original-commit: 576bee4b7e426f45c7bf418b9762a46407f66549
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before 16.0, optional columns used local_storage service that used
JSON.stringify and JSON.parse to store values and so the object were
directly usable.
Since 16.0, we are using the localStorage API directly, so when checking
if a optional field is enabled, we just check for example:
_.contains('currency_id,partner_id', 'id')
which returns true but shouldn't => this causes for example the ID field
to not be hideable.
note: this commit makes makeRAMLocalStorage (used for safari incognito
and tests) consistent with localStorage that stores values as string.
note: the added test without the fix, fails with:
should have 3 th, 1 for selector, 1 for columns, 1 for optional
columns ever after listview reload. Expected: 3, Result: 4.
opw-3339416
closesodoo/odoo#131309
X-original-commit: 922bd446708e05c2368a01b2399855845246885b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 9deb1e6aa902a09c4f invisible duplicate were added for boolean groups.
But the added test could fail on master when installing only base
module: in this case, there is only the group "base.group_allow_export"
that is shown as a selection group because it is the only field of its
category. When we install other module, the field become a boolean group
that is handled by the aboved mentionned commit.
The previous fix and test didn't take this case into account, with
customization this could be a real issue.
With this commit, hidden selection field are also handled and the test
test_reified_groups pass in master when installing only base.
related to #120310closesodoo/odoo#128944
X-original-commit: b22fc41d63bded2435cd330517d407abab5035ee
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Since 16.0's 0501bbd62e fields with groups are now removed from the view
instead of being set as invisible.
Scenario:
- template user has group "Access to export feature"
- create a new user while being in debug=0 mode
- save
=> the users don't have the group "Access to export feature" set,
because the corresponding field is not in the view. If the same scenario
was done in debug=1 mode, we would get the group set.
Solution: duplicate the field that are inside base.group_no_one section
and have them be invisible if someone is not in debug mode.
note: before the fix, added assert fails because there is missing groups
in the newly created user.
closesodoo/odoo#121097
Note: issue observed when working on another ticket
X-original-commit: 9deb1e6aa902a09c4fd6a91ecbd34a89b9c98f98
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- set a quotation template on a quotation that adds lines ordered with
a sequence (eg. 3 lines with sequences 10, 11, 12)
- add lines in this quotation
- save
Issue:
The added lines have sequence 10 and the seen order changes.
This is caused by 6f11060d6afd9edce904dd34a2d415a2a2461108 that tries to
mitigate a more rare issue when there is more than one page of lines.
Solution:
Reverting the previous fix, and setting the sequence of the first line
to -99:
- when resequencing the first page, the sequence will be -99 to -60 =>
records from the second page will not get in the first page
- new lines will be added at the end
Issues still present:
- when resequencing the second page, item from 3 pages get into it (it
was already the case before 6f11060d6afd9edce904dd34a2d415a2a2461108)
- when adding a new line (without resequencing), it is added at the end
and not at the beginning of the next page
But those are just behavior in any list view (as is the original issue
of 6f11060d6afd9edce904dd34a2d415a2a2461108, but since it was partially
fixed for a year, this patch try to give an in-between solution instead
of just reverting it).
opw-2833913
closesodoo/odoo#120047
X-original-commit: 621454fac58e6d079ec6dc52795548c3dadea0e5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The eta.gov.eg production servers can't be connected using OpenSSL 3.0.
This is happening because of the change in:
https://github.com/openssl/openssl/commit/72d2670bd21becfa6a64bb03fa55ad82d6d0c0f3
that now by default prevent unsafe legacy renegotiation that eta.gov.eg
is using.
To prevent this issue, we add the SSL_OP_LEGACY_SERVER_CONNECT option to
ssl context of queries to the eta.gov.eg servers.
SSL_OP_LEGACY_SERVER_CONNECT is not available before python 3.12, so
the value is hardcoded in Odoo.
opw-3102485
closesodoo/odoo#108848
X-original-commit: 0ae8c55ff2db8810a990407e706c4c86b221d4c4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
It seems that there is a rather frequent warning that can be added to
mail received by outlook 365 and that has the form:
```
<table border="0" cellspacing="0" cellpadding="0" align="left" width="100%" style="width:100.0%">
...Caution: This is an external email and has a suspicious subject or content...
</table>
```
The combination of `align="left" width="100%"` means that a div after
this alert will probably have a width of 0 (because the previous content
is floating to the left, and taking 100% of width so there is 0 pixel of
width remaining).
This is not an issue in general, but in Odoo this conflicts with a code
that adds scrollbar if a message content overflows (but here since width
is 0 pixel the content is just hidden).
With this commit, if we detect the code that is used in all our received
report (width=100% and float=left), we ignore the float to prevent this
issue from happening.
An alternative is to avoid Outlook 365 adding this structure in a
message (see [1]), but this is only possible if we can change the
configuration where this structure is added (eg. we can't if it is
a customer that is forwarding a mail already broken).
[1]: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/set-up-anti-phishing-policies?view=o365-worldwide#first-contact-safety-tip
opw-2887342
opw-2925222
opw-2946587
closesodoo/odoo#102107
X-original-commit: ed7280ce8f79ff68904310ca1120cb9c5ee735ae
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The dropdown is positionned from the left, with comming from bootstrap:
- left: 0; # from CSS [OVERRIDEN]
- right: auto; # from CSS
- left: 0px; # from JS
- transform: translate3d(123px, 0px, 0px); # from JS
the 123 pixels is the offset to the left border of the parent component.
This is working in left-to-right, but in right-to-left, only the CSS
style is reversed and we get:
- right: 0; # from CSS
- left: auto; # from CSS [OVERRIDEN]
- left: 0px;
- transform: translate3d(123px, 0px, 0px);
Since the result is `right: 0; left: 0px` the size of the dropdown is
set to 100%, but this is not taken into account by Popper.computeStyle
which will have a 100% parent width Popper set at the position of the
small width Popper.
Graphical example:
```
[----------------------] # width of the page
[---] # popper in LTR
[---] # popper in RTL with fix
[-------------] # popper parent size
[-------------] # popper in RTL without fix
```
as shown, without the fix, the popper content might overflow outside of
the page, and the content aligned to the right unseen).
opw-2926863
closesodoo/odoo#99355
X-original-commit: a883d0de0336c85ebab411ec42ae0e9936b5195f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Odoo may resize attachment image with side larger than 1920 pixels.
But for animated gifs, this resizement seems to in general increase size
file which is not what we want (in some case making it grow from 3MB to
60 MB).
So with this change, we only resize and optimize images that are not
gifs.
Reasoning: pillow doesn't seem to resize GIF (and seems to only increase
their size, especially animated GIF, because each frame is not
optimized) so we should just not touch them.
Note:
- currently tiff were not resized (because of a mimetype typo)
- currently image dimensions were not resized (from our test, resizing
on the dimension does not change the size much, quality is most
important).
both of these issue have been solved in this commit.
opw-2897291
closesodoo/odoo#97083
X-original-commit: 6d903d61adba11c9e46009511fd4065dbc8a9e0c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 7dd5437a65 the usage of imagelib was changed to match the one of
general fetchmail so the flag sent to IMAP server was (\Seen) and not
\Seen which is often accepted but not always.
From recent reports, it seems that the method `uid` and `store` may have
some difference (base on using message-id rather than UID) so this
commit is reverting 7dd5437a65 and using the parenthesis around the flag
explicitely.
opw-2853609
closesodoo/odoo#93158
X-original-commit: 550f9e77625a7917bffd693f18aafe10a04276c9
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
Currently, the timezone offset is taken from the date with reverse
timezone offset applied.
So if there is a change of timezone offset between the wrong date and
the local date, we apply the wrong timezone.
Example:
- be in "Australia/Sydney" timezone
- select date in datetime field 2021-04-03 16:12:34 (at UTC+11)
- save => time becomes 17:12:34
- change time to 17:12:35 and save => time becomes 18:12:35
- change time to 18:12:36 and save => time becomes 19:12:36
- ...
- this issue is happening until 01:59:59 of the following day
Fix:
When we are selecting "2021-04-03 16:01:23" we will get the timezone
offset from the date "Sun Apr 04 2021 02:01:23 GMT+1000" (at UTC+10)
but the DST change was at "2021-04-04 03:00:00 (UTC+11)" with time
becoming "2021-04-04 02:00:00 (UTC+10)".
With this changeset, we are getting the timezone from the local time,
not from local time with reverse timezone offset applied.
opw-2735369
closesodoo/odoo#89619
X-original-commit: 84eb850af614887f7040bffa71cbb7fd239ba857
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
For an imap "PEC server" we will fetch mail and set \Seen flag according to
current value.
But the way imaplib was used seem to possibly cause an issue on some
particular mail providers.
Mailing RFC* gives example of adding flags with parenthesis around flag:
eg. "A003 STORE 2:4 +FLAGS (\Deleted)"
but we are sending these command wihtout parenthesis (which seems to be
working, but apparently not for some providers).
To fix this issue, we change how we use the API to do the same thing
than in fetchmail module that is a lot more battle tested (and from logs
is sending flags in parenthesis).
* https://datatracker.ietf.org/doc/html/rfc3501#section-6.4.6
fixing #89305
fixing #81443
opw-2714596
closesodoo/odoo#89379
X-original-commit: 7dd5437a65bd43a91d6ae7e2fb4f11f2f0b1476b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce:
- Set a new DB without demo data
- Install Ecommerce
- Switch language to Arabic
- Try to open website module
Issue:
Traceback raised.
Cause:
When generating random sample data for website dashboard, it will use
the current local to generate dates (in the given format), who in this
case have a non-latin numbering system, and therefore will break when
trying to parse field value.
Solution:
Use `serializeDate` or `serializeDateTime` to format datetime (with
`latn` as `numberingSystem`).
opw-2743243
closesodoo/odoo#88840
X-original-commit: 5597912ad65e0b98c498f95ba884b9581a737211
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Nasreddin Boulif (bon)<bon@odoo.com>
issues:
- search sale.report with `('order_id', '!=', False)` in list view =>
you might get lines without sale order, with the wrong product, ...
- group sale.report by product on list view => you might get lines with
a different product than the group
cause:
the sale.report IDs are an union of sale_order_line.id and
pos_order_line.id => so there can be 2 lines of sale.report with same
IDs but pointing two completely different record.
rejected solution:
using row_number() over() for ID after the UNION ALL => rejected since
there was a `row_number` on sale.report at one point that was removed
because of performance issue (03bd6f5243e189cd05b3fc7ad774cc07ea733e14).
solution:
using negative IDs for pos_order_line lines
drawback:
in 14.0, we already use negative IDs for sale_order without lines =>
the probability of conflict is lower for this case and sale.order.line
not being in conflict is better.
opw-2586062
opw-2694529
closesodoo/odoo#83621
X-original-commit: cdaf046637704b53047b79984669ed2044cd8da6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 2e3075693b06d71222b446bd8a805dacb639d0e4 we used a head request to
determine type of page before trying to get a title out of it.
But requests.head does not allow redirect by default:
https://docs.python-requests.org/en/v2.9.1/user/quickstart/#redirection-and-history
so if an URL was a redirect, we would not longer get the page title.
opw-2457640
closesodoo/odoo#84832
X-original-commit: 63346cf4b77f760121f88762ab2911c37603b548
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The tool to change background color in mass mailing will currently
set the CSS property as !important.
On outlook software (or windows mail app) this seems to fail:
- !important on inline CSS should not be used
In this fix we remove !important when inlining CSS.
opw-2641343
note: this forward-port is only taking half of 14.0 d7e5101603 since the
issue of targetting DIV elements does not apply here (the <div/> with
the background color are transformed in table in convert_inline.js).
closesodoo/odoo#82924
X-original-commit: fb675251ce8b13d36dfac7a50e9b1cea4759cc02
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 72cd8d076 there was an improvement for removing infinite loop in POP
mail server, but if there was no message to fetch, you can get an error:
UnboundLocalError: local variable 'num' referenced before assignment
because `num` is not set when logging stats of fetching mails.
`num` should be set to 0 by default, we don't want to have it unset or
use a value from a previous loop.
opw-2724216
closesodoo/odoo#82582
X-original-commit: 7b3b623cf3359ac1eea537177f7f963e81403a01
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Reproduction:
- have 308 redirection from /shop to /boutique and refresh routes
- go in incognito on /boutique?order=name+asc (don't go on
/boutique first, or restart odoo to clear ORM cache)
- select a sorting option eg. price
=> we are redirected to /boutique?order=name+asc?order=list_price+asc
and this error is shown:
Invalid "order" specified (is_published desc, name asc?order=list_price
asc, id desc).
This is happening because url_rewrite is keeping current query string
(see ir.http()._slug_matching) and caching it. So if the first call
caches:
url_rewrite('/boutique') => /boutique?order=name+asc
all other url_rewrite('/boutique') calls will give you
/boutique?order=name+asc even if the query string has changed.
In addition to that, url_for may append query_string to url_rewrite
return value, so you may get a double query_string such as:
?order=name+asc?order=list_price+asc
which causes the error.
In this fix, we restore the removal of query string that was removed in
3beb4545c4.
opw-2702036
X-original-commit: 5dcf6e91fed769f4ab22ac63d3e5078cdd352e86
Part-of: odoo/odoo#82099
The translation of purchase.order().notes name (Terms and Conditions) is
wrongly done in bulgarian since 2016
(d14efd562b).
opw-2719178
closesodoo/odoo#82005
X-original-commit: b0be51f8b2fc1c9422aa543d03a321936bb8f667
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When adding a google font, the website test if it is valid with an URL
like:
https://fonts.googleapis.com/css?family=Open+Sans+Condensed
but this is only testing the normal with weight 400 version which might
not be available (for "open sans condensed" only 300 and 700 weight is
available).
Instead with this fix we try:
https://fonts.googleapis.com/css?family=Open+Sans+Condensed:300,300i,400,400i,700,700i
which is what is being queried when the font is really used and will
only fail if all types are missing (in which case it is a good thing
that it fails).
opw-2678485
closesodoo/odoo#80564
X-original-commit: 126ccaecb876c17dd6b7e34aef4aa4927d13b8f7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If there was parameters in the from clause, there was a possible error
when reading progress bar for activities.
eg. grouping product.product by "Routes" raise an error because we have
in FORM clause like:
FROM … ON … AND "product_template__route_ids"."route_id" IN
(SELECT … WHERE … OR ("stock_location_route"."company_id" in %s))
so when we add timezone to parameters, it should be after FROM clause
parameters and before WHERE clause parameters.
opw-2674179
closesodoo/odoo#78867
X-original-commit: 904d0aab204b0ce40d7bc284086c33cbde6f06d8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In activity view, the deadline date that has no timezone is formatted
from UTC to local timezone, so if the timezone is negative, we display
by error the previous day (eg. 24 october instead of 25 october).
With this commmit, we interpret the date in local timezone so there is
no timezone issue.
note: no test added since this only happen on browser with negative
timezone which would be hard to test.
note: this was fixed similarily in 13.0 with 0735547086 but must have
been lost in a refactoring.
opw-2629681
closesodoo/odoo#78938
X-original-commit: 8935899c6fdc21ad6eff9f09af6e474652efbcd2
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
There was a missing translation for apply/cancel button in
daterangepicker widget. With this change, we provide the odoo
translation to the library when initializing the picker.
opw-2628117
closesodoo/odoo#78588
X-original-commit: 40f128baba53ce29c2d03b7370e54b5010edb9ef
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When there is a connection failure (eg. server restart) while we are
polling adyen for payment status during the payment process, we would
show a connection error and when clicking on retry, we would do a new
payment even if the first one was successful causing a double payment.
After dcb1e2b48, the retry after failure should just continue the
polling as if there was no connection failure, so for example:
- order 1: pay with adyen => connection failure during payment
- order 1: retry => payment successful
But in this particular case:
- order 1: pay with adyen => connection failure during payment
- order 1: close adyen payment line and pay with another payment method
- order 2: pay with adyen => we will receive the response from order 1
With this changeset, we only continue the polling for adyen status if we
are retrying to pay the same order.
opw-2587625
closesodoo/odoo#75640
X-original-commit: f83d1b13a96f8df559918b5905b949009d2ece88
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The compute field for fleet_vehicle().account_move_ids can be using
self.id where self might be a recordset with more than one record.
opw-2630226
closesodoo/odoo#75541
X-original-commit: c5e14bee56d2f36499088e217e86df3be0fb0fb0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Slight inconsistency, you could have a view location type not update
when the usage was changed to or from view (the hierarchy would be
shown which should not be the case).
opw-2619043
closesodoo/odoo#75338
X-original-commit: 857ab57756e19525681f0abd36e7f07144f56eed
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:
- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)
This was solved in pdf.js whith this commit:
https://github.com/mozilla/pdf.js/commit/8805614a03
And this PR is backporting that commit in 12.0 version up to master.
opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311
closes#75020closesodoo/odoo#75057
X-original-commit: d3feb26c8923cfde60894058f06dc2c2a8be05f5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If you use firefox and have set cookie to be deleted when you close
firefox, server worker are nuked which cause an error to be shown in
website_event_track:
https://bugzilla.mozilla.org/show_bug.cgi?id=1429714
With this fix, the error is handler and shown in the console instead of
as a traceback to the user.
opw-2556734
closesodoo/odoo#74890
X-original-commit: 8e81db2515dbed196433f2127591384f2e23bfaa
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Edit a website menu label with:
& < > " ` '
This is what is shown after saving:
& < > " ` '
This is happening since ea4dbcd240: characters &, <, >, ", `, and ' are
now always escaped. Before that commit, only < and > where escaped and
only when an image was inside the label.
With this change, we unescape the label when we are editing a menu.
opw-2609413
closesodoo/odoo#74558
X-original-commit: ab77054987287444c5f6141b047a63bab4b67baa
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When setting a Bill or Material to subcontracting, the "Operations" tab
is hidden. But it still effect eg. BoM Structure & Cost report.
With this changeset, we get an error when we save a subcontracting BoM
that has operations.
opw-2513637
closesodoo/odoo#74441
X-original-commit: 41c7bd1461a5346a030ab194b5f7fafa87a4c45a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 2018 geoip2 support was added to allow the new database format that
are freely available. But for these, only a subset of properties are
available.
Since Odoo 13 (August 2019), the sign module is using geoip latitude and
longitude for logging access to sign module signatures, but this was
only working for database using the first version of GeoIP databases.
In other use case there would never be any geolocalization recorded.
With this change, latitude and longitude are available in the session if
the right module/database is installed.
opw-2426323
closesodoo/odoo#73997
X-original-commit: 2be13b57749ac2c45de60717544c3061bbb29671
Signed-off-by: Christophe Simonis <chs@odoo.com>
seen when working on opw-2508263c
forward-port of #72654closesodoo/odoo#72895
X-original-commit: 38906fb5a9c65335f15fd3d09399988616fbe18f
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When setting the request_date_from and request_date_to when creating a
leave that will be used to show the range of days of the leaves, we are
using the current user timezone to determine it.
eg. in UTC+2 if the leave begins at midnight on the 6th, we will see 6
and not 5 which is the day in UTC.
When creating a leave in a mode different than employee, when it is
confirmed and a leave is created for each employee, we would use the UTC
day instead which is a little unexpected.
Without the fix, the added test fails with:
AssertionError: datetime.date(2019, 5, 5) !=
datetime.date(2019, 5, 6) : Timezone should be kept between company
and employee leave
opw-2573730
closesodoo/odoo#73633
X-original-commit: eb5c4e9b8d32a10e460ac089794bf1ceb9b7b71a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The frontend enroll message was display as a `<small/>` tag, but it
seems that lxml HTMLParser parse it wrongly, for example:
html.tostring(html.fromstring('<small data-oe-model="test"><p></p></small>'))
returns:
'<div><small data-oe-model="test"></small><p></p></div>'
So branding attributes like data-oe-model that are on small tag are not
found on root node that has become a `div` tag after parsing => this causes
a traceback error when saving a change in this part.
Fix: use small as wrapper for `<div/>` tag that is treated correctly by
HTMLParser (span is also treated correctly but div makes more sense
here).
opw-2573955
closesodoo/odoo#72315
X-original-commit: 6334c7282c19362ca8bc79dbaefe3d38c055e746
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In fb556ed09c7e the middle vertical line is removed from the timeline
widget because the display was changed to table.
We need display:block so this commit override the value (adding
"height:100%" also fixed it but not for all browser (eg. in safari)).
opw-2558670
closesodoo/odoo#72198
X-original-commit: 7971bcc3ed2c14254b089a6871d151952b4c4d62
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
On safari in saas-14.2, opening the full mail editor cause an error:
Traceback: Error: The string did not match the expected pattern.
matches@[native code]
getMatchedCSSRules
This is happening because this cause an error in safari:
document.body.matches(".custom-range::-webkit-slider-thumb");
and we get selector with :: that we should ignore because in d50c3b07f1
we use a global regex with `test` and multiple call of the regex on the
same string iterates over the string, for example:
var x = /a/g;
[x.test('a'), x.test('a'), x.test('a')]
gives [true, false, true]
opw-2489730
opw-2489515
opw-2502066
opw-2504051
opw-2518635
opw-2532695
closesodoo/odoo#71834
X-original-commit: ad0160de12d362baf56181478ee509ad223147fe
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When l10n_latam_invoice_document is installed and the current company
does not have a custom header (in stable, only Chile and Argentina with
their localization installed use custom header), printing multiple
invoice at once, one out of two had no header or footer.
This is because `<div class="header"/>` and `<div class="footer"/>`
should be unique per record being printed, and when a custom header was
not used they were duplicated with the duplicate empty.
As an example, if we had 3 documents:
- record 1 : good header
- record 1 : empty header
- record 1 : body
- record 1 : good footer
- record 1 : empty footer
- record 2 : good header
- record 2 : empty header
- record 2 : body
- record 2 : good footer
- record 2 : empty footer
- record 3 : good header
- record 3 : empty header
- record 3 : body
- record 3 : good footer
- record 3 : empty footer
When we give them to wkhtmltopdf, it would be mismatched:
- headers:
- record 1 : good header
- record 1 : empty header
- record 2 : good header
- bodies:
- record 1 : body
- record 2 : body
- record 3 : body
- footers:
- record 1 : good footer
- record 1 : empty footer
- record 2 : good footer
so record 2 will have empty header/footer, and record 3 will get those
of record 2.
opw-2507137
note: the master forward-port also remove t-if that are no longer
necessary since the same t-if is on an ancestor tag now.
closesodoo/odoo#69718
X-original-commit: 90bdb5c7b7aa6a9b98e9acb1774d449ae65a3918
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
From 631019b86 /members route never fills free_partner_ids which is used
to determine pagination and filling contact on map up to maximum number
of contacts (currently 2000).
With this changeset, we fix them so the pagination should be shown if it
is necessary to display free membership partners.
opw-2513748
closesodoo/odoo#71512
X-original-commit: 107004eff7f5ebaffac27679a8d6d4f638af78af
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If you set the type (cost_subtype_id) of a new contract
(fleet.vehicle.log.contract) before setting vehicle_id you got an error:
name = record.cost_subtype_id.name + ' ' + name
TypeError: can only concatenate str (not "bool") to str
because vehicle name was False.
opw-2527268
closesodoo/odoo#70973
X-original-commit: 7d956af5106b9efe22b602af007088ce8c2c16ce
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The optimization 2ccf0bd0dc does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.
Added test without the fix fails with:
AssertionError: False is not true : MailTrace: email
test.record.02@test.example.com (recipient res.partner(), state:
sent, record: mailing.test.blacklist(166,)): found 0 records (1 expected)
opw-2536304
closesodoo/odoo#71277
X-original-commit: 965c67cb16d2a4ac10d35a01da3af311867a47e6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before 03025520b rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | -2 | -8 | -2 | -8 | -2
UP | 8 | 2 | 8 | 2 | 8
```
which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.
After 03025520b this became:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | 8 | -8 | -2
UP | -2 | -8 | -2 | 2 | 8
```
which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.
This is happening because 03025520b uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).
With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | -2 | -8 | -2
UP | -2 | -8 | 8 | 2 | 8
```
opw-2451841
closesodoo/odoo#70923
X-original-commit: 23dd2ea535bea0a57dcac773a81e202135cd2ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
A product with single novariant attribute is normally not shown.
But in the configurator modal it was shown and then added in the product
description when doing exactly the same scenario (add the product) than
without the configurator.
With this changeset, we add is_single attribute and only add a no_create
variant if it is not a single value or a custom value.
opw-2494331
closesodoo/odoo#70700
X-original-commit: 9bd32f2a36eae1713753bf7a5a1aee3b5c51a97a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Make translation work for "Visitor" that was appearing in livechat
session to the visitor.
opw-2504461
closesodoo/odoo#70175
X-original-commit: 3b199007bd5a472d57f823a63b2b77841b14c7fc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Make translation works for "Website Visitor" that was appearing when a
logged-out user open a livechat session.
note: list comprehension has to be removed since translation only search
language in direct calling method closure.
opw-2504461
closesodoo/odoo#70146
X-original-commit: 7d28f32d9be1590764883f4621df04e04c4e1f12
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- add a file in mass mailing editor => an icon is added linking the file
- save
- edit => the icon is replaced by a generic icon
- save
- send mail => no icon is shown in email received
The system is using eg. `data-mimetype="pdf"` to show the icon, before
12.0 this worked but in saas-12.3 the system uses mailing.mailing
body_arch's field that is sanitizing attributes and remove it on save,
so the icon is only working in received email if you save one and only
one time after adding file inside the mass mailing.
opw-2474053 (ticket for similar issue in 14.0)
closesodoo/odoo#70057
X-original-commit: 7e14515b84d8081557517df7e9dc7d8c0d17f2be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- add a file in mass mailing editor => an generic icon (instead of lower
version where icon depended on mimetype) is added linking the file
- save and send mail => no icon is shown in email received
The system is targeting `a[href*="/web/content/"][data-mimetype]:empty`
to add real image inside instead of using background-image attribute
which is stripped in sanitized.
With this commit, data-mimetype is not removed when image processing
attributes are removed when a file is inserted.
opw-2474053
closesodoo/odoo#70022
X-original-commit: eb3772508ce518ff3f84724eebbe43fd1e040d77
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When synchronizing microsoft calendar events, if the event is permanent
Microsoft says the endDate is "0001-01-01": we save that and this causes
an error when it is being parsed in javascript since we require a date
with higher than 1000 years in require('web.field_utils').parseDate
function.
With this changeset, we do not set endDate if the type of the event is
not endDate (as shown[^1] in the documentation endDate only makes sense
for event of type endDate).
[^1]: https://docs.microsoft.com/en-us/graph/outlook-schedule-recurring-events#recurrence-ranges
opw-2479029
fixes#69481closes#69944closesodoo/odoo#70009
X-original-commit: 7aa233e63a8c82cce8336adb99418a96e061268f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
To display an aggregate in a list view, the field format method is used.
But since mrp_time_counter that extend float_time has no format method,
you would see eg. 2.07 as aggregate and 2:04 on the line which is a
little confusing.
opw-2514634
closesodoo/odoo#69795
X-original-commit: 020958f55d384e546eb61c98763d45b5db1ed206
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Same reason that cdb7a8ad7647649ad8f595454aa9dc0464117568
The tour bubble animation might cause the page to flicker since the
scrollbar might appear disappear depending on size of modal / browser.
opw-2469248
closesodoo/odoo#69652
X-original-commit: 7405d2a38728d11a5a96c115d7c0c0320dd5ac8e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In mass mailing edition, in some configuration of:
- being in a modal or not
- size of window
- zoom level
we might get an error when getting the scrolling element.
For example when editing a mass mailing, if I set my viewport to 595
pixels height and have a 90% zoom, the editor is broken.
This is because in SnippetsMenu.starts `$().getScrollingElement()`
doesn't find an element that has the height of body. In my use case body
height is 329.111 pixels, and scroll height is 328 pixels.
Testing different zoom level and viewport height, the maximum difference
I was able to get was 1.25 so this commit increase to 1.5 the maxmimum
difference.
opw-2455727
opw-2469174
closesodoo/odoo#69664
X-original-commit: c7a4cca4a082af7c6b33a70d4b19e700e4d487e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Strings in python expression in 't-att-placeholder' are not translated
automatically.
opw-2467404
closesodoo/odoo#69559
X-original-commit: 8f8d55ee4e773884ab35e11bfd0573d7997f3ad3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The /web/webclient/translations route's `lang` argument has had some
changes in the last year:
- before june 2020 (a9a756cf): very often it was set to null
- after june 2020 (a9a756cf): it was more often correctly set or had
en_US as fallback so never null
- after 31 march 2021 (8cc06617) in saas-14.3: lang is not sent to
server if it is null (which should never happen)
- after 15 april 2021 (a93a0a3): en_US fallback is removed to prevent
overriding server language if another language is better
But the fix in 31 march and 15 april are not compatible because the
route /web/webclient/translations require a lang argument.
With this changeset, lang argument is always sent to the server.
closesodoo/odoo#69487
X-original-commit: 0604dce996882fb93cd71885f7eb4d0749eb357f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Detailed Operations tab of a stock.picking was duplicated for style
purpose in 30f2ad8c4. But this caused issue eg. in studio because the
same field with very similary path was being edited.
Since having duplicate fields with same path is not very well supported,
this commit remove the duplication after a CSS fix has been done in
web_enterprise after which it is no longer required.
opw-2480311
closesodoo/odoo#69070
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The transcoder (transforming CSS rules into inline CSS for mail clients)
was not working for text-decoration property because it would transform
text-decoration values in:
{'text-decoration-thickness': 'normal', 'text-decoration': none}
And the regex that ensures we don't add duplicates check if there is:
"(^|;)\s*text-decoration"
so if there is text-decoration-thickness, text-decoration is not added.
The regexp could be changed to:
"(^|;)\s*text-decoration[^\w-]"
but we already have special case for other text-decoration-* properties.
With this change we should get text-decoration applied in:
- edit mode (was already the case)
- readonly mode (new)
- mail client (only if mail client does not override it)
As a side note: text-decoration-thickness seems to be rather new[^1] so
at one point in time there was probably no issue.
[^1]: https://developer.mozilla.org/docs/Web/CSS/text-decoration-thickness
opw-2496490
closesodoo/odoo#69078
X-original-commit: f4f1b890e15e98d9a7e72586faf73327d3f7b716
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Kamen Zhekov <kzh@odoo.com>
The custom code for project.project kanban view prevented the kanban to
works in selectionMode (eg. kanban view to select a many2one record in
mobile).
opw-2490912
closesodoo/odoo#68918
X-original-commit: f03a690f09b07755cf4172524cf99f7ded5e7681
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When using "Generate Missing Terms" we export all translations and
reimport them with `create_empty_translation` so they empty translation
are made available.
But since we export all modules in the same PO file, the same terms that
might have different translation in different modules would get the same
translation value after using "Generate missing terms" which is
unexpected => usually we import/export PO file by module and so a term
translation is unique for one module only.
With this changeset, we import translation module by module.
When testing speed of Generate Missing Terms with 90 modules and 37000
translations, the timing taken change like this:
- original code: 21 seconds
- exporting/importing 1 PO file per module: 45 seconds
- exporting 1 TGZ file total/importing 1 PO file per module: 23 seconds
opw-2439029
closesodoo/odoo#68801
X-original-commit: 240de08ac8f5dbd2e263a48fea859605770f82a3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Special character in reference (eg. '#' character in invoice sequence)
might cause error after payment not showing it was successful.
With this changeset, when a payment reference is used inside an url, we
quote it.
opw-2479658
closesodoo/odoo#68585
X-original-commit: 47645c2f170d5a7c09ae80d4e0de6c3a821f7b36
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Override in enterprise web_studio of _saveView on error never rejected
promises. But now it does so the XML editor interface is not blocked
after error.
But we were already showing the correct error in web_studio use case, so
we don't want another one and this change allow that by only showing an
error if we received rejection value.
opw-2460081
closesodoo/odoo#68569
X-original-commit: 43184af875f3eb52586348b383627cb0140484f5
Related: odoo/enterprise#17395
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When clicking on link in html fields, we do not wish to start quick
edition. With this change this is excluded.
closes#68023closesodoo/odoo#68212
X-original-commit: ecbdddbf0cff0964b44e7f0571d372ccbd051a72
Related: odoo/enterprise#17235
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Do not trigger quick edit when we are selection text with mouse:
- click and holding to select text
- multiple clicks selecting text
Since click on an editable field now change the edit mode, we could no
longer select the text.
With this change, quick edit is delayed by a given delay and if the edit
mode is not enabled if:
- there is a subsequent click within the delay
- there is a text selection when the click event is handled
closes#68023
X-original-commit: 2939ea4dd4736e659cc3e4df2226a3b08ac8ec48
In #67893 the image icon was removed, but it contradicts the interface
and made a feature that was working for employee less available.
Since saas-12.3, we always use the full media dialog when showing the
editor on the forum so we could not add an image with the image icon if
were not an employee.
Before saas-12.3, the original summernote image dialog was shown for
everyone but website editor that saw the full media dialog (beecause we
are using the same editor to do both things).
With this change, we always have the original dialog in the forum
message editor thanks to a new option "disableFullMediaDialog".
opw-2470720
closesodoo/odoo#68166
X-original-commit: c026c360fb77ce43f47f7645f48e37bced988b85
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Correct small typo that the module when exporting translations as CSV
file might have been the wrong module because we used variable from
previous loop.
This did not seem to cause any issue since in this given case in import
we got the module from the part before . in XML ID ({module}.{name})
that was right.
found when working on opw-2439029
closesodoo/odoo#68297
X-original-commit: 62e7b161d39e5f5f6751cf87826fa6f7b729f83d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When importing transtlation from CSV, we:
- cut at `:` character to get the model
- used a model for types other than model and model_terms
This caused error that do not happen in PO import because:
- the model is before the `,` character
- the imd_model column is constrained to 64 characters, and a name that
is not a model could be over that size.
With this changeset, the CSV import match better current PO import.
opw-2439029
closesodoo/odoo#68266
X-original-commit: cff91c6acbb7ef6a884d4dc4170574b83ff6e4cb
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
If a field is sanitized, a6e2b48 would hide the video button because
the video does not show in backend. It is better for the consistency but
if the field appear in frontend, the video would still show so we
prevent something that worked (but is very not user friendly when
editing in backend).
This changeset go back to the previous behavior (keeping the code
simplification), at one point there should be a fix so at least when
editing we see the video (currently we see an empty div in given
conditions).
opw-2463746
closesodoo/odoo#66920
X-original-commit: 73f5781
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- set new background image
- set parallax
- save
=> on next edition, the editor doesn't work on background anymore
Why:
- backgroundOptimize copy attributes of the original image to the real
target element on save
- parallax change the real target element to a new child
=> so if the original element was an editor (with data-oe-model, ...)
attributes, with the combination of the two options we will save
these editing attribute on the child element which is wrong (the
editing attributes are added dynamically and should not be saved).
With this changeset, we don't copy the editing attributes in
backgroundOptimize when we copy the original target image.
opw-2427560
opw-2429340
closesodoo/odoo#66691
X-original-commit: 6e47db5efcd78157f054144315a4812bbb6fbbd9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When switching employee on point of sale, we may have a PIN to enter.
If we enter the barcode and there is a PIN, we get an "Invalid Password"
error.
Why:
====
When we switch with a barcode 12, the barcode system will catch events
and prevent their propagation:
- {'type': 'keypress', 'key': 49}
- {'type': 'keypress', 'key': 50}
- {'type': 'keypress', 'key': 13}
For respectively '1', '2', 'Newline'.
If it match an employee, the PIN number modal is opened which will
listen to KEYUP events => it receives very shortly:
- {'type': 'KEYUP', 'key': 13}
which is the newline character which follows the KEYPRESS.
With a "Return" key received, the PIN modale closes with empty value
and an error "Invalid Password" is shown.
Solution:
=========
Ignore the newline character if no number has been selected.
opw-2448585
closesodoo/odoo#66466
X-original-commit: d056feb4ac885acc6c829c57531b985027d94daf
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Joseph Caburnay <jcb@odoo.com>
Scenario:
- go to /slides and start editing the page
- change the position of background banner
- save
=> traceback
Why:
The code for pan tool duplicates the target element in an overlay. In
the given use case, it means a node with .o_editable class is created
that will cause an error when saving because the code expect the cloned
element to be an editor (in `RTEWidget.save()`) but it is not (and is
eg. missing `.data('options')`).
opw-2427560
closesodoo/odoo#66643
X-original-commit: 96c22e816981d72c185520750167c514c6bded5b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- start editing background position
- press TAB key
- press CTRL + Z
=> traceback
Why:
Restoring a snapshot with CTRL Z can send a click event with target not
wrapped in a jQuery object which was not expected by the code.
reported in https://github.com/odoo/odoo/pull/66462#issuecomment-782025417
opw-2423445
closesodoo/odoo#66564
X-original-commit: 2c0aa825ee54ed674ff9f43722031df8e2f35ca6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- start cropping of an image
- press TAB key
- do CTRL + Z
=> now the image cropping tool are inside the page and there is no way
to remove them.
Why:
The image crop tool was added inside the editable elemnt, so if we did
an action that changed history the cropping tools are saved in the
snapshot and going back to it will add them without any code handling
their removal.
opw-2394877
opw-2423445
closesodoo/odoo#66499
X-original-commit: ce93cbd78e282e6957aaeba6f06945f94bfffb26
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Enter keypress browser event were removed in 3c372d1da8.
It was reintroduced in text fields with d2f024d254 and in source mode
of html field with b10ca1f6094b.
When doing ENTER in the editor, we do our special case of ENTER (eg. it
will split the container in two and have other custom behavior) but when
doing SHIFT+ENTER we let the browser handle it and add a normal newline.
With the "Enter" prevention, SHIFT+ENTER did not work.
opw-2463746
closesodoo/odoo#66455
X-original-commit: 27b84138b422f0dbb3e01c83bb817d0880e3eab3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
With this change, we show the variant price when printing ZPL
product.product report and not the template as we did before.
This way it is the same as what we see in Odoo as well as when printing
PDF label of the product.
targetting only 14.0 for now (but could be backported in stock_zebra)
opw-2455291
closesodoo/odoo#66415
X-original-commit: 7822b5bc76b2cbc1534b8df8d0bb3b5a3b50db0e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The mail signature of an user did not inline the CSS like the body of a
message, so for example icons seemed to work but would not be seen
(unless the mail reader had the same font-awesome system).
With this change we inline the signature too.
On edition there was also an issue since the original icon was saved as
data-class which was stripped: so eg. when editing a mail.message with
working icon, the icons would disappear.
opw-2453912
closesodoo/odoo#66372
X-original-commit: 5e093b7a37984c8cc5aa73d1c0f7aa9c9345e6b1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When we edit a view with ace in eg. studio, if it works the saved button
would never be enabled again because of missing callback.
Match the behavior of dom.addButtonLoadingEffect other usage (80592abd).
opw-2457046
closesodoo/odoo#66301
X-original-commit: 5324f7a6aa757ff6a728258ea1877ded4a6f86cd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In a4d170ad9 there were some improvment to not show event totally empty
on the day calendar view because of different style (font + padding).
The lower part of the text was still a little cut, this commit try to
improve this for week and day view mode by removing 5 additional pixels.
opw-2422700
note:
Also fix the fc-short for fullcalendar Odoo, we had this 2019 change:
fullcalendar/fullcalendar@e879c43
that made it not working without title (odoo use case), in 2020 it was
reverted when refactoring for 5.0:
fullcalendar/fullcalendar@7c7ce1eclosesodoo/odoo#66109
X-original-commit: b856d312be19b0fdf636600a76c4d9b427eedb7c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The company is used to compute currency of:
- discount_fixed_amount
- discount_max_amount
- rule_minimum_amount
If currently we don't set a company, we have an error when using the
company.
opw-2458950
note: forward-port in master set the company field as required setting
it as required in the view.
closesodoo/odoo#66231
X-original-commit: d260dddcdeddecd2bc0649d948f5e0cc30607e09
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In some location, a long unbreakable word would cause following columns
to be hidden (depending on size of unbreakable word, font, font size,
...). For example, this happened in the cart summary on payment page.
With this changeset, if not possible otherwise, line break happen inside
the word.
opw-2451496
note: from 13.0 the shop product lists are inside .card so the h5
override (that is now h6) is not necessary.
note: also adds similar CSS propery for case where word-wrap doesn't
word (added in `#66194` for 12.0 up to 13.0).
closesodoo/odoo#66208
X-original-commit: 9193776417f9da3083ad5c2e1760d0dacfb6bd59
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The update of fullcalendar (ebce7719b) in 14.0 made #45881 not working
(they both happened in same month).
opw-2214445
closesodoo/odoo#65503
X-original-commit: 3ad005a49e44ce35800edcb8a178fc3544d99633
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Depdending on situation several fixes (f885202, fc8e446) leads to issue
in small screen size:
- in iframe editor with without snippets => the width of the content is
decreased of several times the sidebar that is not shown
- in editor with sidebar => the content gets behind the sidebar
With this changeset we remove part of the above commits which seem to
fix both issue.
note: this also fixes that the mass mailing content applied CSS should
not depend on screen size, or what is send would differ dependin on
which screen size clicked on SAVE (on last inlining of CSS).
opw-2426400
closesodoo/odoo#66104
X-original-commit: 3e41618240036f1f47bb25b993c46b4d268031d5
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In ff81fa479 there was some refactoring for change of structure on
frontend, but for the iframe editor (eg. mass mailing), this caused that
the top edition bar was over the content.
opw-2426400
closesodoo/odoo#66099
X-original-commit: d4a2e6cda246b498f604ac5765a5ef5d0041a577
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Scenario:
- create mass mailing with icons and without title
- save and get error "The followign fields are invalid: Subject"
- fill subject and save
- edit
=> the icons have disappeared
This is because mass mailing widget is using:
- a "body_html" field that contains inlined html
- a wysiwyg editor to edit field "body_arch"
- a textarea containing "body_arch" value to be saved
When we save this happens:
1. we save the current value of wysiwyg into textarea
2. wysiwyg content is inlined (eg. transforming font in image)
3. inlined wysiwyg content is set to "body_html" field
4. if there:
- is no error while saving => body_html and body_arch are saved and
will be used on next edition
- if there is an error the fields are not saved, and we now have an
inlined content on wysiwyg, so next time we save the "body_arch" is
going to be inlined:
=> this for example breaking the icons on edition
Issue discovered when fixing opw-2447756
closes#65208closesodoo/odoo#65221
X-original-commit: 0f5f53837bc403960e307ab85e9fe68423c23f5f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.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>
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>
Let's assume the following situation: in a form view, there is a
one2many field A displayed as a list (non editable). In the list,
there is another one2many field B displayed with no widget (it
basically displays "X records"). In A's form view, B is also
displayed, but this time as a list.
There is an onchange on the main form view that adds a line in A,
(and simply sets B to [[5]], i.e. 'No record').
Before this commit, if the user opened the newly added sub record in
A, and clicked on 'Add a line' of B, it crashed.
The cause of the crash was that the wrong viewType was used to
create the new (default) record in B: it used the original
viewType, which was undefined (B is displayed with no widget in
A's list). With this commit, we use the viewType of B that is used
to edit it, in this case 'list'.
In the slighlty different scenario where B is displayed with
widget many2many_tags in A's list, there were no crash, but wrong
fieldNames were sent to the 'default_get' RPC. As a consequence,
default values for fields in B's list were potentially not loaded.
opw-2422806
closes#64793closesodoo/odoo#65186
X-original-commit: 4212f84da83257419d6d98038220ce1dc322fb04
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
When you create a new record, you will have in this order:
- default_get
- onchange (can trigger a warning)
- _pushController => close all dialogs since ea2207afea
This is an issue since the possible warning is directly hidden to the
user.
Without the change, the added test failed with:
Warning modal should be opened
"executing a window action with onchange warning do not hide it":
Found 0 elements to click on, instead of 1
opw-2342273
opw-2374051
closes#61732closesodoo/odoo#63415
X-original-commit: ff61ab121e3fb3c0c9b269c0dc9a65b3f1c8e664
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In the change 6ba81c99 there was an issue with timezone with Google
because we were now sending "20201217T123000+0000" instead of
"20201217T123124Z".
When google received formatted date ending in Z it would treat it as
UTC, but with +0000 ending he treats it as a locale time thus get it
wrong if locale timezone is different than UTC.
opw-2370895
closes#62943closesodoo/odoo#62970
X-original-commit: b68ca9fb1d3f8c0a6346fa1d3d6cce28f4977bbd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 376891294 the default purchase.order view tree was changed to have
different view with dashboard.
But the current view referenced:
('parent.state', 'not in', ('purchase', 'done'))
which seems incorrect because an x2many view towards purchase.order
could currently only be used for purchase.requisition (doesn't have
purchase/done as state value) and stock.production.lot (doesn't have
state field) or a customization that might not have state field.
With this change, we copy what there was originally on this field.
opw-2381767
closes#62903closesodoo/odoo#62964
X-original-commit: 4628675caf37c1699d8c25fe2ff6ef8b7bbc72a0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
steps to reproduce:
- start a certification with time limit
- close it and go to it back after time limit +10 seconds is passed
=> an "There was an error during the validation of the survey." appear
that prevent to finish the survey or do it a second time until the
ongoing survey.user_input of the user is deleted.
This was done to prevent people from cheating by answering after the
time limit end. With this changeset, when we go back to the survey after
its end, we will finish it without saving the answers.
opw-2390623
closes#62752closesodoo/odoo#62770
X-original-commit: 4d088ad719b456e73b7586087084a6d0b59ff455
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Set a arbitrary 10000 limit instead of 40 for the configurator
product_no_variant_attribute_value_ids (attributes that do not create a
variant) and product_template_attribute_value_ids (attributes that
create a variant) fields.
With a limit of 40, when we edited a variant (eg. on sale order) with
more than 40 create_variant=never attributes, the widget
ProductConfiguratorFormView that work with this data would only received
40 attributes so there would be an error message:
"The combination does not exists."
which would prevent edition of the variant.
opw-2333091
closes#58493closesodoo/odoo#58670
X-original-commit: 295884ce154990ecb51d3fc7c39aeeb21dc11f03
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When clicking on the stat button "Meetings" on a contact:
- before dac91bc18 (November 2019): only meetings with participant
matching contact name are shown
- after dac91bc18 (November 2019): all meetings are shown => this was
because the view was used to create new meeting, so it makes sense to
see other meetings and not have a conflict.
- after 16206d72 (August 2020): only meeting of the contact are shown
- after 7449c8a6 and d11fb611 (November 2020): more complicated logic
that will also show partner events, and child partner events.
Since August 2020, when you create a new event, since we are showing a
list of IDs at the time the button was clicked, the new event will not
appear unless you go back to the contact, then click on "Meetings" anew.
With this changeset, we still show a list of IDs, but add an alternative
to also show the events of the current partner (that should be in the
list of IDs, but will match new events).
opw-2374021
closes#61490closesodoo/odoo#61690
X-original-commit: eb6e03908bfb6ed8bbe231da2a4422ec2e149834
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When using eg. arabic locale, the figures inside dates were replaced by
arabic figures which are not supported server side (they are almost
always sent in latin figures).
With this changeset, the we are using english locale to get date in
domains.
Without the change, added test fails with:
Numbers in domain should not use addoneForTest locale
Expected:...[date_field, >=, 2020-06-01], [date_field, <=, 2020-06-30]
Result:...[date_field, >=, 3131-17-12], [date_field, <=, 3131-17-41]
opw-2370392
closes#61354closesodoo/odoo#61443
X-original-commit: 74ea66a107cfc98cce8e52903ec21e3d752fb4fb
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
In 857c485175 currency_rate precision was changed to keep more digits
for the currency rate.
This commit reflects that in the point of sale.
Also this change fixes an update issue that could recreate sale.report
uncomplete because:
=> point_of_sale and pos_sale had different definition of
pos.order().currency_rate field
=> this caused the field to be recreated (to change from double precison
to numeric) on a given module update (pos_hr)
=> this caused the sale.report view to be dropped
=> this caused the sale.report view to be recreated before modules (that
added fields to sale.report) were fully loaded
opw-2306523
closesodoo/odoo#60110
X-original-commit: a73030b3d71d835145b01b81515a21e23187687c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
On safari with apple device in belgium timezone, this code:
```
x = new Date(2020, 2, 28, 2)
x.setDate(29)
```
returns:
> Sat Mar 28 2020 02:00:00 GMT+0100 (CET)
> Sun Mar 29 2020 01:00:00 GMT+0100 (CET)
This is not consistent with any other combination of OS and browser
tested, where this code would return eg. for chrome on macOS:
> Sat Mar 28 2020 02:00:00 GMT+0100 (Central European Standard Time)
> Sun Mar 29 2020 03:00:00 GMT+0200 (Central European Summer Time)
In most instance, this is not an issue, but for country with midnight as
Daylight Saving Time (DST) change, this is an issue, because the Tempus
Dominus calendar widget will have a duplicated day which might eg. make
a month totally not usable.
This issue can eg. be reproduced in Lebanon timezone at this address:
https://tempusdominus.github.io/bootstrap-4/Usage/
Going to the month of April 2020, an error happen because to get the
first day of the week of 1st April, we do:
```
this._viewDate.clone().startOf('M').startOf('w').startOf('d');
// .startOf('M') => Apr 01 00:00:00
// .startOf('w') => Mar 28 23:00:00 (safari bug)
// .startOf('d') => Mar 28 00:00:00
```
which gives us the wrong day (28 instead of 29) which causes an error.
Other report of the issue:
- https://www.donedone.com/timezone-specific-browser-specific-datetime-bug-2014/
- https://github.com/date-fns/date-fns : issue 571
- https://forum.mobiscroll.com/t/issue-with-invalid-dates-range-script/108
opw-2271482
closes#59786closesodoo/odoo#59908
X-original-commit: 112267d62544c56acfdcef96727c32c314c15f16
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Nicolas Lempereur