Previously, when calling error handlers, we would give them a new error
created by the error service, as well as an `originalError` which is the
error that was caught by the error service. In some cases, this error is
part of an error chain, eg: errors that happen in the owl lifecycle are
wrapped in an `OwlError`, so that when an error occurs in a callback
passed to a lifecycle hook, the position where the hook was called to
register the offending callback is part of the stack trace.
In practice, most error handlers only care about the error that caused
the entire error chain (the root) when deciding whether they should
handle the error or not, eg: an RPCError should be handled by the rpc
error handler, regardless of whether it occured in an event handler or
in a component's willStart. It already reads the traceback to display on
the UncaughtError provided by the error service as this traceback
contains the entire error chain stack information and is annotated with
source maps by the error service.
This commit makes it so that the `originalError` passed to handlers is
now the root of the error chain, it also sets the `cause` of the
UncaughtError which is passed to handlers as the error that was caught
by the error service, so that if a handler needs to inspect the error
chain to know whether it can handle the error or not, it can still do
that.
related to OPW-3069633
closesodoo/odoo#106720
X-original-commit: dd6f103b1635868e03a7aa40eb7186861d22d377
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since the Bootstrap 5 migration the "headings" `<h1>`, `<h2>`, ... are
smaller than before.
This commit, restores the old CSS rules from Bootstrap 4 for reports.
Steps to reproduce:
* Open Sales
* Select a quotation
* Print the Quotation (using Print dropdown) => BUG title is smaller
than the old version of Odoo (e.g. Odoo v15)
closesodoo/odoo#106721
X-original-commit: 76299a8d63e85249d30d864a777c2f142ea5daf5
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In kanban view, the columns are in a flex container and as there is no
specific flex rules on the quick create column and is shrink by
default. So when the new column is above the edge of the viewport, it
starts to shrink.
To avoid this bug we have added the same flex rules has the kanban
column.
Steps to reproduce:
* Open Note
* Create many new column => BUG text wrapped when the new column reach
the width of the viewport.
closesodoo/odoo#106683
X-original-commit: 62b692b6edd7d57ef14c02ecd5b731c8ba664b98
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
There was a typo in the color_field xml not allowing to disable the
pop-up in case of readonly. A test validates the feature is active.
The color_field now displays the transparent symbol (instead of black
color) in case the color is undefined.
The product configurator also displays the transparent symbol for
undefined non-custom colors.
task-3013110
closesodoo/odoo#106669
X-original-commit: c67c32c2dbe10b4885ec1177852839b3d18ecf05
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...
closesodoo/odoo#106623
X-original-commit: 54657151957c5be5e885c245db9e1830709833c0
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before this commit**
When a popover is shown and then repositioned to a different placement
(i.e. due to window scrolling or resize), its arrow is misplaced.
This is due to the fact that classnames added in order to correctly place
its arrow are just added to the previous ones instead of replacing all
the needed classnames.
**After this commit**
The classnames are now properly replaced instead of just being appended.
closesodoo/odoo#106495
X-original-commit: c54cc2f87930147b5addb6f447574c677ef3504d
Signed-off-by: Luca Vitali <luvi@odoo.com>
When a one2many is used as a search default, its label has to be fetch
via a name_get in order to get a correct display of the facet
corresponding to that field in the search bar. It turns out that the
search model did not wait properly the return of the name_gets before to
start to compute the facets.
closesodoo/odoo#106624
X-original-commit: 50f58212410b321c1c4ad3d42a91cd1d23567308
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When rendering, the form view looks for the element it should autofocus,
and defaults to the first text input it finds. This extends that default
behavior to the first textarea or contenteditable element.
closesodoo/odoo#106622
X-original-commit: 82a98715ae2937bff8b58212c452a28d0b28e102
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
Prevents auto save of not dirty forms with
text fields on page reload and tab/browser closing.
Specifications
==============
The text field default value is making Odoo consider
the form as dirty even when it's not which triggers
auto saving for not dirty forms.
Change the text field widget setDirty condition to
prevent considering empty textarea string dirty.
Typically, if the previous value was false, false and
empty string should be considered as the same value.
Task-3031570
closesodoo/odoo#106619
X-original-commit: 787ef58dd3f91f829509f738ee40c8764c403757
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- edit RFQ model with studio
- add a toggle widget to the product list
- activate/deactivate the toggle multiple times on different products
Bug:
sometimes the element on the widget is undefined when trying to rerender
Fix:
check the element is defined before trying to render it
opw-3013024
closesodoo/odoo#106614
X-original-commit: 1b09a6314dbce9363f4785c670033f41846359ad
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Use case:
in the reconciliation widget, we need to know when the pager
is updated before the next render because we need to select the
appropriate id to use.
cf the following PR: https://github.com/odoo/enterprise/pull/33631
opw-3031131
closesodoo/odoo#106581
X-original-commit: 19523b511d54278613a3d3e7389a51665dcc3fc1
Related: odoo/enterprise#34408
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
With the arrival of the new always edit mode,
some form views display are broken because of
the very big input width creating white gap
when having inline fields.
This commit introduces new css classes to be
added to the input fields in order to constraint
their width and avoid white gaps in forms.
Task-2996467
X-original-commit: 5fe7759fc457612bfc09e2d97849c5e51874edd2
Part-of: odoo/odoo#106570
The fix in #106174 was not good.
The translation dialog cannot update not translated terms
the initial term value may be empty "" when the source and the translation are
the same at first. So, the source to for update_field_translations should be
const source = term.value ? term.value : term.source;
closesodoo/odoo#106528
X-original-commit: 1ed5ce6f16d32efc0c5ec4cead67b2d8a57f6c41
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
In the bottom of the settings, it would show:
`Database expiration: Invalid Datetime` if
the `database.expiration_date` system parameter
value is set.
After this commit:
The date is displayed correctly
OPW-3047586
OPW-3072884
closesodoo/odoo#106497
X-original-commit: 9f59129f5281894799dfdb0fcd296d2d52823e12
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
*: auth_totp_portal, mail_group, portal, survey, web, website_event,
website_event_track, website_mail, website_mail_group,
website_mass_mailing, website_payment, website_sale
Although this is deprecated since 5 years with [1], new occurrences of
`this.$target` in widgets kept being introduced. `this.$el` can be used
just like in any other widget, or even better: `this.el` to not rely on
jQuery.
For now, this still keeps the definition. This just removes the bad uses
to prevent more copy/paste... let's delay the decision to remove the
definition entirely to another day.
[1]: https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8closesodoo/odoo#106437
Related: odoo/design-themes#618
Related: odoo/enterprise#34343
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Scrolling inside a grouped kanban with a lot of cards on a column
makes the text header appear over the kanban card due to the missing
background.
Steps to reproduce :
- Open Helpdesk on small screen like a mobile
- Open VIP Support
- Made a Group by "Create date => day" (there should be enough cards on
a column to scroll)
- Scrolling the column => bug, the text header appears over the kanban
card
closesodoo/odoo#106368
X-original-commit: 041fddf0c884ae9a6e2b040decfb1f31e9d25a29
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Field tooltip lacks domain information because of a small mistake in
`getTooltipInfo` function.
To reproduce: open a form in debug mode and hover any many2one field that has
domain in its configuration. Example: ``hr.expense:sale_order_id``
opw-3049554
closesodoo/odoo#106225
X-original-commit: c2663c0493f8330041ba426ce233a2a73fda048a
Signed-off-by: Samuel Degueldre <sad@odoo.com>
**Issue:**
When at the first page of the list, and the user deleted all/or some
of the records, the next page is not automatically displayed.
**Solution:**
This is because the first page (offset=0) is exempted from offset
adjustment (_adjustOffset) which is responsible in reloading the
records in the list.
In this commit, we propose to reload the list if the call to
`_adjustOffset` didn't call `load` and there are actually deleted
records.
closesodoo/odoo#106317
X-original-commit: 2863978041d2856644da938ced9eedc640b8f198
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
- Open a list view and group the records. Notice the count per group.
- BUG: When deleting a record under a group, the count in the group
is not updated.
**Solution:**
When calling `deleteRecords` in the `DynamicGroupList`, we call
`deleteRecords` on each group's `list`. This "list" can be
`DynamicGroupList` or `DynamicRecordsList`. Regardless which instance
calls the `deleteRecords` method, we should take the number of the
deleted records and subtract it from the group's current count.
If it turned out that the calling object is a `DynamicGroupList`,
we should make sure that it returns the ids of the deleted records
so that the parent group can update its count as well, that's why
we are collecting the deleted record ids.
It's not so easy to follow but we can roughly imagine the structure
this way:
DynamicGroupList
-> DynamicGroupList[]
-> DynamicRecordsList[]
Deleting items from the inner dynamic records list should result to
update of the parent group list, and eventually, to the update of the
root group list.
X-original-commit: 865c1b37f7986f00b85c9e8135e46cc4b2ac70da
Part-of: odoo/odoo#106317
Some missing aria attributes from 14.0 are reintroduced.
They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).
closesodoo/odoo#106277
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.
However, since the focus is always on the dropdown button, screen
reader users are no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).
The above is fixed by making the activeElement follow the visual change.
Part-of: odoo/odoo#106277
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
**Before this commit**
Various issues are present in the calendar filter autocomplete:
- typing a character in the input would close the autocomplete dropdown
- search for a term yielding to no results would not display the
"No records" entry
- click on the "Search more..." entry yields to a validation error
message: "a mandatory field is not set". [1]
**After this commit**
The FilterAutoComplete component has been removed as it was useless.
It was a kind of higher order component trying to manage the
AutoComplete component's input state, leading to unwanted complexity.
We decided to remove this component despite being in a stable branch
for the following reasons:
- it was not exported and only used by the CalendarFilterPanel
- it brought unnecessary complexity
- it was not working properly
- the branch is still a bit young
- the diff in the CalendarFilterPanel template is minimal
Now that the CalendarFilterPanel directly make use of the
AutoComplete component, the first listed issue has been solved.
The two other issues were simple fixes addressed in the mean time.
[1] this issue comes from opw-3031045, more infos below:
Steps to reproduce:
- Go to calendar basic view
- Click on "+ Add attendees" and then on "Search more ..."
Current behavior:
Validation error on partner_id in calendar_filter create
Expected behavior:
You can look for a partner with advanced research options
Explanation:
The code treated the "Search more ..." option like a partner
option instead off calling the onSearchMore method that creates
the advanced research dialogue.
opw-3031045
closesodoo/odoo#106292
X-original-commit: 73af1d04d9d49eace16e3f88c32ce5d457b44b83
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Martin Fockedey <mafo@odoo.com>
Co-authored-by: Hubert Van de Walle <huvw@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Since the conversion in OWL of the `many2one_barcode` widget, on Mobile
when we open the search more a filter value is added automatically in
the filter and so when we want to change the value we need an additional
step to remove the filter to see all records.
This commit, use a 'custom event' to open the barcode search and restore
the normal behaviour on the `click` event.
Steps to reproduce:
* Go to Timesheet
* Add a new line
* Select a project
* Try to change the project => BUG show only the selected project
closesodoo/odoo#106267
X-original-commit: 6d7f5a0abd79f6185831a2b9617b031d13da89be
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Before this commit, new model term translations cannot be saved if it has been
translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr
However the UI sent {old_term_en: new_term_fr} which was wrong
This commit fixes the bug by changing the key of the mapping from the
old_term_en to the old_term_fr
opw-3074712
closesodoo/odoo#106257
X-original-commit: f28c11917e093d0d3f5d18f0b377cfb24a7dbd92
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Before commit, clicking on the "App Store" and "Updates" menus in Apps
in debug mode causes a crash.
Why:
Since owl 2, rejecting a promise in onWillStat is considered an error
and so we have a crash. In our case, the error is already handled
(Display a notification and do a doAction). So we can resolve the promise.
The two menus ("App Store" and "Updates") will be removed in master.
closesodoo/odoo#106247
X-original-commit: 08c8d64eedb509cdeafa1cecceb28f00a3bd98f0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Steps to reproduce:**
- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.
But it was saved: if you move to another record and return then it
shows the correct one.
**Solution:**
Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.
The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").
closesodoo/odoo#106236
X-original-commit: 93911daab238e96c8aa9b0a951b9a268d83a9847
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
In PR 102662, we added a protection to manage the call to RPC in the new
form views when the component is destroyed.
This fix did not exactly reproduce the behavior of V15 and the new
relational model. The expected behavior of an RPC call when the component
is destroyed is a promise never solved. This commit will therefore
reintroduce this behavior.
In web, it is impossible to test this behavior because no rpc is
triggered when the view is destroyed.
closesodoo/odoo#106171
X-original-commit: 207f26ace6732c33d7169102f2a5a9695f5dda99
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the listArchParser did not offer ways to be extended.
Specifically, when extracting fields and widgets, there was no way to add information
from the outside.
After this commit, the functions that parse fields, widgets and button are methods
of the class hence offering extension points. Specifically, studio uses those to add information.
closesodoo/odoo#105970
X-original-commit: 4c1e0ba228f294c7bd5dd067431a1b660960d8b5
Related: odoo/enterprise#34074
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.
Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.
The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.
However, since revision
odoo/odoo@488e334fc8,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.
A video attached to the pull request of this revision
shows the behavior difference.
Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.
opw-3031290
opw-3038711
opw-3055292
X-original-commit: 48ac799288e76a0256b9ce0712a70ed5abc0f62e
Part-of: odoo/odoo#105251
Since the "always edit" task in form view, the underline (border-bottom)
only appears when input is `:focus` or `:hover`.
The problem occurs because the rule for `.o_field_invalid` doesn't match,
so the transparent color is applied and the red underline only appears
when we are hover or when the field has the focus.
This commit fixes the problem by setting the border transparent only
when the field is not invalid, not hover and not focus and not in a form
`.o_field_highlight`.
So now, we better see the invalid fields without hovering it.
Steps to reproduce:
* Open Project
* Select a project
* Select a task
* Create a new task
* Try to save manually the task => BUG a notification appears but the
"task title" (name field) is not underline
Task ID: 3069662
closesodoo/odoo#106123
X-original-commit: 1666ee5515996fab8a843b36b4fd93b776172f75
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Steps:
- Go to studio
- Open report editor in any report
- Use Text block
- Insert /checklist
Normal bullets without boxes are used in the report, because the checklist are styled separately in web_editor/static/lib/odoo-editor/src/checklist.css
opw-2995045
closesodoo/odoo#102072
X-original-commit: 9b4a1d3a45d294797813d653090b3a3c541210f5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
Steps to reproduce:
- go to Contacts app;
- add a reporting view (Graph, Pivot or Dashboard) (with studio for example)
- tape any character in the search bar;
- on "search related company for" field either use the arrow keys to go down to this and then click the right arrow key or click on the triangle to the left of this field.
Issue:
An error occurs.
Cause:
There is a mismatch between the parameters that are sent by the rpc call and those processed by the logic part.
Specifically, the domain must be part of the kwargs and not the args of the params key in the rpc call.
The problem occurs with a filter that looks like: `<field name="parent_id" domain="[('is_company', '=', True)]" operator="child_of"/>`
Solution:
Move domain in kwargs under key named args in the params of the rpc call.
opw-3031096
closesodoo/odoo#106074
X-original-commit: 8a9b418b27dcc9b904413f14cd0443f9a5b10d17
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Steps to reproduce:
- Activate debug mode
- Go to Sales and open a quotation (actually any form view from any
module will do)
- Start Studio
- Select the "Confirm" button (or any of the top buttons)
- Check the "Set approval rules" box
- Edit the domain by clicking the 'filter' icon next to the 'trash' icon
- Add a condition. You can just keep the default one.
- Click save to save the domain.
- Again, click on the 'filter' icon.
You should see that the domain in the text editor is malformed.
Furthermore, should you change the domain in the text editor (let's say,
change 1 to 2) and hit save, an error message will pop saying the domain
is not properly formatted.
opw-3001622
closesodoo/odoo#106043
X-original-commit: 9535026e00ca07453863d13d68935732cac49bfe
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Current behaviour:
When rendering a calendar view with "Year" option,
the weekday headers may be incorrect in some cases
when the timezone is set to a negative timezone GMT.
For ex. it renders "S S M T W T F" instead of "S M T W T F S",
if the first day of the week is Sunday.
Expected behaviour:
Formatting should be consistent with the first day of the week,
and be indepedent of the timezone.
Steps to reproduce:
- Change your system timezone to somewhere in Alaska
- Install TimeOff
- Open TimeOff and switch to the yearly view.
- Observe that the weekdays headers are incorrect.
Reason for the problem:
The custom calendar header formatter was trying to generate
the end result directly based on the date marker, which is
incorrectly set in that context. This patch doesn't fix the root
cause of why the `info.date.marker` starts at an incorrect date.
Fix:
A formatter shouldn't read state. Since we are using the luxon plugin,
we use the `"EEEEE"` format, which is equivalent to the `"narrow"` options
from JS's `Intl.DateTimeFormat()` available in all browsers.
Affected versions:
- 16.0
- master
opw-3033464
closesodoo/odoo#106041
X-original-commit: e212f8752047222d1d81e1e9589934e70ecacf2a
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
In grouped kanban, when having groups but no record to display, the
group creation button (ie. "+ Stage" in Project) and its related column
are muted instead of being the regular colors (like for the groups'
titles).
This commit fixes it by applying a fix similar to the group's title one
(cf. odoo/odoo@cbefc9cd51)
for the quick create column element.
Steps to reproduce:
- Open Project
- Create a new project and open it in kanban view
- create a few stages
=> the quick create column is "muted"
- dismiss the quick create column (ESC or click outside it)
=> the "+ Stage" button is muted
closesodoo/odoo#106022
X-original-commit: e95e2a23bc168815a27a9c64e4ff9394de468ada
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Bug
===
If we hover the property label, we should see the bottom border of the
property value (like for standard fields).
The bug still exist for the tags and many2many, because it's based on
the AutoComplete component, and the same bug exist for standard
many2many tags.
Task-3039733
closesodoo/odoo#105969
X-original-commit: 3ced33f434e84361448062b4795108df6186ffed
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit adds and fixes type annotations to give more accurate
autocompletion for javascript.
closesodoo/odoo#105670
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
*: im_livechat, website_livechat, website_slides
In c989ff3, the odoo module system has been changed so that it now
errors out when modules are defined but have missing dependencies and
cannot run. Unfortunately, tours are defined in a single bundle,
`assets_tests`, and this bundle is used everywhere tours need to run,
but some of these tours depend on modules that only exist in the backend
and others on modules that only exist in the frontend. We don't want to
break up the `assets_tests` bundle as this creates a poor developer
experience, and so the solution that was chosen at the time is that when
the `assets_tests` bundle is defined, we ignore all module dependency
errors.
This causes a problem however, which is that if a module dependency is
missing in production code, the page will be broken by the module error
(which is expected) but if the `assets_tests` are present, which is the
case when running tours and tests, then it won't, meaning the tours will
happily pass despite the application being broken, which is
unacceptable.
This commit fixes this issue by replacing the assets_test bundle by a
new bundle (`__assets_tests_call__`) within which all module dependency
errors are ignored, which lets dependency errors that are hapenning in
other bundles (ie in production code) happen even during the tests.
Because of this, this commit also fixes the dependency errors that
already existed but were previously silent:
- for im_livechat and website_livechat, the code was refactored to use
the standard mechanism that we use elsewhere to add data directly in the
page: we store the data in __session_info__, and the module that exposes
that data is always present, instead of having a module that's defined
conditionally, which causes issues when non-conditional modules depend
on it.
- in web, the `report_assets_common` bundle was used alongside
`assets_common` but without `assets_frontend` or `assets_backend`.
Reports do not need any js and it appears that it already had what it
needed as far as css is concerned except for one fontawesome override.
Code was changed so that the js from the bundle is not included and it
reports no longer use `assets_common`, the js part of the bundle is no
longer used.
- in website_slides, the `slide_embed_assets` bundle is used alongside
`assets_common` without using `assets_frontend` or `assets_backend`
which is required for `assets_common` to function, the approach here was
to simply take the files from `assets_common` and remove the files that
were causing issues. This bundle should be trimmed at some point, as it
contains way too many things that it does not need.
The file colors.js was also moved to core, as it isn't graph specific
and was causing dependency issues with a field that was importing it.
Fields shouldn't depend on files in specific views' directory.
closesodoo/odoo#104794
Related: odoo/enterprise#33909
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Fields in views can be decorated with attributes decoration-xxx
(e.g. decoration-danger="state == 'error'"). This typically
results in a bootstrap contextual classname being applied on the
field's root node (e.g. text-danger). However, these classes have
no effect on children inputs and textareas. Since we wrap wowl
fields into a div (which thus receives the contextual class),
decorations were no longer visible in edition (which is, by the
way, the mode of almost all fields in form views now).
To fix this issue, we manually force the color of inputs and
textareas inside fields, to the color of their parent.
closesodoo/odoo#105781
X-original-commit: 4b2624ab3e398fe036832d9348bc319992b4fcd1
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Have a many2one field with a domain set in the field definition in
python. Use this field in an editable list view, with a domain set
on the field node. For instance, go to Sales > Sales Team and see
Team Leader field.
Before this commit, we combined the field domain with the domain
set in the view, which isn't the spec. The spec is to use the
domain set in the view if there is one, and if there is not, use
the field domain (see _getDomain in basic_model.js).
In the scenario described above, it produced a crash because the
field domain couldn't be evaluated with the fields defined in the
view.
This commit restores the previous behavior.
closesodoo/odoo#105774
X-original-commit: 32654fd17ab366d20fff8b3fc8134ee209569f1d
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
QWeb views allowed to render QWeb templates rendered by the server in
a view.
Today, QWeb views are only used in website to see the hierarchy of
their views. The use case of website has now more sense in a client
action rather than an extension of a QWeb view.
This commit removes this view because it is not used anymore and will
probably not find any useful use case in the future.
closesodoo/odoo#103477
Related: odoo/upgrade#4016
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
### Steps to reproduce
* install Live Chat (`im_livechat`)
* Go to Live Chat > click any channel
* Under Widget, Click the copy button for the first link
If you're on firefox, nothing will happen (text won't be copied).
On chrome, you will get a traceback saying `Failed to execute 'write' on
'Clipboard'`.
### Expected behavior
The text should be copied to the clipboard, and a tooltip should appear
to confirm that.
opw-3058357
closesodoo/odoo#105756
X-original-commit: 977f5aacf46c3746380dda33585b407df659e07d
Signed-off-by: Luca Vitali <luvi@odoo.com>
Samuel Degueldre