Currently, if someone without access to the full html input filter prepares a page needing this format (for instance due to embedded images), two things happen:
- while the page is in mod queue, it remains as "filtered html" and does not display the
imgelements - when someone removes it from mod queue and applies the "full html" filter, the permission is not granted to the page author for that filter, while, the node/ page does not display the edit tab, and a non-explicit "access denied" message is returned for node//edit because the user does not have permission for that filter
Unless a way to have the content filter authorized on a per-page basis, a useful workaround would be to at least return an error indicating whence the access denied error comes, in that case the content filter permission.
Comments
Comment #1
Bèr Kessels commentedThis is part of a bigger issue, namely that we cannot
* return detailed access denied messages
* return details to the user what role is needed for certain permissions (lfor example "log in or register to post comments" should be "only %role can post comments")
Comment #2
pnm commentedIs this a feature request for core?
If it's (also?) a documentation issue, where should this behavior be explained?
Comment #3
anschinsan commentedComment #4
jhodgdonSounds like it's a feature request for the filter module. Drupal 7 is feature closed, so pushing off to Drupal 8.
Comment #5
sunThanks for taking the time to report this issue.
However, marking as duplicate of #91663: Permission of text format is not checked when editing an entity and instead reset to something a user can use..
You can follow up on that issue to track its status instead.