This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).
This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.
The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.
closesodoo/odoo#31804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Sequel of cc54194e13.
The mentioned fix only worked when the user was public.
The problem arises when calling the function `_get_fpos_by_region()`
in `sudo` without specifying the company and this happens, for instance,
in every `onchange_partner_*` function of a sale order.
We propose to add the `force_company` key in the context of the sale
order to ensure the right company when selecting the fiscal position.
closesodoo/odoo#31751
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
- Fixes incorrect user type assignments on some accounts
- Fixes incorrect account assignments on taxes
- Adds a few accounts that Japanese companies would typically need
- Changes some account codes to make the structure more consistent
- Updates descriptions of some taxes to make them appear more natural
on PDF reports
closesodoo/odoo#30780
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When creating a cart on the website, the website company was not
considered which could end up with the selection of a fiscal position
linked to a wrong company since the method is called in sudo.
closesodoo/odoo#31673
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
To avoid exception:
TypeError: Mixing apples and oranges: gamification.badge() - gamification.badge.user(1,)
when rule_auth of a badge is set to `having`.
opw-1945440
closes#31436closes#31595
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Werkzeug version was being checked to avoid passing quote=True to
werkzeug.utils.escape (as that parameter was changed to `True` *and
deprecated* in 0.9).
However because DeprecationWarning was made silent by default in
Python 3.2 and the way the check is implemented worked for 0.9 it
looks like nobody really noticed it's broken in the usual manner of
half-assed version checks: works for 0.9.0, doesn't work for
0.12.3 (because lexically 0.12.3 < 0.9.0).
Fix by using proper version parsing and comparing the result of that.
See also: odoo/odoo#28116closesodoo/odoo#31553
Signed-off-by: "Xavier Morel (xmo)" <xmo@openerp.com>
The location_id and warehouse_id fields on product.template are just
dummy field intended to add something in the context that will be used
to compute the data being rendered (eg. for location, the quantity
displayed is the quantity of the product in the searched location).
But the feature was broken at a point, and has been solved in 11.0 with
7c7b099273.
This solution was not implemented in 10.0 up to saas-15 since this is
not acceptable for a stable version.
This changeset is only for 10.0 up to saas-15 to implement the fix
differently.
opw-1945417
closes#31475
Improve performance (*3) on _compute_product_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
closesodoo/odoo#30545
On some devices and chromium with printing option "Background graphics",
a printed receipt on the point of sale could have a black bottom below
the receipt content.
This is caused by the point of sale black background and happen rarely
because most frequently browser printing remove backgrounds.
opw-1940434
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
closes#31472
Before this commit, doing expression.OR() with only FALSE_LEAF would
yield [] which is equivalent to TRUE_LEAF and is therefore not correct.
The same happened (to a lesser extent) with expression.AND() within an
expression.OR(), since the former would return a [] which would be
ignored by expression.OR().
See tests for a clearer view of the use cases.
Fixes#30113, #26540closesodoo/odoo#31202
The admin can decide to publish/unpublish messages in the comments
of a product from the website. The button is also shown for notes
even if they are never published.
opw-1935337
closesodoo/odoo#31420
When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.
At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.
We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)
opw-1925547
closesodoo/odoo#30154closesodoo/odoo#31373
- Switch to French language
- Go to Inventory > Inventory Adjustment
- Launch an adjustment
The field 'Real Quantity' doesn't follow the float formatting.
This is because the widget is set as `field_float_scannable`, which is
not recognized by the formatting function.
Since the widget descriptor has priority over the type descriptor, we
must explicitly take this widget into account, on top of adding the
`format_value` method.
opw-1940884
closesodoo/odoo#31366
- When changing the user of a `hr.employee` record, access rights errors
could be triggered.
Those errors are triggered when a record (for example a leave) is
linked to this employee and the current user has limited write
accesses by record rules on this record.
closesodoo/odoo#31032
- Go to Inventory > Reports > Inventory Valuation
- Select the pivot view
The top row (containing the Total) has an empty 'Inventory Value'.
This is because there is no domain on the line, so it is skipped.
We fall back on the global domain instead.
opw-1933191
closesodoo/odoo#31280
On IE11, in 10.0 up to master in some instance when creating a record
under some conditions the dropdown may be automatically opened and need
to be closed.
This has been pinpointed to 90c1af1151 so it seem that a combination of
fields/code/autocomplete and changing the placeholder at one time causes
the issue.
Since IE11 lie and say it is mozilla 11.0 we just apply the 90c1af1151
when the browser is chrome (we did no did this at first to have the same
behavior accross browsers).
note: there is an opened bug in chromium https://crbug.com/928305 if
solved the hack could be removed completely.
opw-1940592
closes#31271
Before this patch, any exception raised by a constraint method that
were not of type `ValidationError` were hard to debug, because the
origin line was never logged.
Explicitly logging the error (with traceback) when we catch it
ensures proper contextual info, even in the absence of exception
chaining.
closesodoo/odoo#28612
In Odoo, create a user John@example.com (the cap is on purpose)
In Google Calendar, create an event and invite john@example.com
Sync your Google calendar.
Before this revision,
the event created in Odoo did not add John@example.com,
but created a new attendee, john@example.com, because
of the sensitive casing.
Besides, give the priority to partners having
users, so if there are two partners with the same email,
one of them having a user,
e.g. John@example.com (with user) & john@example.com (without user),
set the partner having the user as attendee,
as its the one with the user who use the Odoo calendar,
and potentially the Google sync as well.
opw-1925592
closesodoo/odoo#31111
Before this, groups on non-stored inverse fields were not checked upon write.
The impact on existing fields is pretty small, since the inverse methods of
those fields are subject to access rights on the records they use.
closesodoo/odoo#30356
This is the first step to a more comprehensive handling of company-dependent
fields which are ir_properties.
With model-specific access rights, users should be able to read/update a
company-dependent field no matter their access rights on ir_property.
Before this commit, a user having access to res.partner, but not to ir.property
couldn't write on property_account_receivable/payable just because he couldn't
write the corresponding ir.property. After this commit, he can.
OPW 1923345
When an inline editor is eg. in a form view, the focus is always stolen
by it.
This is because we trigger a mouseup on the editor to update its
toolbars values and informations.
note: backport of 11.0's 7a453b0b7a
In 10.0 this trigger could cause a "blur" which in some instance is not
wanted (eg. inside a newline of a list view).
opw-1906581
closes#31078
The html widget automatically replace an empty field value by
`<p><br></p>` to be able to add content.
But this may cause unintended "onchange", since the value has "changed"
and the onchange themself could cause error when triggered at the wrong
time (eg. inside a list view with required fields).
With this changeset, the onchange is averted when the value was false
and is now `<p><br></p>`.
opw-1906581
closes#31078
Revert commit 296c5a2106
which was half-right: the accounting logic is correct but it overlooked
that it broke the reconciliation of cash returns
i.e. the client gives more money, and you return the change
Given that this latter use case may occur more frequently we focus on that
while we break freight returns
i.e. the client returns a product, and you give the money back
It is not possible to support both use cases because
ultimately we don't know from which order an account.move.line comes
the related PR #23356 should support both use cases
but adds a field on account.move.line
OPW 1925607
closesodoo/odoo#31037
This commits adds a message to the module import wizard to make it more
clear what kind of modules can be imported through the front end.
project : RD feedback
task : [base_import_module] what it is not for.
opw-1939967
closesodoo/odoo#31057
Calling `search` on `product.product` without specifying an order
will sort the products by name.
As the product name is a translatable field,
it requires to make a join on the translation table to sort
the product by their translated name.
This join is costly, and in this case it was completely
irelevant to do it, as the goal was simply to compute
a domain with only a list of product ids, for which
the order simply did not matter.
By forcing the order on the id,
we avoid the sort on the product name,
and therefore the join on the translation.
The performance is therefore improved.
opw-1930010
closesodoo/odoo#31066
Force the location and destination location's company to match with the
picking and picking type company. This is to prevent users to move
products between companies without using a transit location, since stock
valuation is not supported.
The record rule `stock_location_comp_rule` gives access to children
companies. The domain added in the view is more restrictive, and allows,
for a company A, transfers from locations:
Company A -> Company A
Company A -> No Company
No Company -> Company A
opw-1893276
closesodoo/odoo#30952
When dropping a snippet into a page, it is dropped in the drop-zone
which is the nearest of the user cursor. When moving a snippet, that
condition did not apply and the user was required to put the cursor at
the exact location of the drop-zone.
Also, for both drag and drop features, the drop zones which appeared
were not displayed correctly for full width columns, which made dropping
sometimes impossible when multiple col-*-12 were below each other.
task-1937758
closesodoo/odoo#30899
If fleet.vehicle_state_active is not found in the system then the method
will raise an error, hence it won't allow creating any fleet.vehicle
closesodoo/odoo#30925
- Create a product and set a contact as the vendor (for instance, Arthur
Gomez from Asustek in the runbot)
- Set a specific name and code for the supplier
- Create a RFQ for this vendor (Arthur Gomez - the contact person)
- Add the product, confirm the RFQ
On the product, the company (Asustek) is automatically added as vendor,
but there is no vendor name and code.
opw-1929745
closesodoo/odoo#30891
- Activate:
'Track lots or serial numbers'
'Manage several Warehouses, each one composed by several stock locations'
'Advanced routing of products using rules'
- In the main warehouse, activate Pick + Ship
- In Stock Locations, create 'WH/Stock/Shelf 3' and 'WH/Stock/Shelf 4'
(1 and 2 already exist, use the same config)
- Create a new product 'Foo', activate Tracking By Lots
- On Foo, use 4 times the "Update Qty on Hand" (order is important):
Add 1 on Shelf 2, create a lot
Add 1 on Shelf 1, use the same lot
Add 3 on Shelf 4, use the same lot
Add 1 on Shelf 3, use the same lot
- Create a SO, set a partner
- Ensure that YourCompany is used as warehouse
- Add several SO lines (order is important)
a line with 1 product Foo
a second line with 1 product Foo
a third line with 4 products Foo
- Confirm the SO, you now have 2 deliveries, 1 Pick, 1 Out
- Open the Pick, all moves should be available, you should have:
4 operations:
Shelf 2, quantity 1
Shelf 4, quantity 3
Shelf 1, quantity 1
Shelf 3, quantity 1
3 moves:
A, quantity 1
B, quantity 1
C, quantity 4
- On each operation, select the lot created before and set the quantity
to be fully done
- Validate the Pick
The moves end up like this:
- Move A with qty 1: is done and linked with a quant of 1
- Move B with qty 1: is done and linked with no quant
- Move C with qty 4: is done and linked with a quant of 1, a quant of 3,
a quant of 1 (sum is 5)
In the Out picking, the move linked with the source move (B) with no
quant stays in "Waiting another move" even if the source move is done.
This outgoing move will never be available.
In the method `recompute_remaining_qty`, we loop on operations, and
match them wih the moves. However, the operation with the largest
quantity (Shelf 4, quantity 3) is processed before the move with the
highest quantity (C, quantity 4). Therefore, when we later loop on move
C, `qty_assign_cmp` is larger than zero, which sets `need_rereserve` and
ultimately triggers `rereserve_quants` in `do_transfer`.
A first part of the fix is to check for the location of the quants when
matching moves and operations. This fixes the original issue, but
inconsistencies can still arise since a quant which is taken partially.
therefore, we make sure to never take more than the quantity on the
link.
opw-1932624
closesodoo/odoo#30857
- Set a cost of 12.34 for product P
- Create manually a new analytic entry
- Choose product P
- Set desired quantity
The analytic amount is set to 12.00.
This is because `move_id` is empty, therefore `currency_id` is empty as
well and `decimal_places` is zero
opw-1924184
closesodoo/odoo#30869
Before this commit, the customer is allowed to change picking type after the
stock.picking record is moved from draft.
But it doesn't make the changes in the stock moves and operations as the
procurements are already created for initial demand.
To avoid confusing the user, it can now only be modified in draft state.
Authored by SodexisTeam
opw 1848252
opw-1934814
closesodoo/odoo#30865
- Create a product P with:
Costing Method Average Price
Inventory Valuation Perpetual (automated)
- Create a component C with, costing 10.
- Create a BOM for P:
1 Unit of C
- Create a MO for P, validate
=> a journal entry of 10 is created
- Modify the BOM for P:
2 Units of C
- Create a MO for P, validate
=> a journal entry of 15 is created
The journal entry should be 20.
opw-1928342
closesodoo/odoo#30766
Before that, having a payment with amount_residual=0, but amount_residual_currency!=0 did not display it.
Also, 'outstanding credits/debits' label was displayed in case amount_residual was != 0 with an amount_currency=0 (and of course, a currency_id value was set on the aml). This could for example happen in case of partial reconciliation, were the amount_residual field is used to keep track of what will have to be written in the exchange rate difference entry when the reconciliation becomes full.
closesodoo/odoo#30362
xmo-odoo