Before this commit, orm service calls had no validation whatsoever,
which means that the requests would fail serverside, then display a
python traceback. This makes it harder for developers to find the cause
of the issue. Also, it is easy to perfom some really basic validation
anyway.
Before this commit, the block UI component was not visible so the interface
was not blocked when sending RPC (at least).
After this commit, the block UI works correctly
closesodoo/odoo#72727
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit:
Currently, failure notifications are sent to the author of the message that the
failure is concerning.
However, if another user than the author is resolving the failure, he is not
receiving any notification without refresh the page, so it appears as if nothing
happened even though the failure was indeed resolved
(either message resent, or failure ignored).
After this commit:
When another user than the author update the status of the failure notification
(message resent or failure ignored). the statues of the failure notification
update instantly, no refresh needed to show the updated status.
Task-2178257
closesodoo/odoo#68860
Related: odoo/enterprise#18748
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit: share button inside project was displayed only in
readonly mode.
After this commit: share button inside project will be displayed in
edit mode as well.
task-2513815
closesodoo/odoo#70441
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
before this commit: create_text was passed in node options and due to which it
was not parsed by translate.py, pass add-label as attribute on field so that
translate.py parse it and it is translated.
after this commit: create_text will be passed as field attribute instead of
node options.
task-1923433
closesodoo/odoo#59713
Related: odoo/enterprise#19418
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit: When there are no columns in kanban and user is
creating very first column then it will display column + examples
clicking out closes quick create of column and due to which mockup
column also disappeared.
After this commit: Quick create of column will not discard if there
are no columns and user is creating very first column, clicking
outside will discard quick create of column if there is atleast one
column exist.
task-2517684
closesodoo/odoo#70220
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
When an installed module is not installable, we don't want
to check its dependencies because they may not be available.
Erroring out on such dependencies is not needed because
the module will not be loaded anyway. On the contrary, such
errors prevent starting a database which would otherwise
function normally.
Such errors occur when doing incremental migrations where
it happen that addons are installed (from the previous version)
but not migrated yet and therefore not installable.
When we migrate lower level dependencies Odoo marks
higher level addons as "to upgrade" even if they are not installable.
That is usually harmless, except when such addons have
dependencies that are themselve not available.
This PR fixes that.
closesodoo/odoo#73206
X-original-commit: a11e8a32883b0d0deaeb2497daa585eb3d3c686e
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
We are now using the sessionstorage to make the data the user enters when
he completes the configurator persistant during the whole session. Which
means that these data are not lost anymore on page refresh.
task-2518565
closesodoo/odoo#73101
X-original-commit: 74cc69f3908a3b1b5bfc76bb362690f72e514b00
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Finally we don't want to change the position of this button (PR #72138).
This commit moves it back to its initial place.
closesodoo/odoo#73103
X-original-commit: 60657db80248714a9b3b7269b70e8c8b25cdce11
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
It has been reported that the page showing the exhibitors is slow because of the
partner table used behind the scene. It turns out that the page can generate many
links for the filters which can trick the crawlers to explore them all. As the
page is slow, the crawlers can put a high pressure on the server by exploring
those links.
SPECS
- Use a POST method to set the tag filters.
By using a POST method, the page will not longer generate links and the crawlers
will no longer explore them. This technique is actually more reliable than simply
defining a `rel="nofollow"` rule on the links.
LINKS
Task id: 2466072
closesodoo/odoo#68192
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Follow-up of [1]
Before this commit the map snippet had life-cycle and naming issues.
Also avoid partially reusing the color picker intended for background
images for the color filter overlay.
The height adjustment has also been removed, the standard top and
bottom padding can be adjusted to achieve a similar result.
[1]: https://github.com/odoo/odoo/pull/66766#pullrequestreview-685976812
Related to task-2464422
closesodoo/odoo#73180
X-original-commit: 8b9225ffd133332630097f29db9522abace7ba09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit updates the res.currency data files to be compliant with
the ISO 4217 standard:
Add existing currencies missing from Odoo.
Remove currencies deprecated since at least 10 years.
Update incorrect currency names and rounding values.
task-2501384
closesodoo/odoo#69356
Related: odoo/upgrade#2400
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
According to Argentinean law 27440, Art. 5º it is mandatory to show the
CBU on the report for electronic invoices and electronic debit notes.
Before this commit, we were showing only in FCE (MiPyMEs), and here we
add it for NDE (MiPyMEs) on invoices reports.
closesodoo/odoo#73108
X-original-commit: d5f3e1ddff72ba05af3b8d20888b92799c7d532c
Signed-off-by: Josse Colpaert <jco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Move the odoo server parameters into the odoo.conf file
instead of being placed as the service command line argument
closesodoo/odoo#73143
X-original-commit: 8943ed4fdd01817a86e6a8abf6463e078182f584
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
https://github.com/odoo/odoo/pull/71872 made country_id readonly in every circumstance. This made it impossible to create an account.account.tag targetting taxes from scratch in the UI. We only want to prevent edition of this field when the tag has been generated by a tax.report.line.
closesodoo/odoo#73142
X-original-commit: 8f0ae54cd24e9a6299d86c47ed37aea2a7fa4ad8
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To reproduce:
1) Install an European CoA and make sure the OSS mapping for its taxes has been generated (either installing l10n_eu_service before, or clikcing the "refresh tax mapping" button, in the settings)
2) Create a new tax with the same rate as one of your original taxes
3) Click on "refresh tax mapping"
===> Instead of reusing the OSS tax mapped with the other tax having the same rate, a new tax with the same name has been created.
X-original-commit: 6f6386ed0374cea143541add69c269f44b098050
When selecting a "basic" color from the color picker, it was displayed
as a custom color.
It was due to the fact that the basic colors were not correctly computed
to build the existing colors: the array of the rows was used instead of
the array of the colors.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
closesodoo/odoo#73139
X-original-commit: 23b182ab1bce9a00cb75d12b0d0c504d1fe19e2f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The commit fixes the display of custom colors in the color picker.
It improves previous fix from #72294, which was not returning all
editables from the editor, thus only the custom colors of the target
were displayed.
For that the request_editable event is reintroduced at the SnippetsMenu
level.
Part of https://github.com/odoo/odoo/pull/72978
task-2476601
X-original-commit: 68d7d42cce012269342e18373a30970e2c582ba3
add resetLocalState method to rendererWrapper and test activity view is not
crashed on on_destroy_callback
task-2466057
closesodoo/odoo#73022
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
before this commit: when switching to form view from listview using Create
button and then activate some other tab and Discard that record which will
move back user to list view now again clicking Create button opens form view
but active tab is last activated form tab instead of first one, this is because
of local state is not cleared.
after this commit: when form view is switched back to list view using Discard
button, local state will be cleared, here we are explicitly removing 'active'
class from all tab and pages of all notebooks.
task-2466057
X-original-commit: ff0e5694e28a46287dc54ab440364e11e8e9c832
Steps to reproduce:
- Install 'Accounting' module
- Switch to "My Company (Chicago)"
- Create an invoice
- Set Invoice date to 1/1/21 and
- Set Due date to 1/3/21
- Add any product and 'Confirm' invoice
- Go to customer profile
- Click on 'Due' stat button
- Click on 'Send by mail'
Issue
In received email, logo displayed is of "My Company (San Francisco)".
Cause
Env company not used.
Instead, logo of customer.company_id is used if mail type have
company_id field,
else will fallback on user.company_id
Also, if customer.company_id is null, it will fallback on '0':
/logo.png?company=%s' % (company.id or 0)
Solution
If mail record have NOT a company_id field or is not set,
set company to self.env.company.
Else, set company to record.company_id.
opw-2474114
closesodoo/odoo#73099
X-original-commit: 316b5956844d6f77f6fef1efeb5a8a8505e36e8e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Issue:
For purchase user, which doesn't have the "Contact Creation" can't
create a purchase, get a AccessError.
The fields `receipt_reminder_email` and `reminder_date_before_receipt`
should be writable also for purchase user which doesn't have access
to write and create `res.partner`.
closeodoo/odoo#64135closesodoo/odoo#73131
X-original-commit: f29b1e81e6adf8532ecf90f9ecb675ec56eb4c61
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Currently if public user has country_id, following traceback is raise
when /shop URL is opened:
Traceback (most recent call last):
File "/.repo_requirements/odoo/odoo/addons/base/models/qweb.py", line 331, in _compiled_fn
return compiled(self, append, new, options, log)
File "<template>", line 1, in template_website_sale_products_item_306
File "/.repo_requirements/odoo/addons/website_sale/models/product.py", line 294, in _get_combination_info
fpos = self.env['account.fiscal.position'].get_fiscal_position(partner.id).sudo()
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 184, in get_fiscal_position
fp = self._get_fpos_by_region(delivery.country_id.id, delivery.state_id.id, delivery.zip, vat_required)
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 141, in _get_fpos_by_region
fpos = self.search(domain_country + state_domain + zip_domain, limit=1)
File "/.repo_requirements/odoo/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/.repo_requirements/odoo/odoo/models.py", line 4485, in _search
model.check_access_rights('read')
File "/.repo_requirements/odoo/odoo/models.py", line 3331, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "<decorator-gen-33>", line 2, in check
File "/.repo_requirements/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/.repo_requirements/odoo/odoo/addons/base/models/ir_model.py", line 1792, in check
raise AccessError(msg)
odoo.exceptions.AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Error to render compiling AST
AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Template: website_sale.products_item
Path: /t/t[2]
Node: <t t-set="combination_info" t-value="product._get_combination_info(only_template=True, add_qty=add_qty or 1, pricelist=pricelist)"/>
Above was tested and reproduced in an instance of odoo runbot v14.0:
https://youtu.be/GgUnyna_EX8
That is due to public user has not permission to read model
account.fiscal.position and in fact in ACL, permission contains
'public' but is setting group_portal.
closesodoo/odoo#73117
X-original-commit: 53dc9f62b6d4c362292bf48df54b11c4852f6006
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The commit fixes an issue with the editor toolbars dropdowns, that would
not close already opened widgets. For example, when the widget color
picker for snippets background was open, opening the one from the editor
toolbar for the font would only close it for the first click, but not
for the ones after.
The issue was coming from Bootstrap, which stops the propagation of
click events for dropdowns. As a result, the click event on these
'.dropdown-toggle' elements was not processed by the listener at the
SnippetsMenu level, in charge of closing the widgets that were already
open in this context. It was the case only for the first click that was
instancing a Dropdown, but not for the ones after.
https://github.com/odoo/odoo/blame/cd9c071c9357cef14635ef094a9f14fc5431956c/addons/web/static/lib/bootstrap/js/dropdown.js#L308-L314
A solution would be to update bootstrap:
https://github.com/twbs/bootstrap/blame/688bce4fa695cc360a0d084e34f029b0c192b223/js/src/dropdown.js#L232-L237
The fix can be to listen to mouseup events on such '.dropdown-toggle'
elements while waiting for a bootstrap update.
Part of https://github.com/odoo/odoo/pull/72539
task-2476601
closesodoo/odoo#73032
X-original-commit: 048a329fc514b2c98cf7e6af7279f90fce53eb09
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When the color palette for the text was open, opening the background
color options was not closing it.
The click event was stopped at the snippet option level for all events,
where it should only be the case if the click was done inside the
colorpicker.
Part of https://github.com/odoo/odoo/pull/72539
task-2476601
X-original-commit: 888f1bd44d0aa431d3d89ee3c913c6eb64c3d54d
After the new editor was merged, custom event 'request_editable'
triggered by the ColorPaletteWidget to retrieve custom colors from the
editable was not processed.
Now, we pass the editable in the options when we init the
ColorPaletteWidget.
task-2476601
closesodoo/odoo#72959
X-original-commit: 3d98268cf93087516743e3f0a2f3af950d4feb6a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, failure_reason was also copied when user duplicate email.
Which is not correct since the Mail is never sent not failed.
With this commit, failure_reason will not be copied when user duplicate email.
closesodoo/odoo#71690
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If user selects 'schedule appointments' as main objective in the configurator
and if the website_calendar module is installed then the Call To Action of
snippets s_banner, s_cover and s_call_to_action is changed to 'Schedule an
appointment' and redirect user to '/calendar' on click.
task-2518565
closesodoo/odoo#71162
Related: odoo/enterprise#18690
Related: odoo/design-themes#5
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Steps to reproduce the bug:
- Go to website app > configuration
- Set the visibility of all the blog to Website A (So that it's not visible on Website B)
- Go to the Blog menu of Website B
- A traceback is triggered
Problem:
The `all_tags` function calls an SQL query to get the tags related to the website blog
with a where condition based on the blog_id. But since there is no blog linked to the site.
The request fails and an error is raised.
Solution:
Do not load the tags, if there is no blog for the website.
Opw-2545315
closesodoo/odoo#72636
X-original-commit: 4d8fc86e4e6beb2171e3bebbabd532086d884d59
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
closesodoo/odoo#72548
X-original-commit: bfa7c9e78037cd0abda3e8f0a9a519a600988e9c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The company is needed in the context to get the paper format for
instance because of `get_paperformat`
X-original-commit: a1526eb4e5b1eb7cada603d7fcee7bb77c64bbac
Steps to reproduce the bug:
- Go to settings > create a new company :
- Choose the country : `Mexico`
- fill in the VAT field : ESA2005273X1
- save
- Validation error is triggered
Problem:
The Mexican VAT can be on the format: "MXESA2005273X1" or "ESA2005273X1".
But only the "MX .." format is accepted for the moment,
and it fails in the case of "ES.." because the function checks if it is a valid Espganol VAT number.
In the case of failure, we use the `partner.commercial_partner_id.country_id` to get the country code.
The problem is when creating the res.company, we also create a res.partner
with a few fields within `VAT` except `country_id` field
while we use it in the `check_vat` function : https://github.com/odoo/odoo/blob/7a7aacedde81998ec0f1a7f3283337236e56de42/addons/base_vat/models/res_partner.py#L167
Opw-2573557
closesodoo/odoo#72633
X-original-commit: a6a46c95e4947997892b21f407132574da1c7ff1
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Add mapping rules to enable the electronic invoicing of document types
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO A" (60) and
"CUENTAS DE VENTA Y LIQUIDO PRODUCTO B" (61).
closesodoo/odoo#72619
X-original-commit: 9fb221459e1137c0622c14a57ec408b3b5f65fe6
Signed-off-by: William André (wan) <wan@odoo.com>
The purpose of this task is there are several places where the
duration is expressed in hours even though the encoding unit
is in Days. This creates inconsistencies.
In this commit, we convert hours into days when the encoding
unit is in Days. Also, we changed the string of the fields
according to the encoding unit.
closesodoo/odoo#70512
Task-id: 2512950
Related: odoo/enterprise#18197
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, a traceback would occurs in sale_management calendar view when the user would try to display the popover of a sale_order.
```js
basic_model.js:2399 Uncaught (in promise) Error: for modifier "readonly": Unknown field state in domain
at Class._evalModifiers (basic_model.js:2399)
at calendar_popover.js:203
at Function._.each._.forEach (underscore.js:145)
at calendar_popover.js:180
at async Promise.all (index 1)
_evalModifiers @ basic_model.js:2399
(anonymous) @ calendar_popover.js:203
_.each._.forEach @ underscore.js:145
(anonymous) @ calendar_popover.js:180
Promise.then (async)
_renderEventPopover @ calendar_renderer.js:861
eventClick @ calendar_renderer.js:416
Calendar.publiclyTrigger @ main.js:6981
EventClicking._this.handleSegClick @ main.js:6462
realHandler @ main.js:385
```
It would happen because the domain of the partner_id is ["state", "not in", ['draft', 'sent']] but the state field is invisible="1" in the view.
state was absent during of the evalContext in the _evalModifiers function.
closesodoo/odoo#72617
Taskid: 2524993
X-original-commit: 0d636c0f8dbcfb4b7adda26c0edc02a12b0c7e44
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
When buying a product on website shop, after the payment with SIPS, the
page is redirected to an Error message: "We are not able to find your
payment, but don't worry. You should receive an email confirming your
payment in a few minutes. If the payment hasn't been confirmed you can
contact us."
To reproduce the error:
1. In Payment Acquirers, enable Sips
2. Go on website shop
3. Add a product to the cart, Checkout
4. Pay with Sips
- Visa card number: 4100000000000000
5. Back to Web-shop, if the payment has been successfully processed,
repeat steps 2 -> 4
Error: The message "Your payment has been successfully processed. Thank
you!" is not displayed. Instead, the message "We are not able [...] you
can contact us." is displayed.
This message is displayed when:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L65-L69
i.e., when the transactions list is empty. Here is how to get the list:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L38-L42
It uses the session of the request. The cookie `session_id` is used to
identify the current session. However, after the payment on SIPS, the
page is redirected to `/payment/sips/dpn` with a POST request. Since the
session cookie has the attribute `SameSite=Lax` and the HTTP request is
a POST, the cookie will be filtered out:
https://drive.google.com/file/d/1xfx3YWkfonO3nK-8Rew45uSoR4lkpjpY/view?usp=sharing
(Browser information: This cookie didn't specify a "SameSite" attribute
when it was stored and was defaulted to "SameSite=Lax," and was blocked
because the request was made from a different site and was not initiated
by a top-level navigation. The cookie had to have been set with
"SameSite=None" to enable cross-site usage)
As a result, the server creates a new one. This is the reason why the
transactions list is empty: the list is based on a new session.
Adding the attribute `save_session = False` to the route will prevent
the server from creating a new session cookie and add it in the POST
response.
OPW-2518377
closesodoo/odoo#72611
X-original-commit: 9637a287923c6b82acfd487ed32d6bbc1fdf74b6
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Before this commit, the clickEverywhere test was run for the demo
user on all apps available for the admin. It thus crashed on the
apps that aren't available for the demo user.
closesodoo/odoo#72430
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Before this commit, when we wanted to select first level menus
inside an app (i.e. menus available in the navbar), we could by
mistake select sub-menus if the dropdown was opened (e.g. if it
was previously tested). For instance, it happened in the 'Apps'
app. It then led to wrong index computation, and a traceback. As
a consequence, the nightly build failed as the clickEverywhere test
didn't pass.
Steps to reproduce :
- Install `CRM` and `Sales` modules
- Go to Settings, activate "External Email Servers" and
set an alias.
- Edit 'Sales Team Europe' : add an alias
(ensure alias end with the "External Email Servers" alias)
- Send a mail to the europe sale team alias email with a
base64 image in the html body
ex: <img alt="" src="data:image/png;base64,ABCDE123....789">
Issue :
- Traceback is raised.
("ValueError: Wrong value for ir.attachment.type: 'opportunity'.")
Cause :
Both `crm.lead` and `ir.attachment` have a `type` field.
When creating the thread, in this case of crm.lead model,
it will add the 'default_type' and 'default_team_id' to the
context.
The context will be inhrited and used on the creation of the
ir.attachment (in this case its the base64 encoded image
inside the body).
Since no `type` was provided while creating the ir.attachment,
it will set the type from `default_type` in context since
available.
Solution :
- Clean the context (in this case, it will remove `default_X` values)
when creating the ir.attachment .
opw-2551461
closesodoo/odoo#72613
X-original-commit: 4504c9d8069082c9542226fbafdbf309089cf7a9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the "Edit View" debug item only worked for
kanban, list and form views. For the other views, it opened a
blank form view. The reason is that for the other views, it didn't
correctly get the id of the view to edit.
Bug reported in the wowl-bugs pad
closesodoo/odoo#72523
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
Update PLS frequencies of "no team" leads when unlinking teams. Instead
of loosing those statistics merging them with "no team" is probably better even
if not completely right. Removing teams with a lot of PLS information is
something that is not a primary use case.
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo#70645
ENT PR odoo/enterprise#18266closesodoo/odoo#70645
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Géry Debongnie