| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit, the `on_attach_callback` and `on_detach_callback`
callbacks are not called all the time on the `Dialog` widget when it's
attached/detached to the DOM. Relying on those callbacks could result in
unpredictable behaviours.
To be more precise, the `on_attach_callback` isn't executed on a regular
Dialog#open() call. But Dialog spawned by the ActionManager will execute
it.
This difference prevents from properly binding those callbacks later on
through an extend or include of the Dialog widget as we have no way to
know if they have already been called or not (e.g. which can result in
calling them twice).
This commit normalize this situation by ensuring that the
`on_attach_callback` and `on_detach_callback` callbacks are properly
called by the Dialog widget and allows any extension of this widget to
rely on them. Therefore the ActionManager is adapted accordingly.
opw-2438534
closes odoo/odoo#64780
Related: odoo/enterprise#15849
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Before this commit: all dialogs would go through the static method (OwlDialog.hide)
when destroyed, regardless of wether they had been opened or not.
Now, only dialogs having an 'el' property set (= having been opened) will use
the 'hide' method.
Task 2170705
closes odoo/odoo#43124
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
New Owl component: Dialog. It does not rely on Bootstrap but behaves the same
and does not conflict with legacy dialogs.
To call this component, you need to define it in the XML parent template instead
of calling it in the JS file, and put a flag in the parent state to toggle the dialog.
Old dialog file has also been slightly updated to ensure compatibility between both
versions.
This commit also updates a list view test which did not wait for click events to
properly trigger and would cause the new dialog system to crash.
|
|
Prior to this commit, there was no clean way to have a button
triggering asynchronous work (like asking user for confirmaton
for example) and close or not close the modal according to the
user choice. Your options were:
1. Swallow the pill and just accept that the modal will close
even if the user chose not to undertake the action.
2. Set the `close` parameter of the button to false and handle
the conditional closing by yourself from outside the dialog.
This commit introduces a way to tell the form view dialog that
the action has not been processed correctly and that the modal
should not be closed by returning a rejected promise. Prior
behavior can still be obtained (close no matter the result)
by having the handler not returning a promise at all.
closes odoo/odoo#33837
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Sometimes when using a form view in a modal (e.i.: in a gantt view), we might
want to have some button in the footer. We expect clicking on buttons to close
the dialog but nothing happens, since the webclient does not know that this is
a modal.
To do so, we provide the `close='1'` attribute on the button, in form view.
This will trigger the event closing the modal.
This is done with the benediction of aab-odoo
Task-2024216
closes odoo/odoo#36493
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
|
|
This commit adds two methods as hooks to customize the way Dialog deals
with its buttons :
* _setButtonsTo() : to render and set the buttons into a container
element;
* _setRemoveButtonOption() : to define the remove button and
set its destination zone (header, footer)
Task ID: 2038324
closes odoo/odoo#35474
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Dharmang Soni <dpr@odoo.com>
|
|
Added an option in the Dialog class to give it a function to run
when it's closed by other ways than by its buttons.
Its default value is the "cancel" callback if given, or none.
Before this commit, there was no way to add any callback to run
when the modal wasn't closed by a button.
Now, when exiting the modal by other means (e.g.: "Escape" key),
it will run a given callback.
|
|
|
|
Since https://github.com/odoo/odoo/commit/2ad49ec93e39ae5d59ccc17884408870e1c86c5e,
all dialogs were able to be closed by clicking on the backdrop which was
not a desired behavior.
Indeed, the 'backdrop' option of the BS component was misused.
closes odoo/odoo#35300
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Rev. ee44d23 fixed a usability issue: when a doAction is performed
from a dialog, it automatically closes the dialog (as the action is
rendered in the background, behind the dialog).
However, it also closes dialogs when the action has target='new',
i.e. when it also opens in a dialog, which is not strictly
necessary in this case.
This is problematic in mobile for the product configurator widget:
in the sale.order form view, the order_line field is displayed as a
kanban, and in its form view, the product_(template_)id field has
widget product_configurator. When a value is set, it performs a
doAction (target="new") to configure the product. The widget listens
to the dialog's 'closed' event to update itself. However, with what
is done in ee44d23, the x2many form dialog is closed by the DoAction,
so the flow doesn't work.
This rev. reverts the attempt done in ee44d23, and does something a
bit more brutal: as soon as an action is pushed in target 'current'
(in the main part of the interface), all dialogs are automatically
closed.
closes odoo/odoo#34678
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
Now we can display dialogs with or without header / footer / backdrop
and we can force the DOM to be put elsewhere than the body.
Part of https://github.com/odoo/odoo/pull/29353
task-1903256
|
|
|
|
|
|
On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes #32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
Since 12.0, some modal footer button order were changed. The primary button
would not be the one in the modal footer corner.
This is against bootstrap but more annoyingly, users are intuitively clicking
on the secondary button, ending up closing the modal and losing form
information they entered.
This commit simply fix the regression from 12.0 as before 12.0 these buttons
were positionned correctly.
Note that a commit in master (saas-12.2) will fix all the other ones that were
wrongly positionned before 12.0.
Step to reproduce:
- Go to an event having the possibility to register.
- Click on 'Register Now', a modal is shown to write details (name, email..)
- You intuitively click on 'Cancel' as it is the bottom right button
|________________________________ CONFIRM _ CANCEL _|
- The modal is closed, if you try to open it again your infos are lost
Closes #29884
task-1922120
|
|
Before this fix, sometimes dialogs that had the option shouldFocusButtons set on open
did not set the focus on the buttons. This is especially true for the "discard changes"
dialog where it is less usable with the keyboard.
After this fix, we wait for the widget to append itself to the dom before setting the focus.
|
|
Introduced by a105e5f2. Doc was ok, code wasn't. This feature is
for mobile only, and for now it is restricted to ViewDialogs.
|
|
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
With this commit, when we perform a close action, we can provide infos to
the `on_close` handler, so that it can handle different cases that caused
the close action.
|
|
https://github.com/odoo/odoo/commit/9de1bc0eef6f5bfaa2a8d745431caa361ae91548
- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
|
|
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
|
|
* test_main_flows
The style of a primary/link button is given by the
'btn-primary'/'btn-link' class. The old 'oe_highlight'/'oe_link'
class should still be supported in views but not rendered in the DOM.
|
|
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
|
|
This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.
The main changes are:
- there is no ViewManager anymore, its work is now handled by the
ActionManager itself, but isolated in a specific file ; this
eases a lot of things, as the breadcrumbs handling for example.
- the ActionManager code is converted to the new coding principles
and guidelines ; mainly, children widgets communicate with it by
triggering events up, and not by function calls anymore.
- the ActionManager layer is now testable, and a lot of tests have
already been written.
- the code in other addons has been adapted consequently.
What's coming next:
- introduce the 'AbstractAction' Widget, and make client actions
and view controllers inherit from it ; this widget will
implement a common API that could be used uniformly by the
ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
getTitle()...).
- move the ControlPanel handling from the ActionManager to the
AbstractAction.
|
|
- labelling and screen redesign (update labels, hide labels, hide fields, ...)
- make UI more mobile friendly (icon biggest, color using less variables,...)
- Page & Redirection menu are for visible only in debug mode
- Add meta noindex for website.page not shown in sitemap
- Add mechanism to be able to edit in backend a broken view
(Needed for - Internal Error 500, css, js file, ...)
- website pagemanager dedicated to website_publisher only
|
|
Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.
|
|
|
|
... sometimes.
When a dialog is destroyed, the last opened dialog (the one which
is just below), if any, is focused. This allows to close it
directly by pressing ESC. For an unknown reason, this was done in
a setTimeout (delay 0).
The problem is that the setTimeout made some JS tests fail
randomly, when a test ending by closing a dialog was executed
right before a test using a many2one inside a dialog. When this
happened, the second test failed sometimes because its dialog was
focused (because of the previous test) while waiting for the
autocomplete dropdown to open, triggering a blur event on the m2o
input, and thus making jquery autocomplete aborting the search,
and the opening of the dropdown.
|
|
The Odoo Dialog API already had the "confirm" helper to open a dialog
which shows two buttons: one to confirm and one to cancel. This commit
introduces the "safeConfirm" helper which requires two clicks to
effectively confirm.
Note: this will be used by the upcoming website update.
|
|
Opening a modal in Odoo should be done thanks to the 'Dialog' class. In
the frontend, there can also be modals which are meant to be shown to
the unconnected frontend visitors and those should then get the style of
the website (bootstrap) and not the one of odoo. To manage this, the
website JS code was extending the Dialog class so that it adds the
'o_website_modal' class on modals which are opened thanks to the class.
The LESS code was then in charge of forcing the Odoo style on those.
This behavior is not the right one. "Visitors" modals should also be
able to be opened with the Dialog class. This commit is a first step
towards to the right behavior:
- The standard 'Dialog' adds the 'o_technical_modal' class on its root
element by default and allows to not put it thanks to 'technical'
options.
- 'o_website_modal' is then replaced by 'o_technical_modal'.
What should be done next is:
- Use the Dialog class when it is possible
- Move modal.less in the common assets and make it style only technical
modals -> remove some forcing of the style on 'o_technical_modal' in
the frontend
This behavior also allows future improvements, like building a
completely different structure for technical modals which would allow
better designing and the end of visitor/technical bootstrap conflicts
(and so LESS efficiency).
|
|
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
|
|
Qweb rendering is great to render "complex" widget structures. However,
using it to render something as simple as a button was not very
meaningful. This commit deletes the "WidgetButton" template and replaces
it with an utility JS function to render buttons according to given
parameters.
Also, this change will allow a better change. Before this commit, the
only templates left in the "base_common.xml" file are the "WidgetButton"
and the "Dialog" ones. With the removal of "WidgetButton", the file can
now be lazy loaded only if necessary, on the first dialog instantiation.
This will allow to remove the need to load static XML files on each
frontend page loading.
|
|
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
|
