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
Due to accounting custom setupclass user in environment is not admin but a
custom user having only accountant rights. This is hidden in accounting
override that changes test user and mix data creation and ACLs tests.
Current tests in sale crash when a flush is involved during data creation
as test user (accounting) has no rights to create users.
In this commit we fix locally sale data creation as fixing accounting
test structure is out of scope compared to this task.
Spotted when working on task ID-2086889
closesodoo/odoo#62672
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Behavior prior to the commit:
- when setting the customer (partner) on a sales order, the sales team
is set based on the partner's sales person. If there is no sales person
on the partner then the team defaults to the first team in sequence for
the company.
- the team set on the partner is not used (by default, this field is not
visible, but it can be set from server action or added via studio). In
Odoo 12.0 the team set on the partner was used as a fallback, but this
was removed in commit 242be00429
Behavior after the commit:
- the partner's team is used as fallback when the partner is updated
- when the salesperson is updated on the quote, we also use the current
team as fallback (since presumably this was set either from the partner,
or using the existing default rule, there is no reason to change it)
- in debug mode, the field `team_id` is shown on the partner view (under
the `Sales & Purchases` tab)
Note:
- Change in existing installation is expected to be minimal since it only
affects the customers who are making use of the partner.team_id field, not
populated or displayed by default, but there is a risk for a customer who:
1. has that field populated on existing partners (maybe upgraded from
an old install where it was displayed?)
2. is relying on the new (as of v13.0) behavior of assigning the default
sales team based on the sequence
opw-2351868
closesodoo/odoo#61827
X-original-commit: 7683e1907f6eb1fde4626927957df4eede49b8ca
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
Before this commit, the evaluation context was forced with sudo(False)
as the call to _render_qweb_html was made with sudo(True). The sudo
was removed to prevent rendering a report on any object.
This was problematic for reports such as sale.order portal page where
the public user does not have access to the record but uses a custom
verification mechanism using an access_token field and then calling
_render with sudo.
This commit moves the sudo call to keep the _get_evaluation_context
with the same environment and allow to call _render with sudo
Add tests with sale portal building the report as low-priviledge user
closesodoo/odoo#56890
X-original-commit: 57665a02f7b4cd113f8f40ec47c58a518fe8669c
Related: odoo/enterprise#12845
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
DBO won't be here anymore 👋
This is my last commit, I had to find something harmless.
Task-NaNNaNNaNNaNNaNNaN
closesodoo/odoo#56789
X-original-commit: fc92728fb2aa306bf0e01a7f9ae1cfa3c1df0e10
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently, if users try to send invoices / quotations / purchase orders to
themselves in order to look at final result, they can't do so because our
default chatter protection prevents sending mails to authors themselves.
This commit uses 'mail_notify_author' context key and allows users to send
mails from the header buttons available on SO / PO / invoices to themselves
if they are in recipients.
This commit targets only those buttons as this is the main case where we
want to allow people to send emails to themselves. In order to avoid
side effects no other use case is supported.
Task ID-2294130
closesodoo/odoo#56370
X-original-commit: 08c0dc929da38595e29a9d1db93065547cd98ad1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180m
l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180
When the discount of a sales order is computed, based on the pricelist,
the pricelist price computation is reversed, to find the base price on which
the discount was applied.
The currency considered as the base price currency was potentially wrong in
some cases (multi-currency environment, different currency between cost and sales prices,
...).
This commit ensures the right currency is used.
closes odoo/odoo#51045
Forward-port-of: #50913
Forward-port-of: #50811
X-original-commit: b39228a505151c669876f858941748fa9146279a
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Sales Order notes were not passed in when generating the invoices.
* [IMP] When generating an Invoice from several SO's the lines sequences
were copied from the SO's. Because of that the resulting Invoice
could have lines mixed-up between the different SO's which could
be confusing, especially as notes are now passed in too.
* [IMP] Down payments where not sent into a separated section on invoices.
This could confuse the user, especially when the down payment was
included in a section created that was created in a previous SO
line.
Closes odoo#47279
Task ID #2206228closesodoo/odoo#47279
Related: odoo/enterprise#9465
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
The default invoicing policy should be based on the delivered quantities
by default because:
- In countries with anglosaxon accounting, that's mandatory
- Even for other countries, it's probably as frequent as the "based on ordered"
quantities
Task 2159161
closesodoo/odoo#47526
Related: odoo/enterprise#9355
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Finetuning of #46133 which refactored qty_invoiced compute for performance reasons,
this commit adds a test to ensure the behavior stays constant w.r.t uom rounding
which was previously done in python and is now done in sql.
closesodoo/odoo#46665
X-original-commit: ce9f13a018b752f47bb455e35737e82247ca3089
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- create a SO with a section;
- create an invoice from the SO.
Before this commit, an SQL constraint was raised : 'Forbidden unit
price, account and quantity on non-accountable invoice line'. This error
occurs, because the default_get function adds a default account_id to
all the lines (including section lines) if a journal_id is passed in the
context. The journal_id is added in the context since : 03353118d3176463fbf779471cc272d31fb11b2e
Now, the default_get function only adds a default account_id if the line
is not a section line or a note line. This avoids the SQL constraint to
be raised, and the invoice is correctly created.
opw-2199356
opw-2199017
opw-2198781
opw-2198650
closesodoo/odoo#45809
X-original-commit: d71830f5d9f9a717194aaa8ec993d99739fe09e7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
During a forward port, a regression was introduced that broke the
multi-company invoicing flow in Sales.
Create a SO in company 1, use the web client with company 2 as the main
one. The invoice should be in company 1.
This commit fixes that by providing the journal_id in the invoice values
(the company of the account move comes from the journal).
While making this fix (and adding a test for it), I stumbled upon
another multi-company issue when fetching the accounts of the product
where the property field was not accessed with the correct company. I
fixed it as well.
closesodoo/odoo#45551
X-original-commit: 07dbc197007c78633decccef2200a628b7d4a363
Related: odoo/enterprise#8498
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature
closesodoo/odoo#38424
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The way the active_id(s) were retrieved made the wizard only take care
of one active_id. This prevented from reverse multiple invoices at the
same time.
closes odoo/odoo#38537
Fixes: #35759
X-original-commit: fe47011c3fdcec0bda5334f10679e853fe41e45a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
It seems the grouping feature was lost during the accountpocalypse.
Add a test as long as I'm at it.
closesodoo/odoo#38500closesodoo/odoo#38552
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Initially a forward-port of 5aecd365d7b, which needed f407e60ad680371 to work.
The do_in_onchange was removed inbetween, but it is not needed anymore here.
The issue was caused by the fact that the cache values given for each
environment, whereas in the new ORM the values are now shared across all.
The other potential issue caught by this test was that the company of the taxes
could be incorrect. This is problematic for the end user, since relational that
violates inter-company rules mean that they won't be able to read or write
the records without sudo. However the model now has _check_company_auto,
handled by the ORM, so the issue should not arise anymore.
closesodoo/odoo#38543
X-original-commit: 30cf4b37327ac86584c3025d8fa11b4094f9cbda
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
**Steps to reproduce**
* Define "Sales Order" sequence for using date ranges checking "Use subsequences per date_range".
* Change sequence prefix to "SO/%(year)s/".
* Create a sales order with order date in 2020 (a different year than current one).
**Current behavior**
Got a sales order with 2019 (current year) number.
**Expected behavior**
Got a sales order with 2020 number.
X-original-commit: 20baf00d07868a83cd73a13a6141bc0d36c85c44
If SQL, if you do
```display_type IN ('line_section', 'line_note') OR account_id IS NOT NULL```
and `display_type` is `NULL` then you can only have `'t'` because
`SELECT NULL OR 'f';` yields `NULL`
`SELECT NULL OR 't';` yields `'t'`
The check of NULL is not blocking, hence the constraint doesn't work.
closesodoo/odoo#37075
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 36284
Change the visual aspect of the reconciliation widget:
* Use a tab system to change modes
* Matching for receivable/payable (and liability)
* Matching for types not above
* Create a new line
* Batch Payment
* Sale Order
* Add a keyboard navigation
* Improve the search bar and use a real search view to do so
* Remove the constraint that prevent to select a line already selected
on another statement. Instead remove it when a reconciliation is
validated
* The lines already proposed are proposed last on other statement
lines
* Put the lines with exact amount matching first in the propositions
* Improve when Rainbowman shows
* Change the order of the propositions: older show first
* Remove the title on top of the view (and the ability to edit it)
* Fix some breadcrumb issues
* Also add lines from receivable/payable without partners in the manual
reconciliation widget.
* Propose things to do if there are no lines found in the manual
reconconciliation
closesodoo/odoo#32631
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
* account, hr_expense, mrp, sale, sale_product_configurator, stock_account,
website_sale, website_sale_comparison
Before this commit, the `product.attribute.value` were stored on the variants.
This required filtering of attribute lines to find the appropriate matching
`product.template.attribute.value` that were used in most of the business code,
such as when computing the `price_extra`.
This also prevented to have multiple attribute lines for the same attribute,
which is needed to handle use cases such as grape varieties for wine products.
This will be done in the following commit.
After this commit, the combination of `product.template.attribute.value` will be
directly stored on the product variant.
Other changes
=============
Add `combination_indices` on product, which allows to quickly find a variant
matching a combination (1 simple indexed equality query as opposed to 1 query
with as many joins as there are attribute lines), and to add an easy
SQL constraint to ensure active combination uniqueness.
Add active field on `product.template.attribute.line` and
`product.template.attribute.value`, with the same behavior as variants:
They become archived if they can't be unlinked. This allows to keep the database
consistent, such as archived variants correctly keeping all their values, sales
order lines keeping their custom and no_variant. This is done with the help of
`ondelete=restrict` on the corresponding m2m fields, and the `unlink` methods
falling back to archiving when `unlink` is restricted.
Part of task-1912579
PR: #32946
- Admin (U1) user, Demo (U2) with Sales Manager rights
- Create parent company A and child company AA, U2 has access to A (U1 to both)
- Create 2 taxes, T1 for A, T2 for AA
- For product P, add tax T1 in company A, and T2 in company AA
- U2 creates a new SO in company A with no lines, export Order Lines/Product
- U2 edits the file to add product P
- U2 imports the file
Before this commit, the sale order's line had the taxes for bot company
After this commit, it only has the taxes for the company of the sale order
OPW 2036453
closesodoo/odoo#35294
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Manage pricelists through a common configuration between sale and point_of_sale
Remove lots of technical fields
Improved Pricelist Flow
-----------------------
if pricelists enabled (product.group_product_pricelist), two modes are proposed:
* basic(default): pricelists enabled, but only with basic rules
* advanced: pricelists enabled, but with advanced rules (product.group_sale_pricelist)
When pricelists are enabled, we can always access them through the menu OR access their product-targeted rules from the products/templates views.
While creating the invoice order, if you choose the radio button of
Down Payment(Fixed amount) then the field with currency will be shown
and if you choose the Down Payment(Percentage) then the field with
percentage symbol will be shown and evaluated respectively.
task-2033229
Before this commit, the signature tour (130af96dc1) would fail sometimes.
Indeed, the tour is trying to get `Thank You` on the page after the sign step
but since the modal to pay will open on top of the page, the `Thank You` would
not be found.
closesodoo/odoo#34990
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Thibault Delavallée