If we create a package X transfering from location A to location B:
- we create a stock.quant for package X in location B
=> The package is on location "B" (OK)
If then we do a transfer of that package from location B to location A:
- we set the location B / package X quant to 0 size
- we create a stock.quant for package X in location A
=> The package is on location "A" (OK)
If then we do a transfer of that package from location A to location B:
- we set the location A / package X quant to 0 size
- we set the location B / package X quant to package size
=> The package still is on location "A" (wrong)
This is because:
- since c0d7a05730 stock.quant.package field `quant_ids` is a view over
related stock.quant but filtered on domain:
['|', ('quantity', '!=', 0), ('reserved_quantity', '!=', 0)]
- stock.quant.package fields `location_id`, `company_id`, `owner_id` are
updated when a related stock.quant has fields `package_id`,
`location_id`, `company_id`, `owner_id` modified
Thus when the `quant_ids` change by changing quantities, `location_id`
are not updated even if it should be.
opw-1963509
closes#32466
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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 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>
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).
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>
- 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>
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>
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>
- 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>
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>
In fullcalendar, we have in f5b7ad80f fake moments date with UTC time
that are the local time, thus when we move an event to another day, we
need to set it as:
- the selected year-month-day
- the original utc hours (real local hours) -> local hours
- the original utc minutes (real local minutes) -> local minutes
- the original utc seconds (real local seconds) -> local seconds
When it is sent to server, timezone offset will be removed so we will
transfer to server the expected datetime in UTC.
With this changeset we send server the correct time when a fullcalendar
event is "all_day" but the original event was not (eg. drag and dropping
event on the month view).
Added test without change failed with:
- 4. event moved to 27th nov 16h00 +40 hours timezone
(expected "2016-11-29 08:00:00", result: "2016-11-27 16:00:00")
- 5. expected: "event|6|11/27/2016|16:00:00"
result: "event|1|12/09/2016|08:00:00"
- 6. expected: "event|1|12/09/2016|08:00:00"
result: "event|3|12/10/2016|23:55:05"
opw-1955281
closes#32136
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When displaying product template list in kanban mode, all the variants
of the product template are loaded but aren't used at all. This causes a
perf issue when loaded product templates have a lot of variants.
This commit removes the field `product_variant_ids` from view
`product_template_kanban_view` to avoid that perf issue.
opw 1951369
closesodoo/odoo#32048
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
closesodoo/odoo#32185
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not raise if data have been deleted. Since the fields are not
required, do not fallback.
opw-1959184
closesodoo/odoo#32163
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set the 'Public Pricelist' with 'Discount Policy: Discount included
in the price'.
- Go to the shop and search the product 'iPad Retina Display'
- Add product to cart by using the quick add to cart button
The 'Add to Cart' modal show public price & discount to the customer.
Closes#31378
opw-1944362
closesodoo/odoo#32114
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Odoo Translation Bot