The creation of a country is not something to create at flight !
The impact could be bigger that what people was expected (no accounting configured, ...).
The bad manipulation is more often the responsible, eg 'Belgium ' was creating a new country with a trailing whitespace, while the user didn't see the difference and use both country withtout making the diff.
This rev. is related to 6641c61ce6
During the above revision, a new jointure has been added
with product_uom, on product template uom_id
The join link was wrong, it was:
- LEFT JOIN product_uom u2 ON u.id = pt.uom_id
and it must be:
- LEFT JOIN product_uom u2 ON u2.id = pt.uom_id
as the alias 'u' is the previous jointure, not this new one.
Besides, the uom_name is now the name
of the product uom of this second jointure
As the uom is now the product default uom
instead of the category reference uom
The groupby clause has been adapted, as the selection was slightly altered
Besides, grouping by u.uom_type, u.category_id was pointless
This rev. is related to 67443b5b17
onchange_template_id returns the attachment_ids as a id list,
not as a *2many command list
The conversion from id list to command list has to be done manually.
At the moment, attachment_ids is the only 2many fields of email.template
Prevent creating/modifying accounting entries made on close periods.
The period_id and journal_id field on a account.move.line is a related so was
silently (without write call) updated so did not triggered the call to
_update_journal_check while modiying the linked account.move
Force the check in the validation of the move. As the move can not be balanced
without going through this method, this will prevent posted entries in closed
accounting period.
Fixes#1633, opw 615886
Correction of c3c7aa79a0, apparently the tour system doesn't click on the a if the selected element is not the a or an element inside of it, even if the selected item only has the a as child.
This is related to rev. d17f22cde7
Compare float values using float_is_zeor only
if the key is 'value',
meaning the changed value is the actual value of the field,
not another variable of the field (widget, etc.)
For instance, changing the currency_info of a float field
using the monetary widget should not compare the old and new value using
float_is_zero (the values are not even floats).
opw-627166
Field date_order of sale.order model was changed from date to datetime
during rev. 56cbc9421d
When converting the opp to a sale order, we must therefore use fields.datetime.now
which returns a datetime
instead of fields.datetime.context_today
which returns a date
It makes no sense to allow inventories in supplier locations as it won't anyway
reduce the Inventory if we want to downsize the inventory. This makes
the Inventory act weird.
Ex:
1. Initial situation: 20 units of stock A at supplier's location
2. Makes an inventory stating there is in fact 0 qty of product A at that
location (in the hope to remove some quants).
3. Still 20 units in Suppliers location + 20 units in Inventory loss...
Managing specific suppliers destination is currently not supported.
Same issue with production locations.
Fixes#5052
when the user press tab in editable list views, the focus is supposed to
go to the next cell unless it is at the last cell of the line. in that
case, it is supposed to create a new record.
Sadly, when the last cell is readonly, this does not work. This commit
make sure that read only fields are properly ignored when computing the
last_field state.
Not passing the context should be exceptional, in almost all cases you should pass it.
In this specific case, not passing it will, for instance,
prevent the use of the key 'active_test' in the context,
and there is therefore no way to count all variants, including disabled ones.
This rev. is comparable to 0b18a5afec
The action action_order_line_product_tree is used in both
product templates and product variants forms.
Therefore, the default_product_id: active_id in the context
cannot be used,
As sometimes the active_id will be a product template,
sometimes it will be a product variant.
I believe two different window actions should be used,
instead of sharing a common one and making hacks.
Nevertheless, as we avoid taking risks in stable releases
This should probably be performed in master.
On one hand, when a product attribute is shared by several
products, some may use different subsets of its possible values.
On the other hand, when less than 2 values are enabled for
a given attribute on a product, no choice is displayed for
that attribute on the shop page, as there is none to be made.
The way those "visible attributes" were computed in
get_attribute_values() was wrong: when counting the
number of values it used the whole range of possible
values for this attribute (cross-product), not just
those enabled for that product.
This lead to inconsistencies vs the website_sale.variants
template, and products using a single value out of a larger
range of values were constantly marked as "Not available"
in the shop.
The next post button at the bottom of an article was stuck when getting to
the last page. A cookie storing the *all* the visited posts was used
to determine the next one according to a non-stored (so not working) and
unexpected criteria 'ranking'. Also could get articles from other blog.
Instead of this whole broken logic, simple loop through articles by classic
order and go back to first one when at the end.
Better looping algorithm can be used in master where ranking is stored.
Fixes#3097, opw 614559
The renaming was done in 2 passes during the new WMS
implementation, and the @oldname attribute was ommitted
at rev.386f7c1212705a9cc3b2e73731bfcc4ca447dfbf
If the variable was existing outside the context of the ``foreach``,
the value is copied at the end of the foreach into the global context.
Fix#4461 - Q74531 - Q71486 - Q71675
The email_from for the order confirmation email in the ecommerce
was forced to the company email,
preventing any customisation concerning the from email address
in the sale order mail template.
When fetching the VAT reports for several periods, only the last period was took into account
This is due to the fact that a browse record assignation no longer works in Odoo 8.0 API
at least not the same way.
code.sum_period = sum_tax_add just do nothing in Odoo 8.0.
Besides, using the variable "code" outside its loop is kinda crappy.
Original code assumed the empty field would be missing or an empty
string, b64decoding an empty string yields an other empty string which
triggered a "not found" response.
However Odoo returns ``False`` in case of an empty field, so that needs
to be replaced by an empty string before decoding, as b64decode doesn't
accept booleans as input (for some reason...)
In case of an empty inline column, a Download link inviting the user to
click would still be rendered (erroring out if the user eventually
clicked on it)
fixes#3684