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.
Accessing a related field with `related_sudo=True` on a draft record should
effectively traverse the fields as the admin user. Traversing new records in a
different cache requires that all new records on the path are copied across
caches. Make the copy across caches recursive when the first record on the
path is a new record.
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 writing on a recordset with duplicates, the ORM raises a `MissingError`
because the rowcount gives a difference with the injected ids. The fix simply
eliminates duplicates from ids.
When a record is exported, an external ID, in the form of __export__.<model>_<id>
is created on this record.
When the translations are generated (e.g. "synchronise terms" wizard), the
translations may be duplicated for records that have been exported. If a
translation is submitted before the export (when the record had no external ID
yet), a new empty translation is created as the module differs in the import.
Creating a new translation may be a problem as the new term (equal to the source
term) will be used as the translation value.
Fixes 9480
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.
The margin in a SO line is the difference between the price unit and
the cost price of this SO line. In function "_product_margin" in model
"sale.order.line", the cost price is equal to the purchase_price or
the standard_price of the product. Then the cost price in the SO line
must be set with the same value when creating SO line linked to the delivery.
opw:668090
Add the normalized quantity to the SO line. This field is useful for
delivery carriers, since the package price depends on the weight, which
is always defined as a function fo the product UoM.
opw-667594
The order of a bank statement lines is entirely done on the sequence:
`_order = "statement_id desc, sequence"`
The `create` method of `accounT.bank.statement` is overriden
to handle the sequences of each line.
The `write` method as well, except that the set of the sequences
lines is done after the call to `super`. So, if you add
several new lines to a bank statement, the order of the line
you just added can be different before and after save,
as the sequence of these new lines are not set before
actually writting them on the bank statement.
The widget `handle` serves this sequencing purpose. The
fact it isn't used here is most-likely because
it did not exist at the time this was designed.
Besides, this gives the possibility to the user
to add a new line and re-order it where he wants.
For instance, when manually entering a bank statement,
a user could skip unintentionally a line. If he would
like to add it at the right place, before this revision,
he would have to delete all the lines coming
after the line he skipped. Now, he can add
it at the end, and re-order it where he wants.
What is done in the overriden `create` and `write`
is now useless, but we left it for retro-compatibility
purposes, for databases updating their sources without
updating their views.
opw-667541
Add filter in domain converter to remove some posts in sitemap.
Avoid to add in sitemap some pages that could not be read
by public user due to a karma restriction.
This function cannot be overridden in a model which inherit utm.mixin
Limitation by the heritage on AbstractModel
record_crm_lead.tracking_fields() will call tracking_fields() from module
utm.mixin (if not overridden on crm.lead) instead of the overridden method
from utm.mixin.
To force the call of overridden method, we use
self.pool['utm.mixin'].tracking_fields() which respects overridden
methods of utm.mixin, but will ignore overridden method on crm.lead
Eg:
class utm_mixin(osv.AbstractModel):
_name = 'utm.mixin'
def tracking_fields(self):
return "A"
class utm_mixin_overridden(osv.AbstractModel):
_inherit = 'utm.mixin'
def tracking_fields(self):
return "B"
class crm_lead(osv.osv):
_name = "crm.lead"
_inherit = ['utm.mixin']
def func_1(self):
print self.tracking_fields()
# print "A"
def func_2(self):
print self.pool['utm.mixin'].tracking_fields()
# print "B"
It's the dispatch method of ir_http which save GET parameters in cookies,
ignoring the overridden tracking_fields method in inherited model.
Messages of type 'notification' and whose model is 'mail.channel' are
considered as 'system notifications'. This is the case of 'join/left' messages.
They aren't taken into account when computing unread messages anymore.
Also use the same heuristic to decide whether or not to display the message's
star, so from now on pure notifications (not system notifications), like status
change on a document, can be starred.
Clicking on that item redirects to the Inbox in Discuss.
The messaging menu's counter is now the number of conversations (public or
private channels, dm and livechat) in which there is at least one unread
message. Moreover, it is emphasized when one of those conversations is a chat.
Also make mass-mailing channels available through the messaging menu (for
consistency as its counter takes those channels into account) and allow to open
them in chat windows without input.
This partially reverts rev. 84ade6a861
In this specific part of the code, the goal wasn't
to check if the module was part of the installed modules,
but if the module was part the "known" modules, in order
to jump on its form.
Besides, as this link is most of the time used
to install the according module, it's quite dummy
to search it within the installed modules.
Before this revision, trying to click on the "Install" links
in the planners linked to an empty module form, instead
of the according module form.
opw-667407
- Unkwnown partner line wasn't added to the totals
- Column 'not due' amount fixed (was not working properly in case of partial reconciliation)
- now also includes the partner that have _everything_ reconciled for the requested date but with a reconciliation made after the requested date
- Recompute the amount_residual instead of using the field as it is problematic when requested date is between 2 partial payments of a single invoice
The method `get_pricelist_available` can be called from the backend.
(e.g. when using `website.pricelist_id`,
whic is a function field ultimately calling
`get_pricelist_available`).
In such a case, `request.website` is not available,
as the request is not done from the website.
Therefore, we have to fallback in a work-around
to detect the website for which we would like
to get the available pricelists.
Passing the `website_id` in the context
is kinda crappy, but as the website for which
we would like the available pricelists is
not passed in the method params (trough a parameter `ids` for instance),
this is one way to put it through.
opw-668230
This reverts commits
- 995b257a6c
- 2ebdb5f36e
- 748a719fd9.
The commit 748a719fd9 leads to an issue
bigger than what it aims to solve:
- as demo user
- create a new invoice
- add a new line
- select a product
-> traceback
opw-668141
The global record rule `Defaults: alter personal values only`
(`base.ir_values_default_rule`)
ensures that all users can only create personal `ir.values`.
`ir.values` for all users must therefore be created as sudo.
opw-667140
Message's body is kept when switching from 'New message' to 'Log a note' since
rev. f35b48aa. However, mentionned partners or channels were lost. This rev.
makes sure to preserve both message's body and mentions when switching between
composers.
- don't print chat windows
- add missing 'width: 100%' on composer and Discuss sidebar inputs (required
for community edition)
- center the Discuss sidebar inputs
- Discuss sidebar items layout: one line, text ellipsis if name is too long
- hide chatter in 'create' mode (messages wrote in the chatter need a res_model
and a res_id, the latter is not yet existing if we are in 'create' mode)
- revert 2d2dacc: print chatter by default (classname 'hidden-print' can be
used for specific models for which we don't want the chatter to be printed)
- thread: ensure the displayed message's date is in the past
- re-render threads every minutes to update dates
- don't squash messages in mass mailing channels
If the SUPERUSER creates an invoice, we should make sure to keep only
the taxes related to the company of the invoice. This is for example the
case in the PoS, where the invoice is created with the SUPERUSER.
Fixes#10648
Christophe Simonis