Add a check to see if we're in test mode that returns an InsufficientCreditError to avoid failing other tests if partner_autocomplete server fails
closesodoo/odoo#28324
web_editor dirty elements are saved by calling the ir.ui.view `save()` method.
As this method is called through call_kw _rpc on the ir.ui.view model, self
is binded to the view which has the `id` sent in the request.
In some cases, when editing a field for example, the id sent is the id of the
field's record (eg: product.template for price field).
In that case, the view binded on self will be the view with the id of the
field's record being edited.
If there is no ir.ui.view with the same ID as the field's record, self won't
exists.
This misbehavior resulted in no error luckily since we only use self to call
ir.ui.view methods without ever using self properties.
Since multi-website 47b00c5d53 overrided the `save()` method and used self.key
it was crashing when the self record did not exists.
This commit will fix that by doing the multi-website check only when it is a
view and not a field that is being edited. (We know that if xpath is set)
opw-1904637
Step to reproduce:
- Go to a product on ecommerce, eg product.template 13013
- Edit the product price field, the oe-id attribut is 13013
- Delete the ir.ui.view that has the same ID than the product (13013)
- Save -> It will crash since self is binded to "ir.ui.view(13013,)" but it
does not exists and we try to access key
closesodoo/odoo#28469
Steps to reproduce the bug:
- Let's consider three products P1(in Unit), P2(in kg), P3(in Unit)
- Create a BOM kit for P1 whit 1kg of P2 and 1 Unit of P3 as components
- Create a SO with P1 and validate it
- Go to the shipment and validate
Bug:
An error was raised saying:
The unit of measure kg defined on the order line doesn't belong to the same
category than the unit of measure Unit defined on the product. Please
correct the unit of measure defined on the order line or on the product,
they should belong to the same category.
PS: The quantity delivered on a SO line must only be computed for the product
defined on the SO line. Otherwise with a BOM kit, the sum of all its components
was done instead.
opw:1905223
closesodoo/odoo#28460
* web, web_editor
The logic which chose if the user text color was supposed to be used as
bootstrap "dark" text color or bootstrap "light" text color
(https://github.com/odoo/odoo/commit/8b2dbd1441d6713d9072db03e8d3cb6c2246410f)
was fine when using the default theme with default bootstrap but was not
working as intended in some themes.
This commit also introduces a more accurate and complex method to
determine the correct contrasted color in most cases.
closesodoo/odoo#28468
When a user accesses a PO through the portal thanks to an access token
(without being connected), the product image on each order line is
rendered using the image placeholder with a size of 48x48.
This raises a 403 Forbidden at image retrieval since the access token is
not passed as a parameter. This commit corrects that behavior by sending
the resized image along with the rendering of the template instead of an
url.
Another solution could be to generalize the access token check to any
model in:
https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/models/ir_http.py#L303-L311
But this seems overkill regarding this specific error.
opw-1902741
closesodoo/odoo#28479
- Configure custom payment instructions
- Create a SO, send it by email to the client (do not validate)
- As the client, open the link received by email and 'Accept & Sign'
- Click on 'Pay Now', choose 'Wire Transfer'
The page reloads and shows the message:
> Pending... The order will be validated after the payment.
along with the custom payment instructions. However, no communication is
provided for the payment.
First, the `reference` is never set when calling the
`payment_confirmation_status` template, as it is done in
`portal_invoice_page_inherit_payment`. Moreover, in this workflow, the
reference is never set on the SO because of an incorrect filtering in
`_set_transaction_pending`.
opw-1906464
closesodoo/odoo#28466
Following commit b43151c11c
The order of the pricelist items on the interface was made deterministic, but
there was still a problem with the actual computation because the SQL was
created manually and used a different order than the _order of the model.
Moreover, it is better to use id DESC instead of ASC to make sure the
automatically created default rule matching everything is actually applied last.
PR: #28476
Some code is in charge of setting the same min-height for all items of
a carousel to the natural height of the tallest item, once the page is
loaded. This code was not working correctly in the case the natural
height of this tallest item depends on the height of one of its inner
image, as we have to wait for the image to be loaded in that case.
closesodoo/odoo#28159
When there is a language and its base language translation files in a
module, in 12.0 an empty translation in the language translation file
will not fallback on the base language.
eg.
fr.po : {'one': 'un', 'seventy': 'soixante-dix'}
fr_BE.po: {'one': '', 'seventy': 'septante'}
=> the translation in fr_BE will be {'one': '', 'seventy': 'septante'}
but before 7288b477 it would have been {'one': 'un', 'seventy': 'septante'}
With this commit, an empty translation is no longer created so does not
override base language.
Also the intention of d84b795b0a that was also lost is restored by
upserting only noupdate==false translation, and inserting the other
ones.
opw-1904638
closes#28297
Since the opt out per mailing list, the intermediate model was used
to list all the recipient of a mailing list. The side effect was that
importing new contacts into mailing list was not possible anymore.
Also, creation of a new contact into a mailing list was made indirectly
by creating a new many2many record between contaxct and list, which was
not really user friendly.
This commit restores the mailing contact model as the view of the mailing
list recipients. In other terms, the contact import is restored.
An opt-out computed field as been added to be able to filter on opted out
contact inside the mailing list recipients view.
This opt_out field SHOULD NOT be used in a form view as it need the active
mailing list id in the context in order to be computable and searchable.
This field has no sense without this active mailing list id context.
Task ID 1891228
Linked with blacklist and opt out per mailing task (ID 33224)
Closes PR #27632
On mobile (specifically in landscape orientation as the height of the
viewport is narrower), the content appear over the bottom toolbar
instead of going below.
Solution is in 2 parts:
* raise the toolbar way above the content
* make the toolbar opaque
closesodoo/odoo#28429
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#28408
Before commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
Introduced by: 3d46887d38
Before this commit, creating an invoice from a SO always chose
the payment_method=all when the number of invoice linked to the SO >0
OR all the lines of the SO were with invoice_policy = 'order'
After this commit, creating an invoice from a SO just choose the payment_method=all
when the number of not canceled invoice linked to the SO > 0 AND when there are at
least one downpayment in the SO
SO:
Steps to reproduce the changement of behavior:
- Create a SO for 10 units (invoicing policy based on ordered quantities)
- Create the invoice for 10 units (from SO) and validate it
- Change ordered quantities to 5 units
- Click on create invoice on the SO
The payment method chosen was delivery instead of all. So choosing the default option
lead to a user error saying: there are no invoicable line instead of creating a credit note.
opw:1904258
closesodoo/odoo#28426
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
As empty arrays are considered truthy, the call to `/web_unsplash/get_app_id`
would always be performed even if no Unsplash images.
closesodoo/odoo#28421
Before this commit:
Reserved column appeared with 0 qty when Delivery Order goes to done Stage
After this commit:
Hide Reserved column when Delivery Order goes to done stage.
This task is related to #1888361Closes: #27223closesodoo/odoo#28409
Creating a service and stockable that create a PO on SO confirmation
(with different suppliers) will indeed work, but the status button
will only display 1 PO. The problem is that stock is not linking
the SO line with the PO line.
Thus, we prefer desactivated the button displaying the wrong value, as
it brings confusion to the user.
A proper bugfix should be done in master, to correctly link SO line with
PO line making the PO count correct.
opw-1905189
closesodoo/odoo#28410
Before 762adedece the search was done on the related field product_id
This was equivalent to make a search on the records order_line.product_id
and to use the name_search of product to find it.
With the filter order_line.product_id.name, it was explicitly searching on the
name of the template
Fixesodoo/odoo#28344closesodoo/odoo#28390
- Activate multi-currency
- Create an Journal Entry manually
- Create a line
Do not fill Account
Fill in Amount Currency
Fill in Currency
A traceback occurs because `line.company_currency_id`.
An extra condition `and line.company_currency_id` is not sufficient to
have the onchange working properly. Indeed, the related field
`company_currency_id` goes through another related field (`company_id`),
leading to an empty value in some cases.
opw-1904854
closesodoo/odoo#28389
When a record inaccessible by the user is linked
to a message in a channel accessible to the user,
Avoid to raise an access error due to this linked record.
Also need an aditional query in test query_count.
closesodoo/odoo#28312
- Scan a barcode for employee 1 in kiosk mode
- At greetings message, scan a barcode for employee 2
2 attendance entries are created for employee 2 instead of 1.
When scanning the barcode for employee 2, the event listener
`_onBarcodeScanned` is still active on `KioskMode`. Therefore, the RPC
call to `attendance_scan` is performed twice.
We deactivate the event listener after scanning, and reactivate on
`KioskMode` only if there is an issue. This is sufficient since the call
to `do_action` in `GreetingMessage` will create another instance of the
client action. In `GreetingMessage`, we add back the redirection to
`KioskMode`.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
Linked to Task ID 1878251
opw-1878632
opw-1888402
closesodoo/odoo#28150
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closesodoo/odoo#28298
Suppose that you have a SO that you deliver.
Then the client returns the products, getting a refund,
which creates an incoming picking.
If you do then update the product sold quantity, the quantity to deliver is
computed by summing the relevant picking.
We now discriminate incoming and outgoing picking, respectively substracting and
adding the quantities.
opw 1903559
closesodoo/odoo#28315
- When using perpetual inventory valuation, the accounts used for scrap, manufacturing,
and inventory adjustment operations are set on the corresponding locations .
- In a multicompany environment, you will have a separate chart of accounts for each company.
- Account fields on locations are not property fields.
- Therefore, in order to separate the accounting of manufacturing, scrap, and inventory
adjustment operations, you must use a location for each operation for each company.
- Set up one location for each company for scrap, production, and adjustment
locations, setting the company field on each.
Bug:
- When attempting to create a MO, inventory adjustment, or scrap order while signed
in to the second company, you will receive a permissions error on stock.location.
Fix:
- Now the right location is taken according to the company of the user.
Backport of this commit: c7526407ab
opw:1817339
The percentage field is computed in _compute_percentage as a value
between 0 and 1. This is good because that's what widget="percentage"
in views expects.
This makes read_group also return a value between 0 and 1, instead of
0 and 100. Otherwise list views will show e.g. 5000% when grouping
lines that sum to 50%.
Introduced in saas-11.4 at odoo/odoo@9148960174.
*Do not forward port, already ported to 12.0 via
odoo/enterprise#2975 (odoo/enterprise@a1484e650c)*
opw-1904481
This shorten form is aa-bbb-x. The a characters are the first two digits of the number, x is the mod10r verification digit, and b characters consist of all the intermediate digits, without the leading 0s. The chain of b characters' length can range between 1 and 6 characters.
Odoo Translation Bot