Before this commit, evaluating a domain containing a like/ilike
operator with an evaluation context in which the value was false
crashed.
Moreover, those operators were wrong w.r.t. the case sensitivity:
like was case insensitive, whereas ilike was case sensitive, and
both =like and =ilike were case insensitive.
This commit fixes thoses issues.
The first issue was spotted on our prod, as we tried to add an
invisible attrs in a form view, using the ilike operator (it thus
crashed in create mode).
The second issue was spotted while writting the test cases.
To the best of our knowledge, those operators aren't used in attrs
(for now), explaining why those issues haven't been found before.
closesodoo/odoo#70951
X-original-commit: 44e185dbd6ddeda7cdcd76882fa0bd231e9d3f37
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Creating an account move from a valuation layer is bypassed in
case the product is consumable. Since 7fa9ec2638, the signature
of _account_entry_move() changed. It no longer return an account move
but a list of values to create everything in batch.
Testing the product type should now return `[]` instead of `False` in
order to be added to the existing list.
closesodoo/odoo#70945
X-original-commit: 5d76ce38a8551f430449b997a875ccc3b5a728cb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When starting work on a blank website, it was possible to start writing
text in the blank page. However that was never the purpose and things
behaved improperly from there.
This commit addresses that problem by consistently applying
contenteditable=false to the #wrap element when it is empty, and true
when it isn't.
At the same time it fixes the fact that starting with a non-empty page
and making it empty failed to show the empty editor message.
closesodoo/odoo#70933
X-original-commit: c9ab6ae3e1e1859c36a4f6e68a7cae25cf92a7b3
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When changing the number of columns of a snippet, the history was
recorded too many times and at wrong moments, resulting in a mess of
undos to trigger before restoring the original column state.
The issue was due a combination of dead code and the fact that
`_updateColumnCount` triggered `remove_snippet` for each of its columns
while `remove_snippet` in turn triggered a history step at every
execution.
This fixes it by removing the dead code, replacing it where necessary
with a call to the editor's `historyStep` method, and adding an option
to `remove_snippet` so its triggering of a history step can be bypassed.
closesodoo/odoo#70932
X-original-commit: 877e5c807087afed880aeba3eab79def3a7b583c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since the link tools were moved from the modal to the sidebar, the url
autocomplete dropdown stretched out of the bounds of the window.
This fixes that problem while restyling the dropdown to look like the
url pickers we already have in the sidebar. In order to achieve that,
we apply to it the "o_website_ui_autocomplete", used by
UrlPickerUserValueWidget (to which we don't have access in the toolbar).
closesodoo/odoo#70931
X-original-commit: 704583aad98287adac9e13772cfb8ca0933b0a32
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When selecting the contents of a promo code then typing a letter, that
letter was inserted before the promo code instead of in it. It was also
impossible to get back inside the promo code after that.
Given the nature of that snippet it seems reasonable to make the promo
code itself unremovable. This way we can benefit from the editor's
ability to keep the cursor in an empty unremovable inline.
Note: This fix requires a change in the editor:
https://github.com/odoo-dev/odoo-editor/commit/1c98f141458de297a4b819f3fb21f532986e9872.
Do not merge without it.
closesodoo/odoo#70930
X-original-commit: ffe0277613f73e046c4e343cfb0197c937063717
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Following the recent reorganisation of the documentation in 12.0+,
the majority of the documents have been moved and their old links are no longer valid.
Some redirection rules will soon be deployed, but those rules might be dropped in some years
and we want the links to still work, which is why we still replace the links to the new ones.
FW-Port of odoo/odoo#70675 (13.0)
closesodoo/odoo#70920
X-original-commit: bc9c1eef538ba6095e74c19d5d9ed9e01625ec7c
Related: odoo/enterprise#18361
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When building a domain `(=|!=)` with
a Binary field stored in attachment and
the right part of the domain is not null,
the full binary content is logged, giving
the logs a huge size.
Now, the content of the binary is cropped to
20 chars as it is useless to log more.
opw-2527629
closesodoo/odoo#70740
X-original-commit: 0ed46ae94b20b30c10025b2a458e1ecf92c2712d
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before 03025520b rounding applied was eg. for these numbers and UP and
DOWN rounding methods to multiple of 10:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | -2 | -8 | -2 | -8 | -2
UP | 8 | 2 | 8 | 2 | 8
```
which is correct for positive numbers but UP and DOWN are inversed for
negatives numbers.
After 03025520b this became:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | 8 | -8 | -2
UP | -2 | -8 | -2 | 2 | 8
```
which is correct for all cases except for positive numbers that are
before HALF of the precision (eg. number 2) for which UP and DOWN are
inversed.
This is happening because 03025520b uses the sign of the rounded value
=> this does not work for 0 so number 2 is broken (and if fixed number
-2 would be broken).
With this commit, the adjustement of sign is done based on original
number, so we get the equivalent of python equivalent methods:
```
Numbers | -8 | -2 | 2 | 8 | 12
DOWN | 8 | 2 | -2 | -8 | -2
UP | -2 | -8 | 8 | 2 | 8
```
opw-2451841
closesodoo/odoo#70923
X-original-commit: 23dd2ea535bea0a57dcac773a81e202135cd2ed6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The "Starting job X" and "Job X done" logs are very useful to monitor
cron executions over time, or to detect a cron job that has been running
for a long time.
Those logs were dropped by mistake in #62124 - this patch restores them.
closesodoo/odoo#70921
X-original-commit: 0db99a9fb00465266485c7f6c8d16760250152df
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Steps to reproduce the bug:
- Go to Project app
- See the overview of any project
- Select at the top right another company with a different currency. But keep the company assigned to the current project selected
Problem:
The new currency is changed in the project overview, but the values are not converted to this currency.
opw-2479364
closesodoo/odoo#70902
X-original-commit: 7f9cacd40d185bb7c943bd2adb7de1ef8a39c367
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Before this commit, status codes were partially handled and users may not had a proper feedback on the status of their payment.
Task #2517498closesodoo/odoo#69948
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently, the default invoicing policy is based in `delivered`
quantity since commit: https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
but due to that onboarding flow is often broken/very complex.
hopefully the statement 'in countries with anglosaxon accounting, that's mandatory' is exagerated.
So in this commit, Default invoice policy is set (back) to
'Ordered quantity'
closesodoo/odoo#69825
Taskid: 2443371
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit, some requests could be sent to the actual IAP
servers during testing. These calls weren't always mocked as many
of these requests are sent in background while performing usual
tasks such as creating a bill.
Now, any call to the function iap_jsonrpc during testing will result
in an AccessError.
closesodoo/odoo#70925
X-original-commit: f31f1972ff0e35deb3005ce160930b70ddc8e531
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This reverts commit d89562e8fe473692296cb209651beb2ce7a715e4.
Since this commit, the taxes mapped by fiscal position wasn't managed by the _fix_tax_included_price_company method anymore.
Otherwise, some customizations exist on this method that are no longer called.
The 2527940 issue is also due to a remaining bug: the total_excluded price should be divided by the quantity but:
- what if the quantity & price_unit are both signed?
- what if the number of digits for price_unit and the currency are different? Should we skip the rounding of taxes?
Since this commit is not perfect and has a lot of dependencies in others modules, we decided to revert it.
Original PR: https://github.com/odoo/odoo/pull/68997
Revert PR: https://github.com/odoo/odoo/pull/70858closesodoo/odoo#70914
Issue: 2527940
X-original-commit: def7d7bb0231fef38e044803b245c9b990a90216
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, when the user edits the description of a task with
use_pad=True and then change the project of this task to one with
use_pads=False. The description written in the pad server is not copied
in the description field of the task.
This commit copies the content of the pad for this case when the use_pad
changes to become False and description_pad is set.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project B"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the "Project A". With this change,
the collaborative pad is disabled for this task since the Project A has
not the pad, and then the description field is empty rather than have
the content that we have just written.
task-2515150
closes#70401closesodoo/odoo#70917
X-original-commit: 32a8f598d6a958f2a08b204524007cc075697fda
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Before this commit, in Project App, when the "Collaborative Pads" is
enabled in the Settings of this app, if the user create a task without
project or in a project that has not the pad enabled and he writes a
description for his new task and select (another) project in which the
pads is enabled then the description field in the form view changed to
have the collaborative pad and the problem is the description is not
copied in the pad and seems erase/delete for the user.
This commit checks if the pad_content_field is not empty after
generating the pad url for the new task/record, if it is the case then
we copy the content in the pad and the user can continue his edition
before saving the task/record.
Step to reproduce:
-----------------
1. Go to Settings of the Project App and enable the Collaborative Pads
2. Go to the Project App, in the Projects dashboard (kanban view of projects)
3. Create two Projects (one called "Project A" and the other called "Project B")
4. Edit the Project B to activate the pad, that is, check the Use
collaborative pads checkbox.
5. Go to the view list of tasks in the "Project A"
6. Click on "Create" button to create a task in the task form view.
7. Write a description for this task.
8. Change the project of this task by the Project B. With this change,
the collaborative pad is actived for this task since the Project B has
the pad, and then the description in the pad is empty rather than have
the content that we have just written.
task-2515150
closes#70401
X-original-commit: d2b55c775d705128fa65c859c5f47bdaf4b705fe
- fix missing access rights when handling feedback data
- redirect customers to the payment confirmation page when notification
data are not acknowledged by PayPal, rather than displaying an
internal server error
task-2494916
closesodoo/odoo#70885
X-original-commit: 948c22243c88dd905f1a7838f6fba75f44f06b2a
Related: odoo/enterprise#18349
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
In Ogone's backend, it is possible to remove `CARD.CARDNUMBER` from
Flexcheckout's feedback data (Configuration -> Technical information ->
Transaction feedback -> Alias gateway and Tokenization -> Dynamic
parameters). Since this is the configuration that was suggested to Odoo
customers migrating from a previous version, we must be able to process
feedback data when the card number is missing.
This commit creates an anonymous card number ('XXXX...') if one is not
provided by Ogone.
task-2494916
closesodoo/odoo#70896
X-original-commit: 272c4259624d88e2d061c6418109d4e0c2dbfb2d
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Issue
- Install "Contacts" & 'base_address_extended' modules
- Go to contacts and create a contact with value:
- street name : Chaussee de Namur
- House : 40
- Save and edit again
- Set country to 'Netherlands' then save.
Address not splited well (wrong values for street name and house).
The issue is not present in UI but is in tests.
(Issue in UI from odoo 14.0+)
Cause
There is 2 '_split_street_with_params'
(inverse function that set street fields):
- partner_autocomplete_address_extended (removed in 14.0)
- base_address_extended
The 'spliting' logic is not the same in both function.
In UI, looks like it does not call '_split_street_with_params'
from 'base_address_extended' since no super(Partner, self)...
However in testing, it does call it from module
'base_address_extended' and therefore trigger the issue.
Solution
Adapt _split_street_with_params function
(in 'base_address_extended' module):
If previous field (from 'street_format') to parse
in 'street_raw' is 'street_name', then:
- set `tmp` to: splitted (max 1 split) street_raw
with current field seperator
- set `append_previous, sep, tmp[0]` to:
splitted tmp[0] (first part of splited street_raw) with `rpartition(' ')`
- add 'append_previous' to 'street_name' value
- join 'tmp' values and set it to street
(should equal to what left from `rpartition(' ')` split
+ seconf part of first normal split)
- continue normal parsing flow
opw-2476096
closesodoo/odoo#70886
X-original-commit: 74116c982a5ddef65a05ef90017ac4ce63bdf58f
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When partner is not selected, Odoo sends name_search request
`[..., ('partner_id', 'child_of', [False])]`. It's not obvious what does such
domain mean ( see #70584 ). This commit clarifies what do we expect to get:
we want all records without restrictions on `partner_id` value.
This also fixes performance issue because domain leaf `('partner_id',
'child_of', [False])` is converted to where-clause `<table>.partner_id in <all
or almost all ids>`
---
opw-2524010
closesodoo/odoo#70873
X-original-commit: 39e0f1fb0f60f309be7f65562911b1236167dce7
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When clicking on "CRM -> Reporting-> Leads (Leads Analysis)" list and form
views are not correctly set, leading to opportunity views. In this commit we
* have changed the list view from ``crm_case_tree_view_oppor`` to
``crm_case_tree_view_leads`` to ensure we use the right view;
* we are now able to open form view from the list view like all other views;
When clicking on "Teams -> Reporting (on a team vignette) -> Leads" list
view used is the opportunity one. We fix it by correctly setting action
views for ``action_report_crm_lead_salesteam`` reporting action.
Task-id : 2497936
closesodoo/odoo#69575
Related: odoo/enterprise#18338
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The FieldChar and the "Emoji" fields support a "onchange_on_keydown" attribute
that allow triggering the onchange event when the user types into the field.
(Instead of having to wait for a blur event).
This is especially useful, for example, in the social module to refresh the
post preview when the user is typing his message.
The current strategy to avoid spamming this onchange event was to throttle the
method to trigger it at most once every second.
However, triggering it every second could still be problematic in terms of
performances and could cause loading issues (e.g: if you have a large GIF in
your post preview)
To try to mitigate this issue, we changed the strategy from throttle to
debounce and changed the delay to two seconds.
Meaning the onchange will be triggered 2 seconds after the user is done typing,
which still gives a nice "live update" effect without triggering the onchange
too much.
Task-2500821
closesodoo/odoo#69023
Related: odoo/enterprise#17573
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when you click the stat button "x Courses" on a contact, you land
on the dashboard of the courses that this user follows. But this information
in not much useful here. You'd like to see information like progress of this
member for each courses, or when the member was last active on a specific
course.
With this commit, when you click the 'x Courses' stat button from a contact,
you will see the list view of model 'slide.channel.partner', having the
default filter for the contact from which you clicked the button. This will
show the additional and relevant information you need, and by removing the
filter, you'll be able to see info about all the attendees and their progress
on courses they follow (Note that here if the partner is a company, you
won't get default filter set but the records will be filtered by domain,
because we need to show courses of current contact and it's children, and
so we have to set domain in action, instead of adding default filter in
action context).
The same way, on the Attendees View of a course (when seeing attendees from the
course dashboard), we add 'Last Action' field, and instead of fixed domain, we
use filter to view attendees of a particular course, removing which can allow
us to view information about all the attendees from all courses.
We also introduce new 'Attendees' menu under 'eLearning > Reporting' that will
show information about all the attendees from all courses, with a default group
of channels
Task Id-2409447
closesodoo/odoo#64152
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The module `@web/js/libs/pdfjs` was imported in the legacy file by PR #70375.
So the file has to be added in external_lib bundle.
closesodoo/odoo#70755
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Move the meeting stat button and kanban pill from CRM to Calendar, purpose is to
allow its usage even if CRM is not installed as this makes more sense since this
field is usually related to Calendar.
Increase query number limit in company leave test, in order to take into account
the newly introduced query in Calendar.
UPG-PR: https://github.com/odoo/upgrade/pull/2423
Task-2514473
closesodoo/odoo#69846
Related: odoo/upgrade#2423
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit,
We were checking for multiple `active_ids` before checking for `active_model` in context,
which was blocking point if user want to use this model with `active_ids` with
different `active_model`.
With this commit,
we are checking condition of multiple `active_ids` if `active_model` is `stock.picking`.
so other users can use this model with `active_ids` without changing any flow.
closesodoo/odoo#70772
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, the wrong many2one value could have been
selected in the tour, making it fail later on with the following
error:
```
AssertionError: The test code "odoo.startTour('sale_timesheet_tour')" failed
Tour sale_timesheet_tour failed at step Click on this stat button to see
the SO linked to the SOL of the task. (trigger: button[name="action_view_so"])
```
closesodoo/odoo#70789
X-original-commit: 4210d7663600027d39ccb88b0bcd6e1422f2d452
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Beforehand, when display the journal entries from a bank statement,
some fields (Due Date, Next Activity, Payment status) that are not very
relevant were displayed.
Now, we use the bank & cash view to display the bank statement in a more relevant manner.
closesodoo/odoo#70811
Task: 2459562
Signed-off-by: William André (wan) <wan@odoo.com>
When exporting the tax report's monthly xml with enterprise, the file wasn't accepted by the government in case 0% taxes were used.
Grid 033 is optional, and can be used for custom tax rates. If specified, it MUST always go with grid 403 (giving the tax rate) and 042 (giving the tax amount). In Odoo, we made the choice to use it for 0% taxes, so 403 and 42 will always be present, and always 0.
In community, grids number were missing on the lines' labels, and the codes (used to retrieve the value of each grid when generating the XML) were not correct.
closesodoo/odoo#70792
X-original-commit: add187862f627c4340ef7ca49d8a75e149cb12f5
Related: odoo/enterprise#18305
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When using the boxed layout, if the business document has a table, its
first row (after the table head) will have a bottom border and the last
cell in the row has a white background.
To reproduce the error:
(Need timesheet_grid. Use demo data)
1. In Settings > General Settings, Change Document Template:
- Select the second template
2. In Timesheets, select list view
3. Select several lines
4. Print > Timesheet Entries
Error: In PDF, the first timesheet line has a bottom line and its last
cell has a white background (instead of grey).
The bottom line should only be applied on row in table header. The
background color should also be applied on first row in table body.
OPW-2478311
closesodoo/odoo#70771
X-original-commit: 88a10bdd8f1d46a8b52be59fe3284cbe284a74f2
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Create a draft payment with payment type and 0 amount.
Save.
The payment type will be overwritten
opw-2495461
closesodoo/odoo#70626
X-original-commit: 86a2819697d5d9d1c32ba902d8a1089acf6110f2
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Purpose is to avoid randomly failing tess depending on how leads are allocated
through teams. We achieve that purpose by
* creating more leads, easing their repartition through teams;
* adding a lower and upper bound test for team allocation to ensure weights
are globally ok;
* changing member assign domain to fit more closely test lead data;
We also improve test by using the ``crm.assignment.commit.bundle`` config
parameter that has an impact on lead duplicates removing and therefore
performances.
LINKS
Task ID-2528906
COM PR odoo/odoo#70756
Followup of Task ID-2489951 (assign process improvements)
Followup of odoo/odoo#70172 (smoother assign process)
X-original-commit: 8fdf97b6498adc0a2fb15e360ebbbaa1672534e5
In case X several recurrences are processed in the same cron execution,
only the last recurring task was created X times, while the other tasks
were not created. There is also a missing id preventing a correct use of
the default stage for the new created task.
closesodoo/odoo#70784
X-original-commit: 5ea2fcbecf572be24af9b2aac76de9e5d5709d2c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
On large database with million of messages made by one partner.
When you try to update the image of partner, it take lot of time (CPU time limit).
closesodoo/odoo#70786
X-original-commit: b44272a662468d164277b265d33ba6f46e631118
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The `search` function of the `re` package can return `None` if the
provided string does not match with the provided pattern
(https://docs.python.org/3/library/re.html#re.Pattern.search).
On the `_parse_youtube_document` function of the `slide.slide` model,
we are directly accessing the capture groups from the returned value
of the `search` function without checking that the returned value is
actually a 'match' object. As a result, an exception can be throw if
there is no match as, in that case, the `search` function will return
`None` and the `group` function will not be defined on `None`.
To avoid throwing an exception, we will check that the returned value
of the `search` function is not `None` before accessing the capture
groups via the `group` function.
LINKS
Task id: 2525007
closesodoo/odoo#70763
X-original-commit: 575a524474fe8866cc71b3befc6bbbde8d73075e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS: TEAM ALLOCATION
Team assignment has to be updated as we may have team domains that overlap.
We therefore remove maximum number of leads to allocate to teams. Instead all
available unassigned leads are allocated within teams.
- Solution: assign all available leads and not a count based on team's
capacity. This notably reverts the main goal of odoo/odoo@6df2f0c
(see odoo#48422)
This assignment process is done proportionally to the team capacity. It is
computed as the sum of each member's maximum assignment counter. This means
that with a team having twice as much sale capacity than another team sharing
the same domain: first team should receive about 2/3 of leads while the second
one should receive the remaining 1/3.
- Solution: assign lead one by one. Choose a team randomly using a weighted
random algorithm, based on team's members capacity.
SPECIFICATIONS: MEMBER ASSIGN
Counting every lead whatever its state may lead to an inconvenient situation.
Moreover salespersons may opt-out from assign by setting their max capacity
to 0, for example when going on holidays.
When doing that lead assignment is not smooth and getting back to a full
pipe may take several days. To solve that issue a compensation is added in
assignment quota done to sales people. Salespersons having few leads will
get a boost in assign as soon as they get back in assign process. When being
near maximum compensation is nearing 0 and daily quota is given.
ENSURE SALES PERSONS PIPE FILLING
Counting every lead whatever its state may lead to an inconvenient situation.
If a salesman always reaches its maximum every days he will always receive the
number of lead he got 30 days ago. For example if the salesman goes in holidays
for few days and set the max to 0 he receives no lead during his vacation.
Then after a few days of assign he reaches its maximum and receive 0 leads
for a few days. This leads to having windows of leads that repeat themselves
every 30 days.
* Solution: do not limit at maximum capacity anymore. Compensation is voided
if limit is achieved. However asked assignment is done. Salesman could
receive more than its max capacity but 30 days window ensure old leads
are regularly going out of count.
``assignment_max`` is now more a mean target of leads to be assigned during
a 30 days window than a real maximum capacity. Field is renamed accordingly.
WORK DAYS / CRON TIME CONFIGURATION
When running the cron is should assign leads based on its frequency. If cron
runs once every day, work_days given to sub methods should be 1. If it runs
more than once day it should be less than 1. We therefore remove the *2
multiplier and support fraction of days.
As assign process changes in this merge, assigning more strictly compared to
salespersons capacity will not be an issue anymore. Assign process is best
designed to run every few hours (~4 times / day) or each few days. Code and
work_days are updated accordingly.
PERFORMANCE
During team assignment setting team on leads one lead at a time may cause
performance issue. As PLS is computed at each flush we want to flush after
a bunch of lead. For that purpose we need to avoid too much commits and
also avoid to search for duplicate at each assignation.
We therefore perform the search for duplicates before going into allocation
and use a cache through loops to ease using pre-fetched information.
Unlinking duplicates at each iteration is also sub efficient as it causes
recomputation or invalidation. We therefore aggregate all duplicates to
unlink and unlink them in the main team-based loop instead of the sub loop
that is lead-based.
LESS AUTO COMMITS
During team assignation, assigning lead one by one may cause performance issue.
Since PLS is computed at each flush, so we want to flush after a bunch of lead.
To solve that we obviously need to not commit at each assignation but
also avoid to search for duplicate at each assignation, that why the
search for duplicates is done at the beginning of the process and stored
in memory.
ASSIGN WON / LOST LEADS USAGE
In this merge we also
* use stage instead of probability to exclude won duplicated leads in order
to include leads with 100% but still not won;
* count all leads in lead_month_count used in assign to effectively compute
sales persons workload;
* keep team when assigning and deduplicating leads instead of erasing
master opportunity team;
* crm: correctly filter out won and lost leads for assignment using
stage;
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172closesodoo/odoo#70723
Forward-port-of: odoo/odoo#70664
Forward-port-of: odoo/odoo#70172
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add a test ensuring ``assignment_optout`` works as intended. Salespersons
being opt-out from assign process should not receive any leads. This replaces
setting ``assignment_max`` to 0 (which is still a working trick). This commit
is a followup of odoo/odoo#68476 (done in a rush), and done in a specific
commit to avoid messing with forward-port.
Task ID-2497077
COM PR odoo/odoo#70664
X-original-commit: 813016e77b6abf9032059725a8725f693b132b58
PURPOSE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS
Counting every lead whatever its state may lead to an inconvenient situation.
If a salesman always reaches its maximum every days he will always receive the
number of lead he got 30 days ago. For example if the salesman goes in holidays
for few days and set the max to 0 he receives no lead during his vacation.
Then after a few days of assign he reaches its maximum and receive 0 leads
for a few days. This leads to having windows of leads that repeat themselves
every 30 days.
* Solution: do not limit at maximum capacity anymore. Compensation is voided
if limit is achieved. However asked assignment is done. Salesman could
receive more than its max capacity but 30 days window ensure old leads
are regularly going out of count.
``assignment_max`` is now more a mean target of leads to be assigned during
a 30 days window than a real maximum capacity. Field is renamed accordingly.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: 3d1841f26ce64f0106122e48750d2c653ea9790f
Co-authored-by: Thibault François <tfr@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
PURPOSE
All unassigned leads should be assigned to teams as soon as possible to ease
lead analysis.
Purpose of assign thresholds is to ensure sales people receive at least this
amount of leads within 30 days, counting lost and won leads. Giving them leads
regularly is also one goal of automatic assign.
SPECIFICATIONS: TEAM ALLOCATION
Team assignment has to be updated as we may have team domains that overlap.
We therefore remove maximum number of leads to allocate to teams. Instead all
available unassigned leads are allocated within teams.
- Solution: assign all available leads and not a count based on team's
capacity. This notably reverts the main goal of odoo/odoo@6df2f0cfc0
(see odoo/odoo#48422)
This assignment process is done proportionally to the team capacity. It is
computed as the sum of each member's maximum assignment counter. This means
that with a team having twice as much sale capacity than another team sharing
the same domain: first team should receive about 2/3 of leads while the second
one should receive the remaining 1/3.
- Solution: assign lead one by one. Choose a team randomly using a weighted
random algorithm, based on team's members capacity.
SPECIFICATIONS: MEMBER ASSIGN
Counting every lead whatever its state may lead to an inconvenient situation.
Moreover salespersons may opt-out from assign by setting their max capacity
to 0, for example when going on holidays.
When doing that lead assignment is not smooth and getting back to a full
pipe may take several days. To solve that issue a compensation is added in
assignment quota done to sales people. Salespersons having few leads will
get a boost in assign as soon as they get back in assign process. When being
near maximum compensation is nearing 0 and daily quota is given.
PERFORMANCE
During team assignation, assigning lead one by one may cause performance issue.
Since PLS is computed at each flush, so we want to flush after a bunch of lead.
To solve that we obviously need to not commit at each assignation but
also avoid to search for duplicate at each assignation, that why the
search for duplicates is done at the beginning of the process and stored
in memory.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: 83f72711e7affa8b0ad997b9ee262326e9577d54
When running the cron is should assign leads based on its frequency. If cron
runs once every day, work_days given to sub methods should be 1. If it runs
more than once day it should be less than 1. We therefore remove the *2
multiplier and support fraction of days.
As assign process will soon change, assigning more strictly compared to
salespersons capacity will not be an issue anymore. Assign process is best
designed to run every few hours (~4 times / day) or each few days. Code and
work_days are updated accordingly.
LINKS
Task ID-2444908 (assign fixes)
Task ID-2489951 (assign process improvements)
COM PR odoo/odoo#70172
X-original-commit: c59ba43d1e9eb0c016b9a113c9475dec28fa413b
Aaron Bohy