Since frontend to backend commit [1], links having `enable_editor=1` to
enable edit mode were not working anymore in certain cases.
Case 1 [OK]*:
From frontend, click on `enable_editor=1` link without `/@/` in it.
Case 2 [OK]:
From frontend, click on `enable_editor=1` link with `/@/` in it.
Case 3 [KO]*:
From backend, click on `enable_editor=1` link without `/@/` in it.
Case 4 [KO]:
From backend, click on `enable_editor=1` link with `/@/` in it.
This commit fixes case 4 and adds a test for all cases, while leaving
case 3 commented as it will be fixed later with a larger fix related to
URL change listener.
* Note that we will probably change the behavior for case 1 and 3: if
the version with /@/ + enable_editor=1 enters edit mode properly in
both frontend and backend contexts (case 2 and 4), it's probably not
worth having code to support case 1 and 3.
The issue for case 4 was that it was trying to load the whole Odoo app
inside of website preview iframe instead of making the parent window
load that URL.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#96054
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
It may happen than the routing map is cleared while rendering a qweb
view. For example, if an asset bundle is regenerated, the previous one
is unlinked, which causes a cache clearing.
Previously-generated EndPoint objects aren't found any more in the new
routing map, so `request.endpoint` cannot be used any more after a cache
clearing.
This commit adds hash and comparison magic methods on http.EndPoint so
that EndPoint objects created by a previous routing map generation can
still be used after a cache clearing.
Two tests were added: one to test the comparison and hash methods, and
the other to test them in a real-case rendering.
Commit 80a04f7ebed fixed this bug too, but introduced another issue
which caused many OPW, so it was quickly reverted by deb23450f18 along
with its performance improvement 33167b3928c. This commit replaces
80a04f7ebed with another way to fix the issue.
A third test has been added in order to avoid reintroducing this other
issue.
By the way, this commit also removes the EndPoint.arguments attribute,
as commit 17f1992698 removed all usages of this attribute in Odoo 9.0,
but left this initialization here.
OPW-2834546
OPW-2834549
OPW-2834625
X-original-commit: bdc45422f5c715782b147eecda2403386ba7eb4a
Part-of: odoo/odoo#91034
Commit [1] introduced an automatic start of edit mode when
selecting a theme but didn't take into account wether the frontend lang
of the user was matching that of the website that is supposed to enter
in edit mode.
Steps to reproduce:
- Create an empty database and install website.
- Add an extra lang on website (e.g FR) and visit the website in that
lang.
- Go in settings an create a new website, skiper the configurator,
select a theme.
- Redirect is with enable_editor but nothing happens.
The editor isn't started if not in the source's lang.
This commit redirect the user to the default_lang of the website
so that editor can always be started. It also introduces a tour
to test out the flow.
[1]: https://github.com/odoo/odoo/commit/f474eac4543712ae5b1c7d614f9eff9367445107
task-2687416
closesodoo/odoo#85058
X-original-commit: 02e08af7278cd66d768fe6a4f23aa17eb816be3c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.
Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
"Pages and Features"
With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.
[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf
task-2687416
closesodoo/odoo#84810
X-original-commit: a0f8fdc65566fafe98dab21f5c2dbab9505c3d5c
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
A while back, the behavior of this setting was changed from a
related field to a computed as a fix to various issues with: cb9f48d
The setting's value synchronization with what is displayed on the
setting's page is broken, since its behavior changed with commit:
2ccc735 . It resets to its default value for the default website when
editing a secondary one and is not only confusing but breaks the
setting in some scenarios.
When changing the auth_signup_uninvited setting, the changes
are correctly reflected and not reset to default upon changing
the website we are currently editing.
task-2612686
closesodoo/odoo#76538
X-original-commit: 6e7a0664850ccbc30a7a8a3ced22f05347bc6f9e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit searched terms were the ones entered by the end-user.
After this commit if the searched term is not found then the search is
performed on a resembling term.
The similarity is obtained from a Levenshtein distance combined with
ratios of common and different letters.
By default the dictionary against which the search term is matched is
based on the content of the search fields containing a word that starts
with the first letter of the search term.
If the `pg_trgm` Postgresql extension is installed the dictionary is
built from matches using the `<%%` operator (similar to the
`word_similarity` function).
Several approaches were benchmarked during development, those results
are available through the task record.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
Based on their path, we retrieve snippets assets, assuming that it will
be in the form : /snippets/{snippet_id}/{version}.{scss|js}
Then we check the template definition uses that version, or if any views
or html fields contains a snippet with such version exist.
If not, the asset is deactivated.
For that, we are looking for the data-snippet attribute in snippets
already dropped. For the template definition, we look at the first class
definition if a data version attribute is also defined.
task-2212216
closesodoo/odoo#73005
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
*: crm_iap_lead_website, website_crm, website_form_project,
website_hr_recruitment, website_sale
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
As `standalone` tests were introduced in 14.0 (see 0453566a76), this commit
adds tests to ensure the `inherit_id` of COW views are correctly updated on
module updates.
This test could not be rewritten in a regular test and merged in 12.0 as module
operation in tests try to be avoided (see 5e7e7b00b7d).
See #64446 for more information about the original fix.
closesodoo/odoo#66096
X-original-commit: 9d2787b1dc1485ed132ca51d2b2a4c85b8c77d0c
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Previously, when removing all the content of a snippet, that snippet
would get automatically deleted. This was not the case for parallax
snippets because we previously intended the user to drop the parallax
snippet, empty it, and drop other content inside of it.
Recently, we added the parallax option on all snippets, rendering the
previous workflow obsolete. There is now no longer any reason to keep
empty parallax snippets. This commit fixes that.
task-2446008
closesodoo/odoo#65551
X-original-commit: 61f410b57f1c28bd6464b86d1582c22b7fd846d5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Some apps, once installed, automatically create a menuitem in website.
What complexify the UI and create useless menu withtout plusvalue.
It is not because you install livechat to make support online, that you want
a link in your menu to show stats e.g.
Now we remove the default menu created, and help user to find it when he create
a link. The autocomplete suggest most of the main App's controllers
task-2189613
closesodoo/odoo#49081
Related: odoo/enterprise#9733
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This will ensure the performances stay correct for a blank page (no layout),
a standard page and a homepage (which has its own controller).
Related to #47257
task-2211013
X-original-commit: 08e01b5fc4a71b8f7639a953137fbb546ddf3b3e
Missing / wrong indented code during rewrite of binary controller:
https://github.com/odoo/odoo/commit/7d85ab1#diff-1407a8ce197a04eefaefa26c127a4418L343-L348
In case you have:
<record id="s_cover_default_image" model="theme.ir.attachment">
<field name="key">website.s_cover_default_image</field>
<field name="url">/web/image/theme_treehouse.bg_img_15</field>
</record>
theme_treehouse.bg_img_15 will be not found in /web addons.
So we need a 301 redirect too.
opw-live
How to reproduce:
odoo.com/trial > Website > Install theme Clean
Drop first snippet > background is 404
closesodoo/odoo#40605
X-original-commit: b8ce93e4eb397e1b7a0e1d408d61d2f283223fb9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When you try to create two users with the same login, the shown error message is
the Postgresql integrity error instead of a nice (translated) validation error.
This happens since bf88f3e which changed the way error messages are translated.
The reason is the manually created unique index `res_users_login_key_unique_website_index`.
The error handling and translation mechanisms don't know it exists.
The index was created for performance reasons in commit b5a12b4 where the
original python constraint was replaced with this custom SQL index.
In this commit, the python constraint is re-introduced to remove the index hack,
but the implementation now uses a single SQL query, which should be quite fast.
closesodoo/odoo#38737
X-original-commit: 817a811ec98b0c313b12e6464b5e98ca432cb3fc
Signed-off-by: Christophe Simonis <chs@odoo.com>
With this commit it is now possible to change the lang displayed in the URL.
Eg, you could use `/fr` instead of `/fr_BE`, or even a fancier `/french`.
Task-32838
Courtesy of pla@odoo.comclosesodoo/odoo#35135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit adds the website_visitor model that will be used
to track website visitor activity (page viewed, number of visits and
more general info about the visitor (country, lang, etc..)
This model will, in later commit, be used to send chat requests
and push notification from the operators (or backend users)
directly to the visitor.
- A website_visitor is created once the visitor is requesting
a website.page that is tracked.
- A website_visitor is considered as connected if his last tracked
website_page request is within the last 5 minutes.
- The number of visits for a website_visitor is incremented
if his last tracked website_page request was at least 8 hours ago.
- A website_visitor is only handled by the system. Users cannot
create, edit or delete a website_visitor.
- A unique website_visitor is created per website.
That means that the same real person can triggers multiple visitor
creation if visits multiple websites.
This is because, for livechat purpose on later commit, for example,
the chat request can be created on the correct livecaht channel
(linked to the correct website)
- The visitor is recognized via his cookie (visitor_id). So if the visitor
flush his cookies, a new visitor will be created the next time he will
request a tracked website_page.
- Link user's res.partner to website.visitor.
If a website_visitor log in
(a visitor that has visitor_id in his cookie),
the website_visitor is linked to the res.partner.
The website visitor name is than adapted to match the name of
the first res.partner linked to the visitor.
A visitor can have multiple partners as the same session
can be used by multiple person (one PC for a team for example).
To keep a detailed history of the visitor page views,
we add a website.visitor.page model that makes the link
between visitor and website.page but that keeps the visit date.
So that we can see if a visitor went mulitple times
on the same page and when. It's usefull to see his last page views.
Task ID : 2028059
PR #34624
Before this commit, when we want to make an external url, we need to know
if the record is related to a specific website or not, and choose base_url
or website domain.
Now each model have a fonction get_base_url (public to be callable from email
template, ...) and website override this function to add the website domain if
the record is website specific.
closesodoo/odoo#34089
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Previously the image that we uploaded as a favicon of the website was not
resized, so it could be extremely excessive in size and resolution, and it also
was not guaranteed to be a square.
Now we always resize it appropriately and save it as an ICO file.
The default favicon is now applied to all websites instead of only the first.
task-1958000
PR: #31811
Before this commit, the website selection was not working when a scheme or port
was encoded in the domain field. This was not obvious or natural for the user,
because the easiest way to fill it was to copy/paste the URL from the browser.
Now it works when scheme or port are encoded, it is even strongly recommended to
actually encode them if they don't take a default value because they will be
used when creating full URL to the website (typically when sending emails to
clients where a link back is necessary).
PR: #30000
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
Refactoring of qweb to call _post_processing_att for each nodes. This
change remove the crappy ovewrite in website module. The website overwrite
only the _post_processing_att to add the cdn parameters.
The static node (without t- attributes) can stay static (remove overwrite
of _is_static_node), the cdn is applied at the compile time for this
nodes instead of at the running time like the dynamic node.
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.
Move URLCase back out of the test module, otherwise loadTestFromModule
attempts to load it in the usual manner (~URLCase('runTest')). Which does not
work at all, because that's not what URLCase is for.
URLCase extends TestCase to benefit from the TestCase.run infrastructure
(running tests, filling result object, etc...)
bzr revid: xmo@openerp.com-20140217151535-alq7pq6qapski73x
Romain Derie