Always return a `sale.order` object, otherwise calling method may crash
since they expect receiving such an object.
opw-761344
Manual forward-port of 0888602831 which has
been lost during normal one.
Using `with_context({'use_babel': True})` overrides completely the
environment context. Therefore, the lang is lost and the date is
formatted in the default language.
opw-779753
After commit 996a817071
The portal report on picking only check if
the user has a 'read' access on picking.
If he can read it, sudo is called and thus
record rule/access right on component objects
are not necessary.
This commit removes useless rights for portal users.
The pad_project addon has a simple mission: allow the user to choose if
he wants to use pads in all tasks from a given project.
This is a noble goal, and the code actually works for projects which
have a 'use_pad' field set to true. However, when a project has
'use_pad' set to false, we have a critical issue, due to the way the pad
widget works.
The pad widget is kind of strange, because it is set on a field which
contains the url for a pad, and it should write itself (the same value),
whenever someone writes on the pad, so the server knows it has to fetch
the result and write it on the 'real' field. This means that the pad
widget has to write its value each time the user modifies the pad
content and press save. However, fun fact, we have no way of knowing
when something was changed inside the pad iframe, so we actually save
the value each time the form view is saved.
So, we have a problem now: the description field AND the description_pad
field are always saved, and they interfere with each other.
In this commit, we put the description_pad in readonly mode when it is
invisible, so we do not save its value at all for each edit/save cycle
(and prevent interference). It actually prevent calling the
generate_pad_url method, but a pad is still created by the server code
each time a task is created.
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
Before this commit, asynchronous field widgets (with willStart async),
with a non empty template had a problem: the invisible modifier was not
applied properly.
The reason is that the code that applied the modifiers was called
directly after the widget was 'willStarted'. This means that if this is
async, and if there is a template, the $el in willStart will be replaced
by another $el after, which will remove the invisible modifier.
This was an interesting problem with the pad widget (it is asynchronous
the first time a pad widget is instantiated)
In left menu used for switching between "apps" particular menu, the
apps names were not translated.
This commit use the "string" attribute which is translated instead of
"data-string" fallbacking on data-string (so things still work without
updating the module).
opw-781728
closes#20972
Because the uom field on production lot is a related field of
product.prodcut, we shouldn't change the uom of a product through the
production lot formé
Consider this: a form view with a one2many list view. In the one2many
list view, there is a many2one field. When opening the manyone in a
modal form view, there is a many2many field. In that situation,
clicking on 'Add a new record' on the many2many field had the
unfortunate effect of interfering with the one2many field in the main
form view, which caused a crash or the modal form view to close
unexpectedly.
The issue is that an event was simply not properly stopped at the proper
location. This is usually not a big deal, but, as described above, it can be
a problem in some cases.
- 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
Nicolas Martinelli