- split the mail_client_extension module onto two modules:
1) module mail_client_extension having mail/contact specific code,
depends on iap and contacts only
2) module crm_mail_client_extension having crm specific code,
depends on CRM and mail_client_extension.
Purpose is to allow the user to use the mail_client_extension
without needing to install CRM, this will also allow
the usage of the mail connector in other modules without
the need for CRM.
- add the module_mail_client_extension field to the
res_config_settings model of the base_setup module
in order to enable the user to install the
mail_client_extension module directly from the settings
- move the crm_lead model from the mail_client_extension_module
to the newly created crm_mail_client_extension_module, as this
model is no longer needed by the mail_client_extension module
because it no longer not implemants CRM functionality
- move the iap_enrich_api model from the crm_iap_lead_enrich
module onto the iap module as it is only related to contacts
and not to CRM, this way it can be used in other modules such
as the mail_client_extension module without the need for CRM
module
Task-2382870
UPG-PR: https://github.com/odoo/upgrade/pull/2156
COM-PR: https://github.com/odoo/odoo/pull/66139
PURPOSE
Clean and improve IAP tools integration in Odoo. Introduce bridge modules
to extract common features, notably for CRM and Partner.
SPECIFICATIONS
In this commit we reorganize IAP module to better understand its content
and ease future cleaning
* have models separated from tools;
* rename some tools to find their grep. An iap_ prefix is added to ensure
we don't clash with other global functions or methods;
* perform some linting;
To provide backward compatibility support we keep some import in init file of
IAP addon. Standard code is about to be updated but we want to avoid too
much issues when migrating code to 13.5 . Compatibility layer will be removed
after v14 final freeze.
LINKS
Task ID-2248367
Community PR odoo/odoo#53214
Enterprise PR odoo/enterprise#11258
Upgrade PR odoo/upgrade#1363
IAP PR odoo/iap-apps#191
Bug
===
Install CRM, then go to the lead kanban view and try to generate leads.
An error will be raised.
Technical
=========
In the "iap.account" model, in the `get` method, we can create the IAP
account if it doesn't exist yet. Since 5307f47d975c3b3ebd87c7f7e2248802a1aa5be7
the operation is done in a different SQL cursor than the current one.
The reason is that we need to commit the change, and committing the current
SQL cursor can cause issue and break some flows (mainly if it's not done
at the very beginning/end of the flow).
In the current code, we cache the `account_token` to be able to read it
with the current SQL cursor (otherwise, the current cursor has no access
to the field because change has not yet being committing for it).
But, the cache is invalidated when the "IAP account SQL cursor" is closed.
```python
with self.pool.cursor() as cr:
...
IapAccount = self.with_env(self.env(cr=cr))
account = IapAccount.search(domain, order='id desc', limit=1)
if not account:
if not force_create:
return account
account = IapAccount.create({'service_name': service_name})
# fetch 'account_token' into cache with this cursor,
# as self's cursor cannot see this account
account.account_token
# <---- Cache is invalidated here
...
```
So we can not access the the field value after the invalidation.
Solution
========
The solution is the store the `account_token` value before closing the
"IAP account SQL cursor" and then, after closing it, we add it in the cache.
Task-2277733
closesodoo/odoo#53323
X-original-commit: 32caf74ff10052d2a303fa24d5cc7b37538dd406
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
The modification introduced in 5307f47d975c3b3ebd87c7f7e2248802a1aa5be7
was not properly managing the 'force_create' argument. When it is set to
false, we only look for existing accounts with the current cursor and
end up returning an empty recordset when the account was created during
the same transaction. Ex:
// Do stuff
IapAcc = self.env['iap.account']
IapAcc.get('my_service')
IapAcc.get_credit('my_service')
// Other stuff
closesodoo/odoo#48201
X-original-commit: c78070dc22f99867b4b1f3a52cd11543da571fe4
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The generic IAP flows forces us to commit the creation of a new record
to prevent the loss of his token once the system contacts iap.odoo.com.
Unfortunately, this operation can drastically alter any business flow if
it's not executed at the very begining or end of the flow.
Furthermore, it can be difficult to exactly pinpoint if this will affect
a flow (for instance, the point of sale is affected by iap because of
the module 'stock_sms' while the former doesn't depend on the later).
To avoid those issues, we isolate the account creation on a dedicated
cursor and load the values of the created record on the current cache.
closesodoo/odoo#47026
X-original-commit: 5307f47d975c3b3ebd87c7f7e2248802a1aa5be7
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Steps to reproduce the bug:
- Go to Settings > Technical > IAP account >
- Remove the access token
- Go to Contact
- Try to create a company called 'Proximus' and click on the autocomplete
Bug:
A traceback was raised because the IAP account token was not set.
opw:2087607
closesodoo/odoo#39099
X-original-commit: bc6357f0b95d354afa602eecce24a3c265819101
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
Allow the user to enrich a lead based on the domain of the email address of
the client.
SPECIFICATIONS
Following fields will be populated if found using clearbit and if they are
not yet populated :
* description
* partner_name
* reveal_id
* website
* street, street2, zip, city, country_id, state_id
* phone (using the first number found in clearbit)
* mobile (using the second number found in clearbit, else the same as phone)
A message will also be logged in the chatter.
If no data is found using clearbit no credit is used and a message will be
logged. If the user has no credits he will be redirected to buy credits for
the service.
It is possible to enrich using the 'enrich' action in listview or with a
cron that will run every hour on leads not older than 1 hour.
Add a "Lead Enrichment" setting in CRM installing lead enrichment.
LINKS
Task 193185
closesodoo/odoo#36419
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The user can already send a confirmation email when the
Stock Picking is done. It'd be great to communicate the
same information by SMS.
In addition, the current mailing tool requires a manual
action. The idea is to automate the process via a
Setting instead.
id=1972567
closesodoo/odoo#35662
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If "force_create" is false and no account was
previously create, the function will raise an
error. With this fix, an empty recordset is
returned.
closesodoo/odoo#35664
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Before the fix, if you had multiple accounts for a specific service, the
settings page was crashing.
(eg: for a service, you have one account specific to a company and
another account with no company set).
We now prefer accounts specific to the current company and tie-break on
the most recently created one
opw-2003744
closesodoo/odoo#33736
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The "company_id" fields for the iap account has
been changed by the "company_ids" fields to allow
the use of an iap account with multiple company.
closesodoo/odoo#35093
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Purpose
=======
Currently, when we click on “Settings” on the Home Dashboard, we arrive
on a new Dashboard with several pieces of information like Installed Apps,
invite new users, or translations. Some informations are reachable in
several ways, which is not necessary.
We would like to remove this page and replace it with the General Settings
page directly. That makes more sense to the user who click on “Settings”. The
present informations will be dispatched in the menu or in the general settings
for a better usability.
Specification
=============
This commit move code from web_settings_dashboard in order to put the features
in settings directly. To do so, we choose to move code to base_setup, and create
widget on the settings form view to keep features. Concerned features are: invite
users, dev tools, odoo edition number and IAP account link.
TaskID: 2006910
closesodoo/odoo#34290
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose :
Allow the user to generate a certain number of leads based on certain criteria like localization, technologies used, or size.
Available filters are :
- company size
- localization (country and states)
- industries
- technologies
The user can also ask for a few contacts that can be filtered based on
their role or seniority.
Each company found generates a new lead/opportunity for which the sales
team, salesperson and tags can be preset from the lead mining request.
This commit includes the followings changes :
- New module crm_iap_lead
- New model crm.iap.lead.helpers which contains helper methods used by
both modules crm_iap_lead and crm_iap_lead_website
- New model crm.iap.lead.mining.request that holds the data of a lead
mining request
- An option in the CRM settings to install this feature
- New button 'Generate Leads' in the leads/opportunity ListView and
KanbanView that opens a modal allowing to create a lead mining request
- New section 'Lead Generation' in menuitem 'Configuration' of CRM
TaskID : 1902172
closesodoo/odoo#30189
When the iap sever is called, it is possible that the request timeout
or that the webserver returns an error code (if the Odoo server is down
for example) and we should warn the user instead of throwing an
exception in a traceback
closesodoo/odoo#29667
In this commit: https://github.com/odoo/odoo/commit/a0b7802a5e7646a896f54cf125f0136ff489d4d9
We've added the possibility to send the dbuuid in the authorize request,
this as been added to allow to give free credits of a service to a
database.
As some services developped in 11.0 are using this mecanism, we have to
add that support in 11.0
Instead of forcing the creation of iap account to consult its balance,
since it will most likely be 0 at creation, we only generate it on
explicit user action (e.g. Click to recharge the account).
- CRON changed to 60min
- Fixed display/rendering issues with autocomplete widgets.
- Moved 'Insufficient credit' banner
- Editable endpoint for partner_autocomplete service
We added the possibility to provide the dbuuid of the client when trying
to authorize a transaction. This will allow to automatically credit the
client accounts that can beneficiate from free trial credits. This
improvement will ease the life of the client as they will not have to go
to iap.odoo.com to charge their account.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
Up until now, services developed (sms) relied on the get() and
InsufficientCreditError mecanism to create iap_accounts on the fly and
recharge it.
This particular workflow does not work well with automated processes which
is why we modify the function get_credit_url such that it will allow the
client to generate the 'recharge' link manually for better integration
of iap services.
Added a possibility to authorize a certain credit amount and capture another (smaller or equal) at the end of the transaction.
For instance, you want to print 2 jobs and one of them fails, you will be able to only print the one that succeeded.
* [ADD] doc: iap tutorial
Should be easier to approach than the raw APIDoc.
contains:
- overview of the flow
- tutorial (coalroller) with guidelines
- technical description of objects/helpers
The Qweb render method returns a strign encoded in byte.
As we want to dump this into a json string in iap.charge,
we need to decode it properly in UTF-8, before the dump.
This problem appeared in Python3.
Errors that are not whitelisted are not managed correctly due to the jsonrpc behaviour in Odoo.
When we make a post in json using iap.jsonrpc function, it contacts iap.odoo.com.
However, if this url does not respond, it falls back to the 'typo' page and the answer to the call
has a '200' status code but with an 'error' key in its response.
Currently, we manage the errors via whitelisting, which hides this kind of errors.
We opted to raise this error (odoo server side) as a UserError and to add UserError to the whitelist.
IAP allow app publishers to charge for ongoing services. In that context, Odoo
acts mostly as a payment platform between the service user (client) and the service
provider (Odoo App developer).
nounoubensebia