This commit fixes the size of an image being set with
a 0 when it was given using the 'size' option.
In legacy, when 0 was given to one of the parameters,
it was simply ignored and not set on the image. Since
the fields has been converted, it was set and the image
was not visible, because of an height/width equal to 0.
A test has been added to assert this behavior.
closesodoo/odoo#99613
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
The changes in `auth_password_policy` are largely the owlification of
the password meter widget:
- modernize the password policy module and convert it to an
odoo-module (note: now exports a pseudo-abstract class which is
really a policy, for the sake of somewhat sensibly typing
`recommendations`)
- replace the implementation of the Meter and PasswordField widgets by
owl versions
The changes to web and base stem from taking a look at converting the
ChangePassword wizard, and finding that it would be a pain in the ass
but also... unnecessary? It seems to have been done as a wizard
completely in javascript despite being backend-only for legacy
reasons: apparently one of the very old web clients (v5 or v6
probably) implemented it as a "native action" which was directly part
of the client's UI, and so it had to be implemented entirely in the
client.
Over time it was moved back into the regular UI (and moved around
quite a bit), hooked as a client action to maintain access to the
existing UI / dialog.
But since it's been an action opened via a button for years it can
just... be a normal wizard, with password fields, which
auth_password_policy can then set the widget of.
So did that:
- removed the old unnecessary JS, and its dedicated endpoint (which is
*not* used by portal, portal has its own endpoint)
- used check_identity for the "old password check"
- split out `change_password` with an internal bit so we can have a
safer (and logged) "set user password" without needing to provide
the old password, which is now used for the bulk password change
wizard as well
- added a small wizard which just takes a new password (and
confirmation), for safety a given change password wizard is only
accessible to their creator (also the wizard is restricted to
employees though technically it would probably be fine for portal
users as well)
Rather than extensive messy rewrite / monkeypatching (the original
wizard was 57 LOC, though also 22 LOC of template, the auth_policy
hooking / patching was 33, plus 8 lines of CSS),
`auth_password_policy` just sets the widget of the `new_password`
field in the new wizard, much as it did the bulk wizard.
Also improve the "hide meter if field is empty" feature by leveraging
`:placeholder-shown`. This requires setting a placeholder, and while
empty works fine in firefox, it doesn't work in chrome. So the
placeholder needs to be a single space. Still, seems better than
updating a fake attribute or manipulating a class for the sake of
trivial styling.
Notes on unlink + transient vacuum
Although the wizard object is only created when actually calling
`change_password`, and is deleted on success, it is possible for the
user to get an error and fail to continue (it should be unlikely
without overrides since the passwords are checked while creating /
saving but...).
While in that case the `new_password` in the database is not the
user's own, it could be their *future* password, or give evidence as
to their password-creation scheme, or some other signal useful to
attack that front of the user's life and behavior. As such, quickly
removing leftovers from the database (by setting a very low transient
lifetime) seems like a good idea.
This is compounded by the `check_identity` having a grace period of 10
minutes. 0.1 is 6 minutes, but because the cron runs every 10 the user
effectively has 6~10 minutes between the moment they create an
incorrect / incomplete version of the wizard and the moment where it
is destroyed if they just leave it.
closesodoo/odoo#99458
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Since https://github.com/odoo/odoo/pull/99503, o_xxl_form_view is
removed from the modal but there was still an useless overflow present.
Also we removed the `flex-flow: row nowrap;`,
as the flex direction is handle by the `form_compiler`
Note:
for a display: flex the default value for direction and wrap are:
```css
flex-direction: row;
flex-wrap: nowrap;
```
To reproduce:
- Add a bank account on accounting app
- Choose "create it" at the bottom of the modal
- The modal is broken
closesodoo/odoo#99677
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, these tests sometimes failed because the
autocomplete dropdown updated itself after a delay. These tests
patch it s.t. there's no delay in the tests. Something similar is
done in the Many2oneField test suite.
Example of impacted staging and nightly builds:
https://runbot.odoo.com/runbot/build/19121210https://runbot.odoo.com/runbot/build/18976006
This commit also removes unnecessary patches that set the delay of
the Autocomplete component to 0, but this has no impact as this
property doesn't exist (this was done in addition to a patch of
setTimeout which is enough anyway).
Closes#99781closesodoo/odoo#99788
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
This commit fixes the BooleanField which didn't
turned the row in edition when clicked on it since
the event was stopped by the Checkbox component.
The disabled input should not stop the event, since
the component do not need to handle a click being
done on it.
The test in editable list has been adapted to add
this assertion.
closesodoo/odoo#99759
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the "canCreate" option was not propagated this was leading
to a traceback with the autocomplete.
Indeed the option "No records" was never added because it was always
in a loading state.
closesodoo/odoo#99689
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
During the OWL refactoring, the "decoration-bf" and "decoration-it" were
not included in the standard decoration handling to convert them into
the default bootstrap classes. I.e. the previously applied commit:
https://github.com/odoo/odoo/pull/73210/commits/29390ccdc3447c3d1ef4da1d805e630d00402fbd
was not ported over to the updated OWL views/fields. Note that this
commit uses the BS5 classes of fw-bold and fst-italic and should not be
backported because of that.
Also added QUnit tests to handle these 2 decoration cases.
closesodoo/odoo#99698
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a form view with a notebook.
In the notebook a page has autofocus, and is also invisible in some
circumstances.
Before this commit, the default page was always displayed, even if invisible,
its anchor was not selected though.
After this commit:
- if the default page is visible, display it.
- if the default page is not visible, select the first visible page
- if the default page was visible and the page has changed, don't select the default page at next render
- if the default page was not visible and becomes visible, select it at next render
closesodoo/odoo#97742
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Observed Behaviour
When opening a pivot view with the catalan language activated
and grouping rows/cols by months, everything works fine. But if
we try to import this pivot view in a spreadsheet, all months
are converted to gener, which means 'January' in catalan
Expected Behaviour
When importing the pivot view in a spreadsheet, we should get
the correct date grouping
Reproducibility
This issue can be reproduced with the following steps
1. Activate the catalan language and set it
2. Got to Sales App
3. Select the pivot view
4. Group the rows/cols by order date > months
5. Try to import the pivot view in a spreadsheet
Fix Description
The issue was coming from the fact babel (the package
used to generate date as text in python) write the month as
'de gener', 'de febrer', 'de març', 'd'abril', while moment
(the lib used to handle date in JS) is looking for months as
'gener', 'febrer', ... (ie without "de" or "d'" prefix),
causing it not to recognize the date proposed by Babel. We then
added a preparse method to the catalan language, automatically
used by moment when present in the language definition.
Related Issues/PR
opw-2817041
closes odoo/odoo#99717
Forward-port-of: #90466
X-original-commit: e6addb809134b37e1c45ca7d80bc4532180e1845
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
This commit changes the style rules on grouped kanban records to apply
an outline on focus and a transparency effect when the progress bar
filter does not match the class of the record.
The rules on both kanban_column_progressbar files (legacy & new) have
also been wrapped in global kanban renderer classes to avoid styling
leaks.
closesodoo/odoo#99712
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the labels tags that were after the fields losses
their attributes (i.e. classes) after the compilation of the form view
arch.
Now, the attributes are correctly copied after the compilation.
closesodoo/odoo#99486
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When one tries to quick create a record in a kanban view column and a
rpc error occurs, a form view dialogs open. If the form view to
display in the dialog is a legacy view, save the record displayed in the
dialog make the kanban renderer receive a legacy datapoint with no resId
key, making impossible to add the appropriate record to the column.
We fix that.
closesodoo/odoo#99294
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Go to eLearning > Courses > Contents, group the kanban view by Course,
then quick create a record in a column. A form view dialogs opens. Save
the record: a crash occurs.
Root cause: the kanban view needs some record data that are not found
on the record created by the form view dialog but tries to add that
record directly to the column.
Solution: we create a totally new record with same resId and add that
new record to the column.
Part-of: odoo/odoo#99294
Before this commit, the form and list views didn't reload when an
action from the ActionMenu (formerly known as "toolbar") was
executed. For instance, go to Contacts (list) > select records >
Actions > Merge: the contacts are correctly merged, but the view
still shows the merged contacts.
Note: it worked well for "static" actions like Archive, Delete,
this fix only concerns "contextual" actions.
closesodoo/odoo#99680
Signed-off-by: Georis François (fge) <fge@odoo.com>
This commit introduces an helper that can be used in legacy tests,
when the tested flow opens a FormViewDialog (wowl). The helper
properly sets up the legacy environment to make the (wowl) dialog
service available, and spawns a MainComponentsContainer s.t. the
(wowl) dialog can open. This helper is already used by several grid
and timesheet_grid tests, and it might be useful in other cases
soon as we are currently removing the use of legacy FormViewDialog.
closesodoo/odoo#99582
Related: odoo/enterprise#31054
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to increase the responsiveness of the kanban
by rendering the view as soon as possible.
Before the kanban view when grouped does orm call to fetch the tooltips.
The rendering of the kanban view is waiting for this orm call.
Now tooltips orm call is done asynchronously and the kanban view
is re-rendered once the call returns.
task-2721035
closesodoo/odoo#97816
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Go to Project -> Reporting -> Timesheets and Planning Analysis and
select other measures in the pivot view via the "Measures" menu.
After that create a new favorite.
Result: the favorite is saved with the correct measures but the
pivot view will never use those measures. This is due to the presence
of the key "pivot_measures" in the action context.
(Note that the same problems occurs with other keys and other views)
We fix that problem by giving less precedence to keys in action contexts
with respect to those found in the search item contexts as it was
originaly the case in legacy views (cfr. __get method in action_model.js).
opw-2945969
closesodoo/odoo#99631
X-original-commit: 4528f562923cd0524f257f3a9c1ecd0002fd49b7
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Name of the test
"utils > dates > parse smart date input"
- Before this commit
The test makes a comparison between the result of parse utils,
which yields luxon's DateTime objects in the user's local TZ
(patched by default to UTC+1 in the testing env), and locally
created DateTime objects in UTC.
This has no sense to compare a date in UTC with another in UTC+1.
The test was thus failing when ran between 11pm and 0am.
- After this commit
The test has been refactored.
Also, even if it has no impact on the parsing result, the local function
parseSmartDateInput now use a DateTime object in local TZ.
This has been done in order to avoid future confusion.
If you're wondering why it has no impact, it is because this function is
used in parseDate(Time), which always sets the local TZ at the end:
```
const a = {
foo: luxon.DateTime.local(),
bar: luxon.DateTime.utc(),
};
a.foo.equals(a.bar.setZone("default")); // true
```
closesodoo/odoo#99616
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the "+" icon was displayed in kanban columns
even if the attribute "quick_create" was set to false in the arch.
With this commit, we correctly takes that attribute into account.
closesodoo/odoo#99626
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In kanban arch, one can set the attribute "on_create" on the root
node to an action xmlid. In this case, when the user clicks on
"Create", the action is executed. When this action is in target
new, it opens a dialog (typically to create a record...). Before
this commit, we didn't reload the kanban after closing the dialog.
As a consequence, the newly created record wasn't displayed. For
instance, it was the case in the Recruitement dashboard.
closesodoo/odoo#99589
Signed-off-by: Géry Debongnie <ged@odoo.com>
Go to a (OWL) list view with sample data, click "Create" to open a (OWL)
form view and go back to the list view using the breacrumbs: the sample
data has disappeared.
This is due to the fact that the form view set useSampleModel=false in
the globalState when it is left while it does not use at all sample data
mode.
Here we make it simply pass the value that it received initially.
closesodoo/odoo#99587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
One can edit the color of a tag in a Many2ManyTags field only in form view.
This commit refactors that field so that the standard field Component doesn't allow for it,
and conversely implements a specialization of the field that can, and should be
selected by the form view.
closesodoo/odoo#99499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
- Install Inventory
- Open any product
- Switch to RTL language
- Edit the product
- Try to translate field "Internal Note"
Issue:
Button is not displayed correctly (nearly hidden).
Issue also present with wysiwyg or codeview editors.
Cause:
Applying style `right: 5px` to the button without taking into account
if layout direction.
Solution:
On translate button:
- Apply direction left for side-space if RTL, else right.
- If wysiwyg is enabled, add it after the buttons in the sidebar.
opw-2962790
closesodoo/odoo#99567
X-original-commit: 56f620ff65ca9c1e5d9a64f5280ea16fd469c87d
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This commit fixes the StateSelection field, which
displayed the wrong value on hover. In legacy, the title
attribute was set to display that value. Now, it has been
replaced by a tooltip, since it can be used with touch
and is more convenient to use. A test has been modified
to assert the presence of the data-tooltip attribute.
closesodoo/odoo#99561
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps to reproduce:
- Go to reconciliation models
- Click on Line with Bank Fees
- Click on a x2many line
-> The popup is missing some padding
closesodoo/odoo#99539
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The "beforeExecuteAction" of view buttons in the form view is set to
automatically save, so that when the user clicks a button which wil
change their current view, we ask them if they want to save their
changes.
In the case of the discard button, we don't want to ask the user if
they want to save their changes, but we don't want to save either. This
commit fixes that.
closesodoo/odoo#99530
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before, the input of the daterange field exceeded the size of its
parent, which caused an overflow and thus a visual bug in the form
and kanban view.
Now the daterange field is displayed as expected.
Step to reproduce the bug:
- Event > Quick create : the daterange is overflowing the parent
- Event > Create : the daterange is not displayed as expected
task-2967165
closesodoo/odoo#99495
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
The `daterangepicker` was in version 3.0.5, since then the library is
now in version 3.1.
This version introduce a new feature that allows to automatically
(depending on the space left) position the picker above or below
the HTML element it's attached.
This commit updates the library but also take advantage of this update:
Before when clicking on a daterange field, even if there was no space
left below, the picker was still displayed below the field.
Now, the picker is displayed above the field if there is less space
below the field
Part-of: odoo/odoo#99495
Have a many2one in an editable list view. Type something in the input and click
on "Create and edit".
Confirm the record creation in the modal.
Before this commit, the input of the field disappears.
After this commit, the input stays.
closesodoo/odoo#99480
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Time comparison can always be slightly random (this is why this test
is a nightly one). The 20% margin left by the 12 ratio is not enough
in all cases. This test was sometime breaking with a
12.944994188420822 not less than or equal to 12
This is one of the max value found by quickly checking the builds.
A ratio of 14 should be hopefully enough.
closesodoo/odoo#99156
X-original-commit: cc86b80342d38913f7af79474c41f8764c8b2dd2
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit improves cards and toggles designs and part of the overall
v16 SCSS optimization/restyle, task-2704984.
The default values of the cards wasn't consistant with the rest of odoo
(ie. default background color value was grey instead of the BS default
which is white) and to avoid these inconsistencies, the card classes
were not used (even though we do have card-like visual elements).
Before this commit, if we wanted to use them, we had to add utility
classes all over the place (ie. the 'bg-white' class) which is not
optimal.
This commit also simplifies toggle's visual rendering by removing
unnecessary graphical elements that were not readable in regular & small
font-size,
In some case the toggle design was even irrelevant with the content and
required unnecessary overrides in css to hide it (ie. it's ok in
Recruitment but not in Payroll).
task-2924487
closesodoo/odoo#98770
Related: odoo/enterprise#29829
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
With this commit, we use the new (owl) FormViewDialog instead of
the legacy one in the "View Metadata" debug item.
closesodoo/odoo#99532
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since commit fbfc0dc63c that reworked the scss of the KanbanView,
the favorite icon in dashboards was no longer aligned with the
text (for instance, in the Project dashboard). This commit fixes
the issue.
closesodoo/odoo#99503
Related: odoo/enterprise#31033
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
In form views, we want the fields displayed in the "oe_title" div
to take full width. It worked before because we have a rule in
webclient that applies on all almost all kinds of inputs (text,
number,phone...). However, since we wrap fields in a div, those
rules no longer have the wanted effect in our particular usecase.
This commit is a heuristic, but it should solve most of the cases.
It applies on all char fields displayed as title.
Part-of: odoo/odoo#99503
This class is added automatically on large screens, to better
style the form view to benefit form the available space. However,
the width of dialogs is limited, so it makes no sense to apply
this classname in this case. If we do, those form views may display
an horizontal scrollbar. For instance: in project with worksheets
enabled, create and edit a worksheet many2one.
Part-of: odoo/odoo#99503
Before this commit, if the user multi-edited a field in a list
view, and the widget on that field was legacy, this widget was
displayed in edition in the confirmation dialog. This was because
the "mode" argument wasn't correctly computed in the legacy
compatibility layer. This fix comes with no test as this layer
will be removed in the next week or two.
Part-of: odoo/odoo#99503
Since the fields were rewritten in owl, they all have a width of 100% by
default, which is what we want when displaying a field on their own.
In some places, fields are used as part of a longer block of content (eg
unit of measure behind a number). In those cases, we want to display the
field inline, which requires the addition of the oe_inline class in the
arch.
There was also a missing piece of css for the monetary field, as the
previous rule no longer applied because of the slight changes to the DOM
structure.
closesodoo/odoo#99529
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984
- Converts dropdown into "nav ul li" structure.
- Removing of '.o_burger_menu_user'
- Removing of '.o_burger_menu_app'
- Removing of '.o_menu_sections'
- Removing of '.o_burger_menu_section'
- Some 't-key' not necessary anymore (thx to OWL2)
task-2812594
Part-of: odoo/odoo#88073
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Before this commit, the `/web/static/tests/views/helpers.js` was only
imported in the "desktop" qunit test suite but unavalaible for the
mobile one.
This commit adds it in the `web.test_assets` bundle to be available in
all tests suites.
closesodoo/odoo#99498
X-original-commit: 2875f43da28d01f837c1ee53f8cadd21e169b612
Related: odoo/enterprise#31029
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, `BooleanToggleField` and `BooleanField` are 2
distincts components. However, they are some attributes in common.
Also, there is an inconsistency between the both components, in the
boolean field, a `onChange` method is defined but not in the other one.
This commit changes the `BooleanToggleField`, this one will inherit to
`BooleanField` to have the attributes in common and override the ones
which are different. Also, the `onChange` method will exist in the
both components.
closesodoo/odoo#99492
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before in BS4, the table used the `$table-head-color` SCSS variable to
color the header of table. This variable doesn't exist anymore on BS5.
In the commit of the BS5's merge, we have replaced the old value by
a value calculated with the color contrast in the case of the list view
it wasn't the right fix, so in this commit we restore the original value
like it was before the merge of BS5.
Note:
In BS4 branch the result is `#212529`:
```scss
$o-gray-900: #212529 !default;
$o-main-headings-color: $o-gray-900 !default;
$table-head-color: $o-main-headings-color !default;
.o_list_view .o_list_table thead {
color: $table-head-color;
}
```
In BS5 branch the result is `#00000`:
```scss
.o_list_view .o_list_table thead {
color: color-contrast(opaque($body-bg, $light));
}
```
closesodoo/odoo#99488
Related: odoo/enterprise#31026
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Connect in your browser to a db on runbot with mail installed and wait
until the runbot put to sleep the db. After a while, a new request to
get im_status will be sent and nginx responds to it with an error 404
and an invalid JSON response. A traceback with a particularly bad
message is then shown. Here we improve the traceback message.
closesodoo/odoo#99430
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
luvi