GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Make final integration of members management by taking into consideration
both multi-membership and automatic lead assignment features.
Correctly hide assignment options and fields if auto assign is not activated.
This means that
* when being in mono membership mode without automatic assign: display
users on team form view;
* when being in multi membership mode or with automatic assign: display
members o2m records, as configuration is done on this model;
* hide the whole right column in sales team form view about assignment when
assignment is not activated in settings;
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Move sales team automatic lead assignment from website_crm_score (enterprise)
directly into sales_team. Some cleaning and renaming is performed while moving
the code as it is old fashioned.
Scoring feature is removed completely from lead assignment. Indeed we consider
PLS is a better feature and provides more accurate results.
Minimal scoring specific field on team is removed. Indeed it can also be
integrated directly into domains linked to a sales team as this is a field
directly available on lead using ``probability``. It allows to reduce fields
of team model and move all logic in the team's domain itself.
Overall behavior as been kept as close as possible from the original one.
Purpose is to avoid too much undesired changes between versions.
In this commit we also add tests for automatic lead assignment.
ASSIGNMENT PROCESS DESCRIPTION
1- LEAD TO TEAM ALLOCATION
Allocate leads to teams given by self. This method sets ``team_id`` field
on lead records that are unassigned (no team and no responsible). No
salesperson is assigned in this process. Its purpose is simply to allocate
leads within teams.
Heuristic of this method is the following:
* first we randomize all teams;
* then for each team
* find unassigned leads, aka leads being
* without team, without user -> not assigned;
* not in a won stage, and not having False/0 (lost) or 100 (won)
probability) -> live leads;
* if set, a delay after creation can be applied (see BUNDLE_HOURS_DELAY)
parameter explanations here below;
* keep only leads matching the team's assignment domain (empty means
everything);
* assign maximum BUNDLE_SIZE leads to the team, then move to the next team.
This is done to ensure every team will have leads enough to fill its
capacity based on its domain;
* when setting a team on leads, leads belonging to the current batch
are also merged. Purpose is to clean database and avoid assigning
duplicates to same or different teams;
* for all teams that still have capacity (aka: a search on unassigned
available leads with team domain still give results), do another
assignment round. Each round teams are randomized so that team order
is not always the same;
Note that leads are assigned in batch meaning a team could receive leads that
could better fit another team. However this heuristics is based on hypothesis
that team domains do not overlap. Indeed if a company has several teams they
will probably target separate market segments: country-based, customer type or
size, ... Having several teams using same assignment domain could lead to less
fairness in assignment process but this should not be the target use case of this
heuristic.
Leads are allocated by batch. This can be configured using a config parameter.
Batch size depends on cron frequency, lead pipeline size and members assignment
maximum. Finding an optimal heuristic for this parameter is not easy as it
depends on internal processes and organization. Higher batch size leads to
better performances when running automatic assignment. It can also give unfair
results if teams domain overlap or if pipeline is not big enough to fill all
teams capacity.
2- LEAD TO MEMBER ASSIGN
Main processing method to assign leads to sales team members. It also converts
them into opportunities. Its main purpose is therefore to distribute team
workload on its members based on their capacity.
Preparation
* prepare lead domain for each member. It is done using a logical AND with
team's domain and member's domain. Member domains further restricts team
domain;
* prepare a set of available leads for each member by searching for leads
matching domain with a sufficient limit to ensure all members will receive
leads;
* prepare a weighted population sample. Population are members that should
receive leads. Initial weight is the number of leads to assign to that
specific member. This is minimum value between
* remaining this month: assignment_max - number of lead already assigned
this month;
* days-based assignment: assignment_max with a ratio based on ``work_days``
* e.g. Michel Poilvache (max: 30 - currently assigned: 15) limit
for 2 work days: min(30-15, 30/15) -> 2 leads assigned
* e.g. Michel Tartopoil (max: 30 - currently assigned: 26) limit
for 10 work days: min(30-26, 30/3) -> 4 leads assigned
Assign process then follows the following heuristic
* take a weighted random choice in population;
* find first available (not yet assigned) lead in its lead set;
* if found:
* convert it into an opportunity and assign member as salesperson;
* lessen member's weight so that other members have an higher
probability of being picked up next;
* if not found: consider this member is out of assignment process,
remove it from population so that it is not picked up anymore;
Assignment is performed one lead at a time for fairness purpose. Indeed members
may have overlapping domains within a given team. To ensure some fairness in
process once a member receives a lead, a new choice is performed with updated
weights. This is not optimal from performance point of view but increases
probability leads are correctly distributed within the team.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFCIATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#9966
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Purpose of this commit is to allow to use either mono salesteam mode, either
multi salesteams mode. Basic CRM use mono membership: a salesperson belongs
to a single sales team. It is however possible to choose to work using multiple
memberships. This is configured through a configuration parameter available in
CRM configuration settings.
Mono salesteam behavior
* a given user can be member of a single sales team at a time;
* when moving an user from team to team, its existing memberships are
archived to keep history of what has been done within this team;
* display an alert when creating a new team member that would archive
existing memberships;
* displayed members on team form view are directly res.users records to
avoid displaying unnecessary layer when using a simple CRM;
Multi salesteam behavior
* a given user can be member of several sales team at a time;
* unicity contraint (user_id, crm_team_id) is still enforced;
* displayed members on team form view are crm.team.member records as
advanced configuration can be done directly at that level;
In all cases when adding a new member check for archived membership before
creating it. If an archived version of the member exists it is unlinked in
order to avoid breaking the unicity constraint.
Archived memberships can be managed in its dedicated menu for advanced sales
team use.
SPECIFICATIONS: SETTINGS VIEW
Move Multi Teams checkbox below Recurring Revenues / Leads checkboxes. On its
right alias configuration should appear if Leads is checked.
PLS take third configuration line. On its right future commits will gradually
add automatic assignment configuration.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: MODEL CLEANING
In this commit we improve team member model to make it more usable and
aligned with current Odoo views and usability.
This commit contains notably
* add some related fields on the user: phone, mobile, company, email;
* rename "team_user_domain" to "assignment_domain";
* rename "maximum_user_leads" to "assignment_max";
* improve member views globally;
We also introduce dynamic domain computation for users and teams when seeing
team members. This allows to limit selection of users or teams depending
on already existing configuration. Purpose is to avoid having people trying
to create wrong configuration (duplicates, ...) and receiving error messages.
Also
* clean some data and demo about teams and members;
* fix some views glitches;
* improve views: add some fields in search views, improve wording of
fields or actions, ... globally improve usability and US as well as
feedback given to users;
* group sales team members by team by default as it help getting an
overview of team members distribution;
* update tests to create team members instead of writing directly on m2m
towards users;
SPECIFICATIONS: SALE_TEAM_ID FIELD ON RES.USERS
In this commit we also rewrite sale_team_id field of res.users. Previously in
crm it was simply a many2one field linking to a crm.team. It was used to compute
team membership as a standard many2one / one2many relationship. In enterprise
module ``website_crm_score`` this field was set as a related on first user
teams. Indeed scoring changed relationship between users and teams to a
many2many.
This field is now directly a computed many2one field that links to the
"main" team of the user even in multi memberships mode. As memberships can
now be de-activated we changed this field to a computed stored field. It is
based on oldest active membership of user. That way default team of documents
will be the user's oldest team considered as its "main team".
SPECIFICATIONS: LEAD_ALL_ASSIGNED_MONTH_COUNT
Improve crm_team ``lead_all_assigned_month_count`` field computation. It is
now simply the sum of assigned leads of team members. Differences may
happen if a lead in teamA is assigned to an user working in teamB. This should
not happen if team / user is correctly set at lead level which is generally
the case. However if that happens, old field counted it. New field will not
count it as it is not directly linked to a team's member.
SPECIFICATIONS: DEMO DATA
Make crm.lead demo data coherent with user_id / team_id . As demo data should
be using a mono-membership behavior for users and teams, we have to ensure
user_id and team_id effectively matches. It allows to have coherent reporting
and assignment demo flows.
Also avoid having Odoobot responsible of leads. Instead of undefined user_id
and team_id leading to Odoobot being responsible of some leads, force it
to be False. Those demo data allow to test automatic assignment of lead
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICIATIONS
Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.
Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.
Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Rename views according to guidelines in order to better understand what
they are. As there are few views let us take a few minutes naming them
correctly.
Also prepare sales team enhancements and ease migration scripts addition by
bumping version numbers.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Move mail.channel.partner and mail.moderation models into their own file.
This makes some noise in diff but as channel is quite an heavy model let us
do this once for all.
Move mail.channel.partner views in their own file, as for python models.
Also containing
* separate and reorganize fields by main definition;
* separate and reorganize methods by categories, notably CRUD + orm, members
management, moderation, mailing, IM, commands;
* reorganize compute section: compute (by field order), constraints then
onchanges;
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
Some tools methods do not necessarily require to be public.
Cleanup a bit mail addon by moving menu definitions in their own file
according to guidelines.
No functional change should be involved in this PR as only some code move
and light renaming has been performed.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR #64862
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Purpose is to better spot future query counter updates by ensuring current
thresholds effectively match runbot state. Some query counters for admin
are currently a bit lower than expected, probably linked to various ORM
improvements and cleaning done since last counter update.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Cleanup a bit mail addon by moving menu definitions in their own file
according to guidelines.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Some tools methods do not necessarily require to be public.
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
PURPOSE
Reorganize and lint mail.channel code. Purpose is to ease future modifications
linked to groups and channels in mail / Discuss.
SPECIFICATIONS
Move mail.channel.partner and mail.moderation models into their own file.
This makes some noise in diff but as channel is quite an heavy model let us
do this once for all.
Move mail.channel.partner views in their own file, as for python models.
Also containing
* separate and reorganize fields by main definition;
* separate and reorganize methods by categories, notably CRUD + orm, members
management, moderation, mailing, IM, commands;
* reorganize compute section: compute (by field order), constraints then
onchanges;
LINKS
Prepares Task ID-2070632 (Discuss channel task)
Prepares Task ID-2419762 (SM channel task)
COM PR odoo/odoo#64862
When offering services, it is critical to make sure that the time being
delivered is billable. Otherwise, the company is loosing money.
This commit adds two fields in product.template:
1. service_upsell_warning
2. service_upsell_threshold
The first one is a boolean, if it is checked than the second one is
displayed to add a threshold. This threshold is used to create a upsell
activity want the (qty_delivered / qty_ordered) in a SOL of this product
is greater than the threshold defined in the product.
Moreover, when the following condition for a SOL:
(delivered quantity / ordered quantity) >= threshold set in the product
is True, then we display an upsell warning for the corresponding
SO. The problem is we don't check if the warning has already displayed
by a certain SOL. Thus, each time we timesheet for this SOL, we display
one more time.
This commit avoids to spam the salesman, to do this, we add a new
boolean field in sale.order.line, this field will be True if the warning
upsell activity is shown thanks to the SOL.
A method is added in sale module to create the upsell activity for each SO.
This method is used in sale_timesheet module to avoid duplicated code.
Finally, an unit test has been added to check the feature.
task-2411291
closesodoo/odoo#64252
Related: odoo/upgrade#2066
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
3 fields were useless in `stock.move` (only one store):
- `picking_partner_id` not used and we should use `partner_id` instead
- `backorder_id` not used and no sense
- `note` (store), not used and always empty. remove it.
task-2424248
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
To improve the scalability of `_free_reservation` avoid use RecordSet
union. Simplify the parameter `ml_to_ignore` of the method into
`ml_ids_to_ignore` which take only OrderedSet of ids instead of
RecordSet.
task-2424248
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2424248
Add a way to validate pickings in the stock populate,
used to fill a historic of validated picking. it allows to
measure the performance of `_action_done`.
task-2424248
Issue
- Connect on smartphone (or use chrome debug mode to switch to mobile view)
- Install "Ecommerce" module
- Add a delivery method D with a price on product P
and publish it
- Go to shop and add product P to your cart
- Go to payment and switch delivery method
Total amount above the summary is not updated.
Cause
Update is done on JS when delivery method is changed.
No targeting Total Amount in summary head card (seen only on small device).
Solution
Add ID on Total Amount in summary head card element and update it with JS
in same time as other fields (taxes, total, ...).
opw-2424355
closesodoo/odoo#64808
X-original-commit: 7ab63d323680a6a69e77dcc59819928aa7872582
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
- When trying to timesheet on a task that is linked to a sale order
line from a different company than the user's current one.
An error is triggered due multi company access rights issue.
This is due to two computed fields that are not computed in sudo
mode.
They make more sense as `computed_sudo` fields as they are only
computed stats and are not leaking private data.
closesodoo/odoo#64828
X-original-commit: 721378370f5aadb476e8cc606be9a41a3ffad74a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 7fa9ec2638 create accounting entries from stock_account in
batch. The test on `self.company_id.anglo_saxon_accounting` is
problematic in case of multi recordset. Instead, this commit evaluate
the company_id for each record of `self`.
closesodoo/odoo#64813
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit the image wall and image gallery snippets had no
default images (unless overridden by some themes), and the buttons to
add or remove images where not easily visible
After this commit the image wall and image gallery snippets have default
images and the action buttons are their first option line and have
highlighted backgrounds colors
task-2431420
https://github.com/odoo/design-themes/pull/442closesodoo/odoo#64427
Related: odoo/design-themes#442
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps:
- Go to "Website" > "Go to Website"
- Click Edit in the top right corner
- Click Options
- Select "Add a Google Font" in the Font Family field
- Insert an erroneous Google Font link (e.g. https://fonts.google.com/specimen/Robotoj )
- Save & Reload
- Click Edit again
Bug:
The Edit button is not responding anymore
Explanation:
We try to `@import` the link in multiple files.
For example, here: https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/website/static/src/scss/website.scss#L10
An erroneous font family results in an error 400 from the Google Fonts
server. This prevents parts of the JS to load and makes it impossible to
enter the edition mode.
`EditPageMenu` handles the behavior when clicking on the Edit button.
This menu depends on `website.compiled_assets_wysiwyg` as seen here:
https://github.com/odoo/odoo/blob/b02a99bec709b5a6dc4dabb6cb81435dadc24e7e/addons/website/static/src/js/menu/edit.js#L10-L14
Since there is an error generating the file, the Promise fails but the
error is not handled:
https://github.com/odoo/odoo/blob/70eb39b0cf30c1acf9a7116e109874b60e27aa2c/addons/web/static/src/js/core/ajax.js#L164-L168
This commit prevents CSS loading errors from silently failing. The crash
screen will only show up if the user is logged in and has edition
rights.
This commit also prevents the user from posting the form if the font is
not accessible. At the moment, querying an unknown Google font from a
script will result in a CORS error. A valid one will pass just fine. In
case Google changes the behavior of these queries and allows the 400 to
be sent, the fix also checks if the query returned an `ok` status code.
opw:2439073
closesodoo/odoo#64824
X-original-commit: 604c07edcd4da8cf2a663d06ba91f137eb74691b
Signed-off-by: backspac <backspac@users.noreply.github.com>
The graph controller _attachDropdownComponents is not safe: it assumes
that it is not destroyed whenever it manipulates its own measureMenu sub
component, but it is certainly not guaranteed. This commit protects
against this possibility.
Also, at the same time, we return the promise in updateButtons, so it
can be chained if necessary (which is useful in the Dashboard view for
example). This is a new problem, because with the change to Owl, we go
through multiple phases of rendering.
closesodoo/odoo#64820
X-original-commit: 2dcf251c2d7a8bd43193e3e0b715ef3692d4e00f
Related: odoo/enterprise#15869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Create a promotion auto applied with 0 minimum amount on any product in
catalog.
Have a DEMO product invoiced on delivery
Create a sale order with DEMO, apply the promotion. Confirm.
Click on 'Create Invoice'.
The invoice will only contain the promotion because the line for
DEMO is to be invoiced only after delivery, while by default the
promotion product has the invoice policy 'on order'
This commit will:
* avoid highlight the button 'create invoice' if the only
invoiceable lines are promotion lines as well as raising an error if the
invoice is created in the same scenario
* refuse to invoice only promotion lines from a SO.
* adds a test to cover the case
opw-2414630
closesodoo/odoo#64826
X-original-commit: 6532c6ba7acb2de53fc839d5a7c5d8b200716565
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Some added readonly attributes in the unbuild form view were overriding
the `states={'done': [('readonly', True)]}` attributes in the models'
fields. So we add the readonly when state='done' to the view as well.
Note that same issue exists in saas-12.3 and 13.0, but only for 2 of the
4 fields fixed in this commit (i.e. it probably isn't a big deal for
these older versions.)
Discovered during task: 2033341
closesodoo/odoo#64815
X-original-commit: 8bfa9efd989f4123b021c47f13cfe324eeb14013
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit o_row class wasn't applied on mobile because
we wanted that each field take all width.
But we have noticed that this class is quite well used on desktop
and is often used for specic cases that we also want on mobile.
Example: Unit of measure (UOM) next to a numeric field.
So in this commit, we simply removed mobile media queries.
Due to the number of places where this class is used, fixes will
surely follow.
Related to task ID: 1929043
closesodoo/odoo#64532
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit 'product_qty' had a width of 0 because
the 'product_uom_id' field took 100% as width on mobile.
This rule has been added by the 'oe_inline' css class.
To fix this we simply removed this class as we don't need it
on desktop: rules have been overridden by another
selector for this case.
Steps to reproduce:
- Manufacturing
- Manufacturing Orders
- Create
- Quantity field with UOM active.
Related to task ID: 1929043
Before this commit, the `on_attach_callback` and `on_detach_callback`
callbacks are not called all the time on the `Dialog` widget when it's
attached/detached to the DOM. Relying on those callbacks could result in
unpredictable behaviours.
To be more precise, the `on_attach_callback` isn't executed on a regular
Dialog#open() call. But Dialog spawned by the ActionManager will execute
it.
This difference prevents from properly binding those callbacks later on
through an extend or include of the Dialog widget as we have no way to
know if they have already been called or not (e.g. which can result in
calling them twice).
This commit normalize this situation by ensuring that the
`on_attach_callback` and `on_detach_callback` callbacks are properly
called by the Dialog widget and allows any extension of this widget to
rely on them. Therefore the ActionManager is adapted accordingly.
opw-2438534
closesodoo/odoo#64794
X-original-commit: 036fc78103e3d8875a5a54c797e1ba0670d02272
Related: odoo/enterprise#15856
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit o_row class wasn't applied on mobile because
we wanted that each field take all width.
But we have noticed that this class is quite well used on desktop
and is often used for specic cases that we also want on mobile.
Example: Unit of measure (UOM) next to a numeric field.
So in this commit, we simply removed mobile media queries.
Due to the number of places where this class is used, fixes will
surely follow.
Related to task ID: 1929043
To fully allow f4e67d8ae174d7e2ee75a1de1083b31a6ff2af8b
we need also to disable to check on account when
the constraint field has been used to set the account on
the journal
opw-2394959
closesodoo/odoo#64792
X-original-commit: 655597e9a3637abbaeffddcc78663e8733070db4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
The call model.browse('xxx').exists() should not return the record.
Instead, it should fail as the string 'xxx' is not a valid ID.
closesodoo/odoo#64783
X-original-commit: 824a6515a528cd2b682c3d3504c0d27ed9427cdb
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
'percentage' is computed by default whatever the wizard action (change_period/change_account) but there is a constraint raised when the percentage is != 100 in change_account.
closesodoo/odoo#64743
X-original-commit: 20d6efa817a4d839777c81d403bb8770807e784a
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Use case to reproduce:
- Go to MO form produce at least 2 units of a product with a component
tracked by serial number.
- Edit the producing quantity to 1.0
- Save
- Edit the producing quantity to 2.0
The move lines are removed.
It happens because the lot_ids field is empty and thus the setter remove
the existing stock.move.line. It's empty because the compute try to do
a match on existing id. However the stock.move in the onchange
could have a new virtual id.
fine tuning of commit 8dfee8cb2d60942641b73eaa6489b02aa378c5ac
closesodoo/odoo#64788
X-original-commit: a3ab5c3a73243e6f4d5662ee27765439ba9b5363
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
cache_value could be empty string rather than None. I'm not sure why it was
different before.
STEPS:
* install an app that adds menu Products (e.g. Sales)
* activate second language and switch to it
* create new product, set some value to field description ("Internal Notes"),
save
* click edit, remove description, save
closesodoo/odoo#64752
Before: the value is not removed
After: value is empty, translations are removed
X-original-commit: 3ef5e63f62f0f84d6e92cb55eb112ab2f2924faa
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Purpose
=======
This PR is in continuity of #62360 and #62900 done in 14.0.
The goal of this PR essentially updates and improves the changes done in 14.0.
## Details
- Remove the context key added in 14.0 to keep the 'Create Sale Order' button in task and helpdesk.ticket. Because at the end we remove this button in these models.
- Remove non_allow_billable field in tasks and timesheets.
- Remove the partner_email from task form view.
- Remove timesheet_product_id from task form view
- Merge sale_timesheet_edit module with sale_timesheet module.
- Remove timesheet table in portal sales order and invoice (deprecated templates in #62900).
- Remove override of project kanban controller (deprecated file from #62360).
- Store remaining_hours field in sale.order.line model (this field has been introduced in the following PR #62900).
- Remove _onchange_task_id_employee_id, the process in the method is done in _compute_so_line.
- Merge bill_type and pricing_type in project.project.
- Move partner_id field in project form view.
- Remove value selected in SO and SOL in project if the customer does not fit with the SO selected.
- Changes SOL in mapping when the pricing type of the current project is "employee rate" if the customer changes.
- Hide the timesheet_product_id field if the project is not a fsm project.
- Move sql constraint for timesheet_product_id in industry_fsm_sale, because this field is no longer mandatory in project which is not fsm project.
- Changes the search of timesheets in portal > timesheets.
- we allows the user to search with name of SO and invoice to find the timesheets about the wanted SO or invoice rathan than the id of SOL and invoice.
- Move View Timesheets button in portal > invoice
- Remove deprecated codes.
- Miscellaneous fixes.
Task-2424382
closesodoo/odoo#64474
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
Have a product category Inventory Valuation Automatic
Create a SO and deliver the product in such category
Create return and validate
In Journal Entry the accounting move related to return will not have
partner id
opw-2421393
closesodoo/odoo#64764
X-original-commit: 1d4460bcc80e31e9198b19502951d68b447a136a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, this field is stored and contains by default the
value of the same field in project.project. Moreover, we cannot choose
another timesheet_product_id in task views. It means that field is most
of the time the timesheet_product_id of linked project.
This commit converts this stored field into related field to the same
field in project.project and remove an inherit view which adds only this
field without displaying in the view.
task-2424382
Before this commit, we use the _get_not_billed method to get all
timesheets not billed. But in each using, we call the method after a
filtered method.
This commit changes the method to use this method wiht only one
recordset in the self and rename the method to _is_not_billed. This
change allows to avoid the succesive filtered to get the timesheets that
we want. Now, we can use the _is_not_billed method in the first
filtered rathan than realize another filter.
task-2424382
Before this commit, in portal timesheeets (/my/timesheets), we need to
give the id of the SOL or invoice to have only timesheets linked to the
SOL or the invoice that we want. The problem is the portal user does not
know the id of both.
This commit changes these both searchs to search with the name of SO or
invoice. The name of SO and invoice are the reference about these both
and should be unique. This changes are more clearly than the previous
search.
task-2424382
Before this commit, we want the timesheet_product_id field be set if the
project is billable and allow timesheets.
But, now the timesheet_product_timesheet field is only required for fsm
project which is billable and allows timesheets.
This commit moves the sql constraint in industry_fsm_sale.
task-2424382
Thibault Delavallée