| Age | Commit message (Collapse) | Author |
|---|
|
Purpose
=======
User tests have been made by the Product Owners team. It showed that the planners are not used by new users on Odoo due to several reasons (They are too static, too heavy to use,...)
Specification
=============
Remove the module and its different applications. The onboarding on the business flow will be improvement in the weeks to come.
|
|
remove double cross
close #19731
|
|
Although a dark 'border-bottom' is necessary in some occasions (to add
contrast between the page's content and the navbar itself), the other
borders were totally unnecessary.
Moreover, having a complete border causes complications to calculate the
sidebar height and to manage buttons' size and line-height.
This fix will keep the border-bottom only, removing the other ones.
Compensation rules ("- 2px") are no longer necessary.
|
|
* Share code between website and backend
* Do not do a [100ms - 500ms] RPC on each app change in the backend
but do it only if the planner is asked to be opened
* Use the Dialog class so that the planner is not broken
* Simplify/optimize code, use standard conventions, lint files, ...
|
|
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
|
|
|
|
* Convert some CSS to LESS
* Split/Join LESS files
* Remove duplicates between website and web_editor
* UI improvements
* Allow simple customizations thanks to LESS var&mixins for website
|
|
The web planner should be hidden by default. Now, it is displayed,
then hidden in js after a while (but it can be seen by the user), then
displayed again if necessary
|
|
Merge appswitcher navbar and app navbar.
Merge planner menu and user menu.
|
|
Credits go to qsm for the fix.
|
|
* As the animations were already defined in web_planner, they are now moved in web (animations.less)
|
|
|
|
|
|
|
|
|
|
Also correctly left align the menu when there is a multi line item and
vertical-align all the elements of the header so that it does not look
broken when there is a multi line title.
|
|
fp's request
|
|
fp's request
|
|
fp's request
|
|
lle's request
|
|
With selectors here and there to make it work with the community
webclient, the enterprise webclient and the website without duplicating
the module.
|
|
* Correct inheritance of async method
* Correct calls to do_hide/show
* Fetch the template in `willStart`
* Correct bootstrap structure for the layout, remove useless branding
and dom depth
* Each planner page is now in its own bootstrap grid
* Compatibility between both webclients
|
|
This introduces a new way to define web_planners. They now take the
following form:
<template id="project_planner">
<t t-call="web_planner.pages">
<t t-call="web_planner.category">
<t t-set="menu_categorytitle" t-value="'Prepare'"/>
<t t-set="menu_categoryclasses" t-value="'fa-flag-checkered'"/>
<t t-call="web_planner.page">
<t t-set="page_title" t-value="'Welcome'"/>
<t t-set="hide_mark_as_done" t-value="True"/>
<t t-set="hide_from_menu" t-value="True"/>
<!-- content here -->
</t>
</t>
</template>
The menu is not manually created anymore, it is automatically generated.
Pages do not have to be part of a category and can just be defined as
children of web_planner.pages. A page can have hide_mark_as_done and
hide_from_menu, these are optional and will both default to False when
omitted.
|
|
|
|
- clean the planner style
- add specific class per planner crm (avoiding collisions)
- create .o_planner_white_box class used in all planners
- add planner for project module
|
|
This commit impact crm, website, website_sale and web_planner modules because it
- add planner for website and website_sale
- improve planner notebook by setting texterea and input size to 100% and using col-md-* class
- split js code into common part (used in backend and frontend) and backend part (only for backend)
- adapt some tour, since every page will have the planner modal in its DOM, the tour selectors msut be more accurate
- introduce some style fixes and adaptations
- ...
|
