The BS4 tempusdominus lib has 2 issues within Odoo: 1. On wrong string formating (eg typing "33"), the lib would trigger its own error "datetimepicker.error" that would be catch in our crash manager making it display a modal error. This is generally handled by catching that event and preventing it to bubble to the crash manager, see: Datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/widgets/date_picker.js#L128 OWL datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/components/datepicker.js#L43 Snippets options: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web_editor/static/src/js/editor/snippets.options.js#L1646 2. If there is a valid date, and an user enter an unvalid date, the lib crashed by throwing `Cannot read property 'format' of undefined'`. Datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/widgets/date_picker.js#L94 (fbbfa6ddca and 5481c429efb) OWL datepicker widget: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web/static/src/js/components/datepicker.js#L149 Snippets options: https://github.com/odoo/odoo/blame/00b61c752e2cf514fdfb291ee36344e5af3b04dc/addons/web_editor/static/src/js/editor/snippets.options.js#L1617 Note that the issue was reported at https://github.com/tempusdominus/bootstrap-4/issues/223 Those errors can be seen for instance in Page Properties dialog (publish date field) and in the form builder snippet if you add a date(time) field. task-2335403 closes odoo/odoo#60514 Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
*bus,mail This commit extracts the common basis of the env to use both in the frontend and the backend. The public env now contains most of the features that were previously (only) in the webclient env. Moreover, the PublicRoot no longer uses the ServiceProviderMixin, such that services are only deployed once, in the (public) env. Owl components can now be defined in the website, and rely on a properly built env. Legacy widgets still works as they access services through the PublicRoot (via trigger_up) which redirects those requests to the env.
*: web Before this commit, when a widget declared assets to lazy load through the assetLibs key, the asset was loaded through a context-less call to the server through the base `rpc` function. This caused problems in website: the website ID was not given to the called route and the loaded assets were then stripped of their specific-website parts. This commit solves the problem by allowing the `loadLibs` and `loadAsset` functions to receive an extra argument: an extra `context` to use for the actual call to the server. The method is now available in the ajax service, so that website can add its custom context automatically, the same way it does it for normal `_rpc` calls. Part of https://github.com/odoo/odoo/pull/44596 closes odoo/odoo#44596 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The handling of unhandledrejection in the frontend was done with dedicated code since the crashmanager was not in the frontend. This is the case now so that dedicated code became useless. closes odoo/odoo#42927 Signed-off-by: fja-odoo <fja-odoo@users.noreply.github.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. closes odoo/odoo#32465 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Following of https://github.com/odoo/odoo/pull/28457. Promises which are rejected are acting the same way as exceptions and thus have to be catched. The Odoo `guardedCatch` method is not stopping the exception though. In the backend, unhandled promise rejections are catched by the CatchManager, which then ignore them. This commit makes the frontend act the same way regarding unhandled promise rejections. We might want to share the crash manager behavior someday. Part of https://github.com/odoo/odoo/pull/31664 closes odoo/odoo#31664 Signed-off-by: Quentin Smetz (qsm) <qsm@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>
* web, website_blog, website_sale, website_twitter Before this PR, all website widgets were named 'Animation'. Now that they are 'Public Widgets', we can at last stop using the confusing 'animation' name. Part of https://github.com/odoo/odoo/pull/29442 task-1932066
* portal, sale, web, website_blog, website_crm_partner_assign, website_forum, website_event_track, website_links, website_mail, website_slides, website_mail_channel, website_mass_mailing, website_sale, website_sale_comparison, website_sale_delivery, website_sale_wishlist The `editableMode` option and its related options in public widget should only be part of website, this commit moves them there. This is also the occasion to implement something that is long overdue: stop creating 'animations' / public widgets in edit mode by default. Indeed, lots of 'animations' were defined by beginning with 'if not edit mode'. Now, if a public widget should be considered in edit mode, it must be defined explicitely through a property at *definition* of the widget. Part of https://github.com/odoo/odoo/pull/29442 task-1932066