If the smtp session was dead, it would lead the whole mail batch to fail.
opw 1949270
closesodoo/odoo#32424
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
We base ourselves on commit f206714af0, which added a check on user groups.
The tax-included and tax excluded displays are meant to be exclusive,
but wily users can add themselves to both groups using the res_users view
in debug mode.
opw 1950833
closesodoo/odoo#32200
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
With this patch, `sale.order.line` records can now be created in batch,
this means that operations such as:
- SO copy
- SO create + commands
- SO import
will benefit from this patch in terms of performance.
E.g.
For a SO of 2k lines, duplicating the SO takes:
Before patch: 1515s
After patch: 171s
Creating an SO with SOL as o2m commands:
Before patch: 181s
After patch: 43s
closesodoo/odoo#32040
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
At the moment, the HS Code is only used in FedEx. This is confusing for
users, since they expect it to be supported for all providers.
We improve the tooltip.
opw-1961472
closesodoo/odoo#32445
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a multi-company / multi-currency / multi-pricelist environment,
sending the sample SO may crash because the `company_id` field on the SO
line is not yet defined when a price conversion is necessary.
This is because it is a stored related field used in `product_id_change`
which is called programmatically at creation.
opw-1948629
closesodoo/odoo#32443
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When doing a copy, create the new translations directly in SQL and handle
potential conflicts.
Conflicts can occure in case of reinstallation as showed in opw-1955062 and
opw-1950117.
In case of "leftovers" of translations (e.g. remaining after the uninstallation
of a module), creating the new translations (when reinstalling the module) may
produce a conflict with (type, name, res_id, lang) and raise an error.
This is NOT a problem of reading .po file during installation (which handles
correctly conflicts) but of business code creating new records and linked
translations (e.g. website copying website.menu records).
Removing old translations during uninstall is handled in a previous commit in
ir.model.fields _drop_column method.
This commit fixes the reinstallation on instances with leftover translations
and fixes the issue without needing a manual intervention (i.e. delete the old
translations manually).
Closesodoo/odoo#32056
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Better than if ba58888ced as the records may be removed via ondelete='cascade'
(where the unlink is not called on the record). Will be faster too.
A solution to opw-1955062 and opw-1950117 with uninstallation of website.
Closesodoo/odoo#32056
Technically it does 3 different things:
* switch from 1 level of o2m to 2 levels of o2m when recursing
* handles `parent.<xxx>` readonly modifiers on o2m subfields
* handles `id` readonly modifiers on o2m subfields (already worked in the
normal case but not for o2m records from default_get)
The last two especially are temporary quickfixes, that will need proper fixes.
closesodoo/odoo#32428
Signed-off-by: Christophe Simonis <chs@odoo.com>
When creating a customer profile in Authorize.Net we specify a field
merchantCustomerId that is composed of:
ODOO-{partner-id}-{8-random-characters}
But the limit of this field is of 20 characters:
https://developer.authorize.net/api/reference/index.html#payment-transactions
So if we have 1 million partner, we may have eg. a partner 1000005 that
would result in an ID `ODOO-1000005-af123c5b` that is too long and
results in an error.
With this changeset, the generated ID is truncated to 20 characters so
this should theorically be alright for up to 9.99*10^15 partners (the
postgres limit for an integer is 2.15*10^9 so this should be safe
enough).
opw-1962422
closes#32423
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
The board created out of a tree view wasn't taking the default domain of
the view.
opw-1958349
closesodoo/odoo#32240
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- currently, cuurency_id has default value as currency of user's company id. but, when there is no partner set then 'onchange_partner_id' will trigger and set currency_id to false.
- so, set user's currency_id instead of false if no partner set.
Related to Issue: 1948645
closesodoo/odoo#32415
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If bulk-importing clients with a parent_id set, there's a ton of extra /
post-processing work which is not batched and "de-optimises" the
batching added to import.
High-level comparison of performing a "Test Import" on a synthetic test
file of 10000 partners (all with a parent_id set to a pre-existing
record) went from ~30mn to ~8mn on my machine.
Fixes#31549closesodoo/odoo#31876
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make some invoices
Make a payment
Reconcile it with the invoices through the reconciliation widget
Print the payment receipt and the checks
Before this commit, neither the payment receipt nor the checks contained
the invoices
This was because the prints relied on only the field invoice_ids
filled specifically when registering a payment on an invoice
After this commit, the prints mention the invoices
OPW 1947002
closesodoo/odoo#32365
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When a report with header is displayed in iframe with layout
"Background", part of the header maybe outside of the page.
For example on /my/invoices portal show of an invoice, the max width
report iframe can set at 210mm (+/- 793.7px normally), the header in
background layout has `min-width: 900px` so is wrongly centered and may
have content outside of shown page (eg. company tagline).
The same issue happen when using HTML rendering of the report in
backend, but depends on the viewport width.
This may be the expected configuration when printing (wkhtmltopdf should
unzoom if something was too large to fit) but not when displaying html
directly.
opw-1915807
closes#32373
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Mostly a concern during bulk import of partners with parents.
First remove syncing extended fields, that seems completely
unnecessary since the street gets sync'd and will get split through the
normal process (updating the sub-fields), by also syncing the split
fields we're redundantly calling _set_steet and rewriting the address
we just sync'd.
Second if write()ing both the country and street, the override would
then go and re-write the street based on what had *just* been split
into sub-street fields, which could waste a lot of time during the
import post-process as address fields get moved back and forth between
parents and children leading to *lots* of writing both country and
address together, we're talking:
ncalls tottime percall cumtime percall filename:lineno(function)
10002/2 0.111 0.000 344.390 172.195 res_partner.py:181(write)
[...]
2 0.455 0.228 165.264 82.632 base_address_extended.py:41(_set_street)
My initial instinct was to just add the country_id to _set_street and
remove the write override but it would break
88ff6beb01: if the country alone is
updated on a partner, we do want to re-format the "unified" address
based on individual fields and the new country's format.
Note: it might be that the logic would be more sensible by inversing
the entire thing, such that the split fields are the proper
source (regular stored fields) and street is converted to a computed
field instead, but that'd be a larger model change. Seems like it'd
make more sense though, at least given what the modules attempts to
do (OTOH the module probably fails
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
in just about all the ways).
Should correctly handle / fallback to regular code when processing
non-stored partners.
Perf difference according to cprofile on my machine:
original python:
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.134 0.134 205.380 205.380 res_partner.py:277(_compute_commercial_partner)
SQLized
1 0.118 0.118 67.239 67.239 res_partner.py:280(_compute_commercial_partner)
most of the time leftover seems to be in modified_draft
With profiling enabled, importing 10k partners, with all of them
having the same parent (though not with all of them having the same
is_company setting) lowers sync / post-process time from ~550s to
~330s.
Put it in an override to _load_records_create so it's only active for
imports (which is the original report & test case), use a context key
to avoid going the post-processing work in create.
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Go to the eCommerce, buy "iPad Retina Display" which as a 20 %
discount
In the corresponding SO, the discount appears to be zero, and the
discount is included in the price unit. However, adding the product
directly to the SO in the backend displays the discount as expected.
There should not be a difference in behavior between the eCommerce and
the backend.
Fixes#31337
opw-1943989
closesodoo/odoo#31965
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate multi-company, but do not share contact book.
- Create 2 companies A & B
- Create a partner named 'PartnerA' in company A
- Switch to company B
- Import a bank statement with partner name set as 'PartnerA' (use the
bank statement template if necessary)
- Reconcile the entries
An `AccessError` is raised.
The partner suggestion doesn't take into account the record rules,
therefore it might happen that the user doesn't have access to it.
opw-1958711
closesodoo/odoo#32239
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case two modules are using the same local name for their external identifier,
a conflict may occure.
e.g. the templates
- l10n_generic_coa.a_salary_expense
- l10n_be.a_salary_expense
will generate
- l10n_generic_coa.1_a_salary_expense
- l10n_be.2_a_salary_expense
As the previous search for in_xml_ids was using a domain
('name', '=', 'a_salary_expense')
both records were returned, making in_ids to have one more record than out_ids
Followup of review made at odoo/odoo#31510closesodoo/odoo#31604
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating a record from a calendar view,
the default form view is always used when using the popup mode,
ignoring the `form_view_id` attribute of the <calendar/> tag.
After this commit, the `form_view_id` is no longer ignored.
closesodoo/odoo#32379
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- Set your fiscal year end date to 28th February
- Run the P&L a year before a leap year, e.g. anytime between March 1st
and December 31st 2019.
- Select 'Last Financial Year'
The dates are set from 2019-03-01 to 2019-02-28.
There are actually 2 bugs. The one solved here is the following
inconsistency:
```
current_date = type(date)(2019, 4, 3)
date_utils.get_fiscal_year(current_date, day=28, month=2)
'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 28)
current_date = type(date)(2020, 2, 28)
date_utils.get_fiscal_year(current_date, day=28, month=2)
{'date_from': datetime.date(2019, 3, 1), 'date_to': datetime.date(2020, 2, 29)}
```
Both should return `'date_to': datetime.date(2020, 2, 29)`. This implies
that the period is recognized as `custom`, which is affected by the bug
solved in PR https://github.com/odoo/enterprise/pull/4006
opw-1949628
closesodoo/odoo#32366
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- Create a storable product P with a vendor V and a purchase price = 100€
- Set the category of the prodcut to automated and AVCO and set a price diff account on it
- Create PO for V with 10 P with a price_unit = 110€
- Confirm the PO and deliver 7 P with no backorder
- Change the ordered quantity of P to 9 on PO (and the unit_price will be set to 100€)
- Go on the delivery order and deliver 2 remainig P
- Create the invoice and validate it
Bug:
The amount due on the invoice was 900.02€ instead of 900.00€
PS: The debit and credit of an aml are computed with the price (defined in function
_anglo_saxon_purchase_move_lines) with the function _convert_prepared_anglosaxon_line
defined on model account.invoice. So rounding the price unit after the computation
of the price allows to keep the same total as the one computed for the PO.
opw:1951465
closesodoo/odoo#32345
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When we go on a failed mail.mail and do "Retry" -> "Send Now", if there
is an existing notification that is not to the current user, we may get
an error or get the email in error.
This is because on a notification only:
- the superuser
- the targetted user of the notification
have write permission by default in Odoo.
So with existing notifications resending (by the mail.mail views, the
alternative mail.resend.message wizard works as expected) only worked
if they were current user's notifications or if user is superuser.
opw-1957730
closes#32346
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Test was relying on qty_to_consume getting saved when the produce form
is saved, a behaviour of the SSF which diverged from the actual
client.
After fixing the SSF to behave more in-line with the actual
client (don't save o2m sub-fields unless they're flagged as
force_save) the test is now visibly broken.
Fix it so qty_done is properly updated during wizard configuration /
edition instead of updating the in-database object directly.
closesodoo/odoo#32047
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The SSF would correctly filter out readonly fields when saving a
toplevel form, however it could not remove readonly values when saving
o2m pseudo-records to the parent form (as these would be expected to
remain available for reading upon the next edition and whatnot), so
these values would get sent in 0/1 commands.
Filter out these fields during the parent / toplevel save call.
Complexity notes:
* evaluating readonly modifiers requires the entire record, so
unchanged fields still have to be written back to the parent form
and be filtered out when *it* is set up for save, an alternative
would be to store the `changed` and `readonly` flags alongside the
record dict, and have the post-process only override the
pre-computed readonly flag using force_save
* had to fix a test to match the new behaviour, the post-edition
states turns out to be in line with the client's behaviour (or how
it looks anyway)
Fixes#32019
The extra setup probably affects any o2m whose edition view itself
contains an o2m, but most likely to blow up entirely on models with
some sort of tree structure (parent/child relationship): the SSF
eagerly loads and setups the o2m's view, and the o2m's o2m's, ... ad
infinitam.
A better / cleaner fix would be to set up the subview on-demand (and
possibly cache it), but the rest of the o2m stuff is unlikely to work
correctly recursively so just don't recurse the o2m view setup at all
for now.
fixes#31458
Deprecated accounts are available in the reconciliation widget, while
they shouldn't be.
opw-1949667
opw-1945585
closesodoo/odoo#32304
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`res.partner.bank` is ordered by sequence, but:
- there is no default value
- there is no widget handle to set it
Therefore, methods such as `_get_partner_bank_id` might retrieve an
unexpected value.
To avoid this:
- we fallback to sort by ID
- we add a default value
- we add the widget handle
opw-1948964
closesodoo/odoo#32300
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a company on the inventory location
- Create a stockable product, FIFO, real-time, with a cost
- Receive a unit
The product stock value remains zero.
The fact that the inventory location has a company set should not impact
the product cost. This is useful when a scrap location as a company set.
The domain of move selection is incomplete. It should be, for the 'in'
moves:
- coming from a location without company, or an inventory location
within the same company
- going to a location within the same company
For the 'out' moves:
- coming from to a location within the same company
- going to a location without company, or an inventory location within
the same company
opw-1943384
closesodoo/odoo#31485
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PRs #28645 and #31494 were not applied to 12.0, but there's no reason
not to, they should only fix things (make behaviours more in-line with
the regular client), and since o2m is an area where more fixes are
needed and it would be nice to have them in 12.0...
To be able to override the initialisation of the work orders states,
we put that in a function.
opw 1943674
closesodoo/odoo#31774
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Create 2 identical SO: one with a quotation template set, the other
without
- Validate them
- Go to the portal at `/my/orders`, access both orders
The order without template redirects to `/my/orders/<ID>`, while the
order with template redirects to `/quote/<ID>`.
Once the SO is validated, there is no reason to show a different page.
The redirection should only apply to non-validated SO.
opw-1925131
closesodoo/odoo#32262
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Google maps used to be free, but became a paid API.
Technically, the usage could be part of the free offer,
but to benefit from it the account needs to have billing enabled.
Since it's a paid feature security had to be ramped up,
so now APIs have to be explicitly enabled (here geolocating/geocoding).
All this makes it so that the Google account has to be properly configured
before the calls to the Maps API can work.
As a result we add an explicit UserError if the request fails,
to help the user configure the Google account
(before the error was entirely hidden as to give the user no chance at all).
Also exports transaltions, including for commit e6ca846c65
which raised a similar error message if no API key was found.
opw 1946485
opw 1947292
opw 1947337
closesodoo/odoo#32162
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Olivier Dony