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 ...
Use case: I can create a Channel on a chatter, for example on a task
If I choose create and edit, there's another window coming where I
can set up the Channel. In this situation I can't add any members.
But then as the channel is empty and I (as the creator) am not by default
in that channel, I can't find it in my Channels in Discuss...
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]
* It is sometime useful to be able to set the package type and the package weight during the delivery
* These fields can be edited during the 'put in pack' operation or after, with a button in the view
* As the weight is computed, a new field 'shipping_weight' has been added
* These fields (package type and weight) will be used in the delivery carrier for the shipping
* Packaging types are now handled in a centralized way for all shippers
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.
Using message_post_with_view, raw html contained in python is now moved into
a template data and called from the code. This allows to avoid having raw html
directly embedded in python code.
Using message_post_with_view, raw html contained in python is now moved into
a template data and called from the code. This allows to avoid having raw html
directly embedded in python code.
Using message_post_with_view, raw html contained in python is now moved into
a template data and called from the code. This allows to avoid having raw html
directly embedded in python code.
Added a mail_template_field on project stage model (project.task.type). This
fields is used to automatically send an email when a task or issue comes in
this stage.
Recruitment code has been updated to use the mixin method.
When performing automatic tracking it is now possible to automatically send
emails based on a template. This template can either be a qweb template
using its xml_id or a MailTemplate using its record.
This is simply implementing directly in the mixing a feature already present
in recruitment and soon to be added in task, issues or helpdek.
Composer in mass mailing mode currently keeps a copy of the emails in the
document communication history (chatter). It is done by keeping the
mail_message that is used to create the mail_mail record. It is now possible
to customize this behavior. Using auto_delete_message one can choose to not
keep a copy of the sent emails.
Note that the notification field on the mail_mail is used to know if the
associated mail_message has to be unlinked when unlinking the mail_mail.
Auto deletion of sent emails is based on the option on the template used
to generate the emails. It is now possible to bypass the template behavior
if requested, using the auto_delete field in the composer. If this field
is not set, the previous behavior applies.
It is now also possible to tune the message_type and subtype_id of the
posted message. Previously all messages posted through the composer
were comments with a computed subtype being either a comment or a note.
Those values are now default values but can be changed in the wizard
and correctly taken into account when posting the message.
Those modification do not change anything in the default behavior of the
composer and templates. They are mainly introduced for use in future
improvements in various addons, like sending reminder emails that are
not stored.
get_template should accept ids or xml ids. However the id or xml_id is given
to IrUiView.get_view_id that waits for an xml_id. get_template crashed if it
received an id.
This commit solves this by setting view_id to the given id, or resolve the xml_id
through get_view_id.
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
Jeremy Kersten