summaryrefslogtreecommitdiff
path: root/addons/web/static/tests/fields/basic_fields_mobile_tests.js
AgeCommit message (Collapse)Author
2021-02-02[FIX] web: Not hide daterange if scrolling on mobile + unit testNasreddin (bon)
Issue - Install "Field Service" app - Create new task - Try to select Planned start/end date and valid Daterange picker is hiding when trying to scroll down to valid selection. Cause The daterange picker is closed when ev.target is not inside the picker, however ev.target always return the document element. Solution Do not hide daterange picker on scrolling if on mobile. Note : It will only apply if scrolling on the daterange picker and will still hide if scrolling outside this last one. opw-2428099 closes odoo/odoo#65423 X-original-commit: fb01006342c6d6fd902e13a5f4c2642c87fe452d Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
2020-02-13[FIX] sms, web: phone widget with sms tested in right moduleLucas Perais (lpe)
Before this commit, the behavior of the phone widget was tested in web as if it was always altered with module SMS Giving wrong test results when sms module was not installed After this commit, the separation is clearer, and the phone widget's behavior is tested according to the modules it is altered by closes odoo/odoo#45271 X-original-commit: 2e337516468797dd898c79c9669b5a90c83b56a7 Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
2020-01-27[IMP] web: field phone widget deals with SMS by defaultLucas Perais (lpe)
Task 2123526 Before this task, the phone widget on char fields was not displaying the send sms button by default After this task, the default behavior of the phone widget is to display the send sms button
2019-03-06[REF] web: adapt code after jQuery updateVincent Schippefilt
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>
2018-12-07[REF] web: move ControlPanel inside controllers/actionsGéry Debongnie
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>
2018-11-19[REF] *: update js test suite to use helpersGéry Debongnie
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.
2018-08-22[FIX] web, website: fix tests giving 404 errorXavierDo
-Some tests where moved without addapting the path to them: path is now update and tests fixed. -A picture was removed in commit 4dce6cc98b2b95a00249ac29245305e08f288e6c but still referenced in template website_twitter_snippet. -A test was missing a data leading to the wrong path to image beeing loaded
2018-08-20[IMP] web: mobile: add swipe support in form viewsVandan Shah
This rev. allows to navigate, in mobile, through records in form views by swiping. We also moved mobile-specific tests involving a form view to the mobile test suite, since those tests became async because of the lazy loading of the swipe lib (in the mobile suite, that lib is already loaded). Related to task #34727 Co-authored-by: Mohammed Shekha <msh@openerp.com>