The "BoM Structure report" should not include the cost of the products
as it is often shared with third parties. We now only display the cost
on the "BoM Structure and Cost report" and remove the "BoM Cost report"
as it is redundant with the former.
Task Id: 1969709
closesodoo/odoo#33323
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a mailing campaign
- Create a mailing 1, set the subject to "Test 1"
- Create a mailing 2, set the subject to "Test 2"
The subject of mailing 1 is set to "Test 2".
When checking the code, this behavior seems the one expected. The
`_rec_name` of a mass mailing is the `subject_id`:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L437
Moreover, there is an onchange to set the subject in line with the
subject of the campaign:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L608
However this behavior is not present up to v11, and only appears in v12.
Surprisingly, this is due to an unrelated improvement which adds the
field in the view (in debug mode): 5b0bcaef3e.
Up to v11, the onchange exists, but since the fields are not in the
view, it has no effect. However, in v12 the fields are in the view so
the onchange has an effect.
Since this was the behavior up to v11, and that the behavior is fixed
in f50fbc6d16, we keep it consistent in v12 as
well.
opw-2007764
closesodoo/odoo#34028
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, those pages would be flag as noupdate.
If not modified, those view would not get modification on module update, which
is not logic.
Now, those view will benefit from any update. It makes even more sense since
multi-website as those views will never get modified directly (it will COW).
closesodoo/odoo#33920
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The tests relative to workcenters planning takes (sometimes) long time
to be executed. Before investigation more deeply, this commit relax a
bit more the tolerance delta in the test comparison
closesodoo/odoo#33939
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit aims to propagate the cancellation of a purchase order or a
request for quotation to the relative stock moves. And thus respect the
configuration of the stock rule.
Task 1913297
closesodoo/odoo#33803
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
cancelling propagation in a move chain was True be default. That means,
without any configuration, a cancel move will always cancel its next ones
This commit change the default to allow only cancelation of move chain
until the stock location. Here are 2 examples :
1. Reception and delivery in 3 steps. The moves chain is the following:
Vendor -> Input -> Quality -> Stock -> Pack -> Output -> Customer
In case the Purchase order is cancelled, we want to move from Vendor to
Stock are cancelled but not the ones from Stock.
2. pbm + sam. The manufacturing process is the following;
Stock -> Pre-prod -> Production -> Post-prod -> Stock
cancelling the first move should cancelled until Production and not after
Task : 1913297
This new Predictive Lead Scoring (aka PLS) replaces the stage based probability mechanism.
It uses Naive Bayes probability computation theorem.
The lead probability is now computated automatically based on multiple criteria (= frequency fields).
Some are mandatory and will always be used, some are optional and can be activated
in the settings.
- Mandatory fields :
- team_id
- stage_id
- tag_ids
- Optional fields :
- email_state (validity of the email_from field: correct / incorrect or empty if email_from is empty)
- phone_state (validity of the phone field !! not the mobile one !!: correct / incorrect or empty if phone is empty)
- country_id
- state_id
- source_id (UTM Source)
PLS uses a start date to consider only the lead created after that date to generate the frequency table
and to recompute the lead probability. This date is also configurable in the CRM settings.
Default start date is date.todays() (at module install).
The settings for PLS are NOT company related :
PLS Fields = Many2many to a model that store only the fields allowed for PLS computation.
PLS Start Date = Date
As Date and Many2many fields are not allowed for config_parameters,
Char fields are used to store the configuration
and Date and m2m fields are used to ease the configuration by the user in the config panel.
Date and m2m fields are both computed fields based on their corresponding Char fields.
Char field for Date store a strigified date.
char field for Many2many store a comma separated string which is a list of activated fields.
Each mandatory field is used in a specific way
- Team_id : the frequency table is split for every team_id, plus once for leads that don't have a team_id.
Considering Lead A from Team 1 and Lead B from Team 2.
Even if Lead A and Lead B have the exact same attributes (country, phone, email,stage, ...),
their probability will most likely not be the same.
That's because each teams compute their leads' probability based on their own won/lost leads.
- Stage_id : if no optional fields are activated and if there is no tag on the lead,
this will make PLS work quite the same way as it was working with removed stage based probability,
as only the stage will count in the computation.
But here, instead of fixing manually the probability for each stage,
this stage related probability is automatically computed based on past experience (won and lost leads).
- Tag_ids : each tag is considered separatelly, as if the lead had only one tag.
(no link between tag on same lead is made). To avoid that a tag take to much importance if his subset is too
small, we include the tag frequencies in the frequency table only if at least 50 won or lost leads had this tag.
The frequency table is a table where all won and lost leads are aggregated by fields
(mandatory or optional if activated). For each team_id / field couple, we store the number of
won and lost leads that has that fields values.
For example: Lead A is assigned to team 1 and client comes from France and has been won.
If we consider only this lead A, the frequency table will looks like :
id | variable | value | won_count | lost_count | team_id
--------+-------------+-------+-----------+------------+---------
1 country_id FR 1 0 1
To computed the probability of a lead, we get all the records for the frequency table
that match all fields (per team_id) and we compute a won score and a lost score.
The probability is computed and normalized based on those scores
- P = S(Won) / (S(Won) + S(Lost))
Considering two variables A and B :
- S(Won) ∝ P(A∩B | Won)*P(Won) = P(A|Won) * P(B|Won) * P(Won)
- S(Lost) ∝ P(A∩B | Lost)*P(Lost) = P(A|Lost) * P(B|Lost) * P(Lost)
To overcome the 'zero frequency problem',
we do not start at 0 for the won or lost count for each variable / value combination.
It suggested to start at 1, but to avoid that a small subset take to much weight compared to
a larger one, we start at 0.1.
For example :
If we start at 1 : If team 1 has few records from France,
it can get high probability to win even if every lead where lost.
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 1 7 1 0.125
country_id FR 198 7306 2 0.0263
If we start at 0.1 :
variable | value | won_count | lost_count | team_id | Probability
-------------+-------+-----------+------------+---------+-------------
country_id FR 0.1 6.1 1 0.0161
country_id FR 197.1 7305.1 2 0.0263
The more we have records for each couple, the more the computation become precise.
The allow the user to decide himself which probability should be set on the lead,
a manual probabiltiy system has been implemented using 2 stored fields + 1 computed field :
- probability (stored): Probability set on the lead, can be set manually in the lead form.
- automated_probability (stored): Probability computed by PLS.
- is_automated_probability (computed): If both previous fields are equal, the probability is considered
as automatic. and each time the automated_probability is updated, the probability is aligned.
If both are not equal, the probability is considered as manual. The automated_probability is still
updated but the probability is not aligned. The user can reset the probability in automatic mode
by clicking on the estimated probability displayed in edit mode in the lead form.
probability and automated_probability are not computed fields as they are manually computed at write and create.
The computation is triggered if one of the activated frequency fields is modified or set.
To trigger also the computation when modifying the lead values on the lead views (form and kanban),
_onchange methods have been added for each frequency field.
Also, a cron has been added to run every day to rebuild the frequency table and to recompute all active
and pending leads (not won nor lost) probability.
Task ID : 1925439
PR #33589
remove rerun cron on action lost and won
This commit prepares the next Predictive Lead Scoring (aka PLS) ones.
With the new PLS implementation, stage based probablility is not relevant anymore
as the probability will be computed based on multiple criteria
following the Naive Bayes probabilist theorem.
To determine if the stage is a won stage, a new 'won_stage' boolean field replaces
the old probability field that is now removed.
won_stage = True is equivalent to stage.probability = 100.
Task ID : 1925439
PR #33589
This commit moves phone validation from bridge module to crm directly.
This commit prepares the PLS feature (see next commits).
PLS needs the phone state to evaluate the probability to closes a lead.
So as crm will depend of phone_validation, the content of the bridge
module is moved in crm module.
Task ID : 1925439
PR #33589
As Flanker can be used to validate an email address and was originally
used in website_crm_score module, the Flanker usage is now moved into tools.
This commit prepares the next Predictive Lead Scoring (aka PLS) ones
as PLS will use the email state as computation variable,
it will need this flanker validation to compute first the email state.
We use also the already implemented normalized email as a double validation.
Flanker is not in the required dependencies of Odoo :
So if flanker is installed, it will check if email is valid
(checking DNS and other standard rules).
If Flanker is not installed, email_validate will only normalize the email.
Anyway, the email must at least be normalizable.
Task ID : 1925439
PR #33589
Have a translation linked to a record unreadable because of a record rule
(e.g. a product that is not shared between companies).
Display the translations list view; if one such translation is in the view,
it will raise an access error.
When computing the source value, _compute_source will fail to read the record,
and raise an access error.
This will make it impossible to access untranslated terms.
Instead we guard this error.
Since it is displayed in the view, we display an informative message.
Note that since we make this error go away, we also fix the check method.
Only the superuser bypasses the record rules; so if we made the check on write
with _is_admin, it means than a user in group_erp_manager cannot read a record
but can edit its translations.
opw 2000817
closesodoo/odoo#33989
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Purpose of this commit,
Salesperson does not need email notification as there is not implied action
to perform salesperson side. It's just polluting the user's mailbox.
What matters is the order confirmation, and they already receive the email.
So when a quotation is viewed by the customer, salesperson will no more receive
an email that customer has viewed the quotation.
task-1950368
closes: #34004
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Instead of date_init/date_update, let the ORM use its own fields
This is a part of an effort to clean old models created before the use
of the ORM was generalized.
ir.model.data model also has date_init and date_update columns but
this may be changed later as more prone to side effects
closesodoo/odoo#34988
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The check for abstract driver classes results in some errors being logged on the iot box.
Since this check is not essential at this point, it was removed and will be reintroduced later
if needed.
closesodoo/odoo#35014
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Purpose of this commit is to help designers seeing lessons state, notably
published, and modifying it directly from frontend.
The unpublished courses card are now a little bit translucent
and there is a 'unpublished' tag to clearly show their state.
Task 2033052
closesodoo/odoo#34880
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Actually, when a browser_js test is running, screencasts and screenshots
are saved only if a "--logfile" parameter is specified.
This is problematic with the runbot because '--logfile' arg is not
provided when running tests. Also, in most situations, developpers
prefer to have logs on stdout.
With this commit, two CLI args are added to specify screencasts and
screenshots directories. If no screenshots dir is provided, it defaults
to "{tmp_dir}/odoo_tests/{db_name}/screenshots".
It means that screenshots are always enabled during browser_js tests.
If screencasts arg is given, it enables screencasts and save them in
"DIR/{db_name}/screencasts". If the screencasts parameter is "1", DIR
will be the same as for screenshots.
The ffmpeg tools is used to encode frames into a video. If the ffmpeg
tool is not found on the system, the frames are kept as pngs files
instead.
closesodoo/odoo#34640
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, in collapse category list, if the children of a category
are currently hidden due a search not including them, the parent category would
still be displayed as having expandable children, but clicking on the expand
button would have no effect.
After this commit, the expand button will not be shown if the children are not
shown.
PR: #34249
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Use the pivot table instead of a mapping on all found products (which does not
scale well at all when there are many products found).
On a test case of 10000 products and 300 categories (including parent/children),
testing the /shop page with a search:
- number of queries from 138 down to 128 queries,
- total request time from 0.55s down to 0.40s
- time of the changed line from 32% of the total request time down to 10%
PR: #34249
The parent categories can be retrieved directly from the current category by
using the efficient `parents_and_self` field.
This also prevents computing the parents on the controller for no reason when
not using the collapse view.
PR: #34249
Speed up:
- all queries involving `child_of` and `parent_of` by using
´_parent_store=True` and `parent_path`
- `name_get` by also taking advantage of `parent_path`
- `order by` by indexing the sequence
This reduces the time of the corresponding search lines by 20%.
PR: #34249
When search is used, include the search term in the message.
When categories are used, include the category in the message.
Prevent editing the "click new" message shown to the sales manager.
PR: #34249
*base,hr,lunch
From now on, search panels can be activated on any multi-record views, and are no longer
restricted to kanban views.
The arch of the search panel has to be specified in the search view.
HR and lunch usecases have been adapted accordingly.
Task 1985921closesodoo/odoo#34219
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Rev. e264eca enabled the search with 'child_of' operator for
categories on many2one fields. However, it crashed if there is no
parent_field on the comodel.
Before this rev. the searchpanel could only be activated in kanban
views (and it was specified in the kanban arch). From now on, the
searchpanel can be activated in any multi record view. It's arch
is moved to the search view arch (inside the <searchpanel> tag).
Task 1985921
Co-authored-by: Aaron Bohy <aab@odoo.com>
A share button has been added to the fullscreen view to avoid
exiting the view to access the share tab on the full description
of the slide.
Task ID : 1984509
closesodoo/odoo#33418
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the commit is to ensure parent and child partners have the
same company. When creating a new child in another company and one of them
tries to log a message on other contacts an error is raised due to
multi company record rules.
It makes no sense to have child contacts belonging to separate companies.
If parent is set on contact then the company_id should be readonly and
it will automatically set the parent's company_id.
Task-1934813
closes: #32405
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The button wasn't displayed when going through a template's variants
stat button. It was missing an inherit on this view. We also try to
align them the best we can.
task-2029011
closesodoo/odoo#34682
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose of this commit is to ease slides / lessons management in eLearning
frontend.
The publisher will now be able to see if a slide is in preview mode from
the slide list in frontend of eLearning.
He'll be able to activate/deactivate the free preview mode with a button.
Task 1999705.
closesodoo/odoo#34182
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of the commit is to improve the user experience of the chat by
deleting some extra step that might be unnecessary
So when a user tries to remove him/her self from the follower, it will not ask
for confirmation and removes the user from particular document straight away
without any confirmation.
If user remove the another partner from follower then it will raise the prompt
dialog for confirmation
task-1998188
Closes: #34050
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
When we change job_id on an applicant, we want that the stages above
change (if there arre special stage for this job).
On website recruitment, a traceback prevent to complete the form to
apply for a job.
closesodoo/odoo#34981
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Indeed we don't rate slides, we rate courses. Therefore rating mixin is not
necessary as well as access token.
Access token field as we are using the _mail_post_access and a karma check.
Commit linked to task 1952064.
Purpose of this commit is filter that allows to
filter by messages is not working properly so
removed messages filter from custom filter menu
task-1939953 closes-#34141
closesodoo/odoo#34141
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
PURPOSE
Provide fixes to SMS behavior, notably in composer.
Better integration in various applications: contacts, calendar, crm.
Allow to automatically send SMS from server actions.
SPECIFICATIONS
See sub commits for more details.
Linked to task 1925950 and 1935280
closesodoo/odoo#34864
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Christophe Simonis