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
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
Commit a29e291 uses the SUPERUSER in order to create the invoice.
However, we should still link the Salesman of the invoice to the PoS
user.
Fixes#10647
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
Methods get_formview_action can be called by sudo() so for knowing the
real user they should prefer context['uid'] to uid.
Without the action `/web` can't figure out that e.g the view we want is
the one for portal user and not the default one.
With this fix, portal user (not in base.group_user) get to the intended
view with the intended menu when clicking on a invoice/sale order portal
mail link. As for other user there is no change.
closes#10681
opw-666260
The system cannot create two inventory adjustements in state 'in Progess'
with the same product, with the same location, same package, same lot and
same owner.
Example:if two adjustments(ADJ1, ADJ2) are created with the same product(P)
and with the same location(L), let's say:
qty_available for P is 10
in ADJ1: Theoritical Quantity=10 and Real Quantity=20 => a quant with +10 is created
in ADJ2: Theoritical Quantity=10 and Real Quantity=30 => a quant with +20 is created
When ADJ1 is validated then qty_available for P is now 20(that 's ok)
When ADJ2 is validated then qty_available for P is now 40(that's wrong because
the Real Quantity is expected which is 30)
This is why this fix is required.
opw:660658
Raphael Collet