- This commit, fixes a crash triggered when the user is paying a quote while having his browser language set to a language not defined on the Odoo database.
This is due to the fact that the field 'name' on the model 'account.analytic.account' is translatable.
Stripe sends a json query to the server with the user's browser's language on the 'Accept-Language' http header field.
By doing this, Odoo add a 'lang' key to the context, which is then used to translate translatable fields.
- Install French language
- Set language of Customer A to French
- Create an invoice for A (some tax must be applied)
- Print the invoice
The tax amount below 'Subtotal' is not formatted in French.
`t-esc` does make use of the `t-lang` option, so when the expression is
evaluated, the lang is not in the context. We do not change this
behavior since it can have a major impact.
opw-782118
- Install French language
- Set language of Customer A to French
- Create an invoice due in the past
- Open the Customer Statements
The customer statement of A is translated in French, but the amounts are
formatted in the company's user language (English by default).
We add the possiblity to take into account the lang in the context when
calling `formatLang`.
Before this commit, if you go on /shop/cart and your cart is empty, it will
show the total (Subtotal, Taxes, Total) as $ 0.00.
Indeed, the code is retrieving a 'sale.order' if you are connected and you
already have a draft sale order on DB (eg: you just add something to cart and
emptied it afterward).
- Add product to your cart and proceed to checkout
- On checkout cart, remove the product, your cart is now empty
- Reload the page (you should still be on /shop/cart) or go to /shop/cart
- You now see the zero prices (Subtotal, Taxes, Total)
Now, we will hide this if you have an order but no line on that order.
This closes#20896
In the media dialog, when an image is selected, it has a colored border
to indicate it. Commit https://github.com/odoo/odoo/commit/e011d58bee140411ccfb1ef9115dddc090d573c3
made changes, part of them designed to "Improve the image dialog to be
able to select/unselect". While this commit was indeed doing that, it
was also breaking stuff: when selecting image(s) then performing a
search, the colored border disappeared while the images were in fact
still selected.
Fortunately, this stuff breaking is only due to code modification that
was made for no reason (so reverting part of the commit is enough to
restore the features while keeping the commit's improvements).
* [IMP] Doc: improve the documentation
This makes the documentation more readable, makes cleaner sentences and removes the random capital letters within the sentences.
* [IMP] doc: make the info of switchAccount as clear as possible
* [IMP] doc: Make requested changes
When buying a kit, the components should not get their unit price on the
kit. By doing this patch + a previous that set the unit_price on the
move as copy False, it'll take the standard price.
When confirming a move for a kit, it is basically unlinked and replaced
by moves for its component. The link to the purchase line was kept in
v10, but since rev[1] it is not anymore. Make an helper to get the
values and override it in purchase_mrp to add the purchase line link.
[1] https://github.com/odoo/odoo/commit/8248f0e153ae5fcc1449d0d05149b61df615ad4f
opw 779497
A return should be valued at the standard price. As the `price_unit`
field is not set as copy=False and a return move is a copy of the
original move, the valuation was wrong.
opw 779803
Only looking on the stock move to determine if a move should create
accounting entries is not enough: it is possible that sublocations
implement some strategies that impact the valuation (example: a move
between stock and stock where the move lines move things to a scrapped
location).
We now look on the move line and if any of the move lines is IN, the move
is IN, if any of the move line is OUT, the move is OUT, if there's a
mix, the move is invalid.
We can imagine a scenario into which the main stock location (wh/stock)
is set as a view location to force people to put things in the
sublocations. Since the stock_account refactoring, only the location of
the stock move is considered to know if the locations should be valued
and, if so, the quantity to value. It is problematic since a view
location shouldn't be valued, but if its move lines put or take things
to or from a valued location to a non valued one, the valuation
mechanism should run.
We now introduce these specifications to handle this kind of usecase
correctly:
- the authority to get the price_unit is on the stock move
- the authority to now how much quantity should be valued is delegated
to the move lines.
The initial condition was too naive, it only checked the presence of
company_id on the concerned locations. This is problematic because
people need to create, for instance, multile inventory loss locations
once they have multiple companies, as the accounts set on the locations
are not property fields.
We also use the same condition to determine if the move is IN or OUT on
the move valuation mechanism and the accounting entries creation
mechanism.
The logic was not the same in function _compute_product_pricelist and in function
_inverse_product_pricelist.
The function _get_partner_pricelist must check the default pricelist for the company when
no pricelist is given for the specific partner(res_id) because the function set_multi doesn't
set a specific pricelist to the partner if the pricelist set and the default one are the same.
opw:779808
Go to Report -> Operator Analysis -> Apply group_by 'Creation date
(hour)' => traceback.
`start_date_hour` is implemented for Livechat Support Report on
Channels, but not on Operators.
opw-782255
Before this commit, when you had a lead coming from your website form, you
had no informations from where it was located.
It was especially painful for USA which should add customer their location to
know their timezone and know at which time they could call him.
Now, the state code is added to the created lead. It is easy to figure what
timezone the user is on without contacting him first to ask.
This closes#20424
task-29784
When choosing inventory at specific date the default value
is the start time of the server instead of the current time.
When using fields.Datetime.now as default value, will set the function
as default and future object will need to evaluate the funcion each time an
object without default is created. fields.Datetime.now() will evaluate the
function once at the server start and use the retun value as default value
for future objects.
Use case to reproduce:
- Sell 1.1 unit
- Validate the picking with 1 unit
- With or without backorder the initial demand is 0.999
- The backorder initial demand is 0.101
It happens because _compute_quantites uses 'UP' by
default. Since 1.1 - 1.0 equals 0.10000000000000009
we face the problem.
This commit uses an 'HALF-UP' instead. It should not generate
any problem since float_compare in order to decide if we need
a back order or not use a float_round on the same precision_digits
When you have another module installed before sale, and ever changed
some settings, a record of res_config_settings exists and when you
install sale, it cannot set a value for the required new column
'sale_show_tax' for existing records.
To fix this, we have set back the default values on the required field
'sale_show_tax' that has been removed in commit: https://github.com/odoo/odoo/commit/71e5c8b0b5bb10f571030a25875e33b25cda073d
... gives wrong values due to the timezone.
For instance, let's assume that the browser timezone of the user
is UTC+2, and the user types 10/09/2017 10:00:00 in a searchview
with a datetime field in its arch (i.e. which autocompletes on a
datatime field). Before this rev., the suggested value was
10/09/2017 12:00:00, i.e. the timezone offset was added to the
value.
opw 779832
Nicolas Martinelli