With the demo data:
- Go to Sale > Products > Products, search for 'Customizable Desk'
- Click on 'Configure Variants'
- For variant 'Legs: Steel', add all attribute values for the
'Conference Chair'
- Create a SO, add a line with 'Configure Product'
- Select the 'Customizable Desk' with 'Legs: Steel', add
Boom boom, traceback at template rendering at
`first_possible_combination[variant_id_index] == value_id`
This is because the `parent_combination` is not taken into account when
evaluating `_is_add_to_cart_possible`.
closesodoo/odoo#31496
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With the demo data:
- Go to Sale > Products > Products, search for 'Customizable Desk'
- Click on 'Configure Variants'
- For variant 'Legs: Steel', remove the attribute values for the
'Conference Chair'
- Create a SO, add a line with 'Configure Product'
- Select the 'Customizable Desk' with 'Legs: Steel', add
The 'Conference Chair' is displayed in the 'Available Options', while it
shouldn't.
The methods `_get_own_attribute_exclusions` and
`_get_parent_attribute_exclusions` compute the exclusions based on the
attribute values. Since there is no values in our case, the exclusion is
not taken into account.
We add a specific case to search for exclusions without values.
opw-1945460
Since #26134 the po files are compared with pot content when loading a
translation. If a term is found multiple times in a po file, the terms
that does not exists in the pot files are ignored. If the pot files does
not exists, the unicity constraint leads to an error.
Closes#31583closesodoo/odoo#31823
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When importing bank statements, a rainbow man is shown but with no action button
The active model is account.bank.statement.import in this context
Before this commit, the rainbow man was staying with no possible action
closesodoo/odoo#30723
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Activate: 'Order-Specific Routes' and 'Dropshipping'
- Create a stockable product in AVCO + AUTO
- Purchase the product at $10 and validate the receipt
=> One product @ $10 in stock
- Sell the product via dropshipping
- A PO is generated, change unit price to $20, validate
- Validate the picking
The product in stock has now a cost of $15, i.e. the dropship impacted
the cost of the product.
Now if the product in stock is sold, the product will go out at a cost
of $15. This will lead to a wrong accounting valuation (0 product in
stock with -$5 in stock).
opw-1922289
opw-1935272
opw-1937672
closesodoo/odoo#31786
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The widget handle was displayed on x2m fields in form views, even when
the field was readonly, which makes no sense.
It is now correctly hidden.
Fixes#30580
opw-1937833
closesodoo/odoo#31743
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.
closesodoo/odoo#31828
Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closesodoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
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>
When comparing product, there was already an exceptions that would not
list the attributes if they were only "create_variant=False" type.
But if we mix attribute create_variant False or not on a product, we
could get an error.
With this changeset, create_variant=False attribute are ignored also
when mixed with create_variant=True attributes.
opw-1946361
closes#31680
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This field is a non-sense. By using the same logic, it should be added
to any low level model.
Replace the check by a simple verification of presence of an XMLID.
A more generic opt-in solution should be integrated into ORM.
Partially revert commits 0db0e66e96 and
bbd64c22ab.
See #29257odoo/enterprise#3550closesodoo/odoo#31778
Signed-off-by: Christophe Simonis <chs@odoo.com>
Currently, user input lines of type ´datetime´ are not
correctly displayed in both situations:
1. not displayed at all in the survey result frontend page
2. the answered value is not displayed in the form view of
a user input line.
This commit fixes both issues
closesodoo/odoo#31815
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Commit 98d0424 (merged in saas-12.1) fixed a Deprecated warning by using
`field_utils.parse.date` instead of relying on
moment to parse the date.
However, a datetime question type was added in saas-12.2.
When the fix commit was forward ported, the parsing of datetime
broke as `field_utils.parse.date` can't parse a datetime.
Fix: use `field_utils.parse.datetime` if `questiontype === 'datetime'`.
Also, defining `toJSON` method is no longer necessary because
it is already done in the field_utils methods.
The Widget's init function is synchronous.
The 'then' will execute after the end of the function so
self.group_portal_id will not be set immediately.
Also, RPC's in the init function is really not a good idea, it should be
putted in the willStart.
Original commit: https://github.com/odoo/odoo/commit/855c6dac25fccaf9312543022001ed0b360d6e13closesodoo/odoo#31508
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Which was basically creating n² account move lines.
If a POS session has 100 orders with each 10 lines,
100 * 100 * 10 account move lines were being created.
closesodoo/odoo#31736
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
`fast_counterpart_creation` creates new move lines.
The ORM doesn't know if these new move lines changed
or not the value of the field `journal_entry_ids` of each
of the bank statement lines, and for that reason
this field got invalidated from the cache at each iteration,
and the value was prefetched as soon as
`st_line.journal_entry_ids.ids` was asked.
Storing the value of this field for each line in the dict
`journal_entries` overcome this problem as we get the value
from this dict during the loop.
Of course, this relies on the fact the value of `journal_entry_ids`
doesn't change during the loop
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>
We don't want to notify inactive followers,
especially in the case of oddobot that was considered
as a inactive partner in _notify_compute_recipients.
The computed recipient data for odoobot are
(pid:2 active:False pshare:True notif:None)
It was considered as a partner and notified by email.
This fix simply removes inactive partner from partner to notify.
closesodoo/odoo#31734
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
Before this commit the flow of using wishlist with dynamic attributes was not
tested, and it also wasn't tested when combinations were not possible.
Those cases are now tested too.
closes#29859
PR: #31752
task-1920065
Signed-off-by: Sébastien Theys <seb-odoo@users.noreply.github.com>
In the portal, when the client signature is asked (for a SO for example).
Before this commit, the client could send the form without really signing
the document.
Now, a warning is shown if the form is not signed.
opw-1943702
closesodoo/odoo#31768
Signed-off-by: Sébastien Theys <seb-odoo@users.noreply.github.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Suppose that a payment transaction cannot be reconciled for any reason.
Then _cron_post_process_after_done will try to process it every 10 minutes until
the end of time.
Moreover, if the user takes some manual action before
_cron_post_process_after_done,
even if in principle it would have been able to go through,
then it is likely to fail, e.g. on invoice_open.
Meaning that a transaction that could have been processed will become
an undead transaction.
To avoid that situation we set an arbitrary retry_limit_date set to 2 days,
which seems a reasonnable compromise.
It gives some time for the transaction to go through, but not exaggeratedly so.
opw 1945953
closesodoo/odoo#31791
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This makes the assets to be recomputed everytime somebody with a different
language load the page.
closesodoo/odoo#31782
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
When there is an optional product for which the quantity is set to 0 because
there is no stock available, the cart update would raise because it tried to
read the order line even though it was deleted above.
Now we apply the logic only if the order_line actually exists.
Part of task 1950712
closesodoo/odoo#31779
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Sequentially previewing and paying two sale orders was causing a
redirection issue. Instead of being redirect to the SO preview
(/my/orders/<:order_id>), the user was redirected to /payment/process.
The issue was due to processed transactions not being removed from the
session.
opw-1948288
Closes#31741
Signed-off-by: Toufik Benjaa (tbe) <tbe@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>
Groups with more than 3 digits exist, but none of the accounts are
"hanging" from them. For example, the group of accounts 1030 and 1034 is
103, even though 1030 and 1034 groups exist. The account structure
should concur with the account group structure.
closesodoo/odoo#28420
Signed-off-by: Josse Colpaert <jco-odoo@users.noreply.github.com>
This reverts commit 1cdf2bdaf6.
$(':focus') seems not working depending on browser version but
we don't know yet exactly why.
opw-1948266
closesodoo/odoo#31807
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Have a list view, apply a group_by and a filter with a sort parameter
Click on one record to access the form view
Have a x2m within it
Before this commit, the x2m records were loaded with a context containing
the keys orderedBy and group_by
It seems harmless at first, but even conceptually those keys should not be here
- they apply on a list of records, and not to individual ones
- they may contain field names not existing in the x2m model
Hence, when accessing another list view through an action button, the list
will try to be orderedBy or group_by with the given context
Which is plain wrong in the first place and may cause crashes
After this commit, the context of a record datapoint (representing a single record)
is stripped from the keys
Read the opw for a concrete use case
OPW 1943583
closesodoo/odoo#31706
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Create a fiscal position FP which maps the deposit product account to
another account
- Create a SO, use the fiscal position FP.
- Create a downpayment
The account is not mapped following the fiscal position.
opw-1947069
closesodoo/odoo#31781
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reverts 2b1d3ff82d introduced in 10.0 via
It was relatively useful in Odoo 10.0 because in Python 2 the exception
was missing a root cause traceback. But Python 3 includes exception
chaining by default, so it comes for free.
See [PEP3134](https://legacy.python.org/dev/peps/pep-3134/)
On top of being redundant in P3, it can also break some testcases
by causing an extra ERROR log entry, even when the final exception is
expected and caught. So it's simpler to remove it.
closesodoo/odoo#31699
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Nicolas Martinelli