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.
If a selection field is created with an empty list of choices (e.g. added by
submodules), initialise the field as a varchar column (most common).
Check if the list exists to avoid crashing while checking the type of the first
key.
Fixes#3810
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
In currencies, advanced search with "equals" or "not equals" on rates
was not possible for something else than a date, in server format (crash).
This is because the name field of the model res.currency.rate is a date
This is now possible to search rates with just a float and the equal operators,
it returns currencies which are having at least one rate set to this float value
This is also possible to search rates with the equal operators with a date in
user (context) date format.
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.
When returning an HTTPException e.g. by calling ``request.not_found()``
which returns a ``werkzeug.exceptions.NotFound()``, the http system
would log a warning as HTTPException is neither a subclass of Odoo's
Response nor a subclass of werkzeug's BaseResponse.
Move the string response case about (for flow clarity), and convert
HTTPException instances to Werkzeug responses then fall into the normal
BaseResponse -> Response case to ultimately get an Odoo response object
out of the HTTPException instance.
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
When changing the type of a column (if size differs for example),
'selection' field should be considered like a 'char' field (since they
are internaly the same column type)
This will fix some migration issues where 'char' fields were correctly
changed but not 'selection,' field.
Use case:
* create a 6.0 db with 'stock' module installed
* 'state' field in 'stock.move' model is of type 'character varying(16)'
* migrate it to 8.0
* 'state' field is still 'character varying(16)' but should normally be
'character varying'
This was broken by mistake at rev. d6c6f31231
partially undoing the introduction of this feature at
rev. 49c0ed6467 (probably due to the
confusing name of that manifest option)