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
Purpose of this commit is to ensure side documents are redirected to the
master opportunity when merging leads. Those side documents include
* communication history (mail.message);
* attachments (ir.attachment);
* visitors (website.visitor);
However some documents are currently not specifically handled :
* meetings (calendar.event);
* activities (mail.activity);
* sale orders (sale.order);
* attendees (event.registration);
In this commit we ensure all are attached to the final master opportunity.
That way we prevent loosing access to those documents and ensure we keep
the complete history of all merged leads.
Also tests are added to ensure the merging of leads and its contents.
A new field is added to have the o2m field between leads and calendar events.
In order to clarify naming, ``meeting_count`` is renamed to
``calendar_event_count`` to match naming.
Task Id-2457941
COM PR odoo/odoo#68884
UPG PR odoo/odoo#2494
Related: odoo/upgrade#2494
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Reduce friction submitting a CRM contact us form while linking the
lead to the portal contact.This facilitates the flow generating leads
from the contact us form.
The partner_id of the lead created from form is set to the one of the
logged visitor if model is crm.lead and there is a logged_visitor and
if the prefilled email and phone number of form match the logged partner's
(otherwise it would change the partner when setting it on lead
In details : there must be an email, the same in input and in partner,
after normalization. Only then:
- If there are both a phone in values and a phone on partner,
propagate partner on lead only if they are the same.
- Else, that is if there is no phone in partner or no phone in values,
propagate partner on lead. If no phone in input, it will not propagate.
on the model. If no phone in partner, then if there is one in input, it
will write that additional info on partner, completing its profile.
Concerning phone comparison: extending current logic, the numbers are
still formatted before comparison. That is:
- Before this comit, the form value was formatted according to country in
record or geoip. Now, if there is no country_id in record, uses the logged
visitor partner's country or env company country, if there is a logged user.
Finally, it uses session geoip as last option. (changes in _get_country())
- The partner's number is formatted through its model function _phone_format,
according to the partner country (or env company).
- Both formattings are done in international format.
Adds tours to check that partner is linked to lead only if phone and email
are not changed from prefilled data (from logged visitor's partner on form.
Task-ID : 2241639
PR : #61126
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently there are several limitations in visitor email and phone
computation, notably phone of partner is not taken into account (only mobile)
and computation does not work in website_crm if there are no leads.
In this commit we
* support both mobile and phone fields of partner. Indeed generally all
SMS flows check for those two fields and not only for mobile;
* replace the SQL by standard ORM computation. As those fields are not stored
and displayed in list views ORM should be capable of managing them;
* avoid crash when creating visitors through the UI (no ids -> don't go
into raw SQL);
* correctly keep partner-based values when no lead is linked to the visitor;
Tests are also added in order to ensure behavior.
Task ID 2196869
closesodoo/odoo#48369
X-original-commit: 02ceb42e204be2b40b334b4e554eef6dfaffd228
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the syntax to start a tour was extremely verbose.
With this new method, it is possible to start a tour by just giving the
essential parameter: the tour name.
The full set of features from browser_js are kept by using **kwargs.
closesodoo/odoo#32316
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This allows rpc requests in `HttpCase` to use the cursor `self.cr`, which is
now shared between the Python test and the rpc requests. This simplifies code
to prepare a JS test, and code to check the result of a JS tour.
Fixes#12237
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
* run tours as public users since these screens should be accessible to
and used by public users
* fix access rights issues in website_crm tour (default value of team_id
when creating a crm.lead requiring read access on crm.team, which the
public user does not have)
* remove duplicated crm.lead field (phone declared as char(size=64) then
as char() a few lines below, removed first instance)
To check for result of a tour, would run a second tour performing
JSON-RPC calls to check if the first tour had correctly impacted the
database.
Tours are expensive, an empty tour takes ~6s without doing anything.
Replace second tour by regular ORM calls.
Matthieu Stockbauer