The idea is to warn user if he created a special file (website.page with
supported extension) and he wants to change the file's name, which will at the
end also change the key).
If this special file has been t-called elsewhere, they t-call wont work anymore
This is why warning user is needed.
Note that this is different than the already existing page_search_dependencies
that is just checking if the URL is present in menus, templates, blog or pages.
This is about checking if the key is present somewhere. (we assume that if the
key is present, it is surely about a t-call.
Technically, the flow is:
1. Get supported extension
2. Get key dependencies
3. Check if user modify name
4. If name changed and it is/was a supported extension (special file) and it
has dependencies (surely t-call) then warn user these call wont work anymore
--
search_page_dependencies is also improved by returning links to be clickable
(on delete dialog eg) and splitting template/page results.
it also refactor dependencies warning that was creating HTML in javascript into
using XML template
Before this commit, error thrown by scripts injected in DOM won't return a
clean error on window.onerror.
It would open the crash_manager's show_error's dialog that wouldn't display
any informations except "Script Error." and "Traceback:".
This is because of browser's security reason: it will just give you a
'Script error.' as message and nothing else for security issue.
Now, this kind of error will show a clearer message informing that it is
probably originating from a Javascript file served from a different origin.
There is now also the possibility for developers to handle/override the
behavior when this kind of error is catch to prevent the dialog to open for
example.
Might be of use:
https://blog.sentry.io/2016/05/17/what-is-script-error.htmlhttps://stackoverflow.com/a/7778424https://danlimerick.wordpress.com/2014/01/18/how-to-catch-javascript-errors-with-window-onerror-even-on-chrome-and-firefox/ (Search for Script Error)
- labelling and screen redesign (update labels, hide labels, hide fields, ...)
- make UI more mobile friendly (icon biggest, color using less variables,...)
- Page & Redirection menu are for visible only in debug mode
- Add meta noindex for website.page not shown in sitemap
- Add mechanism to be able to edit in backend a broken view
(Needed for - Internal Error 500, css, js file, ...)
- website pagemanager dedicated to website_publisher only
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.
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).
* Set the blocking warning if the user enters a 'Client ID' without
any 'Tracking ID'.
* 'Google Analytics in Dashboard' field is visible only if
'Google Analytics' is checked in website settings.
* Get/Set the value of 'google_analytics_key' and
'google_management_client_id' from 'website' model instead of
'ir.config_parameter' on 'Google Analytics' wizard.
* If ID is set on 'Google Analytics' wizard then activated the related
features and populate fields in website settings.
This commit merge the two website menu items in order to ease user flow
inside Odoo. When clicking on the Website item a server action is called
that decides to redirect the user either to the dashboard if the user is
an admin or a website publisher, either to the website for other people.
Overriding this method allows to define a specific behavior. Future commit
will also redirect sales people to the website dashboard.
Dashboard itself is customized to add a header used to display a website
button. It will be used in future commits to add other new stuff to the
dashboard.
Specification
=============
- no boxes around fields
- use regular form style for input fields
- don't split page/URL into two fields, just do one URL field, with autocomplete
- Add alpha, beta, gamma, delta and epsilon color in color selection because they are used in mass mailing and themes also.
- Add a selection option with label "L" inside circle for link.
- Add Color selector for choosing button color
- Remov select2 page selector and used jquery autocomplete on same input
- Fix issue of page search in ir.http
When on a page event for example, when the user choose "Edit menu",
a modal is first opened to ask which menu to edit (the top menu or
the event menu ?).
This feature was broken with a web_editor refactoring. Indeed, the
dialog was converted to use the standard dialog class but the
widget was still inserted in the DOM thanks to "appendTo" instead of
the modal built-in "open" method, preventing it to be properly opened.
The dashboard must be visible for non-'group system' users, hence
the sudo call + only display the link to modify the client id
if the user has sufficient access rights.
Small visual correction for live users counter in the dashboard.
The Website Admin dashboard displays graphs for sales, analytics,etc.
using a (somewhat easily) extensible js framework.
Unfortunately, this framework is ACL unaware, meaning that it will
completely and silently crash if you are missing any of the required
access rights.
To solve this, extensions must now specify not just a graph name
but a necessary group for it and set the value for this group in
the extension of the backend controller.
This commit also
- make the icon visible for the group 'Website Designer and Editor'
(not juste the Settings group, which is extremely restrictive)
- make the button to set the Google API key only visible to people
with sufficient access rights
* display all lines and don't display the scroll bar into ace editor
* lazy read ace lib and add missing lib file
* use not minified version of ace lib
* Move ace lib from website to web
* Added ace widget for webclient
* XML mode for view text box
* Python mode for server action text box
* Removed web_ace_editor.xml, instead added template in base.xml itself
* Added widget=ace_editor in compute field of ir.model.fields
Now, when clicking on a menu item while being in edit mode, a modal
opens asking if we want to go to that page, edit that page, edit the
menu or do nothing (it only allowed to edit the menu item before).
The welcome message was using the mt/mb classes to add some space on
top and bottom of it. This is fine when the background-color of the
website is white, but this is not the case with every theme.
To fix the problem, add padding in LESS instead. Also move the inline
style in LESS to prevent theme extension problems.
The code for page creation from menu edition dialog was there but
invisible to the user because of a wrong qweb template inheritance.
Indeed, the edit menu dialog relies on an extension of the link dialog
template. But this one is extended in-place in another location and
that extension is not considered when the second extension is made
because a t-extend always use the base template. The only solution to
achieve the same result is to copy the edit menu dialog qweb extension
in Javascript.
Note: the feature was still available from the link dialog in page
edition though because this was not concerned by the wrong qweb
extension.
However, adding a page by this way would create multiple pages because
one was created each time a page name was entered (and not only on
save !). So typing "test", then changing its mind and typing "hello",
then rechanging to "test", then hitting the save button created the
"test, "test-1", "test-2" and "hello" pages.
This fix takes advantage of an already present parameter which can
determine if a new page should be created or not. However, a code
refactoring should be done in master for these classes.
* 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
* ...
* make CSRF protection the default on all non-SAFE methods
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get the
CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before hashing/validating
the CSRF token
* opt-out database manager from CSRF: The super-admin password serves
the purpose of a CSRF token in the database manager screens.
There is no request database to obtain the
secret and generate a CSRF token.
For some strange reason, two CSS rules had different priorities between
firefox and chrome (which forced chrome to always display published and
unpublished at the same time).
The chosen solution is to change the value of the button in published/
unpublished instead of toggling and relying on CSS classes (with this
method, the DOM looks better too).
There was also duplicated code in website for assets_backend.
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".
Force fa size to 14px, to avoid that themes which change body size,
change the fa snippet icon size and display it on severals lines.
Add text 'Snippets are loading' while snippets template is downloading.
rde