When checking if tags had changed, a missing .ids made it that a recordset was
compared to a set of ids (integers).
As a result, to make an edit the forum would always check that the user had
sufficent karma to retag, even if it was not needed.
opw 1866019
Before this commit, you can set the question of a post like the post itself.
That will generate a traceback:
RecursionError: maximum recursion depth exceeded in comparison
Now we check that there is no recursion
If you set 200 kamra to allow to flag a post and 300 to edit all post, you was
not able to flag the post before this commit.
This commit closes#21274
@kangol: warning, fwd port need to add tag_ids into trusted_keys
On P3, "text" IO (open(f, mode='r')) will default to the encoding
provided by locale.getpreferredencoding(False) which apparently is
regularly cp1252.
Replace by misc.file_open which enforces UTF-8 decoding in text mode.
/mail/view controller is a generic controller that redirects to a view
on a document either on backend or frontend depending on the module,
user and some model specific conditions.
However currently url computation is not always correct as you may end
up on frontend view even when you are a regular user that should land
on backend views.
In this stable version we introduced a key in the returned action that
indicates the action is a pure front-end (public) action or not. This
way people are correctly redirected to the backend or the frontend
when going through the controller.
In order to be able to identify what action to return based on the
access_user.
Typically portal users will need to be redirected to the front-end,
while internal users will need to be redirected to the back-end.
mail.thread mixin will (re)provide the field 'website_message_ids'.
Models can redifined its domain, since it can differ a bit (blog, forum,
... are not the same).
Even if the domain can differ, we still keep it on the mixin since
it will be required for the new chatter frontend (see following
commits).
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
As message_post is defined on mail.thread abstract class its api.returns
is not automatically added on overridden versions of the method. This
commit add missing api.returns on all overrides of the method.
There is now a single method easier to inherit to add specific behavior
for the display of access button as well as actions buttons. All addons
using this mechanism are updated accordingly.
mail/view controller is a generic controller that redirects the user to a
given view, depending on the record and the user. Users may be redirected
to the backend form view, or to a website view. This is done notably by
calling get_access_action method that gives the action to perform (act_window
or url).
Previously this method was called using SUPERUSER. However it was therefore
impossible to know who the user was. This method is now called using the
current user. Various overrides of get_access_action have been updated to
add some logic and access rights check directly in the method allowing
more fine-grain behavior of the access action.
Forum and blog are public models that could have a lot of followers. After
notifying followers of a new comment, discard the needaction information.
For those models email is considered as sufficient. This way we avoid storing
a lot of unnecessary entries in the m2m table between message and partner.
Now having
* sanitize: run the sanitizer to clean the html (removing javascripts,
unwanted tags, ...)
* sanitize_tags: only a subset of tags is allowed in html content.
Unwelcomed tags are remove dand their content stripped.
* sanitize_attributes: only a subset of attributes is allowed.
* sanitize_style: only a subset of style attributes is allowed. Style
attributes are parsed to keep only a white list.
* strip_style: all style is removed. It bypasses sanitize_style as there
is no need to sanitize something that is removed.
* strip_classes: remove class attributes
Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.
Nicolas Martinelli