Problem/Motivation
In #602234: Don't allow admin users to access their own contact form the ability for admins to access their own contact form was removed. Some felt this was a regression and should be reversed, so that admins could access their own contact form, e.g. for testing purposes.
If this issue lands, the contributors from #602234: Don't allow admin users to access their own contact form should be credited. This is essentially a continuation of the work there, but that issue was closed due to a combination of factors making it incredibly difficult to navigate or push forward.
Steps to reproduce
- Log in as admin user with personal contact forms enabled
- See that you can't access your own form
Proposed resolution
Allow users with the 'Administer users' permission to access their own contact form.
Remaining tasks
- Agree that this change should be made
- Make agreed changes with tests
- Review
User interface changes
TBC - admin users would be able to view their own contact form
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Issue fork drupal-3221619
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3221619-allow-users-with
changes, plain diff MR !880
Comments
Comment #2
pameeela commentedComment #3
pameeela commentedComment #5
bnjmnmA working patch that makes it possible for 'administer users' users to use their own form was provided in the issue that spawned this one: #602234: Don't allow admin users to access their own contact form. That patch can be a good starting point if there's agreement that allowing access to their own form is a desirable change.
I'll vote this is a desirable change. This would counter a decision made in 2006 to hide a users own contact form in Drupal 4: #70895: usability: don't show contact when viewing *own* profile. To address the concerns that motivated the change, I recommend that a message be provided when a user accesses their own contact form:
The addition of a 'your own contact for is here for testing' message reasonably mitigates the UX concerns from 15 years ago, but without an opinionated access restriction. I'm not even sure it would be particularly confusing for most users with 'administer users' permissions at this point. Users and Drupal have both changed a great deal in the past 15 years.
Access to ones own contact form IS very helpful. Without knowing that Drupal intentionally prevents access to ones own contact forms, a user may not be sure if the contact form is broken (And yes, this happened to me). It's silently opinionated in a traditionally unopinionated CMS. Creating a test user to test SMTP is an annoying step, especially for local sites that are routinely refreshed with new prod instances.
Comment #7
bnjmnmTagging "needs product manager review" to get signoff on making a users own contact form available when that user has the 'Administer users' permission. Comment #5 has some rationale, as does the issue that preceded this.
Comment #8
pameeela commentedI’m not sure it should be limited to admin users. Seems reasonable that a regular user might want to test their own form too?
Edit: don’t want to derail the issue, it just occurred to me so I thought I’d mention it. Probably that change should be a separate issue since this one has a very specific scope.
Comment #9
andypostThere's related issue which may fire if this setting could be configurable
Comment #10
andypostOne more related because of access
Comment #15
quietone commentedThe Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.
Contact will be moved to a contributed project after the Drupal 12.x branch is open.
Comment #17
andypost