On 1/13/2026 10:46 AM, Stephen J. Turnbull wrote:

dap1--- via Mailman-users writes:

...

How do I manually change a member's address? I can't find any way to do that from the mailman-web pages. Do I need to do it within MySQL somewhere? TIA.

Log in as superuser (list owner does not allow you to manage users), click on the the Users tab (this is visible on the list of lists page; the Users menu for the list itself does NOT provide the "manage user" functionality), find the User for the member in question, and click the Manage button on the right hand side.

You could also do it with "mailman shell", but I don't know the exact APIs.

It *may* be possible to do with naive SQL queries but I'm not sure about that -- there are various relations and indicies you may to update as well, and you have to know the ins and outs of the tables because there isn't a straightforward user record with a text record for "email". An Address is not just a string, and the User-Address relation is one-to-many. All that is managed automatically by the Python models in Mailman.

I can't seem to confirm the superuser's email address. I get the confirmation link and when I click it, the confirm button shows up. However, when I click confirm it immediately goes to the login page and when I try to login it sends another confirmation. Its an unending loop.

On 1/14/2026 1:41 AM, Stephen J. Turnbull wrote:

Dennis Putnam via Mailman-users writes:

...

I can't seem to confirm the superuser's email address.

Find the address in both the account_emailaddresses table and the addresses table. I'm interested to see the full record for both (you can obscure the email and display_name for this purpose). This is in the interest of figuring out why you are inflooping in the confirmation process. From database mailmanweb:

mysql> show tables; +-----------------------------------+ | Tables_in_mailmanweb              | +-----------------------------------+ | account_emailaddress              | | account_emailconfirmation         | | auth_group                        | | auth_group_permissions            | | auth_permission                   | | auth_user                         | | auth_user_groups                  | | auth_user_user_permissions        | | django_admin_log                  | | django_content_type               | | django_mailman3_maildomain        | | django_mailman3_profile           | | django_migrations                 | | django_q_ormq                     | | django_q_schedule                 | | django_q_task                     | | django_session                    | | django_site                       | | hyperkitty_attachment             | | hyperkitty_email                  | | hyperkitty_favorite               | | hyperkitty_lastview               | | hyperkitty_mailinglist            | | hyperkitty_mailinglist_moderators | | hyperkitty_mailinglist_owners     | | hyperkitty_profile                | | hyperkitty_sender                 | | hyperkitty_tag                    | | hyperkitty_tagging                | | hyperkitty_thread                 | | hyperkitty_threadcategory         | | hyperkitty_vote                   | | postorius_emailtemplate           | | socialaccount_socialaccount       | | socialaccount_socialapp           | | socialaccount_socialapp_sites     | | socialaccount_socialtoken         | +-----------------------------------+ 37 rows in set (0.00 sec)

The table account_emailaddress has 3 entries:

mysql> select * from account_emailaddress; +----+-----------------------+----------+---------+---------+ | id | email                 | verified | primary | user_id | +----+-----------------------+----------+---------+---------+ |  1 | uuuu@ddddddddd.net    |        1 |       1 |       2 | |  2 | uuuu@ddddddddd.net    |        0 |       0 |       3 | |  3 | xxxxxxxx@gmail.com |        1 |       1 |       4 | +----+-----------------------+----------+---------+---------+ 3 rows in set (0.00 sec)

Yes, id 1 and 2 are the same email address.

From database mailman:

mysql> show tables; +--------------------+ | Tables_in_mailman  | +--------------------+ | _request           | | acceptablealias    | | address            | | alembic_version    | | autoresponserecord | | ban                | | bounceevent        | | contentfilter      | | domain             | | domain_owner       | | file_cache         | | headermatch        | | listarchiver       | | mailinglist        | | member             | | message            | | onelastdigest      | | pended             | | pendedkeyvalue     | | preferences        | | template           | | uid                | | user               | | workflowstate      | +--------------------+ 24 rows in set (0.00 sec)

I'm not sure what you want to see in this address table. There is a lot of unexpected email addresses that I have no idea where they came from. In any case the user_id in this table does not correspond to the user_id in the table from the previous mailmanweb table. Here are the columns:

+----+---------------------------------------------------+-----------+------------------------+---------------------+---------------------+---------+----------------+ | id | email                                             | _original | display_name           | verified_on         | registered_on  | user_id | preferences_id | +----+---------------------------------------------------+-----------+------------------------+---------------------+---------------------+---------+----------------+

Confirmation you can do with a single SQL update. Find the address in the account_emailaddresses table and update the verified attribute to t. I think that's enough to allow you to log in. If not you should do the same for that address in the addresses table. However, in the addresses table you need to fill the verified field with a timestamp. Not sure how that works in SQL, try copying the value of the registered field.

I don't know why you're inflooping though. It's possible that you're verified in one table but not the other, confusing Postorius.

Dennis Putnam via Mailman-users writes:

From database mailmanweb:

mysql> show tables;

I'm sorry for the typo for account_emailaddress, but I don't need this. I know what tables mailmanweb creates, and what tables mailman creates.

The table account_emailaddress has 3 entries:

mysql> select * from account_emailaddress; +----+-----------------------+----------+---------+---------+ | id | email� � � � � � � � �| verified | primary | user_id | +----+-----------------------+----------+---------+---------+ |� 1 | uuuu@ddddddddd.net� � |� � � � 1 |� � � �1 |� � � �2 | |� 2 | uuuu@ddddddddd.net� � |� � � � 0 |� � � �0 |� � � �3 | |� 3 | xxxxxxxx@gmail.com |� � � � 1 |� � � �1 |� � � �4 | +----+-----------------------+----------+---------+---------+ 3 rows in set (0.00 sec)

Yes, id 1 and 2 are the same email address.

I asked for the superuser ONLY. I assume "xxxxxxxx" is irrelevant and "uuuu" is the superuser, and I guess the duplicate is probably why you have the verification loop, as Mark did. Please check the logs for a backtrace indicating that the address uuuu@ddddddddd.net was found twice. I'm not sure it will be there, but if it is, I'd like to see it (the whole thing including the specific exception).

I'm not sure what you want to see in this address table.

I want to see the address of the superuser (if it's there, it might not be). That's why I specified a WHERE clause.

There is a lot of unexpected email addresses that I have no idea where they came from.

Why "unexpected"? I seem to recall you tried a migration of your list from Mailman 2 at some point. Deleting your Mailman 3 installation will not delete the MySQL databases. You need to do explicit DROPs on them from an SQL application. Mailman 3 does not do that for you.

In any case the user_id in this table does not correspond to the user_id in the table from the previous mailmanweb table.

I still want to see the query results (with the WHERE clause, please). The user_ids need not be equal. Addresses in mailmanweb are many-to- one with users, and addresses in mailman are many-to-one with users, so addresses are used to identify users in both databases.

-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan

On 1/13/26 9:08 AM, dap1--- via Mailman-users wrote:

I got a different user set up as superuser using a gmail address. However, I get to the member's management page but cannot change anything. I see update buttons but they don''t seem to so anything although I get a banner at the top saying the user was updated. What am I doing wrong?

You can't change the user's address that way. You can only update the display name, the verified status of the address and the moderation and delivery mode of subscriptions.

I think you can do it in mailman shell like this

$ mailman shell
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.

 >>> um = getUtility(IUserManager)
 >>> addr = um.get_address('address_to_change')
 >>> addr.email = 'new_address'
 >>> commit()

However, the preferred way is for the user to log in, go to https://whatever/accounts/email/, add the new address to their account, make it primary, go to the list info page at https://whatever/lists/LIST, and if their Subscription Address is still the old address (because they weren't subscribed by primary address), click Manage Subscription and change it, and then possibly remove the prior address.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 1/13/26 11:30 AM, alain williams wrote:

Like it or not it is sometimes easier for me to do that sort of thing than try to explain it to them.

I understand.

So: it would be really useful if the list manager were able to do this via the web interface.

As you indicate, a list admin can use the mass subscribe/removal UI to remove the old address subscription and add a new address subscription, but as you probably know, this doesn't preserve the user's other settings, and for a user with multiple subscriptions, it needs to be done list by list, so this really isn't a satisfactory way for an admin to change a user's address.

There is a current issue at https://gitlab.com/mailman/postorius/-/issues/399 to simplify the process for a user to change their address and one at https://gitlab.com/mailman/postorius/-/issues/194 to allow an admin to change a user's address.

Merge requests are welcome.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan