Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
At bee938e (following task-id 2042303), the label of the action was
changed globaly.
The action is however shared with multiple menus like Inventory Report.
The Update Quantity label only makes sense when coming from the
product where the quantity will be updated.
Closesodoo/odoo#50523
1. Create a new location of type internal in WH/Test
2. Create a new product P with availability of 100.0 in WH/Stock
3. Create a new transfer from WH/Stock to WH/Test with 50.0 units of P,
Put in Pack and Validate
4. Create a new transfer from WH/Test to WH/Stock/Shelf 1 using the
previous package, Validate and Unpack
5. Repeat steps from 3 and 4
6. Create a new transfer from WH/Stock/Shelf 1 to Customer with 100.0 units of P
7. Review stock quant from the location WH/Stock/Shelf 1
2 quants of the same product in the location WH/Stock/Shelf 1: one
negative with -50.0 and another positive with 50.0
The step 4 creates 2 quants of 50.0 units, which are reserved at step 6.
However, when validating the transfer 100.0 units are taken from one of
the quants.
To prevent this situation, we run the quant vacuum process after
unpacking. This will merge the 2 quants of 50.0 and prevent any future
negative quant creation. We also clean zero quants, although this is not
mandatory to fix our use case.
Closes#53535
opw-2283707
closesodoo/odoo#54431
X-original-commit: f7168311f4333f7fc684e00e1c1c284981718335
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit if you have a quant that has a location linked of the type 'view' you'd get this warning
but you would not know about which location this was and figuring that out is not trivial for most people.
After this commit users get notified about which location is of the type 'view' and can directly correct it if they want to.
closesodoo/odoo#51137
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
1) removal_date in inventory report should be readonly if
product tracking is none or use_expiration_date of product
is false.
2) removal_date should be editable in inventory mode.
Fixes-2273732
closesodoo/odoo#52827
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Before this commit, `self.env.user.company_id.id` may represents different company from the current company based on context.
In this commit, we use correct company based on contextual company.
Follow up on b39173a8ffclosesodoo/odoo#52328
X-original-commit: 2314ce8b3de80ff6c4c9dec35ea6a201f885ba16
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
Since trying to create a record in a grouped tree view has no effect
(previously that opens a new record in form view), this commit removes
useless dynamically added default group for the quant list view.
task-2217907
If you create a quant through the inventory mode of the list view and
you don't set a quantity, the quantity is null and the quant isn't
unlinked by _unlink_zero_quants.
Also consider null quantity as 0.
We don't have the issue for the reserved_quantity field since this one
is not nullable.
closesodoo/odoo#48005
X-original-commit: 08e428458aa545b3602c56b6866a447126cf8825
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
=======
PURPOSE
=======
Improve duplicated serial number message to show more information.
=======
SPEC
=======
In this commit, we show full information about all invalide product name
and lot/sn number when the user enters duplicated ones.
- Change the sql constraint for checking duplicate sn/lot to python
constraint to support customised error message.
- Create lot in batch to show all invalide ones in error message.
=======
LINKS
=======
task 2083605
pr #44366
Related: odoo/upgrade#954
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Go Inventory > Master Data > Products
- Group by Category
- Go to a product
- Click on 'Update Inventory'
An error is raised because the field `categ_id` doesn't exist on
`stock.quant`.
opw-2161129
closesodoo/odoo#42964
X-original-commit: 901d60cd90f1e6ba0fd6502c04619193d3ca1c7b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When accessing the quantities on hand of a product, `_get_quants_action`
is called to specify the action returned.
In some cases, the action context may be updated. This led to a
traceback because the context of the action isn't a copy of the current
context but a link to the current context frozendict, which cannot be
updated.
Instead of hardcoding a domain in the action, we add a field that will
be used to apply the domain. The goal is to be able to define a static
domain in the xml so we'll be able to default on the filter while still
being able to remove it.
Let's consider this usecase:
Physical
| \
WH Subcontracting
| |
Stock 5 units
|
10 units
With the hardcoded domain, we have two problems
- the right part of the tree isn't visible
- the user can add a quant in subcontracting but it will disappear at
the creation since it isn't part of the hardcoded domain.
The complicated part of the domain is the `_get_domain_locations` call.
It will use multiple context keys, the current company and get the
hierarchy of internal locations below warehouses to see what it should
include or not.
To be able to remove a domain, it should be declared in the xml and not
hardcoded in the action. Since the domain is complex, we can't express
it. So we add a computed field "on_hand" and its search method is
overiden to call `_get_domain_locations`.
task-2061825
closesodoo/odoo#40403
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Adds a domain on quant `lot_id` when user changes quantity on hand of a
specific product, so user can select lot only for this product (or its
product variants if user come from a product template).
closesodoo/odoo#36467
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case there is a lot of stock_moves and/or lot of
stock_quants, the function _get_qty_procurement
takes a lot of time because there is no index defined
on most accessed fields.
I.E. OPW-2027183
closesodoo/odoo#36113
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
product.template
- make responsible a property field in order to ensure proper next activities when a product
is used between multiple companies
stock.putaway.rule
- added a company_id field
stock.move.line
- company_id is not related anymore since a move line can exist without a move until its validation
stock.package_level
- added a company_id field
stock.picking.type
- company_id is now required
stock.production.lot
- added a company_id field, adapted the constraint accordingly
stock.quant
- check the consistency only in inventory mode
stock.quant.package
- company_id is now empty if the package is empty
stock.picking
- company_id is now related to the one of its picking type
Added some tests.
Moved stock_traceability in the `report` directory.
Removed useless /tests/tours/route.js.
task-1985992
Before this commit, if user tries to create a new record from a empty
grouped editable list in 'Inventory Report', he/she will get the form
view open which isn't editable.
To avoid that, we remove the group filter if there is no quant, so user
can create a new quant directly in the editable list.
Task #2056651closesodoo/odoo#36221
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: jip-odoo <jip@odoo.com>
- Before the change of `sudo` and `with_user` the code was non sense, it
was doing a `self.sudo(self._uid).check_access_rights('read')` which
was doing nothing.
But now with `with_user`, doing a `self.with_user(self._uid).check_access_rights('read')` breaks the
flag `superuser`.
Meaning that if the code was called using `sudo` it was bypassing the
ACL tests.
closesodoo/odoo#35896
Signed-off-by: Toufik Benjaa (tbe) <tbe@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>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.
opw-2008491
closesodoo/odoo#34067
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Made some changes in stock.quant model to allow user to modify product
quantity easier.
To allow the edition of quant without opening more permissions on the
model, we switch to sudo in create mode and write if the conditions are
met (special key in context + access rights on the current user + write
on a specific field).
Also, we have two list views for the quant:
- The old list view who still readonly.
- A new list view where user can create new quant or edit quantity
of existing ones
We display the second one if user is a stock manager.
For existing quants, user can modify counted quantity (which will modify
product quantity). User can also create new quant, in this case:
- The quant is really a new one (ex.: new product/location
association) so will simply create a new quant.
- A corresponding quant already exist, so will modify the existing
quant instead of create a new one.
When an user creates a new quant, the model will check each time a
non-quantity field (product, location, SN/LN, package or owner) is
modified to see if corresponding quant exists. In this case, it'll get
the quant ID and will update reserved and on hand quantities.
If user didn't change the inventory quantity, it'll be updated too.
On product form view, the 'Update quantity' button was removed as user
can now simply modify quant with 'On Hand' stat button.
Task #1935921
Co-authored-by: sle-odoo <sle@odoo.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Some quant can have no company_id (quant for partner locations).
But when user edit a quant, the stock move `company_id` is based on the
quant's one. As the `company_id` is required for a stock move, we force
to take the `company_id` of the user in case the quant don't have one.
Task #2035465
As quant from inventory loss location balances real quantity, it could
be really hazardous to able user to modify it. That said, modify it now
has no effect. So, with this commit, we exit the quant write method in
case of user tries to modify it manually if the quant location is
inventory loss, and we inform the user he can't modify it.
We could set the field as readonly in this case, but it's clearer for
user to inform him/her in case he/she tries to modify the quant than set
the field as readonly and take the risk user don't understand why he/she
can modify some quant and can't modify some other.
It would be preferabler to raise an UserError in the write than do
nothing in the write and return a warning in the onchange, but in case
we raise an error in the write method, user side the field is still in
edit mode and then, every time user clicks somewhere but on Discard, it
will raise the error again and it's not convenient for the user.
Task #2035465
Since changes made on multi-company, env.user.company_id doesn't
reprsent the the current company anymore, it is only the company in
which the user will be connected by default in Odoo.
The current main company is now available under env.company, so we use
now the current company instead of the user default.
closesodoo/odoo#35129
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Connect on demo user (inventory user)
- Go on product page and click on stat button for 'quantity on hand'
> AccessError on decimal.precision object
due to commit a1eb000c93
When the user click on 'report inventory' button it will garbage
collect the remaining quants without quantity. In order to do it,
it needs the precision rounding in order to have a rounding and do
not let quant without significant quantity.
closesodoo/odoo#34780
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Usability improvement because when the user click on inventory
report it's mainly in order to edit/check its current stock since
commit da33eb36b8
This change redirect the user directly on stock.quant tree view
and add an inventory at date button in the control panel. This
button will open the same wizard than previously and ask for a
date. The same principle is used for valuation layer.
Co-authored-by: svs-odoo <svs@odoo.com>
Task: 1880379
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Martin Trigaux