Problem occured when the first call to get_channel_preview was directly
followed by others, before the channels_preview_def was resolved. In that case,
the other calls all returned an empty array, as only the channels_preview
array was only filled with the RPC result for the first call to
get_channel_preview (the one which initiated the RPC).
Those items might have been rendered and inserted into the DOM before the chat
manager initialization was completed. As those items rely on chat manager's
data, they should wait for it before executing their action (inbox redirection
and channels preview display).
- discuss notifications are always sent natively if possible
- clicking on native notifications focus the tab
- clicking on native notifications closes them
- granting notification permissions will display a confirmation
notification
In sale.config.settings, the method get_default_sale_config has api.multi decorator.
However, the method definition should be def get_default_sale_config(self, cr, uid, fields, context)
(see https://github.com/odoo/odoo/blob/9.0/openerp/addons/base/res/res_config.py#L534 ).
The api.multi decorator results in the model being browsed with fields as ids, which results in that kind of queries:
select * from sale_config_settings where id in ('generate_sales_team_alias')
This change corrects the method definition to fix that.
In IE11 the values can be not string (for example a number and so not
have .indexOf method), but then there will no be !important bits and we
can just ignore this feature (which check if an overriding rule has an
!important flag).
There was another edge case when getting a "" set style, we get undefined.
opw-667917
When connected as a website manager,
in another language than the default
website language,
it was not possible to use the optimize
SEO feature, because it needed
variables that were not available if the website
was considered as translatable only,
not editable. This is the case
when you are in any other language
than the default website language,
`editable` is `False`
and
`translable` is `True`.
This is a change of behavior compared to Odoo 8.0,
where `editable` was considered to `True`
even if you were only editing the website translations.
opw-668632
Copied from _get_delivered_qty in addons/sale_mrp/sale_mrp.py
When a product with a BOM is delivered, the delivered qty must
be the produt qty set in the PO line.
PS: There is no dependencies between mrp and purchase
opw:668572
There was a domain on the action to display only the leaves and not
the allocations. Because of this, it was impossible to display the
used leaves, the allocated leaves and the remaining leaves on the same
view, which is frustrating for a HR when he wants to reports some leaves
from a legal year to another
pos_restaurant creates temporary orders when splitting the bill. This
ensures those are never saved to persistent storage. As soon as the user
clicks on the pay button, the order is not considered temporary anymore
and will be saved.
Closes#10767Fixes#10350
opw-666141
In new api, the context in encapsulated and propagated with 'env'. There is no need to add in the signature. Method decorated with api.multi/api.model replace method(self, cr, uid, context).
The payment method code is not supposed to be changed
from an `account.payment`.
Besides, this field is only used for technical reasons,
as stated:
```
Technical field used to adapt the interface to the payment type selected.
```
There is therefore no reason to not set it as readonly.
Not setting it as reandonly could lead to a `write`
operation on the `account.payment.method` with the value
of the code, even if this is already that one set, and
such an operation could be prevented by the access rights.
opw-668624
A missing feature in discuss was the possibility to directly reply to a
message from a channel without opening the document. This commit add
that feature. Now, there is a small 'reply' icon in channels (including
inbox/starred) if the message comes from another document. This icon
opens an extended composer, which will post the message in the document
chatter.
This controller was very slow as not providing a pricelist computed the price of
all products of all pricelists.
Instead only fetch the prices for the useful products.
Could incorrectly rename the stock.location.path objects, and in case
the route has push_ids but no pull_ids would crash the method entirely.
closes#10747
In a multi-company environment, a user from company A which is a parent
of the company B has access to taxes from both companies. The
consequence is that the method _set_taxes will automatically add the
taxes from both companies.
Only call `product_id_change_margin` method if exists. This method is
defined in `sale_margin` module, but as there is no dependency between
modules (nor a bridge module), the call have to be done here.
The condition self.uom_id != self.product_id.uom_id could actually
never be met, since a few lines before you could read
self.uom_id = product.product_tmpl_id.uom_id. From now on, simply
check if the uom_id on the cached record is different from the one
on the product and check the price using the pricelist (_compute_price
does not take pricelists into account) with the wonderfully explicit
with_context call.
Code introducted by commit f39e535 was ignoring the value.
Now, we change the logic to always have True as value regardless the operator.
!= False become = True ...
Commit c04103f re-renders the thread every minute to update messages' date.
As a consequence, the expanded messages are lost (they are shortened again).
This rev. makes sure to keep those messages expanded.
Iterator was consuming the first 45k records.
So don't need to specify an offset, because that will ignore the next 45k.
Eg: if step of 5, and range(1,13),
it will only use [1, 2, 3, 4, 5, 11, 12, 13]
When overriding a method that calls its super later on, it's important
that arguments is used to correctly pass all arguments to the super.
Consider the following:
// module 1 (not correct)
method: function(a) {
return _super.call(this, a);
}
// module 2 (correct)
method: function(a, b) {
return _super.apply(this, arguments);
}
If the method of module 1 gets called first it will throw away the b
argument when it calls _super. Therefore the b argument will never
arrive in method of module 2.