[FIX] *: do not use groups when extending an asset bundle
Using groups when declaring an extension of an asset bundle leads to a
different generated asset bundle according to the user's group. This
is not something we want because a dynamic asset bundle's content
means that it could (and it does) trigger unwanted cache invalidation.
website_event, website_blog, website_forum and website_sale add
functions to . These functions are bound to
server side qweb nodes protected by groups. We can always add the
functions; if a user tries to use the routes he should receive a
traceback because of lack of access rules
website_blog adds a module, but is guarded by
the presence of a node in the DOM. We use the same logic to guard the
module added by website_sale with the node.
website_gengo is working as expected.
- Create a tax:
Fixed amount: 10
Price included
- Add it by default to a product costing 100
- In a SO/PO/Invoice, add 2 units of the product
The total price is 210 instead of 200.
opw-779696
Fields `amount_type` on `account.tax` and `account.tax.template` are
already defined in the `account` module.
Redefining them here (with the same parameters) breaks every other
module that would have used `selection_add=` on those fields.
Actually, it is the case in `account_tax_python`, and thus, all the
localizations/customizations that depend on it were broken by this one.
~ Old API backport of 5d0d80afa5 ~
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
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
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
When following these steps on Firefox:
- Select all text in a bold link (triple click)
- Type some text
The typed text did not replace the selected text but was instead put
at the front of it.
5afb5ecd04 rewrote the tax computation
in both account and point_of_sale to fix complex tax computations but
it no longer allowed negative prices in the point of sale.
opw-778013
Before this commit, a portal user would land on /web after login in with oauth.
He would then just see the "Website" app.
He should then click on it to land on website instead of landing directly on it
after login in, which is not convenient, especially since theses users doesn't
know Odoo (in case of sale customers manually created for instance).
Now, if users has no 'base.group_user' right, it will be redirected to the
website directly instead of /web.
- Create a tax included of 21 %
- Create a product sold 7.00, set the 21 % tax
- Add the product in a SO
Amount w/o tax: 5.79
Amount tax: 1.22
Total: 7.01
We defer the base rounding to the end of the method so that the rounding
doesn't impact the tax computation of included taxes.
Complement of 6e46ba7b46
opw-777221
We have problems when trying to validate our EU VAT report because some vat number are wrongly encoded in Odoo.
There are 2 problems:
1) We use vatnumber library to check the validity of the VAT number entered by the user on website.
That library removes the following characters '.' and '-' in order to perform the check and
thus can return True for a number like 123.123.123.13 or -123-3454-34
And those VAT number are then saved in our database but are rejected by the state
as VAT number should only contains alphanumeric character
-> Solution: prevent entering vat number with other characters than alphanumeric for users that are located in EUROPE!
2) Usually VAT is prefixed by country code, however some people in europe managed to bypass the system
by prefixing their VAT number with CC instead of their country code, CC is consider valid in odoo
(it means Country Code) but is not a valid European country code in general, which means that those
people that should have pay some tax have not. Which is a huge problem.
-> Solution: prevent the use of CC as country code by the user when entering a vatnumber only if the user country is in EUROPE!
source: https://en.wikipedia.org/wiki/VAT_identification_number
opw:772621
opw-774286
*Before this commit:
On checkout, you can enable a step to force user to have the General Terms of
Sale checked to continue the checkout. Checking/Unchecking will correctly
disabled/enabled the button.
The checkbox is already checked at page load (on the template).
BUT, if the template has been modified to set the checkbox as unchecked at load
(eg the user removed 'checked="checked"' from the template), the button will
still be enabled even if the checkbox is unchecked.
*Now:
No matter if it is checked or not on the template, the button will
correctly be enabled/disabled regarding the checkbox state at load.
Specifically, the command `(6, 0, ids)` should only unlink/detach the lines
that satisfy to the field's domain.
Test from #18440
opw-756983
Closes#18438Closes#18440
Origin of the fix: the snippet background image did not change the background image.
This was due to commit a14f89c which wraps the snippet's content into a table for outlook display compliance
This issue is fixed here, with the modificaion of the background snippet option.
OPW 772442
In some case, user set a currency on the journal which is the same as the company currency. In that case, the field taken was amount_currency which should not be the case.
OPW 775123
When an element is placed multiple times in a page, it is saved only
once. Unfortunately, when a view was divided in multiple editable
parts (XML branding), only one of those parts were saved.
When editing the content of a <label/> which has XML branding (first
DOM element which is editable in its hierarchy), a <p/> element was
added inside. This behavior is there to automatically add <p/> elements
in empty editable <div/> / <section/> elements on edition. This should
however not apply on <label/> elements.
8ac39287 introdcude a way to export the source terms not located inside an
addons module (e.g. error messages in openerp/service/models.py)
0529a7f9 fixed a bug in the get_module_from_path with addons path with similar
names.
The above commit introduced a regression making files located outside of an
addons path to be wrongly considered as a module
e.g. openerp/service/models.py used not to match any module and was considered
correctly as belonging to base module
After, 0529a7f9, '~/openerp/service' being different than '~/openerp/service/'
the module was considered as 'models.py' (which is incorrect).
Compare correctly both parent path to have a correct match
Fixes # 19907
- Create 2 companies: A is parent of B.
- Demo is in Company A
- Create 2 invoices for a partner: one in A, one in B (100 each)
- Validate the invoices
Connected as Demo, the 'Invoiced' amount on the partner form view (stat
button) is 100, while clicking on it shows both invoices (total of 200).
There is no need to manually add the company in the `where` clause since
the `_apply_ir_rules` will take care of adding the appropriate
multi-company rules.
opw-772479
The google 'video.google.com/get_player' URL seems to be deprecated so
the URL used by website_slides had to be updated.
Also when switching a slide URL from a drive URL to a youtube URL, odoo
still kept thinking it was a drive URL.
opw-773984
Odoo Translation Bot