broken by e11f23b
If not full, result was always empty
This commit fix the list of view when you click on Customize top menu in website.
This menu should only display the 'customize_show' views.
When changing tracking mecanism in v9 'always' tracked fields lost their meaning.
They were managed like 'onchange' fields. This commit sets the old behavior back.
* 'onchange' fields are displayed in tracking every time they change
* 'always' fields are displayed in tracking every time they change or whenever
other tracking exist; those are used to display some contextual
information
It wasn't possible to validate a vendor bill
using a product with an asset type due to the fact
the `default_type: in_invoice` was propagated through the
context to the asset creation, and `in_invoice` is not a valid
type for an asset.
opw-689897
On a given instance with 600 000 stock.history, the query changed by
this commit takes:
- before this change => 32 minutes
- after this change => 20 seconds
opw-685747
Purpose of the code is to automatically add the recipients of quotation emails
as followers. It is done using the mail_post_autofollow context key. However
current code add the context key in all cases and not just when composing
a message on sale order.
Following commit 3cbc7ebc4c, the bug for customize menu
could have been ignored but as it is an easy fix :
The customize menu is filled after a rpc which is performed on
mousedown on the menu toggle. But in the case the user clicked on the
customize menu before the mousedown handler was attached... nothing
occured. It is possible since the customize menu is rendered but its
JS widget is only attached to it once everything is ready.
Now, the menu is filled on first mousedown or if the menu is already
opened when the JS widget is attached.
Frontend tours have to wait for base.ready() before starting otherwise
they can find DOM elements whose event handlers have not been attached
yet.
Note that this is a workaround to ignore these real "bugs" as users
should not be able to see buttons they can't click at once but there is
no safe and small fix which will resolve that. The time between the DOM
becomes visible and handlers are attached is small enough to ignore
this bug for now anyway.
Previous commit tried to handle iframe assets in a more standard way
but instead broke the order followed to install iframe communication.
While waiting for a more clean way to handle iframe assets and
communication, revert to old set up.
by auto-extending addons path with odoo.addons.__path__.
This patch also introduce
* an explicit declaration of odoo.addons as a namespace package
This is necessary because the standard way of declaring namespace
packages in setup.py does not work as long as odoo/__init__.py
contains code.
* a more reliable way to find odoo root path.
Creating a centos docker image fails on our nightly server with
this issue: https://github.com/docker/hub-feedback/issues/461
To create a centos image, we used another repository to host the
image and we make it build in docker hub, then we pulled it. It
was getting really annoying.
The use of an entry point was considered in order to provide
an `odoo` command in the path for the packages users, but the
generated entry point will first check that all the things in
install_requires were provided in a not bright way: it'll check
that it matches a distribution name. This does not work because
python-chart does not have the distrubtion name "pychart" which
is provided by the python-pychart package in debian jessie. Same
for suds-jurko which is provided by python-suds in debian stretch
but does not have the distribution name "suds".
Also, adapted the packages tests to these cli changes.
and move it under the setup package. Since the rename of the
openerp directory into odoo, having a script named "odoo.py"
conflicts with a package named "odoo".
This way we do not have to pass the version as argument. This
was error prone. If the timestamp has to be included in the
version, just patch it during before running package.py. This
was already done in our nightly servers anyway.
Following commit 6006c0d72a, the shipping address can be changed after
the call to `checkout_form_save`. This is the case, for example, when
the user has the same shipping and invoicing address. We need to make
sure to recompute the fiscal position after the shipping address is
finally set.
opw-689281
_create_user was called on self instead of wizard_user
(for wizard_user in self...)
This created an ensure_one crash later on if more than one record in self.
An issue occurs in the following case:
- create a SO
- set a partner for which a fiscal position applies
- change the partner to a partner for which no fiscal position applies
The fiscal position set in a first place remains. This is a major issue
when interacting with the eCommerce, since a fiscal position can be
first set based on the GeoIP results, then might need to be removed when
the user fills in his address details.
opw-689281
Use case fixed: create a draft supplier payment, tick it in list view and launch the action 'print check'. Then, on the pop up window cancel the operation => the state was badly set to 'sent'.
Using the same journal for both the session closing and the invoices generated
from the PoS may be problematic as they share the same sequence.
In such case, gaps may appears in the invoice numbers (as the sequence is on the
account.move, closing a session increases the sequence by one).
cf opw-685660
Fixes 13242
Jeremy Kersten