jQuery has a special behaviour when using .contents() over an iframe
object. This caused an error for escaping when saving the page with an
iframe content of an external domain.
introduced by 8c77c711
opw-649570
Escape text nodes changed via the web editor before sending the content
it to the server controller.
It is done since the content is unescaped one time when being displayed,
and it is not done for inline style and script tags (which may be
injected by dropping a snippet) since that would break them.
replacing the solution in cdb900044.
Pasting from the website to the website could for example copy
t-field="..." which then would easily add an error if e.g a field
is copied to an area where it is not available.
This fix strip the data-oe-... attributes of nodes added to the DOM
when pasting.
closes#7653
opw-644968
when closing a modal, the class 'modal-open' was removed from the
'body' tag and all the existing modals became not scrollable.
The class 'modal-open' must be kept in the 'body' tag if there is
still a visible modal in the dom.
Inspired from commit: dee000be14
opw:633801
For some reasons, the browser will prevent to open the system file browser when clicking the input file with javascript using the jquery class element, but it works when using the standard js dom element.
Changes to contentEditable or attributeEditable attributes
should not cause the corresponding section to be marked
as dirty (oe_dirty). This would otherwise cause an extra
editor save() for those, wrongly marking untouched
templates as `noupdate`, and possibly triggering access
right errors.
The Edit button never appeared anymore for these users.
The idea was that they should see an edit button with
limited editing capabilities depending on their other
access rights.
For example, someone with only Sales Manager access and
'Display Editor Bar on Website'
would be able to edit online quotes from the website_quote
module, but not change the actual website pages or menus,
for instance.
This quick fix avoids a buggy behaviour in version 8.0 that could
confuse users.
A future version should implement properly selection fields in t-field.
(closes#2490)
(cherry picked from commit fe3cac30e4c5c132da1de02576d4aa325979ccd9)
The @groups attribute in qweb views was not rendered (even when matched by the
user), so editing a template with an @groups would either remove the whole
section (if the user didn't have the groups, fixed in previous commit) or only
removed the attribute itself making it visible to everybody (which ought be
fixed-ish by this commit).
If the current view uses @groups attributes (possibly in called templates),
the corresponding elements are rendered to a void (empty string in qweb). If
said user can edit the page, does so and saves a view section in which there's
a @groups to which he has no access, the element[@groups] is completely
removed from the template once saved, losing it.
If QWeb encounters an @groups to which the current user has no right during
rendering, have it request a no-RTE page, so the user can not RTE-edit the
page (or drop snippets in it).
set of fields that we try to edit (body_html and body for body, email_from and email for
email-from, name and subject for subject), because t-field is not dynamic. If the model
that should be edited does not hold those fields, the mail editor won't work.
Also fixed editor not being actiated when going into the body edition.
bzr revid: tde@openerp.com-20140416105901-vavkh9erjsq4mof9
Nicolas Lempereur
Goffin Simon
Goffin Simon
Jeremy Kersten
Denis Ledoux
Olivier Dony
Christophe Matthieu
Ajay Patel
Fabien Meghazi
Christophe Simonis
Simon Lejeune
Paramjit Singh Sahota
Xavier Morel
Christophe Simonis
chm@openerp.com
Thibault Delavallée