Previously, customizing the website footer was not very easy. This
commit will allow users to customize the footer like any other
snippet area.
There are several behavior changes, as mentioned below:
- Removed toggles 'Automatic Footer' and 'Payment Icons' from the
Customize menu
- Language Selector was moved near the 'Copyright' section of the footer
and features a dropdown (dropup technically) to select the language
- Moved some footer links from various modules to top menu
List of the added menus / changed menus:
(a) Resellers (new menu for previous footer link 'Resellers')
(b) References (new menu for previous footer link 'Our References')
(c) Forums (renamed from 'Forum', as a replacement of 'Forums'
footer link, showing all the forums instead of 'Help', as there
is no link available to all forums after this commit)
(d) Live Support (new menu for previous footer link
'Livechat Support')
(e) Mailing Lists (new menu for previous footer link 'Mailing List')
(f) Members (new menu for previous footer link 'Members')
- Links which were already available as a website menus (Presentations,
Jobs, Events, News, Documentation, etc) are simply removed
Technical Notes:
- Introduced a new template called 'brand_promotion' in website.
This will help to avoid adding redundant footer content (like
copyright, language selector etc) from several modules (website_sale,
website_event, website_quote, etc) while the only intention is to
replace module page links.
- Removed summernote related fix in portal.less (caused by xpath)
because footer is now customizable and added padding to structure
instead of footer itself so that bg-color/img can be applied on
whole footer.
- Few of the tours are improved to drag and drop snippets at proper
places and not inside the footer.
- Used Flex in copyright portion of footer, so that text will always be
horizontally centered (Some themes have different padding for buttons,
etc, so if we don't align text dynamically, it has to be managed in
particular theme and in particular layouts like full-screen / boxed.
And if someone changes height of this portion, we have to re-design
this portion again, etc).
task-38069
Closes https://github.com/odoo/odoo/pull/22298
Co-authored-by: Dharmraj <dja@odoo.com>
Currently, if user does not have enough karma to perform specific action on
forum, alert-box with appropriate message is displayed to the user.
There are several issues with these alert-boxes, like :
- Click on same CTA multiple times, creates multiple alerts
- Click on another CTAs keeps previous alerts on the screen, and adds
further alerts, which sometimes overlaps adjacent CTA and looks ugly.
After this commit :
- Alerts are displayed below their related CTAs
- Only one alert appears at a time on the screen
Fixes : #23071
PR : #23800
Task# : 1829835
This commit closes#23071
This commit closes#23800
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Before this commit, badge, user,... was available when a forum is archived.
Now we display a msg to explain to the user that the forum has been archived.
Related to task-33955
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Before this commit, all tooltip users was showing website and parent_name from
the Main company and not the current focsed partner.
This commits closes#18430
@kangol: fwd-port company_name
[FIX] *: do not use groups when extending an asset bundle
Using groups when declaring an extension of an asset bundle leads to a
different generated asset bundle according to the user's group. This
is not something we want because a dynamic asset bundle's content
means that it could (and it does) trigger unwanted cache invalidation.
website_event, website_blog, website_forum and website_sale add
functions to . These functions are bound to
server side qweb nodes protected by groups. We can always add the
functions; if a user tries to use the routes he should receive a
traceback because of lack of access rules
website_blog adds a module, but is guarded by
the presence of a node in the DOM. We use the same logic to guard the
module added by website_sale with the node.
website_gengo is working as expected.
Purpose
=======
The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.
A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.
Specification
=============
Make the atttribute name required
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
* 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.
Since the previous commit, the `color_field` needs to be explicitly stated
in the options for the tags to be colored.
The previous behaviour (always read the field `color`) was leading to server
warnings if the field was not present on the comodel.
Thìs commit set the `color_field´ for every many2many_tags on fields that have
a `color` field on the comodel.
In the new implementation, the type is checked to prevent loading
a view type that does not exist.
In the old implementation, the type was ignored resulting in a graph view.
So, before this commit, some views were no longer loaded.
The 'pivot' type should not be used since there is a dedicated pivot
view.
Karma is now displayed on preference view. Also,
add a empty group to allow other module to set their
preference parameters on this form view.
Little big details are important !
Christophe Simonis