Steps:
- Open project.task form view in Field Service
- Go to Timesheets page
- the 'is sales order item manually edited' field is visible in Field Service
Issue:
- The technical field is displayed to the user
Cause:
- The view modifier is not updated
Fix:
- Using column_invisible instead of invisible.
closesodoo/odoo#132933
Task: 3461563
Related: odoo/enterprise#46186
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
-Create a system parameter called "blacklisted_emails" and holding
all emails that we want to consider separated by a ,
-When an applicant is generated from an email, if the email is present
on the system_parameter, don't create a partner automatically + don't
use the blacklisted email on the field email either
-When the field email is updated on the contact, or on the applicant
and that the new value is not present in the blacklist, synchronize
both records. (as long as we are obliged to use the partner to send
the email, we need to keep it synchronized with applicant)
-Display the used email on this screen
closesodoo/odoo#126065
Task-id: 3358086
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Currently, errors occur when generating the e-invoicing for
ZATCA (Saudi Arabia). This is because currently, users create invoices without
a tax, but in Saudi Arabia, the invoice line must require at least one tax.
The validation error is present at Line [1], but due to recent changes in
Code [1], the validation is not working. As a result, the user can create an
invoice line without tax. see https://github.com/odoo/odoo/pull/130034.
This commit fixes the above issue by filtering invlocice line ids
that have display_type 'product'.
Line [1]-https://github.com/odoo/odoo/blob/d2f0a0f2c9a18a7a6cef8ca3be52324ad2a1dad6/addons/l10n_sa_edi/models/account_edi_format.py#L406
Code [1] odoo@d8d47f9#diff-78f3e1847de8ca0acf28d72a412947a549acdb08142d1dadf7646363d7972cb0R268-R280
sentry-4467808485, 4467794808
closesodoo/odoo#136568
X-original-commit: 6ee82c26483fabd7962ff4f421924c7330f9b70c
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
To reproduce
============
- create a purchase order and confirm it
- create a Bill, set its Bill date and Accounting date to different dates
to today
- save it, then choose the created PO in autocomplete field
the Accounting day will be changed to today
Problem
=======
when calling the autocomplete, some values will be updated on the record,
where `move_type` is one of them, and updating this field will trigger the
compute of accounting date.
Solution
========
if the value of `move_type` on the record is the same as the one of the update,
it should not be taken into account which will avoid uneeded recompute.
opw-3381530
closesodoo/odoo#136559
X-original-commit: 6abcac2025522e5e023d51c02f14c49044658b70
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Abdelouahab Laaroussi (abla) <abla@odoo.com>
*: website_event
Without this, the seo saving would not forward the current website in
the context. It's especially bad in this case as it's writing on views
which are not triggering the COW due to the lack of a website_id in the
context.
Step to reproduce:
- Go to /shop (if you didn't do anything, this will be bound to the
`website_sale.products` view which has no website_id set and is called
a generic view)
- Open "Optimize SEO" dialog and type something in the title
- Save
- It saved the change on the mentioned view, without duplicating it
(COW) before writing on it. The title you added is now applied to
every websites and not only the one you edited, which is against the
website holy grail rule: only the website you edit should be changed.
Technically, this is because we refactored that part of the code in Odoo
16: the website is now editable in the backend.
Note that this fix also revealed that a test for events (which has been
introduced with [1]) was relying on the bug: it tested the meta title of
a view that should (and will after this fix) have been COW'ed. This test
will now indirectly protects this bug from re-happening, although we
might want to write a dedicated test in the future as the behavior for
events might need some refactoring.
[1]: https://github.com/odoo/odoo/commit/2072a7739eb9a9ee87c8b3c7b0d43a82a7e2375f
opw-3499285
closesodoo/odoo#136550
X-original-commit: c45c0bf8fff7285a9fff33ff9bf1c24bbfb130e7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Before this commit:
-On selecting fullscreen/description for image toolbar stays.
-On selecting description for image focus in not set on input field.
After this commit:
-Now toolbar is removed when selection changes.
-Now on selecting description for image, focus is set on input field.
task-3468251
closesodoo/odoo#136466
X-original-commit: 210230f972c4468c3f472509adb25dfc87d4c2b2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
During a credit time period where the employee works zero hours,
the employee should still be able to take maternity leave.
Before this change this was only possible if you manually set the
duration of this leave for it to be non-zero, which was kind of a hack.
Now that durations are computed correctly automatically, maternity (and
paternity) leaves were added to the list of exceptions of leave types
that can be taken even if their duration is zero.
Part-of: odoo/odoo#119317
The idea of current date_{from,to} computations is as follows:
The user selects the request_date_{from,end} (and optionally
request_hour_{from,to} and these inputs are then processed into a
date_{to,from}, taking into account the type of leave, the work schedule
(resource_calendar) and time zone (since date_{to,from} are saved in UTC
while the request_dates are stored in the user's timezone.
However, in practice this computation is very messy, resulting in
date_{to,from} needing to be specified in all demo data and test cases,
even though it should be derived from the request dates. Various
superfluous or poorly named methods also exist in this flow
(eg _get_start_or_end_from_attendance which really performs a timezone
conversion, the logic of which resource calendar to use is scattered
across the whole model etc).
date_{to,from} are used many times as inputs throughout the code, with
code being present te inverse compute request_date_{from,to} from these
values. However in reality this is not possible to do consistently.
Therefore with this commit, we restore request_date_{from,to} as the
sole possible inputs, with date_{from,to} being derived from them. In
addition, the timezone and resource calendar are consolidated into their
own fields, with a single computation method computing them.
task-3081565
Part-of: odoo/odoo#119317
Removed this test because
1. What it was testing doesn't make sense, namely the behaviour of
resource leave creation when you explicitly set the resource
calendar id of the employee to a different one than the one on the
current running contract, which is an inconsistent state that
generates warning messages when you try to do so.
2. The test wasn't testing that correctly because it was only testing
whether two resource leaves were created, but not whether they were
actually created in the two different calendars, which was not the
case.
Part-of: odoo/odoo#119317
Currently when a global leave is removed or modified in such a way that
the duration of an existing leave increases, the leave is instead split
into multiple leaves with a gap in between such that it no longer
includes the period that was previously covered by the global leave.
However, this splitting is very error-prone and from a user perspective
is not even always the behaviour that is expected, especially because
editing global leaves is a very low-threshold operation during which it
is in no way indicated that existing leaves might be impacted.
Also note that this is very specific edge case, that in normal operation
should almost never occur. It is therefore best to simply use an
approach that has a minimal impact on the codebase complexity and
produces no unexpected results for the end user.
Therefore in this commit, we handle this case in the following way:
- If a global leave is created or extended in duration, we simply
recompute the impacted leave durations (as was the case before).
- If a global leave is shortened in duration or deleted, the durations
of the affected leaves are also recomputed, but:
- In the case that existing allocations can cover this increase in
leave duration, the leave is left 'as is', but the user is
notified that additional allocation time has been taken.
- In the case that existing allocations cannot cover this increase,
the user is again notified, but the leave is additionally reset to
the 'draft' state (to prevent the allocation from going negative,
which is impossible).
With this approach, it now up to the user to handle this specific edge
case, while no information is changed or lost, which was possible to
happen with the previous approach.
Part-of: odoo/odoo#119317
Before this commit, a company access rule existed for hr_leave but it
checked the company of the associated leave type, instead of the
company associated with the specific employee (or company in case of a
company leave) the leave applied to. This is especially problematic as
leave type are often reused across companies.
This was partially worked around by forcing the company domain using
employee_company_id on the specific actions that showed overviews of
leaves.
With this commit, this is rectified.
task-3383478
Part-of: odoo/odoo#119317
On Database having a postgresql server version superior or
equals than 14.0, a feature called memoization is caching
result of the lateral join made in this query.
This cache creates an issue that results that customers
have the same result for their bank journals.
By adding a LIMIT 1 at the end of the lateral join query,
the memoization is not enabled (according to query plan).
Another solution could be to change the condition of this
lateral join (currently ON True) for a condition on the
journal id but it was less efficient.
opw-3422495
closesodoo/odoo#136498
X-original-commit: 0ccdd9344e2192049aa196f419abac7eb59e4f1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
If the currency_id and cost_currency_id is different for a product, the cost in the purchase order is wrong. The purchase order should use cost_currency_id instead of currency_id.
Steps to reproduce on runbot:
-Set the currency of main company as Dollars (USD).
-Choose in runbot the company "My Belgian Company" as its currency is Euro.
- Add the currency rate of today between EUR and USD
- Take a product and edit the cost to 100 EUR - as the cost field is linked with the currency of the company
make sure on the tab purchase there is no information - so the vendor pricelist is not present.
- Go inside the purchase module and start a request for a quotation
leave the currency as EUR
- Select the product to purchase
Current Behavior:
The unit price will be (100*currency rate). If you do the same but take the currency as USD the product unit price on the purchase order line will be 100
Expected Behavior:
The unit price should have been 100 Euros. And when dollar is chosen as currency, the exchange should have been applied.
OPW-3460551
closesodoo/odoo#136298
X-original-commit: f9c66ff20f2e7d8d35b9bc775486bb62abd4c367
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hamza Islam (hisl) <hisl@odoo.com>
Before this commit:
-With selection on checklist, on unchecking it toolbar is not updating.
After this commit:
-Now toolbar is updated when list unchecks.
task-3504398
closesodoo/odoo#136541
X-original-commit: 2cf3dd5988914a09bbc2098eccb3c8419995e120
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit:
Indenting list using tab inside a table used to switch to the next cell.
After this commit:
Indenting list using tab inside a table now indents a list instead of switching
to the next cell.
task-3470092
closesodoo/odoo#136538
X-original-commit: 62c16468e2759eb0a0c3eecf3866b543be3bfabb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Report footer is sometimes misplaced in settings preview.
We change the css to always stick to the bottom of the preview,
no matter the content height.
Task-3145445
closesodoo/odoo#136534
X-original-commit: 9be75bb17063c6b0207aa82144e9f44b6e49dc45
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Report body size was too narrow to render bootstrap .col as column,
the media query consider the report as a mobile view.
We unlock this limitation to let customer add column in the footer.
Task-3145445
X-original-commit: 3631e51e224e843cf6b6cd1da82592be4cb9397f
Part-of: odoo/odoo#136534
Before this commit:
when selected cell is clicked, its selection collapses yet toolbar is visible.
After this commit:
Now toolbar is removed when selection collapses.
task-3458048
closesodoo/odoo#136533
X-original-commit: 89116f6f356df0b33ba61f8b2e725ae7530bdceb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This is just a typo XD
closesodoo/odoo#136536
X-original-commit: 7c5fcf4c631cfcb80786566acae7ca4484fcf048
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
In a website forum post without any previous scrolling, select some
text. A traceback appears due the fact that there's no .o_action_manager
element in website forum.
This commit uses the document body as a fallback for the scroll
container when the .o_action_manager element is not present.
task-3506312
closesodoo/odoo#136508
X-original-commit: fc6f66f179798a731489a6a3e73af0d37af27f7d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Rodolpho Cammarosano de Lima (rcdl) <rcdl@odoo.com>
Upgrade (aka migration) scripts are a core part of Odoo, allowing
database manipulations for modules during version changes.
Any module, including custom ones can run upgrade scripts, even if the
`--upgrade-path` flag (and with it, the `odoo.upgrade` sub-module) is
not present. Currently only the "standard" modules benefit of easy
upgrade script testing. Any custom modules that want to run tests of
their upgrades have to import the tests in the usual `tests` folder,
which is not ideal.
Therefore, to allow TDD and programmatic testing of upgrade scripts in
custom modules, the test discovery is here modified to also parse the
module's `migrations` and `upgrades` sub-modules for tests.
closesodoo/odoo#136505
X-original-commit: c924434d35f80c223491371a87da7eab18956004
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
1. Backport of [1].
2. Steps to reproduce:
- Install website_crm
- Connect as Admin and remove the sales rights for Demo
- Check the website on a private window (to create an anonymous visit)
- Connect as Demo on the normal window
- Go to Website > Reporting > Visitors
=> It triggers an access error due to lead_ids being restricted to
sales_team.group_sale_salesman.
(Note: the error sometimes isn't triggered at that point. In that case,
click on the visitor: the same error will trigger.)
Considering the computed field doesn't do anything critical as it just
retrieves the email and phone number, the restriction is overridden on
the field.
[1]: https://github.com/odoo/odoo/commit/7de453477d7c23e607a15e0d60613080857e3371
opw-3475301
closesodoo/odoo#136362
X-original-commit: 70faf9bb07c9d801b3b06b325fc33de66c8406f3
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the din5008, there has been problem in the display of the paper format either
in the pdf or the preview.
In the preview we had a part of the page on the right that wasn't used caused by
the negative margin and the width of 180mm. But by removing that the pdf is
broken, the header is hiding some information.
To deal with that, we will add the width and negative margin only for the pdf
by adding a conditional css classes.
Also,it seems the footer with the company details can go out of page, by adding
a text-wrap on it, it solves this issue.
(In this commit, we override part of those commit:
https://github.com/odoo/odoo/commit/481f442f4ef176072edf3261415dbb06f8a3bc6fhttps://github.com/odoo/odoo/commit/f7812ae848e0a79adcd11f936f6cd7890da00112)
closesodoo/odoo#136500
X-original-commit: 6512069880407e5c48b0a07c0b5a74fc74633c9c
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
If somehow there is no selection but the `_handleShortcuts` handler still gets
called with `CTRL+A`, `container` would be a JQUERY object instead of an
element leading to a crash in `selectNodeContents` which expects a `Node`.
task-3506666
closesodoo/odoo#136499
X-original-commit: e6fac045282465960c0e4a7ecbbbb5e5ac8dff92
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Prior to this commit, there was a spacing issue in large screens (eg. 4K
screen), the form view wasn't large enough and this created a big gap
between the form view and the chatter.
This commit adapts the form view to large screens.
task-3453381
Part of task-3326263
closesodoo/odoo#136454
X-original-commit: 1a995cad898283f6909506ba43d1692381b3d6ef
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When the onchange triggered by an x2m fails on the parent record,
we want to reuse a valid value (the one before the onchange).
How to reproduce:
- Go to a form view with an x2m (onchange=true) that contains at least one record
- Edit the record in the x2m
- onchange on parent record fails
Before this commit:
The value is unchanged.
After this commit:
The value of the edited field is replaced by its old value.
closesodoo/odoo#136450
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior this commit:
The mail scheduler of the event notifies the attendees even when the event is
no longer active.
After this commit:
Inactive events no longer notify attendees.
Task-3381876
closesodoo/odoo#136429
X-original-commit: b61ece38a29e63f77daa638472228caa063d26e6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
In the survey, when you start a live session and click on the URL the `copied`
popover appears but doesn't go away.
After this commit:
Now that popover will close automatically.
Reason:
There was already a `tooltip` instance on the element and we try to add the
`popover` on that element which causes an issue.
Task- 3458901
closesodoo/odoo#136424
X-original-commit: 01dabbd207b230a3348aad0e48a208ba2f49d162
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
before this commit, in resume we are able to put end date less than start date
which is not possible in real life.
make change in constraint to check selected end date is greater than start date.
make changes in demo data of end date which are according to new changes.
task-3397726
closesodoo/odoo#136326
X-original-commit: 1cf56688126d3f0a1d27f4ed5ee995c4dcd956bc
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
This commit removes a loophole in the evalContext used in form,
list and kanban views to evaluate python expressions (modifiers,
domains and contexts). Before this commit, the evalContext was a
mix of different things:
- keys of the current context (which also contained keys from the
user context);
- a key for each field in the view (allowing to use field values);
- a "parent" key in the case of x2many records (allowing to go up
to the parent record values).
- "active_id", "active_ids", "active_model", "current_company_id".
All those keys were mixed in the evalContext, and they could
obviously conflict (e.g. if there was in the context a key which
was also the name of a field).
Even though the evalContext didn't contain an explicit "context"
key, expressions like `context.get("x")` worked. This was because
the python evaluator automatically adds the whole evalContext as
value for the "context" key if this one doesn't exist. This allowed
people to also access field values with `context.get("fieldName")`
and thus bypassing the view validation, which ensures that
everything used in those expressions is either a py builtin
supported by pyjs, a field name which is in the view or some other
whitelisted keys ("uid", "allowed_company_ids"...). Fun fact:
people did it, in a form view that is used on two different models
(product.product and product.template).
With this commit, the context (and user context) keys are no longer
spread into the evalContext. Instead, a "context" key is added.
Two special user context keys can still be accessed directly though,
without doing `context.get("...")`: "uid" and "allowed_company_ids".
The reason why we keep them is simple: those were the two only keys
that could be used directly as they were whitelisted by the view
validation. The client also evaluates domains and contexts coming
from actions and from search view filters. In those cases, the
evalContext is simply the context, and those two keys are widely
used. So it's easier if we know that, e.g. "uid" can be always
directly accessed, whether we're in an action domain, in a search
view or in a form/list/kanban view.
To summarize, accessing a context key must always be done through
`context.get("...")` except for "uid" and "allowed_company_ids",
which can still be accessed directly. This doesn't change from
before. What changes is that a record field can no longer be
accessed with `context.get("...")` (which kind of allowed to bypass
the view validation).
closesodoo/odoo#135782
Related: odoo/enterprise#47522
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Previously, the dashboard action needed two RPC calls to be ready:
1. load the dashboard groups (with the dashboards ids in the groups)
2. load the dashboard display names
Now, with the new `web_sear_read` we can load both at the same time,
saving one http request.
closesodoo/odoo#134984
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
In the odoo/odoo#122194 PR I incorrectly used the `need_cancel_request`
flag instead of the `show_reset_to_draft_button` one.
Italian EDI doesn't allow any sort of cancellation
(in case of error you have to a full refund credit note).
closesodoo/odoo#136436
Signed-off-by: Josse Colpaert <jco@odoo.com>
Previously, the self-order code and parameters were split into two parts
mobile and kiosk.
Now kiosk and mobile have been merged with each other to simplify
maintainability.
closesodoo/odoo#136051
Related: odoo/upgrade#5174
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The iframe doesn't need assets tests because they are loaded outside of the iframe.
The tour didn't crash because the content of the iframe was present (below the traceback message)
closesodoo/odoo#135492
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit fixes two issues with the ´date´ argument for
the ODOO.CURRENCY.RATE function.
First, the helper to cast the date is `toJsDate`, not `toJSDate`. Using
the wrong function name obviously crashes.
Second, the date was actually given to the server as a full ISO datetime
string, including timezone (UTC).
For function `ODOO.CURRENCY.RATE("EUR","USD", "12-31-2020 00:00:00")`, we
actually sent to the server "2020-12-30T23:00:00.000Z" (Brussels local time)
Notice that it's the previous day!
The field of `res.currency.date` is a date field, so it doesn't make sense
to send a datetime.
Now, only the date is sent ("2020-12-31")
opw-3498115
closesodoo/odoo#136411
X-original-commit: 6a4b7e7f216dc9a6372f5cc382262ff09cb317f3
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Problem
---------
When you go in the settings -> layout (debug mode) -> select external
layout --> preview document a traceback appears due to infinite looping
in the view definitions.
Solution
---------
This field is highly technical and should not be fiddled with by users.
For such reason, we set it as `readonly`.
task-3479152
closesodoo/odoo#136399
X-original-commit: 03cffc460e620639db6dbe132aa0be073a6396f5
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Antoine Boonen (aboo) <aboo@odoo.com>
Before this commit, some actions related to link creation and edition
were not tested by the LinkTools tour.
This commit adds steps to the mentioned tour in order to avoid
regressions of the issues fixed in the referred task.
task-3284649
closesodoo/odoo#136278
X-original-commit: b2a79ed9960d88d1bdf6465389f4ef720f6bc235
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When changing a link's content, its URL (href attribute) might change
(if the new label is a valid URL), due to a mechanism in OdooEditor.
Before this commit, when a change in the link's content leads to a href
change:
- if the LinkTools is opened, the URL input field would become outdated
and display an incorrect URL.
- likewise, if the popover is shown, its content and position would be
outdated (possibly covering the link's new content).
This commit makes sure both the LinkTools URL input field and the
popover stay up-to-date if a link's content or href changes.
task-3284649
X-original-commit: 1b0952f3635f5677ba3ab221a28ceb26920a1862
Part-of: odoo/odoo#136278
Before this commit, any changes made to label input field were lost when
the LinkDialog or LinkTools component was re-rendered.
This commit fixes it without leveraging OWL's reactivity/declarative
approach, because most of the code in these components is imperative and
not yet converted to the OWL paradigm, leaving such refactor to be done
in the master branch.
Part-of: odoo/odoo#136278
If a link's content is equivalent to its URL, two problems can arise
when its URL is changed via the LinkTools:
- The link's content becomes outdated, showing a different URL;
- On LinkTools destroy, the OdooEditor mechanism that updates a link's
href on label(content) change will update the href according to the old
label, effectively reverting the changes in the URL.
This commit avoids such issues by syncing the label with the URL input
field in such cases.
task-3284649
X-original-commit: 8ddcc08c1700151e697ecb3c0c1daec2db9f8fd2
Part-of: odoo/odoo#136278
Before this commit:
- URLs like "domain.com/@/page" were incorrectly detected as an email
URL by Link(Dialog/Tools),
- switching from an email URL to a http URL with the Link(Dialog/Tools)
was not possible (URL remained prepended with "mailto:").
This commit improves email detection from simply looking for a "@" to
something slightly more robust, and makes switching between 'http'
and 'mailto' links possible.
task-3284649
opw-3245501
X-original-commit: e849ff4333355386dfb79bc574c93c76ed3e2d3b
Part-of: odoo/odoo#136278
Typing a URL + SPACE transforms the URL into a link.
Before this commit, email URLs were incorrectly prepended with
'https://'.
Because it is not desirable to automatically transform email URLs, this
commit disables link transformation for email URLs, leaving it only
active for http URLs.
task-3284649
X-original-commit: ad0e7845fceb578398e42e4b35820c415734452a
Part-of: odoo/odoo#136278
OdooEditor has a mechanism to update a link's href on label change, if
the new label is a valid URL.
Before this commit, there were two issues:
1. it did not work for email links. In fact, because this mechanism was
incorrectly prepending email URLS with 'https://', [1] disabled it for
'mailto:' links.
2. when a link had a 'http' href but its label did not contain the protocol,
upon label change (into a valid URL) the link had its href changed to 'https'.
This commit:
1. re-enables the auto update mechanism for email links and fixes it, so
that it can correctly update both http and mailto links.
2. fixes the 'http' to 'https' coercion issue, making sure the current
protocol is kept when updating http(s) links.
task-3284649
[1]: https://github.com/odoo/odoo/commit/ea00a628969a0eeda66e06776af721a99a32cc57
X-original-commit: 6740e2821c51897baa110e9e4129b40c403e000c
Part-of: odoo/odoo#136278
Commit [1] separated the two responsabilites of _onURLInput: making
changes to the DOM and updating the UI, taking care that only the second
one is done at start.
But this broke the following functionality:
- Have a URL-like text (ex: odoo.com), select it and click the link icon
on the sidebar.
- The URL is deduced from the link's label.
- Click anywhere to close the sidebar.
Before [1], the link transformation would be kept. After it, it is not.
This happens because this is a particular case in which we want to apply
changes to the DOM at start time, as if a URL input event had happened.
This commit fixes it.
task-3284649
[1]: 54746012d3
X-original-commit: da0a3f34401547478107945626034d7932855f02
Part-of: odoo/odoo#136278
Before this commit, the setup actions performed by _configureToolbar
were missing for the website toolbar. This resulted, among other things,
in non-responsive buttons like create link or insert media.
Part-of: odoo/odoo#136278
This commit changes the canOpen prop of the many2oneAvatar field to be
set to true only when in form view. The field will therefore stop being
a link in readonly when outside of form view.
closesodoo/odoo#136118
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Manushi Shah (mash)