Due to a wrong order of operations, after splitting an anchor (press
ENTER), the range was setting on the first anchor. Now it sets on the
second one (as the code - but not the tests - suggests was supposed to
happen). Tests were adapted to reflect that change.
In tests, after splitting the anchor, `Wysiwyg.getValue` didn't always
properly clean up `data-original-title`. Targetting empty
`data-original-title` attribute instead of `aria-describedby` attribute
should fix that issue.
closesodoo/odoo#30923
This fixes issues with CTRL+A then delete.
Now CTRL+A selects all the contents of the unbreakable node in
which the range is contained. Deleting it all will replace the contents
with `<p><br></p>` so the user can start editing afresh.
Note: Only CTRL+A is handled: ``select all`` in contextual and edit
menus are still handled by the browser.
closesodoo/odoo#30648
The refactoring also had to be done in order to create a set of unit
tests.
Each behavior can be tested, including the behaviors performed as a
consequence of keyboard interactions (for instance: Enter, Tab...).
This commit also contains some changes to test_utils that were
necessary given the new structure of the wysiwyg editor.
Co-authored-by: Gorash <chm@odoo.com>
The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
removeSrcAttribute should avoid these rpc, but for some
unknown reasons, on firefox it works but not with chrome.
Because the purpose of the test is to check the url and
not the content, that works to use an existing route.
Courtesy of @kangol for the fix
Fix over this one: https://github.com/odoo/odoo/commit/cae188514fa8b0a7c785a630ac4aff677b2071fa
The intent was to disable buttons in form views until html fields are fully loaded,
but it was not disabling the buttons for the following reasons:
1. It is looking for buttons in the DOM, although they
are not already attached into the body at this moment.
2. It was disabling the buttons only at widget start(),
so only once after "Empty Cache and Hard Reload".
We propose a better solution than disabling the buttons in the control panel:
when we click on "Save", the html field ensures that it is fully loaded while commiting the changes.
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
The translate feature of widgets html and html_frame had been
broken by the new views refactoring. This commit restores it for
the html widget, and removes it completely for html_frame as it
wasn't working correctly before the new views anyway (moreover,
it had already been disabled for mass_mailing: de403dc1ab).
This commit also ensures that the changes are correctly saved for
the html_frame widget. Note that this widget still needs to be
converted to our new coding guidelines.
If the method commitChange from the widget FieldTextHtmlSimple was
called in mode=readonly, a traceback was displayed. This is not very
common, because most save operations are done in mode=edit, but it can
happen in readonly mode: when the user clicks on an action button, then
the form view is saved, if necessary.
To reproduce this bug, just open a form view for res.users, and click on
the Change Password button.
The field widget html wasn't implemented yet in the new views. A
very basic implementation was done in addon web. It only handled
the readonly mode so that the field were displayed in studio.
This commit removes this basic implementation from web, and re-
introduced the old one, converted, in addon web_editor.
- use 'nodeOptions' instead of 'options' in FieldTextHTML as
'options' doesn't exist, it has been renamed into nodeOptions
in AbstractField.
- mock iframe route in test to prevent the test framework from
displaying an error (unimplemented route), and so the test from
being red.
- test that the url given in the node options is correctly used.
- remove useless and broken code introduced by last rebase.
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
Antoine Guenet