* [MOV] sale and invoice portal related code from portal_sale to
website_portal_sale. Security rules and website related stuff should
indeed be located in website_portal_sale.
* [MOV] sale and invoice standard code to sale and account. Adding customer
as follower is a standard feature for sale orders and invoices.
* [IMP] website_portal_sale does not depend from portal_sale anymore but sale
and other portal / website addons
This code seems to add recipients of an email to the sale order followers.
However currently the custome of a sale order is already automatically
added in the followers. Adding other recipients should not be
something completely custom in sale order, moreover by overriding
mail_mail methods.
People should add followers when necessary and should avoid adding
too many people automatically. When you send an email to other people
than the customer those will be added as followers when replying.
Set the company rounding policy to "Round Globally". Create the
following SO (or PO), with a 7 % excluded tax:
- Qty Price
- 880.000 5.79
- 120.000 4.36
- 28.000 2.88
- 68.000 11.09
- 35.000 5.20
- 35.000 5.32
The total tax on the SO is 477.48, while it is 477.50 on the invoice
generated from the SO.
Fixes#13687
opw-690090
This link was useful when the "Technical Features" group was not linked
to the "?debug" parameter. This is not the case anymore, and this button
has no effect.
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.
Thibault Delavallée