When creating a new company the system will generate a
new warehouse, its location and its routes.
However the default company is the company that the user is
using.
For example user is in company_1 and creates company_2 it will create:
'company_2: Receipt in 1 step' and the company_id on it will be company_1
This commit completes the dict for create routes in order to introduce
the key for company_id instead of using default value.
Use case to reproduce the bug:
- Enable multi company and create a second one.
- Add both company to another user and give him stock manager rights
- Login on the second user and select as active the created company
- Go to product and create one
-> access right error on stock.location.route message.
It happens because the routes 'buy' is selected by default.
However the route buy when created use the default company
although it's generic for all companies.
This commit change the data in order to remove the company on
routes buy, mto, manufacture and drop_shipping. Since this commit
was released after v11 release, it could happens that already created
database still have the problem thus the solution is to remove
manually the company on the routes quoted above.
opw-777718
Before this commit, when trying to access website_public_price from the backend (when adding this field to a view for example), a traceback saying that the website attribute on the request object was non existent was raised.
After this commit, we control for this and the field displays correctly
OPW 778586
closes#20536
Before this commit, when opening the POS in IE11, then the customer list, the list was empty.
This was due to condition that was wrongly evaluated as false due to the fact that IE11 apparently only wants ECMA5.1 to deal with constructing Date() from a string.
After this commit, we construct the Date() object with the right string, and the list of customers doesn't disappear.
OPW 776463
For reference:
http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.1.15closes#20468
When evaluating a domain, each x2many in the evaluation context is
actually replaced by a list of ids. However, previously, it was actually a
list of commands. The list of ids is much better, since it does not
depends on the exact commands that were generated.
Taxes tags for some localization have been rewrote in order to improve the taxes report.
However, these changes delete the existing account.tags on stable version.
These "[l10n_*] one tag per grid in tax reports" should target master instead of 9.0.
-opw: 777464
Before this commit, if comments were found inside the body of a mail
template sent through mass_mailing, the regex in append_content_to_html
that converts possible uppercase tags to lowercase tags would replace
comments by broken html elements, this would break the in-browser parser
and thus would show partial content or no content at all, depending on
the positioning of the comments.
i.e. from <!-- This is a comment --> to <this -->
The regex in question is r'(</?)\W*(\w+)([ >])' which basically matches
opening and closing tags (this was a bad idea from the beginning btw),
the \W* will match any non-alphanumeric chars (so !-- in the
case of comments) and this would be completely discarded since it's not
a match group and when replacing we only use match groups.
This is fixed by simply stripping the \W* since it's discarded anyway,
an alternative fix would be to put it in a match group and add it when
replacing as well, but I don't know if we purposefully discard it or
not.
Neither fix is the good one, the good fix is to replace all the re.subs
by lxml which is much easier and more concise.
When an onchange fails (for example, because the onchange python code
raised a ValidationError, it is convenient to revert the form view to a
valid state, which is the previous state.
To do that, we keep in the _applyChange function the initial state, and
restore it in the case the onchange fails.
- When paying with stripe an error occurs because of a callback generating the invoice for the SO which is called now automatically by the payment system
- Before this patch, stripe doesn't get displayed.
It was a bug related to the fact that stripe doesn't respect how the generic payment form works.
So to make it work, we were relying on small hacks that got broke by changes on the payment form.
To fix the bug we are no longer adding an event to the pay button of the payment form, instead
we listen all the changes made to the DOM and detect if a form with an attribute 'provider' set to
'stripe' is added.
If so, we open up the Stripe payment form.
- Fix ACL issue when trying to pay with Stripe on eCommerce without being logged.
Closes#20202
opw-776200
Enhanced version of the traverse function in utils,
so that it also builds the paths to any tree element.
There is a function visit in /enterprise/web_enterprise/static/src/js/app_switcher.js that has almost the same purpose as traverse in /odoo/addons/web/static/src/js/utility.js.
It seems more appropriate to move visit to utility.js.
Also, in order to keep good performance of traverse, it might be better to add an additional 'enhanced' version of traverse instead of making changes on traverse.
Hence the newly added function traversePath.
In some cases, vendor reference for payment may already exists.
For instance in Belgium, some suppliers provide recurring invoices which
contain the same communication for the payment. From the version 9.0,
the field Vendor refrence is used for payment communication and the
maching on bank statement.
So, in this case, we have to put the communication from the payment in
this field and, as explained just above, maybe the same as on another
invoice.
Therefore, this commit provides a hook to modify/disable this behavior.
Closes#20343
opw-777608
A recent fix in web changed the field FieldImage to make sure it also
loads a __last_update field. This is fine, except that a test in
enterprise (web_clearbit_tests) was using a field image, and failed
because it could not find the __last_update field in the demo data.
With this commit, we make sure that the mock server is always aware of
the __last_update field.
The access to the state of sale.order.line (related field) seems very slow for big sale order. Bypassing the related field and using the real field instead, improves performance.
'Invoice sent' custom notification was added to the invoice when user
send it by email. This is not necessary as the invoice email should
be displayed in the chatter. This commit also cleans the mail composer
override because context keys were added in a strange way.
Redirections are not correctly computed when the error or success urls
already contain some query parameters, like the access token. We now
use a function added in portal module that correctly computed the
redirection using standard werkzeug methods.
When trying to get the pdf content in an IFrame, the url based on
ID was not found and then redirected to a rewritten URL eventually
with wrong protocol (https became http). This causes a bug in
modern browser that doesn't allow mixed content if the base website
is in https. By using the slug in the URL, there is no redirection
and we avoid changing the protocol.
Thanks @Gorash and @nim-odoo
opw-777950
Before this commit, you was able to double click on the button when
are in registration flow. In this case, you subscribe 2 times and so
take 2x more seats, what can be annoying when you have a limited room.
In the same time, we fix the form in the form that generate
strange behaviour like some events not bubbled correctly.
The attendee form (into the modal) was inside the registration form.
$'attendee_form).on('submit') obviously failed due to this bad dom.
This commit closes opw-778191
Since Odoo 8.0,
the default stock input account for product categories
in the Canadian localization is set to
`214100 CANADA REVENUE AGENCY`
This is the case since this commit:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecL294
In which the account with the XML ID 2141_en
214100 Stock Received But Not Billed
has been renamed
214100 CANADA REVENUE AGENCY
In this very same commit, the account "Stock Received But Not Billed" has been moved to the account 217100,
under the XML ID chart2171_en:
https://github.com/odoo/odoo/commit/13dacd11c10dac853def763432829b8976604a7d#diff-2e65e26a4efc4ab95e72dbe2033141ecR447
While the default value for the products categories stock input account remained the same, the account with as code 2141:
https://github.com/odoo/odoo/blob/8.0/addons/l10n_ca/account_chart_template_en.xml#L8
This is an oversight. It was not meant that way. The default stock input account for products
should well be "Stock Received But Not Billed".
In addition, a stock account is supposed to be of type assets, and not of type liabilities.
I contacted @max3903, who was a contributor of the l10n_ca localization,
and who is therefore a better expert than me regarding the Canadian localization.
He confirmed me all the above findings.
opw-775413
Purpose
=======
User tests have been made by the Product Owners team. It showed that the planners are not used by new users on Odoo due to several reasons (They are too static, too heavy to use,...)
Specification
=============
Remove the module and its different applications. The onboarding on the business flow will be improvement in the weeks to come.
When having a product with included taxes that are changed/removed with
a fiscal position, the price changes depending on if the pricelist's
discount_policy is with_discount or without_discount.
This commit aligns the without_discount behavior to the with_discount
behavior.
Note: the behaviour isn't 100% correct. The applied discount will be
computed on the list_price, instead of the tax excluded
list_price. If a price_surcharge is set, it will be wrong.
Supplements https://github.com/odoo/odoo/commit/0d56dca
When basing a pricelist on another pricelist in different currency
conversion was not being made correctly, since commit https://github.com/odoo/odoo/commit/6b3a808
that changes the pricelist_item on which the currency_id is set in
_get_real_price_currency.
Also align the _get_display_price's base_price to the
_onchange_discount's new_list_price in the case where the pricelist
depends on other pricelists that are in without_discount mode as well.
When doing CTRL+V inside an editor on a P tag we could very easily break
things because P or other phrasing content tags should not contain
flow content tag (eg. `<div />`).
opw-772579
closes#20503
When clicking on WH/OUT in a SO as portal user in My Account on the website,
it raised an 500 error if the product in the SO is not published on the website.
opw:777708
Python 3 (before 3.6) is affected by outstanding issue 24291:
https://bugs.python.org/issue24291
In Python 3.6 the issue is gone thanks to this patch:
https://bugs.python.org/issue26721
The base StreamRequestHandler class does not properly deal with raw IO
output streams. This affects most HTTP servers that use it, including
werkzeug. It causes large HTTP responses to be truncated when the
output socket is unbuffered and in non-blocking mode.
This is the case in multi-process mode (workers > 0) due to the socket
timeout configured to avoid worker deadlocks.
Typically, large file downloads (2MB+) and large JSON responses will be
truncated and cause corrupted files or errors on the client side.
As a workaround, we turn on the buffering on the output stream by
default in multi-process mode (it is already turned on for the input
stream) when running on Python 3.5.
See also the socket.makefile() method and the docstring of
`socketserver.StreamRequestHandler` at
https://github.com/python/cpython/blob/dcb101e7f078f12fc3d2bf1730410798a880bfe3/Lib/socketserver.py#L707Fixes#20158
opw-777120
Arnold Moyaux