In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
As steps are encapsuled in an arrow function from
69a5d8e3ce47238 for steps tour definition to avoid
direct Markup(_t()) interpretation, the same is done
for registerWebsitePreviewTour() of
"odoo/addons/website/static/src/js/tours/tour_utils.js"
in this commit.
This is done in anticipation of the use of
_t() (import from @web/core/l10n/translation) with
registerWebsitePreviewTour().
task-3292454
closesodoo/odoo#130248
Related: odoo/design-themes#678
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
*: test_website, website_blog, website_crm, website_hr_recruitment,
website_mass_mailing, website_sale, website_sale_wishlist,
website_slides
This commit creates a new util which clicks on edit and waits for the
edit mode to be started. This way, we make sure that the edit mode is
enabled before testing the next step of the test. This avoids race
conditions during tests.
This commit replaces all the uses of the old util with the new one, it
also removes the steps that are waiting for the edit mode to start.
Finally, from [this other commit], we can start a tour in edit mode. For
these tests (which have `edition: true`), it is useless to check if the
edit mode has started at the beginning of the test because this check is
already done by default. This commit removes unnecessary / duplicated
steps.
[this other commit]: https://github.com/odoo/odoo/commit/99b50d18e220aedf14de806f4bf1b2d35c32de35#diff-c7720501ec33f5f92c907d8bb41de50edd832a4564317073e801a6915796a6bdR278
task-3203820
closesodoo/odoo#120481
X-original-commit: https://github.com/odoo/odoo/commit/9fd5d25f59578abc9c608578a7d2e2953880b582
Related: odoo/design-themes#656
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume-gdi <gdi@odoo.com>
Making a test post_install using @tagged should always remove the
at_install tag.
The main reason for that is that runbot split config select if an
at_install or post_install tests should be executed is using negation:
`--test-tags -post_install`. The reason for that is that giving a positive tag will
replace the "standard" tag and non standard tag could be executed if
giving `--test-tags at_install` (without negation)
Since runbot tests in parallel builds, one of them using
`--test-tags -post_install` and the other `--test-tags -at_install`,
a test that is both post install and at install wont be executed at all.
Also, a tests with both tags will be executed twice
in a normal flow, usually not intended.
The correct way to make a test post_install is to use
@tagged('post_install', '-at_install')
closesodoo/odoo#118969
X-original-commit: d1db306b212d4abb5b2faab9e56c8e83b85c53b9
Related: odoo/enterprise#39966
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
*: website_crm, website_form_project, website_hr_recruitment,
website_mass_mailing, website_sale
Prior to this commit, modules that add elements (fields, references,
etc.) to the website_form registry, would do so inside the
`website.assets_editor` bundle.
It creates a module dependency error since [1] + [2]:
The form options (`s_website_form/options.js`) defined in
`website.assets_wysiwyg` requires the registry defined in
`website.assets_editor`. But since [1] and [2], the
`website.assets_wysiwyg` bundle is loaded inside the iframe without
`website.assets_editor`, as only `website.assets_wysiwyg` is needed to
properly display and interact with the editor. (Although, most of the
bundle is not necessary and a later IMP will either only load the CSS
needed or split the bundle).
This commit moves the modules that creates the registry as well as
modules that extend it to the `website.assets_wysiwyg` bundle, fixing
the dependency error. Though they are not required inside the iframe,
the bundle can now be loaded without the need of assets_editor,
removing the missing dependencies. But mainly, this should have been the
case since the introduction of website.assets_wysiwyg at [3] anyway: we
want to lazy load everything that is editor related. Although it was [4]
which mixed the form editor files between the `website.assets_editor`
and `website.assets_wysiwyg` bundles.
[1]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[2]: https://github.com/odoo/odoo/commit/a154ee7ad6fd3ebdd38943e1439badae11c3151d
[3]: https://github.com/odoo/enterprise/commit/19a144d6af2974e964c6487170e6bca1b14d3898
[4]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0declosesodoo/odoo#110811
Related: odoo/enterprise#36195
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
request.geoip is no more a dictionnary cached in the session. It is now
a full blown object with lazy and smart geolocalisation capabilities.
Among other things, the previous dictionnary API is now deprecated. The
changes are:
* `request.geoip['country_name']` -> `request.geoip.country_name`
* `request.geoip['country_code']` -> `request.geoip.country_code`
* `request.geoip['city']` -> `request.geoip.city.name`
* `request.geoip['latitude']` -> `request.geoip.location.latitude`
* `request.geoip['longitude']` -> `request.geoip.location.longitude`
* `request.geoip['region']` -> `(request.geoip.subdivisions[0].iso_code if request.geoip.subdivisions else None)`
* `request.geoip['time_zone']` -> `request.geoip.location.time_zone`
It is safe to access all the attributes. Doing `request.geoip.city.name`
when the geolocalization failed (missing db, invalid address, ...)
evaluates to None. It does not raise an AttributeError.
Task: 2848206
Part-of: odoo/odoo#91337
In large database with lot of user, the browser don't respond.
closesodoo/odoo#106640
X-original-commit: 0f597b3a9c4110d2984000c21564cc95e61491c4
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Follow-up of [1].
With [2], the contact us page was made entirely static to ease and allow
more things in its customization. The customize_show option of the
website_crm app which added the possibility to switch between sending
emails or creating opportunities was to be removed to rather be done via
the standard edit-mode option, by clicking on the form itself. Part of
this option view was however kept (the auto-fill of some more values)...
but it was not supposed to be kept as a customize_show view. With this,
a customize_show option with the same name "Contact Form (Opportunity)"
still appeared and gave the illusion that this is the way to make the
form create opportunities instead of sending emails. In master with [3],
the customize_show was removed but refactored to appear in the editor
panel.
After this commit, we remove the editor panel option that was converted
by mistake.
We also re-enable the view automatically via the 16.0 migration scripts.
[1]: https://github.com/odoo/odoo/pull/69888#discussion_r921081562
[2]: https://github.com/odoo/odoo/commit/417138b44311a05aa206b6e2e38bb67863843c74
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
Related to task-2462993
closesodoo/odoo#96145
X-original-commit: 8620c3bc71183b5ebd7801c139eab1736070d846
Related: odoo/upgrade#3690
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
*: website_crm, website_crm_partner_assign, website_customer,
website_forum, website_hr_recruitment, website_membership,
website_slides, website_slides_forum
This commit adapts "customize show" options from several website modules
by creating new options available in edit mode.
See merge commit for more information.
task-2710582
* im_livechat, test_event_full, website_blog, website_crm,
website_event, website_event_track, website_event_track_quiz,
webite_livechat, website_sale
There is 6 main changes in this commit:
1. Using raw SQL Upsert instead of the ORM methods. While raw SQL should
generally be avoided, it makes sense for such a low level behavior which
is impacting every flows.
Indeed, tracking visitors is a generic behavior done on all pages and
controllers. It is important to optimize it to reduce processing time
and SQL Queries.
Benchmark of that change alone:
> Rendering a tracked page improves from ~19.5ms to ~17ms (using `ab`
with 1000 loop) and the requests involved in the tracking process are
reduced from 8 SQL Queries to 3:
- 1 request to upsert the visitor
- 1 request to fetch the visitor data
- 1 request to add the tracking record
2. Adding in that upsert query the `visitor.track` insert, creating both
records in one go, bringing the query count from 3 to 2.
3. Refactoring of the `parent_id` behavior that was introduced in stable
with [1]. The purpose was to keep track of multiple visitor linked to a
same user to merge the tracking together. Especially useful for tracking
a same visitor on different devices (when logged in).
Only one visitor was kept as active, others would be archived and their
tracks would be set/moved to the main partner.
Removing those duplicate visitor was not possible because those archived
duplicated visitor were holding the devices notification push token.
Since [2], those token were moved to their own table, all related to the
main visitor.
We can then now safely remove those duplicate visitors after merging
their track to the main visitor. Thus, the `parent_id` field is no more
useful. Removing it removes a layer of complexity.
Note that thanks to this part, the `active` field can also be removed.
4. Deeper functionnal change, inspired from Plausible: The access_token
is no more stored in a cookie but is the result of a hashing method
based on <IP Adress, User Agent>.
The reason behind that change is that, in an upcoming refactoring,
sessions won't be stored anymore unless absolutely needed (login, add to
cart..). It will also ship a no cookies policy, trying to get rid of all
cookies.
This change is bringing some functional changes:
- Since the IP is included in the hash to generate the token, it means
that:
A. If an anonymous user switch IP (eg from 4G to wifi), it is
considered as a new visitor.
B. If 2 anonymous users with the exact same user agent (same browser,
same browser version, same exact os or phone) are on the same IP,
those will be considered as the same visitor.
- Since the request host is not included in the hash, it means that
visiting a DB from 2 differents URLs (domain and/or ip) on the same
device and same browser will result in a shared visitor.
It shouldn't imply any issue as this is A. not wrong and B. mostly
used for tests.
As all this is only related to non logged in user, it shouldn't be a
real issue as anonymous visitors are not supposed to be meant to be
business critical, even if we use them for "a bit more" than simple
analytics data.
5. The access_token is now replaced by the partner_id once the user logs
in, so:
- We don't need to either search on the partner_id field or the
access_token field (depending if the user is logged in or not), we can
only use the access_token row/field to do both.
- On logout, everything works out of the box as the access_token will be
regenerated since there is no partner_id anymore.
- On login, if an access_token matches the user's partner_id, that
visitor is returned.
If there is no such token, a new visitor is created for that partner_id.
In both 2 cases, tracks are moved to that visitor and the anonymous
visitor is removed.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from another user eg,
different user login on same device). Indeed, such collision is not
possible anymore as the access_token automatically match the logged in
user.
- We can remove the code that was in charge of checking if the
access_token / visitor cookie was wrong (coming from a logged in user
while the current visitor is not loggedin). Such collision is not
possible anymore as the access_token is (re)generated as an anonymous
token (hash) when not logged in.
6. There is no more check to prevent a track to be created if there was
already a track for that URL in the last 30 minutes.
While this can easily be re-introduced (one CTE on the upsert), it was
adding ~100ms (from ~20 to ~110ms) to the request on a big database as
Odoo where there is ~100 millions tracks and ~100 millions visitors.
It has been validated that it was not a real issue as it is not
fundamentally wrong. If a visitor visited 20 times a product or a
specific page in that short amount of time, you might want to know that
because the user is most likely interested by it.
Changes (1+2), 3, (4+5) and 6 are all independant from each other and
could have existed on their own.
[1]: https://github.com/odoo/odoo/commit/c6b8a44b970a46dcd87a4e2cb1ad52fa340b209f
[2]: https://github.com/odoo/enterprise/pull/16781/commits/f75090fe8b42484e89e933976e8441d2f5eb9415
task-2867045
closesodoo/odoo#87857
Related: odoo/enterprise#28004
Related: odoo/upgrade#3566
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
- In CRM seetings, activate Leads
- Create a sales team with "Pipeline" selected in Sales Teams Settings
- Set a form. The action is "create opportunity" and the Sales Team is the one you created
- Send a form
Issue:
A lead will be created. Not opportunity.
Solution:
Fetch the info related to the team
opw-2856520
closesodoo/odoo#92563
X-original-commit: 1e35d5a2f832901e1269c0f133eb846350f4ba0a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
Currently stat button on crm.lead form view still shows page views count of
archived visitor records. This is not coherent with the action performed
when clicking which filters out archived records.
We now correctly count only active visitors page count.
closesodoo/odoo#87574
X-original-commit: 325aaebca2d7b6b3a0e285f957e2be5736e7c69e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
Purpose
=======
Ensure that the names of the UTMs models (campaign, medium and source)
are unique.
If not, generate automatically an unique name.
The name field is no more translatable; it makes no sense to translate
a technical which will be added in the URL, and can even cause issues
(the UTM record is not recognized because of the translation).
For the campaign, we keep a "translatable" name which is called
"title".
For the UTM source, use a mixin to generate automatically the name of
the source based on the content (_rec_name) of the record. So we remove
the override of create / write / copy in the different models and
ensure consistency between those models.
Task-2245823
closesodoo/odoo#60501
Related: odoo/enterprise#21882
Related: odoo/upgrade#1863
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
Visitors are useful in terms of marketing analysis but they can bloat the
database really quickly if you have a lot of traffic on your website.
This commit aims to relieve the database by fully deleting inactive visitors.
SPECS
On an active website, you can easily reach hundreds or even thousands of
visitors per day.
While active visitors are useful for marketing purposes, inactive ones were
archived after a period of inactivity (i.e: not connected for X days in a row,
where X is configurable as a parameter and 30 by default).
But archiving visitors is not really useful either.
We don't see any specific cases where you would want to restore some visitors.
That means we are better off unlinking the visitors completely to save database
storage space.
We want to make exceptions and avoid deletion of inactive visitors in some
cases:
- When they are linked to a partner (meaning most likely linked to a
registered user)
- When they are linked to leads
- When they are registered to events
Several tests were added to ensure that leads matching these conditions are not
unlinked.
We also took this opportunity to enforce the "_link_to_visitor" rules in those
tests to make sure that:
- When visitors are linked, the leads are merged into the main visitor
- When visitors are linked, the event tickets are merged into the main visitor
- When visitors are linked, the wishlisted tracks are merged into the main
visitor
This is also preliminary work for a commit that will move the push_token of
website.visitors to a separate table.
That will in turn allow us to link the push_tokens within the
"_link_to_visitor" method and delete the linked visitor instead of archiving
it.
LINKS
Task-2410217
Part-of: odoo/odoo#65113
The concept of 'parent_id' on website.visitors was introduced in the saas-13.3
stable while implementing the "event online" feature:
However, it should have been part of the website module from the start since
it's a 'global' concept that does not depend on events at all.
See #53540 for more details.
This commit aims to clean the code by moving the field to the website module,
which allows a nice cleaning of associated overridden methods as well.
Along with that, we move the website.visitor demo data from the event module to
the website module, allowing a fresh install of website to showcase some of our
visitors feature.
We also took this opportunity to do some minor improvements in the visitors
kanban view in order to make relevant information more visible.
Task-2429652
Part-of: odoo/odoo#65113
Before this commit, if we try to merge crm leads and few of the
details are not available, traceback was thrown. For ex-
- When lead does not have a company or the company does not have
currency set
- When the visitor name is not set
This commit fixes both of the tracebacks and thus allows users
to merge the leads in these cases.
taskID-2745017
closesodoo/odoo#84656
X-original-commit: eda3f43dde8122aa5f572f57bf2c3c0d94abe1f2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose
=======
It's configurable from the website editor itself.
Keep the default fields on the website model in case someone
changes its mind though.
closesodoo/odoo#82999
Related: odoo/upgrade#3210
Related: odoo/enterprise#23612
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, The 'TestWebsiteCrm.test_catch_logged_partner_info_tour' is randomly
failing on runbot. The tour is triggered on contactus page. Tour bug is
occurring because editor may not be completely loaded. In that case some
selectors are not accessible.
This tour is linked with selectors. In this commit updates the selectors and
add the extra triggers in order to be sure editor is fully loaded and the
tour can resume.
Task-2649723
closesodoo/odoo#78676
X-original-commit: d135916b754ae7fde184c4e2d69177dbc1dddc9d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
On the page 'Visitors' page of the website module (backend), the cards
can be miss-aligned on small screen size. To improve the responsiveness
of the cards, we will use the `col` and `col-*` classes of Bootstrap
with some specific breakpoints (e.g. `col-sm-*`, `col-lg-*`, etc). We
will also use flex display to reduce the number of custom css rules.
task-2524363
closesodoo/odoo#73355
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use a template for merge post messages and clean how fields are displayed,
notably by fixing the display format, and the field order.
Indeed, previously posted lead merge message contained all fields in an
alphabetical order, even ones that had empty values, which is not very user
friendly in terms of display.
Now, the displayed fields are determined and ordered by sections, which greatly
improves understanding the various information.
Please note however, that it has the downside of not including all fields
anymore.
The merged leads information are included in a "read more/read less" enabled
block using the "data-o-mail-quote" feature to get a nice rendering and avoid
cluttering the Odoo chatter UI.
Within the sent mail however, the full text is directly visible when viewing
through a mail client.
Task-2451164
closesodoo/odoo#75946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
Side effect of https://github.com/odoo/odoo/commit/69cc2911b52fd17b37fb71544574f63cf09dd17e.
On a lead, there is a smart button allowing to see his page views on the website.
In case we have many views, we are grouping them by page. Currently, the check on
the pages is made through field page_ids which is restricted to Website Editor
access group. We should allow a regular salesman to see page views without error,
and this can be achived by using field website_track_ids.page_id instead.
closesodoo/odoo#75761
X-original-commit: 76e1d609ad0e6d9a3dd2703185f4b87759823c70
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
PURPOSE
Perform a global renaming / cleaning of IAP features often added or merged
with minimal review. Time to cleanup !
SPECIFICATIONS
Reorganize module according to guidelines. Notably correctly name files,
split python fiels and views according to their model, split some data
to ease module organization and understanding.
Perform some code re-ordering in some big files in order to have code clearly
separated by main usage and ease future changes.
Quickly lint or update some view names.
LINKS
Task-2630969
Prepares Task-2600047 (code improvements and cleaning)
COM PR odoo/odoo#75514
ENT PR odoo/enterprise#20424
UPG PR odoo/upgrade#2770
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
- fixed xml data files order, otherwise form field would not be whitelisted,
including `email_to`, so the mail would not be send.
- add the same data-for behavior from website_crm to website, to be able to
prefill a field with an URL param
- removed the fallback data-for in website_crm, the JS in now in charge of
doing that. Plus it was creating a misheavior -> you could have prefill set
to false but still, it would prefill the user info
- fixed the form option so the field.name is not used as field.string if there
is already an explicitely set field.string..
- adapt field name in /contactus form (xml view), form snippet (registry) and
crm form (registry) for more consistence
- added the prefill option set to true by default on /contactus (to fit what
we had before). This came with a change in the test as we don't need to
enable it anymore.
- added also the prefill option to true by default on form snippet
Part of #69888
task-2462993
Before this commit (and the previous ones that prepare it), the contact
us page was largely editable but not entirely. The automatic address
field on the right column prevented the page to be considered like any
other page and only the left column was editable. That led to less
possibilities and difficulties to make a modern contact page.
Now, the whole page is static, like a page the user would have created
himself. Same for the thank you page. This comes with the disadvantage
of having to handle the address by yourself (but that's not a field that
would normally change a lot anyway) and the website_crm app now needs to
be enabled on the form via edit mode after install to change the form
action to lead creations.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
*: website_crm, website_form_project, website_hr_recruitment,
website_sale
Replace website_crm specific behavior by another option for all website
forms.
Part of https://github.com/odoo/odoo/pull/69888
task-2462993
Gorash