For signature field widget, we can set 'full_name' node option, which can be
used to auto fill the sign. However, current implementation for getting data
for field provided in 'full_name' (mainly, a string) has some flaws.
For example :
-In case of m2o fields, the string is not properly fetched due to different
structure than regular 'input' fields
- In case of x2m views inside a form view, field with same name can exist in
both parent record and child records. This is already the case with form view
of res.partner, where 'phone' field is there in both parent's form as well as
children's kanban view (for field 'child_ids'). With current implementation,
if we add signature on the form view, and set 'phone' as 'full_name' node
option, instead of form view, we will get phone number from 'child_ids'.
This commit improves the behavior by getting data from the 'recordData' instead
of searching them from the DOM. To have recordData in it's latest state, we've
set 'resetOnAnyFieldChange' flag to true.
task-1948364
closesodoo/odoo#33105
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The disconnected/connected notifications were broken due to changes in
the way the Notification template was loaded. We need it loaded in
assets as we cannot load it afterward if the server is disconnected.
This was broken by : https://github.com/odoo/odoo/pull/32793closesodoo/odoo#33252
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since saas-11.3:
Bootstrap sanitizer sanitizes html and removes attributes which are not
defined in whitelist, here is the documentation link:
https://getbootstrap.com/docs/4.3/getting-started/javascript/#sanitizer
Restore sanitize=false for bootstrap popover.
A scenario where the sanitizer will break a popover: compare 2 products
and open Compare popover and try to delete a comparison item from the
popover -> item can not be deleted because data-product_product_id has
been removed by sanitizer and so the item can not be deleted because
deletion logic depends on data-product_product_id.
Reference commit: https://github.com/odoo/odoo/commit/36caf5fc16b5a95a0bf37f08f0caf974683b2df6
Closes https://github.com/odoo/odoo/pull/31961
task-1950702
In the context of a livechat session, a placeholder that looks like a
person is better than a generic "missing picture" one, when the user has
no public avatar.
In order to allow a different placeholder without exposing a public
placeholder parameter, a separate route is introduced for the
purpose of displaying user avatars:
/web/partner_image/<id>/<field>/<model>
and can be simplified to:
/web/partner_image/<id> for loading a partner avatar (`image_small`).
The common part of the /web/image route was moved into a helper
function that is not directly exposed.
Task-ID 1924666
Closes#32664
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
- Install the 'Maintenance' app
- Create a maintenance request, set a day and a duration of 6 hours
- Go the calendar view, month mode
- Move the maintenance request from one day to another
The duration is changed with a non-sense value.
In month mode, the hours are not represented in the calendar so it is
not possible to compute the `date_delay`. Moreover, when a record is
moved from one date to another (`_onDropRecord`) in month mode, there is
actually no point recomputing the duration; the `date_start` is enough.
Note that `date_delay` is used (at the time of writing) in 2 views and
absolutely not tested.
opw-1984637
closesodoo/odoo#33193
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This rev. disables Popper.js 3d transformation for positioning
bootstrap dropdowns in navbar, as this transformation causes a
rendering issue on webkit-based browsers (the text in the dropdown
is blurry).
See https://github.com/twbs/bootstrap/issues/23590
Note that it has already been disabled for the other menu dropdowns
(user menu, debug menu) by rev. 5373db1.
Another solution would have been to override the default value in
our bootstrap.js extension file, but for dropdowns that aren't in
the navbar, the dynamic positionning could be interesting.
Fixes#33096closesodoo/odoo#33174
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Arabic customers are complaining the Lato font is very odd looking for
Arabic scripts. Furthermore, since #32312 Noto is used as the prefered
font to display arabic scripts.
The classes are used by the "Company Tagline" configured along with the
template in use in the general settings.
opw-1946109
closesodoo/odoo#33141
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The `read` done by `_fetchRecord` in `basic_model.js` expicitly set a
`bin_size: true` in the context. That context option tells the backend
to send the size of the binary payload instead of the payload itself
thus slim the response size. Frontend widgets are then responsible to
fetch the actual payload in a separated http req.
The `search_read` done by `_searchReadUngroupedList` didn't set the
context option thus all the binary fields were sent b64 encoded along
with the `search_read` response.
opw-1963842
closesodoo/odoo#33014
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Open a record with a chatter (ie an opw task), add an attachment, enable
debug mode and click on "Set Defaults" in the debug tools, traceback.
The `message_attachment_count` field is a special view added by the
chatter on the form view. This field exists on the view but is absent on
the list of field listed by the XML file. Setting a default value on
that special field is not supported.
opw-1972372
closesodoo/odoo#33044
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closesodoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
backport of 12.0 535da9e (in pr #30239) since video loader was in 11.0
opw-1928512
closes#32983
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closesodoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The closure overrides the arguments, which makes it impossible to
recover the attachment_ids hence sending null python code which then
breaks.
closesodoo/odoo#32810
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 42530b02fe was fixing a bug in reports that were using the standard
bootstrap fonts instead of the changes we made in $font-family-sans-serif
To solve this, 42530b02fe replicated the change in the file
web_editor/static/src/scss/bootstrap_overridden.scss
which is imported in report_assets_common **before** web._assets_bootstrap
This was solving the issue for the report but had also the side-effect of
changing body font-family in enterprise as the bootstrap_overridden.scss file
is also used in web_editor._assets_backend_helpers and
web_editor._assets_frontend_helpers
42530b02fe had effect only on enterprise where the desired font is Roboto/Noto
Create a new bootstrap_overridden (6th of the name) file only for report
closesodoo/odoo#32902
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, a domain that had been written in order to be
JSON parsable, would trigger a JS crash when activated in the UI
It happens when adding custom filters through the edition of the search view with studio
This was because, Odoo developers write, in the XML of a search view
domains python style: `[('field', '=', 'value')]`
When parsing the view in JS, this doesn't get altered by `xml_to_json`
Then, the search view code evaluates it python style
This commit considers that behavior fortunate, but not really clear or conceptually correct
But, when customizing a search view with studio, the domain is written by the code, in JS
JSON parsable format `[["field", "=", "value"]]`
This should be supported too, as so many customizations may have been done before hand
After this commit, both expressions are supported by the filters menu
OPW 1957297, 1960732, 1965649 (at least)
closesodoo/odoo#32690
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.
Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.
closesodoo/odoo#32408
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
Subpixels computation is different accross browsers and platforms as no
rounding rule is specified by HTML5. Difference in this computation
breaks one of the editable list tests on Chrome and Firefox on MacOS.
In an editable list view with at least a facet (e.g. filter) in
the search view, start editing a row, then click on the 'x' to
remove the facet. The view being updated and re-rendered, the row
in edition (if still present) is back in readonly. However, the
buttons in the control panel are not updated ('Save' and 'Discard'
are still displayed, instead of 'Create' and 'Import').
Normally, when the user clicks outside the list, the edition is
left smoothly. However, this scenario is a corner-case because the
element we clicked on (the 'x' in the facet), is no longer in the
DOM when we enter the list '_onWindowClicked' handler, being in
charge of deciding whether or not we should leave the edition. For
this specific case, this handler doesn't leave the edition, because
it assumes that we have clicked on an sub-element of the list that
is no longer in the DOM (e.g. a modal opened from a field widget).
Since it's no longer in the DOM, there is no way to determine
whether it was in the list or not.
This whole '_onWindowClicked' logic is problematic, but we don't
have any better solution for now. So this rev. fixes the issue by
always resetting the buttons to 'readonly' when the view is
updated, which is valid in the case of the list view.
Unfortunately, we couldn't reproduce the bug in a test, because of
a difference between user clicks (with the mouse) in the browser,
and programmatical clicks (triggered in JS) as we do in the tests.
For natural clicks, there is a delay between the (different level
of) handlers call (probably a nextTick) whereas all handlers are
executed in the same tick for programmatically triggered clicks.
For instance, when the user clicks on the 'x' to remove the facet,
the 'click' handler on '.o_facet_remove' is executed, and the
searchbar is re-rendered (new Widget, so next micro-task tick, but
still before the next tick), and in the next tick, the 'click'
handler on 'html' is executed (and the event is triggered on
core.bus, followed by the execution on '_onWindowClicked'). In the
test, both handlers are executed directly, and thus when in
executing '_onWinowClicked', the searchbar hasn't been replaced by
the new one yet, and the clicked '.o_facet_remove' is still in the
DOM. The row is then unselected, and the buttons are correctly
updated.
Before this rev., when adding then discarding a new record in a
(main) editable="top" list, the record was added to the top of
the list, and then replaced by an empty row when discarding,
whereas that empty row should have been rendered below potential
data rows.
Recent work on the list view allowed to add buttons in group
headers (see 015958dc17). However, we couldn't execute the action
of the button by pressing Enter, because the Enter keydown was
stopPropagated by another handler (folding the group).
This rev. makes this work, and also improves a bit the style of
the buttons in group headers.
Task 1915702
Assume an x2many editable list where the user edits a record (input
field), and then clicks on 'Add a line' (and keeps it pressed for a
while, before releasing the click).
When the 'mousedown' event occurs, the 'change' event is triggered
on the edited field, and (once potential onchanges have been
applied), the list is updated, i.e. all rows except for the one
being edited a re-rendered.
However, the 'Add a line' handler listens to the 'click' event,
which never occurs if we release the click after the rows have been
re-rendered.
This is an issue for every rows, not only 'Add a line', but for
data rows, the issue is already present in former versions, and is
not that easy to fix). The 'Add a line' case is a consequence of
the recent work on list views (see 234d92c4f0), so we can fix it
independently.
Task 1915702
Have a timesheet uom per Day
Have a language with a different number format than English
Click on grid cell to change its value
Before this commit, the value was stuck on the highest value in range
This was because the parsing of the value into float was not taking into account
the real format of the float
After this commit, it works in all languages
OPW 1964657
closesodoo/odoo#32581
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The basic font-family offered on Odoo do not support a large set of characters
and rely on the system fonts for non-latin languages
On a system without specific fonts installed, the characters were replaced by �
For Hebrew, the system sans-serif font (at least on Windows pc) was too small.
Rely on the unicode-range range CSS descriptor to load a font only for a
specific range of unicode code.
https://developer.mozilla.org/en-US/docs/Web/CSS/%40font-face/unicode-range
This way, the fonts are ignored for English text (and you don't have to load
the fonts of every possible language).
Add Noto fonts that covers many charsets.
There is an heavy version for many charset and lighter ones for Arabic and Hebrew
More ranges can be added later
Serve the fonts on our CDN to avoid shipping several MB of fonts for everyone
but lazyload it when needed.
Fixesodoo/odoo#32228Fixesodoo/odoo#21781
Dharmraj Jhala