| Age | Commit message (Collapse) | Author |
|---|
|
Before this commit:
When logged in and navigating on a frontend page, the accessible `ir.ui.menu`
would be loaded in qcontext.
Loading those menus performs alot of SQL request, up to ~2.000 requests on big
databases such as Odoo.com for an user with a lot of access rights.
This is not a problem on low traffic website as this is ORM cached, but when
there is a lot of traffic, the cache is clear very often, thus this code only
is adding a lot of requests for no reason most of the time as the user is just
navigating without any intention of opening the application menu.
Note that this qcontext computation in frontend was pointless in enterprise as
the applications menu in frontend redirect to the backend without using it.
This commit removes that computation from the qcontext. The menus will be
computed and loaded only when the user really needs it, when he is about to
open the application menu.
closes odoo/odoo#46127
X-original-commit: 471ddf85ce619961e46fb281bf721968ff298d3b
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
|
|
in this commit, throw the wizard to enter the new page name, while duplicating
page button and new duplicate page button added in the page properties dialog.
updated the test case related to duplicate page along with duplicate menu
consideration.
task-2088546
closes #40085
Co-authored-by: jpr-odoo <jpr@openerp.com>
|
|
Following things are done in this commit:
1. changed some labeling and string for more readable and helpful to the user
2. added extra width to the text box
3. added publish/unpublish option for mobile view.
4. track page option auto-activated for any new page,event,job offer,course,
blog.
task-2088546
closes #40085
Co-authored-by: jpr-odoo <jpr@openerp.com>
|
|
It is now possible to specify the forum mode : Questions and Answers or
Discussions. In Q&A mode, a user can only reply once while there is no
limit in Discussions mode.
task-2008910
closes odoo/odoo#34097
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
|
|
Close icon should now be put after the modal title in the DOM.
Completes commit https://github.com/odoo/odoo/commit/d9801c1abe06b4c20702c0e94c56eea6a3ed8327
|
|
The 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
|
|
Panels and wells were dropped and replaced by the "Card" component.
|
|
col-lg-* -> col-xl-*
col-md-* -> col-lg-*
col-sm-* -> col-md-*
col-xs-* -> col-*
col-lg-offset-* -> offset-xl-*
col-md-offset-* -> offset-lg-*
col-sm-offset-* -> offset-md-*
col-xs-offset-* -> offset-*
col-lg-pull-* -> order-xl-1
col-md-pull-* -> order-lg-1
col-sm-pull-* -> order-md-1
col-xs-pull-* -> order-1
col-lg-push-* -> order-xl-2
col-md-push-* -> order-lg-2
col-sm-push-* -> order-md-2
col-xs-push-* -> order-2
|
|
BS4 "btn-default" class was replaced with "btn-secondary", which makes
more sense.
|
|
Odoo made the bad choice of using the 'btn-sm' class for every button
instead of configuring the padding for default 'btn' to be smaller.
In BS4, the style of btn-sm is actually more complex, lowering the
font-size too. Also, btn-xs was removed so we would not have the
possibility to display smaller button than our default ones.
This commit removes btn-sm wherever it was used. Unfortunately, this
might remove it at some places where it made sense but this can be
restored in a second time.
|
|
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
|
|
* 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.
|
|
Opening a modal in Odoo should be done thanks to the 'Dialog' class. In
the frontend, there can also be modals which are meant to be shown to
the unconnected frontend visitors and those should then get the style of
the website (bootstrap) and not the one of odoo. To manage this, the
website JS code was extending the Dialog class so that it adds the
'o_website_modal' class on modals which are opened thanks to the class.
The LESS code was then in charge of forcing the Odoo style on those.
This behavior is not the right one. "Visitors" modals should also be
able to be opened with the Dialog class. This commit is a first step
towards to the right behavior:
- The standard 'Dialog' adds the 'o_technical_modal' class on its root
element by default and allows to not put it thanks to 'technical'
options.
- 'o_website_modal' is then replaced by 'o_technical_modal'.
What should be done next is:
- Use the Dialog class when it is possible
- Move modal.less in the common assets and make it style only technical
modals -> remove some forcing of the style on 'o_technical_modal' in
the frontend
This behavior also allows future improvements, like building a
completely different structure for technical modals which would allow
better designing and the end of visitor/technical bootstrap conflicts
(and so LESS efficiency).
|
|
|
|
* Adapt modals for new pages/product/... to leave some space for tour
tips on the right
* Remove the "click on add page" step which was the start of each tours
and leave it to be the last of the website tour
* Change position of some tips
* Remove step "click on parent button" in website tour as it is not
necessary anymore
* Remove the possibility to skip the frontend tours
|
|
|
|
* Remove dead code + optimization
* Use Dialog API from web module
* Reorganize files
* Correct buggy $() function for snippet option class
* Add comments
* Fix the snippet parent navigation :
If a page contained a three level snippet structure (i.e A contains
B contains C), when editing the following bug occured :
If B or C was selected first, parenting buttons were correctly set.
But if selecting A then C, clicking on the parent lead to going back
on A instead of going on B.
* Fix snippet thumbnail layout
* Better isolate ui css from themes
* MediaDialog image list : prevent displaying empty attachments
* ...
|
|
* Adapt DOM selectors
* Refactore dialog XMLs to have odoo styling
* New editor options (background-position, ...)
* Various improvements
|
|
|
|
|
|
In 7d40a7d, f820c07, 3ed0628 the way the mobile preview iframe is set
was altered several times. This left an inconsistent needless page load.
This page load was cancelled, but as a side effect in a given set of
conditions:
- an ajax request is done early in current (and so iframe) page,
- phantomjs is used for the test,
- server response time
this could lead to a false positive caused by a cancelled xhr request
throwing the error: "Can't load template, http status 0".
|
|
Code from delete_page has been spliited (functions, templates, ...)
to be re-usable by rename_page
Change default input type from website.prompt.
Old default value 'text' had no sense, there are no tag <text>.
|
|
Clear cache after delete view
Move menu to keep all 'New page', 'New blog', 'New forum', ... together
Disable continue button from popup while user don't confirm with checkbox
English typo
|
|
|
|
|
|
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes #1260
|
|
Render the top-menu (backend menu or frontend editbar) server-side.
Use Fontawesome icons (mail, timezone, chat).
Refactor website widgets, split Website.editorBarin editorbar, ace, editorbar- content, editorbarCustomize.
|
|
If the current view uses @groups attributes (possibly in called templates),
the corresponding elements are rendered to a void (empty string in qweb). If
said user can edit the page, does so and saves a view section in which there's
a @groups to which he has no access, the element[@groups] is completely
removed from the template once saved, losing it.
If QWeb encounters an @groups to which the current user has no right during
rendering, have it request a no-RTE page, so the user can not RTE-edit the
page (or drop snippets in it).
|
|
user save views
bzr revid: chm@openerp.com-20140220103355-0us8k76yrrodqs0u
|
|
bzr revid: chm@openerp.com-20140206145236-vwdq74yyz21qvyzu
|
|
bzr revid: al@openerp.com-20140128205017-47rxm2xbb84dmjas
|
|
bzr revid: fme@openerp.com-20140128161531-t0m0hqpk5u871rwg
|
|
bzr revid: fme@openerp.com-20140128154909-oau6aq702rw062gy
|
|
blog...)
bzr revid: chm@openerp.com-20140116180535-c736cuxn12qghiea
|
|
bzr revid: ddm@openerp.com-20131203100851-rjdhmgfrq3i4o1nx
|
|
bzr revid: ddm@openerp.com-20131129143058-oi6swnul3idr7ngp
|
|
bzr revid: chm@openerp.com-20131127161627-fwokmahwvp8jxhgl
|
|
already exists
# Through the menu
Rather than output a generic error (500 due to an IntegrityError),
return a templated 409 letting the user either visit the
page-which-already-exists-with-the-name-he'd-picked or open the page
creation dialog again for a second round.
An alternative would be to promote the website.prompt use to
full-blown dialog as a result of selecting "New Page" and handle the
"page already exists" case without even closing the dialog.
# Through the link dialog
Added an RPC call to check if a page already exists (essentially a
cheaper version of opening /page/whatever and checking whether it's a
200 over JSON-RPC), if the page matching the completion term already
exists, do *not* add the choice of creating the page, only provide
completions from existing pages.
bzr revid: xmo@openerp.com-20131126160148-wrk4zvz9istscwa0
|
|
bzr revid: chm@openerp.com-20131126094255-eawnxkj1cbso0x8m
|
|
bzr revid: fp@openerp.com-20131114212856-ff42xtka5dlv8c8c
|
|
bzr revid: ddm@openerp.com-20131114161740-ymggmzdwwyacz60f
|
|
Yeah ! You read me ! I (fme) wrote documentation !
Yeaaaaaaaaaaaaah !!!
bzr revid: fme@openerp.com-20131114093214-isjmwwbzsj3ahr61
|
|
TODO: website.prompt() should be finished for Add a blog post link
Added @id=editable_scripts_hook in layout template so modules can easly add *.editor.js files
bzr revid: fme@openerp.com-20131113171438-3l0wo08ta5vsulq3
|
|
bzr revid: chm@openerp.com-20131112180007-d9qqxcrrguo3y8ts
|
|
bzr revid: fp@openerp.com-20131109194306-h3d25wgbuvsk2fm2
|
|
bzr revid: fp@openerp.com-20131109185847-rrejtk6e0i77yln2
|
|
bzr revid: fp@openerp.com-20131109150613-scepw4gdw7my4s76
|
|
bzr revid: fp@openerp.com-20131109144350-34tyjox2q5r9lc35
|
|
Not working quite well
Working it out
bzr revid: fme@openerp.com-20131105151651-8jn1po2fhyojum2c
|
|
bzr revid: fme@openerp.com-20131105091117-hgzbnrxju3ftzmyx
|
