- Differentiate between the Community and Enterprise editions
in the version number. By adding this attribute on the global
odoo JS object in the web client bootstrap controller /web,
we can differentiate between versions easily on the client
side without extra RPC calls.
- Remove a couple of version-related RPC calls in case
the global version info is present in the JS environment
- Update "About" panel to display the edition info
- This commit also reverts 07fe5afc87
which implemented the idea in a more limited way.
Closes#9625
A PlannerDialog does not extend Dialog for historical and graphical
reasons. Thus sometime a logic in Dialog is missed in a PlannerDialog
whilst it is useful.
In this instance, when doing an action from the planner which destroyed
it, the modal backdrop was not removed by bootstrap. Bootstrap does this
when the modal 'hide' function is called.
opw-653734
Help has been moved to web_planner, but only in backend. The comportement needs to be defined in website also so it is now shared in frontend and backend (mixin in common)
* 'Help' has now its own dropdown, directly accessible in the systray, instead of being hidden in the Administrator dropdown
* 'About' has been moved there also
* We can access the planner through this dropdown, even if the planner is hidden (complete)
This method generates many queries on:
- `ir.module.module`, to known whether a given module is installed;
- `ir.actions.act_window`, to know whether a given action exists.
Add a cache for both cases. The number of queries is reduced by 90%.
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
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.
* listing of modules in website already bypassed session user
* altered authenticated endpoint so it does the same
* sudoed a few read accesses & name_get in groups
* other accesses are list/form views, menu only accessible to
system_user
* new-API-ified some calls & unified listing of installed modules
* 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.
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
- 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
- ...
- Make planner accessible only for erp manager and admin. Portal and employee are not concerned by planners
- Clicking on link redirect to module installation form if module not installed
- Add 'is_module_installed' method to display note if module is (not) installed
Planner is like web Tips : a data in a module.
- Rename planner.planner to web.planner
- Rename files according to guidelines
- Remove planner_crm module
- Make CRM depends on web_planner, and add its planner as crm data
- Remove duplicate less style
- Add 'active' boolean field on planner (to disabled them), and create planner backend views
Damien Bouvy