Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
* crm, project, website, website_event, website_blog, website_forum,
website_sale
Eg: the tour 'shop_buy_product' is extended by the website_sale_options
addons to add a step to close a modal.
The current solution was requiring the module that defines the tour
to extend, then add/remove steps in the "step" key of the tour
definition.
Some of the problems with this method were:
* The "register" method calls the "update" method to immediately
search for tip to place once registered (as register may be called
after the DOM is ready). So extensions of tours were happening after
the tours were started (and the tours were not restarted).
* The addition/removal of steps was happening after they were filtered
according to the "edition" key.
To allow extension, the system is changed as follow:
* The "register" method now only saves the steps and options without
modifying them and does not call the "update" method.
* Once the DOM was ready, the tour service started listening to DOM
mutations and called the "update" tour method. Now, this "update" call
is replaced by a "_register_all" call, on DOM ready and at the end of
the current call stack (which makes sure all modules are loaded). This
"_register_all" method marks the registered tours as ready after having
filtered the steps according to the "edition" key and initialized the
current step to trigger.
* Also, tours can now define a "wait_for" option which allow them to
be marked as ready for run and update after the given deferred. Those
tours can now also be extended without having to wait for the deferred.
PhamtomJS must wait for the "ready" key to be true to run the tour.
Google made the use of an API key mandatory to use the "Google Static
Maps API". The API key field will be created for the upcoming version.
opw-686510
As of June 22 2016, the use of API key is required to access the
following:
- Google Maps JavaScript API
- Google Static Maps API
- Google Street View Image API
https://developers.google.com/maps/pricing-and-plans/standard-plan-2016-update
For domains accessing the API before June 22, it will still work without
an API key. Since Google advises to use the API key, we hide the Maps if
no API key is defined.
better patch for rev e9b649b555
* also fixes website_event which present the same issue (depends
on a function that slugs)
* raise an exception when slug is called with wrong arguments
instead of returning None (which was unclear)
* before calling slug in a function where we got a depends, check
that the record is actually created
Since saas-3, website controllers use `request.website.render`
to render the template of a web page. This was kept for retro
compatibility. It's time to stop using deprecated stuff.
Same for `_render` method on website.
'json' route don't use `request.render` since
`JsonRequest` has no `render` method.
On website/theme installation and other website_* module installation,
an action was triggered to launch tours. These tours are now used only
for tests and should not be used as onboarding anymore.
Note: in master these tours will be removed to use the new test system.
Jeremy Kersten