Compute methods could give results that should not be considered as default
values. For instance, a related field usually defaults to a null value, which
is then set to the field with its inverse method by create(). This may violate
a non-null constraint if the original field is required. Therefore, compute
methods are no longer used to determine default values.
The method _prefetch_field() was accidentally prefetching fields to recompute;
which was skipping the actual recomputation, since a value was put in cache.
But sometimes the field's value was fixed by an extra recomputation of the
field. Here we remove the extra recomputation and fix the cache corruption.
The customer can change the country and tax
number in the billing information during
checkout, and the taxes should be properly
updated according to the re-detected fiscal
position.
The fiscal position detection also depends
on the `vat_subjected` flag, which we now assume
to be implicit as soon as the customer filled
in a valid Tax Identification Number.
Rev f2cf6ced1 modified RFC2822 parsing in order to better support
unicode characters inside the Name part of an address header.
However the patch broke handling of multiple addresses (comma
separated) - silently discarding all recipients except the
first one, as soon as any non-ASCII character was present.
This patch restores the functionality while preserving the
fix from f2cf6ced1, and simplifies the code using email.utils
utility functions.
Fixes (again) lp:1272610, OPW 607683
An issue occurs when a constraint is checked before computed fields are marked
for recomputation: the constraint will read the field's current value, which
may be wrong. If the field is marked soon enough, the constraint will trigger
the recomputation and use a correct value.
Instead of just hidding it
Otherwise, when opening a new dialog, it is considered that there is a previous opened dialog, and this can lead to refresh the record which opened the hidden/previous dialog
This is related to rev. 57b48602fb
Because of the parameter overriding mechanism implemented by fields, it is no
longer necessary to copy field objects. It is even better to no copy them in
the case of related fields.
If an email contains several text/html parts inside a multipart email, the previous code was only keeping the last content part.
The Content-Type: multipart/mixed allows several independent part (RFC1341 7.2.2), so two html is technically valid.
With this patch, the two parts are concatenated. (opw 614755)
Modify append_content_to_html regex to make sure the regex keeps the content of the html instead of removing it.
e.g.: "123 <html> 456 </html> 789" used to be stripped to "123 789" while we expect "123 456 789"
I tried starting a better one, but the workflow code is a complete mess so I
have no idea how this thing works without significant study and testing.
Thus, not trying to write a brand new and complete doc, maybe later.
Auto confirmation is now controlled by a field on the acquirer
that proposes to confirm
- at payment (Pay Now button on ecommerce)
- at payment confirmation (transaction feedback)
- never
Also fixed the state of tx for transfer transactions that was modified
for debugging in a previous task but not reverted.
Registration are now for one attendee only. When buying several seats for an event
you have now one registration for each attendee.
event: nb_register field is removed; as well as unnecessary user_id and it subscribe /
unsubscribe behavior. Also slighly cleaned some views.
event_sale: do not auto confirm registrations linked to a draft sale order. Note: strange
origin is a char field, not a sale_order_id. Added a small wizard to edit attendees
data when confirming a sale order containing event related lines.
website_event: when buying free tickets, ask for attendee details. Added template,
controllers to handle that behavior.
website_event_sale: when buying tickets, ask for attendee details. Events ecommerce
should be better integrated with online events, using inheritance to add details
instead of being very different.
This solves a subtle issue: in the following case, the class Bar should
override the default value set by Foo. But in practice it was not working,
because _defaults is looked up before field.default.
class Foo(models.Model):
_name = 'foo'
_columns = {
'foo': fields.char('Foo'),
}
_defaults = {
'foo': "Foo",
}
class Bar(models.Model):
_inherit = 'foo'
foo = fields.Char(default="Bar")
The change makes field.default and the model's _defaults consistent with each
other.
also fix the corresponding text and add explicit sequence number because I
don't understand what the bloody hell it does without that, except that it's
not the right thing. At all.
To allow the on change to set the product default unit of measure when changing of product, and only in this case (not when changing price or quantity)
Consider the following example:
class Foo(models.Model):
_name = 'foo'
_columns = {
'state': fields.selection([('a', 'A')]),
}
class Bar(models.Model):
_inherit = 'foo'
state = fields.Selection(selection_add=[('b', 'B')])
The attribute 'column' of the field does not have the full selection list,
therefore the column object cannot not be reused, even a copy of it. The
solution is to systematically recreate the column from the field's final
specification, except for function fields that have no sensible way for being
recreated.
Raphael Collet