Revision settings visible to users that don't have administer users permission

Created on 23 September 2016, almost 8 years ago
Updated 4 April 2023, about 1 year ago

At admin/config/people/revisions users who don't have the administer users permissions can set whether editing users creates a new revision or not. Does this mean that this module can't be used to build a system where some people can update users, but those changes are tracked? What determines whether a user can see this page and edit this setting?

πŸ› Bug report
Status

Postponed

Version

1.0

Component

Code

Created by

πŸ‡³πŸ‡ΏNew Zealand thomasmurphy

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany Ronino

    #2 works for me, thanks!

    RickJ wrote:

    I don't agree that this patch is necessary. The admin page in question already requires "View revisions" access, which is noted as a trusted permission. This permission in fact covers the "administer" case. Ordinary users should not be able to see other users' revisions for obvious security reasons.

    In my opinion, viewing something should never cover administering something. The user module does it right, introducing two permissions to view users ("access user profiles") and administer them ("administer users"). Likewise this module should either use the existing "administer users" permission to restrict access to configuration (like the issue title implies) or introduce its own administer permission (like #2 does).

  • Status changed to Postponed about 1 year ago
  • πŸ‡¬πŸ‡§United Kingdom RickJ

    Arguable.

    Viewing revisions is not like viewing content, it's implicitly an administrative function in itself. Viewing the revision history of content other than your own is not something a normal user should be doing. So "view any revision" implies administration. Adding another permission just to manage access to the configuration page - with 2 options, 4 if diff is enabled - strikes me as overkill. I can see an argument for using "administer users" as the permission to protect that page though.

    Also, would an "administer" permission override view-any, revert-any, and delete-any? It starts to get messy.

    The fix in patch #5, which expands the permission descriptions, was rolled into the 7.x-2.x release anyway, which I recommend using.

Production build 0.69.0 2024