The portal view for tasks previously listed all task of all projects
without grouping them. It was a problem, mainly when we want to make
the distinction on project label_tasks, to make the difference
between tasks, issues, ... Grouping task by project by default allows
to show the label_tasks before each project.
Grouping the tasks removes the possibility to define a primary
ordering. We want to be able to ungroup the tasks in some cases.
The implentation was done in the portalsearch bar adding
a group by option. The portal proposes two grouping options,
project (by default) and none (to keep strict ordering).
Task: #1827950
PR #23769
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
60c920d4a should solve duplication of chatter when editing the website.
But portal module doesn't depends on website, so eg. on a instance with
just helpdesk (and no website) we would not see the chatter on the
frontend.
This fix reverts 60c920d4a and adds another solution not depending on
website.
opw-1813792
closes#23614
Before this commit:
The style of the Optional labels in portal's form was written in website_sale
module.
Problem is portal can be installed without website_sale.
- Install website module
- Go to /my/account
- Every labels are in bold as if they were mandatory
Now:
Portal's optional label's style is in portal module.
* set height for draw signature when user want to accept order to avoid
various display issues;
* fix name input not being displayed as error if trying to sign with a
void partner name;
* no more show 'Accept & Sign' button if customer signed document;
* update message string for success message after signature;
* add an option to specify the signature button label and use it in
sale customer portal;
* improve return of signature route to return more specific error
messages;
This commit contains squashed code from @rop-odoo .
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
Indeed this lib is used either in frontend and backend. Portal modules
uses it in frontend (sale to sign orders in customer portal). eSign
uses it in backend. Let us therefore put it in common assets.
This generic widget allow to confirm and sign documents on the customer
portal. Purpose is to reuse it in sale customer portal and online quotes
notably. It is made generic to call a route using parameters given to the
widget. It also supports access token to ease its use in various customer
portal pages where the customer is not always connected but is granted
access through an access token.
Original commit e38de9dfa4 is about CSS classes and state code
update. It is not clear why hiding Your Details in some cases improve the
state code update. Forward port 017ee5eab3 broke the customer portal
display using this condition. This commit fixes the customer portal by
removing the condition.
Second part of the original fix that was about using a correct base layout
to render the your details page is already done in master since the
customer portal cleaning.
Two things happen in this commit
* move portal less from web to portal. This code has been wrongly
moved to web when moving the customer portal and should be in
portal module;
* merge customer portal generic less and customer portal chatter
specific less into the same file;
We should now have only one less file for customer portal less and
located in the right addon.
* mass_mailing, payment, point_of_sale, portal, survey, web, web_tour,
website_blog, website_crm_partner_assign, website_event,
website_event_questions, website_form, website_forum, website_gengo,
website_hr_recruitment, website_links, website_mail,
website_mail_channel, website_mass_mailing, website_quote,
website_sale, website_sale_options, website_slides, website_twitter
This commit reviews the whole "JS side" of the web_editor and website
apps. This is a first step to be able to improve them with new and
better functionnalities; this commit is not supposed to change any
visual behavior.
The main goal was to achieve a structure similar to the backend one.
Now, the frontend side also has a root widget (like the WebClient)
and all other widgets are attached to it one way or another. This allows
the benefits of using the 'trigger_up' functionnality for example.
As RPC are now mainly done with the `this._rpc` functionnality (being
possible thanks to the parent hierarchy), the frontend will also be
possible to test thanks to QUnit in a future update (besides the "text"
editor side which still requires a refactoring to be able to do that).
---
Here are some of the changes:
(-) conventions and documentation
The code has been updated to follow JS conventions and a lot of code has
been commented (around +2000 lines of comment). This also means that
lots of functions have been renamed to use camelCase or simply to make
their name understandable.
See https://github.com/odoo/odoo/wiki/Javascript-coding-guidelines.
(-) deprecated: web_editor.base
The "web_editor.base" module has been split and does not force the
modules which require it to wait for DOM ready anymore. This was indeed
slowing loading times, but also prevented to use some modules in some
contexts (see the LESS editor use in web_studio which is the subject of
another task).
Now the "editor context" can be got thanks to the "web_editor.context"
JS module with its "get" function.
The "web_editor.base" module should probably not be used anymore (see
its code and recent updates).
(-) new: web.dom_ready
If a JS module should wait for the DOM to be ready to be executed, a
new JS module has been created: "web.dom_ready". This should always
be used in a module which only want to instantiate stuff. Do not
extend (or worst, include) classes after DOM ready.
(-) website.website
The "website.website" module has been split. "website.website" does not
return anything useful anymore, it just initialize some miscellaneous
stuff, without waiting for the DOM to be ready. You might want to check
"website.utils", "website.content.compatibility" or `WebsiteRoot`. Also
`website.form` has been deleted (use `this._rpc`), so has been
`website.error`. `website.prompt` will be removed in a future update to
be replaced by `Dialog.prompt`.
(-) widgets are great
Many classes which were not widgets are now widgets. This allows them to
use the 'events', the 'xmlDependencies' and the 'this._rpc' features for
example. Here are some of the main ones:
- Snippet options: these were classes with a `$el` for the menu element
and `$target` for the customized element. This is still the case
but following standard `Widget` structure (one exception: using
`this.$(...)` searches in the `$target` as before this update).
- Snippet animations: instead of class instances with a `$target`
element which can be `start` and `stop`, these are now standard
widgets which can be `start` and `destroy`. `this.$target` is
an alias to `this.$el` for ease of compatibility.
- Snippet editors: instead of class instances in charge of an editor
overlay, these are now widgets. Each "child" snippet editor is
properly attached as a "child", which allows editors to communicate
and to be properly destroyed.
(-) root widgets and website navbar
The frontend is different of the backend. In the backend, the page has
an empty <body/> element and all the components are instantiated from
parent to children (i.e. the `WebClient` is instantiated and is in
charge of instantiating the `ControlPanel`, etc). The frontend cannot
work like that on page loadings as they are way more frequent than in
the backend and we do not want them to flicker. A frontend page is
loaded as a <body/> element which already contains the website navbar
and its menus and the whole content page. JS code has to be "attached"
to these existing elements. This is possible thanks to the `RootWidget`
instances and the specialized `WebsiteRoot`, `IframeRoot` and
`WebsiteNavbar` (see code for details).
(-) lazy loading
No more (or at least a lot less) XML/JS has to be loaded on page
loading, thanks to the use of the `Widget.xmlDependencies` feature.
XML which have to be lazy loaded is loaded only on related Widget
instantiation if necessary, which allows to execute a lot of JS code
before the DOM is ready and to start many widgets on DOM ready (not
later). A visual benefit of this is clicking on the 'edit' button as
soon as it is possible: before this commit, this was sometimes not
doing anything as event handlers were not binded yet.
Still a possible exception: loading the session and locales. This may
be asynchronous stuff which is still required before widget
instantiations but this will be the subject of another task.
(-) deprecated code and code location
More than reviewing code and organizing it, many apparent dead code was
removed. More importantly, mislocated code was put in the right app.
This is the case for snippet animations which is a concept for website
apps but was defined in the web_editor app, or some translation concepts
which were part of website but should have been part of web_editor.
---
There are probably more things to say about this commit but I will let
the comments speak for those.
This commit moves the whole customer portal to the portal module.
It now completely uses portal and http_routing features and is not
dependent on website anymore.
An override of web controller is added in portal in order to redirect
portal users to /my instead of /web. That way once having the customer
portal installed all share users are correctly redirected to their
account.
All modules defining customer portal templates and controllers are
updated accordingly.
As customer portal will be moved to portal module support of pager
has to be moved previously to the various portal moves. This commit
moves the pager code and template to portal.
Compatibility using website-based pager is provided to avoid having
to update all website addons currently. Future commits will make
addons use the portal pager instead of website pager.
This module adds required base code for a fully integrated customer
portal. It contains the base controller class and base templates.
Business addons will add their specific templates and controllers
to extend the customer portal.
This module contains most code coming from odoo v10 website_portal.
Purpose of this module is to allow the display of a customer portal
without having a dependency towards website edition and customization
capabilities.
Some CSS files used in frontend assets are already moved to have a
working portal skeleton. A is_public method on users is also added
as it will be used in various portal code soon.
All portal features were moved into base
and website_portal, portal module is obsolete.
This commit remove its code, and modify the modules
dependencies accordingly. website_portal now depends
on auth_signup.
The goal is to prepare the removal of
'portal' module.
- demo portal user is moved into base
- 'is_portal' field on res.group too
- remaining security rule are moved to base too
- mail template is moved to website_portal
Remove all backend menuitems related to portal, as the supported portal
mecanism is now throught the website_portal My Account page.
Original authors: Vipul Bhatt, Florian Wintjens
- replace the portal_sale blue ribbon by a website_portal_sale link from the portal home
- remove all fields and methods related to banner in portal_sale
- remove "validation" field in payment_acquirer since it was only used here
qsm-odoo