Currently if public user has country_id, following traceback is raise
when /shop URL is opened:
Traceback (most recent call last):
File "/.repo_requirements/odoo/odoo/addons/base/models/qweb.py", line 331, in _compiled_fn
return compiled(self, append, new, options, log)
File "<template>", line 1, in template_website_sale_products_item_306
File "/.repo_requirements/odoo/addons/website_sale/models/product.py", line 294, in _get_combination_info
fpos = self.env['account.fiscal.position'].get_fiscal_position(partner.id).sudo()
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 184, in get_fiscal_position
fp = self._get_fpos_by_region(delivery.country_id.id, delivery.state_id.id, delivery.zip, vat_required)
File "/.repo_requirements/odoo/addons/account/models/partner.py", line 141, in _get_fpos_by_region
fpos = self.search(domain_country + state_domain + zip_domain, limit=1)
File "/.repo_requirements/odoo/odoo/models.py", line 1708, in search
res = self._search(args, offset=offset, limit=limit, order=order, count=count)
File "/.repo_requirements/odoo/odoo/models.py", line 4485, in _search
model.check_access_rights('read')
File "/.repo_requirements/odoo/odoo/models.py", line 3331, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "<decorator-gen-33>", line 2, in check
File "/.repo_requirements/odoo/odoo/tools/cache.py", line 90, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/.repo_requirements/odoo/odoo/addons/base/models/ir_model.py", line 1792, in check
raise AccessError(msg)
odoo.exceptions.AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Error to render compiling AST
AccessError: You are not allowed to access 'Fiscal Position' (account.fiscal.position) records.
This operation is allowed for the following groups:
- Accounting/Advisor
- User types/Internal User
- User types/Portal
Contact your administrator to request access if necessary.
Template: website_sale.products_item
Path: /t/t[2]
Node: <t t-set="combination_info" t-value="product._get_combination_info(only_template=True, add_qty=add_qty or 1, pricelist=pricelist)"/>
Above was tested and reproduced in an instance of odoo runbot v14.0:
https://youtu.be/GgUnyna_EX8
That is due to public user has not permission to read model
account.fiscal.position and in fact in ACL, permission contains
'public' but is setting group_portal.
closesodoo/odoo#73117
X-original-commit: 53dc9f62b6d4c362292bf48df54b11c4852f6006
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In order to ensure consistent results of all error conditions returned
by the LDAP server, the _authenticate() method should return `False`
for every kind of exception, not just for INVALID_CREDENTIALS.
This is not actually relevant in 12.0 as the result is exactly the
same, due to the way the `entry` variable is being initialized, but it
will make the code path "visibly consistent" across all supported
versions
closesodoo/odoo#72484
X-original-commit: 24a3f669e5199c35849dabbf7b0d37f43b684538
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
This method only expects to be called as POST and should not be called
with GET.
This commit enforces that.
[CLA] Signature for sushiwushi
closesodoo/odoo#71575
X-original-commit: 00f2eeee7aa514599b40e049be46eacdcc8332fa
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In odoo/documentation-user#945, the developer documentation is merged
with the user documentation in a single repository and build config.
This commit then removes source files for the developer documentation
from the odoo/odoo repository.
DOC PR: https://github.com/odoo/documentation-user/pull/945
task-2351938
task-2352371
task-2205684
task-2352544
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>
Previously, lazy-loading xml templates was only possible by fetching the
xml file directly, this meant that it was impossible to lazy-load an
entire bundle's templates with a single request. Additionally,
requesting the xml files directly meant that no inheritance was applied,
causing the need for a separate inheritance system using t-jquery on the
client-side.
This commit alters the /web/webclient/qweb route so that it now takes a
bundle id, meaning that it is now possible to lazy-load the xml from
arbitrary bundles.
task-2497943
closesodoo/odoo#70084
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
RATING
Rating texts currently have a negative skewness. Indeed apart top rating
all ratings have a negative feeling. In this commit we update them
to match more closely a 1-5 range from dissatisfied to satisfied, ok being
the middle value.
PROJECT
Filter customer rating were taking in account ratings from first e-mail
instead of current satisfaction.
IM LIVECHAT
Livechat did not catch feedbacks without comment.
Task ID-2439720
COM PR odoo/odoo#66992
ENT PR odoo/enterprise#16757
The calendar renderer used a template for events.
Now moved as a configurable template to ease futur calendar changes.
This commit adds also a custom event to the calendar renderer so that custom
implementations have a way to re-render the event items within the calendar
after making internal changes to the event records.
We introduce also a new option for a field "filter_field" which allows to specify
the field of the model in which we will save the status of a filter.
This is preliminary changes in order to make the calendar view able to modify
the attendance status of a meeting and refresh the events to visually display
if the user is attending or not.
Task ID 2196775
COM PR: odoo/odoo#55190
ENT PR: odoo/enterprise#12196
UPG PR: odoo/upgrade#1532
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: jeh-odoo <jeh@odoo.com>
Rationale:
The majority of cases where an ir.asset is manually declared
outside of manifest files is to specifically add a single asset file.
This means developers are specifying a single asset *path*, and not a
glob expression. In this context, it seems better to name the filepath
field `path`, and document that it can be specified with a glob
expression when (seldom) needed, rather than making the exception appear
to be the norm - possibly puzzling many developers (What's a glob and
why do I need one?)
The doc is updated as well, and some spell-checking and wording
improvements were done too.
This required some adaptations to the existing `ir.asset` declarations:
- odoo/enterprise#17465
- odoo/design-themes#459closesodoo/odoo#68695
Related: odoo/upgrade#2348
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
- fixes some typos
- adds command parameters which are present when running odo-bin --help
- updates some descriptions, e.g. regarding configuration file and data-dir
closesodoo/odoo#67778
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A few changes to the layout and texts of the "Assets Management" part of
the javascript reference documentation.
closesodoo/odoo#68649
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit changes the way assets are declared in Odoo modules.
Before: assets were declared in template files. Template bundles were
generated from primary templates, so technically any qweb template could
have been called as an asset bundle, with the 't-call-assets' directive.
Being standard qweb templates, they had access to standard HTML tags
(script, link, with or without raw scripts or style definition), qweb
directives (t-call, t-raw, etc.) and could be inherited by other
templates.
Now: assets are defined in the module's manifest and generated by the
't-call-assets' directive.
More information on the new system can be found on the updated user
documentation (see the "JavaScript Reference" section).
Task: 2352566
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
OdooJeel