[wp-trac] [WordPress Trac] #60789: Administration Email Address: Allow method to deactivate

[WordPress Trac]

#60789: Administration Email Address: Allow method to deactivate
-------------------------------+------------------------------
 Reporter:  andrewhoyer        |       Owner:  (none)
     Type:  feature request    |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Administration     |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion close  |     Focuses:
-------------------------------+------------------------------

Comment (by jonschr):

 I don't understand why something so simple couldn't just be fixed. Is
 there any net benefit to *anyone* in not allowing a former administrator
 to remove their email address?

 Then, on next login of an administator-level user, the user logging in
 would be able to set that administrative address (to their own address, or
 to someone else's).

  I agree with some of the comments above: this probably more looks like a
 bug in the processes than an issue introduced by WordPress itself. The
 main administrator account should be set to the owner of the website, not
 to the person who installed the website.

 This administrative address is used for technical contacts, primarily, and
 the owner of the website is often not the technical contact. This is not a
 bug in the process. This is a failure of system design on the part of
 WordPress itself, not on the part of developers who are mostly doing the
 same thing – using their own email address, because that's the most
 obvious way to set it up from the get go. (If there were separate fields
 for technical contact and site owner, users would generally set this up
 the "right" way, but this would be purely forward-looking, and wouldn't
 fix the existing issue).

  non admin users shouldn't be able to change databases

 - A non-admin user leaving a comment on a website running vanilla WP with
 no plugins is changing the database.
 - A non-admin user logging in to the website stores the session token in
 user meta for that user, changing the database.
 - A user registration changes the database (as a non-admin user).
 - Core forms, including a password reset attempt, modify the database.

 For these reasons, this objection is nonsensical.

  @webdados I don't think we should allow anyone from the outside to change
 a WordPress option on a website they no longer control, even if it's their
 email address.

 This assumes details of the implementation which might or might not be how
 it would actually be implemented.

 It's *their* email address. This isn't an incidental point. CCPA gives a
 particular class of users, including for this use case, the right to opt
 out of having their personal data be stored. WordPress Core has an
 opportunity to solve this simply and completely, rather than putting the
 onus on individual site owners.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60789#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform