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>
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>
- 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>
Before this commit, when a product goes from manufacturing order to
location having putaway strategy, if this product is tracked, the
putaway strategy don't apply.
opw-1948514
closesodoo/odoo#31808
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.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>
This widget does not exist anymore since the merge between the all widgets
(new view refactoring).
closesodoo/odoo#31643
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before 11.0 the kanban view used to have its own widget registry. It is not the
case anymore, but there are still leftovers from the past. For example, the
widget `kanban_label_selection` is still used in many views, even though it is
now called `label_selection`.
As we are in a stable version, a fallback has been added for it in the field
registry.
Similar to odoo/odoo@5401c15Closesodoo/odoo#30904Closesodoo/odoo#25928
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>
Since f8b38f64d dictionaries "groupbys" are the same object between the
pivot model instance and the headers menu.
But this causes an issue in 12.0 since when there is no results, the
headers menu groupbys is truncated and now being the same object, the
pivot model instance is also truncated.
So succedding search that find results would possibly have lost the
groupbys which is unexpected and breaks some 12.0 tests not expecting
it.
With this changeset, the groupbys are not truncated anymore.
Without the change, the added test fails with:
Column groupby not lost after reload after empty results
expected: { "pivot_column_groupby": [ "customer" ],
"pivot_measures": [ "__count" ], "pivot_row_groupby": [] }
result: { "pivot_column_groupby": [], "pivot_measures":
[ "__count" ], "pivot_row_groupby": [] }
closes#31644
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Since those taxes are missing a sequence and they're at the bottom of
the data, they're being taken as the default ones for the mexican chart
of accounts. However, the default taxes for sales and purchases should
be IVA 16%.
closesodoo/odoo#31651
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The generation of the deffered revenues took initially 471s.This
improvement permit to reduce the time to 72s (behave Cprofiler).
The issue was related to the fact that all the message post and logs
invalids the cache. It results that several read requests were
repeated multiple times.
closesodoo/odoo#31750
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
If the zipfile contains some garbage directories (e.g. leftover empty
directories from git, `__MACOSX` metadata folder, …) it seems
unnecessary to log an error, just skip the directory and don't mark it
as a proper / successful module.
closesodoo/odoo#31639
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The default PoS picking sequence should not be reset.
Losing custom configuration can lead to errors.
For instance:
- A customer initially uses the default sequence until POS09999
- he changes it to another one of his own taste starting the
sequence over, like: WH/POS/00001
- In a module update, the sequence is reset and then we get the POS
prefix again.
- In the next picking, we could have a duplicated name, and an error
would raise in the Point of Sale.
opw 1962302
closes#32299closesodoo/odoo#32842
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Have a partner which is only a company
Print "Due Payments" report
Before this commit, the name of the company was shown in double
this was because both `name` and `contact_address` are shown in that report
but in the case of a company, or child of a company, the company's name
is included in contact_address
After this commit, the name appears only once
OPW 1970581
closesodoo/odoo#32838
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a SO with a partner in another language
Apply a quote template to a SO
Customize the portal view to show website_description of a product on the template
Translate it
Show the SO on the portal
Before this commit, the description of the product was not translated
This was because the field was not included in the onchange of template_id
causing that field to never have changed, that is, it kept the description
done injected with the first write
After this commit, the description is changed according to the partner's lang
OPW 1960977
closesodoo/odoo#32825
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
To reproduce:
0. Start an odoo v10 instance with --load=saas_worker,web
1. Install ecommerce.
2. Enable "Allow external users to sign up" and "Enable password
reset from Login page" from General Settings.
3. Open different session then signup a new user.
4. After successfull signup, the new user will be redirected
to the backend (/web).
Facts to consider:
1. odoo.addons.auth_signup.controllers.main.AuthSignupHome and
odoo.addons.website.controllers.main.Website both inherit
odoo.addons.web.controllers.main.Home
2. When instantiating an odoo instance *without* saas_worker,web,
the mro is the following:
( <class 'odoo.http.Home (extended by Website, AuthSignupHome)'>
, <class 'odoo.addons.auth_signup.controllers.main.AuthSignupHome'>
, <class 'odoo.addons.website.controllers.main.Website'>
, <class 'odoo.addons.web.controllers.main.Home'>
, <class 'odoo.http.Controller'>
, <type 'object'>
)
while the mro *with* saas_worker,web loaded is:
( <class 'odoo.http.Home (extended by AuthSignupHome, Website)'>
, <class 'odoo.addons.website.controllers.main.Website'>
, <class 'odoo.addons.auth_signup.controllers.main.AuthSignupHome'>
, <class 'odoo.addons.web.controllers.main.Home'>
, <class 'odoo.http.Controller'>
, <type 'object'>
)
You can notice that depending on how the instance is instantiated,
the order of inheritance is different.
The problem occurs when saas_worker is loaded, so this bug can be
experienced by saas clients.
Explanation of the fix:
Notice that the original code calls web_login of its super in its
web_auth_signup method. This is technique is used normally during
optimization (according to RCO). If website is installed, the
portal user should be redirected to '/' instead of '/web' and this
is defined in web_login of website. However, the web_login of
"website" is not called after signup because "website" is not super
of "auth_signup" when saas_worker is loaded (see the mro above).
Calling self.web_login will make sure that web_login is called from
top to bottom, and regardless of the order of website and auth_signup,
web_login of "website" will be called and makes sure that the
new portal user is redirected to the '/' and not to '/web'.
opw-1956980
closesodoo/odoo#32741
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The computation of hash integrity depends on the field
`tax_ids_after_fiscal_position`. However, this field is computed, but
not stored.
It means that if one modifies a fiscal position used in the POS, the
computation of `tax_ids_after_fiscal_position` will change.
Consequently, the hash computation of the order will be modified, and
the hash integrity of the journal will be corrupted.
We prevent the modification of the taxes implied in a fiscal position if
any POS order use it.
Closes#32665
opw-1969009
closesodoo/odoo#32701
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit introduced a regression in web_studio, discovered at opw-1947380
A fix in web_studio will be integrated too but the regression is the proof this
commit should not have been integrated in 11.0.
While the new behaviour introduced at d855e3911f makes more sense, it is still
a change of behaviour that should not target a stable version.
For the problem raised at opw-1887162 that d855e3911f was trying to fix, a
workaround should be used instead.
For instance, setting a widget='html_frame' allows to translate in the website
editor that handles this correctly.
In master, the new behaviour can be maintained and eventual regressions will be
investigated there.
closesodoo/odoo#31585
Signed-off-by: "Martin Trigaux (mat)" <mat@odoo.com>
Since https://github.com/odoo/odoo/commit/5a030db3eb77b6d80187f8ae1a64303b2f50391d
the HTML editor displayed the translated versions of the templates it
allows to customize. So if the user edited and saved such a template,
the non-translated version was saved with translated-version content.
The behavior before the mentioned commit was:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, re-make a RPC to load the view again
The mentioned commit made this simpler by making:
1) Load all views the HTML editor allows to edit
2) Each time a view is displayed, simply show the previously loaded view
... the problem was that the step (2) of the old behavior was
explicitly saying (client-side) to load the view's untranslated content.
This commit makes step (1) always load the untranslated versions of the
views (server-side).
tarteo