2023-05-16 17:42 に peter@chubb.wattle.id.au さんは書きました:
I notice that for people with multiple email addresses, the email address that appears as the 'FROM' address in the hyperkitty archive is not the primary address, nor is it the address that the email actually came from, but the address that was created first. (Hyperkitty version 1.3.7)
I can't help with this. I don't understand why that would happen, maybe Mark or Abhilash does. I would think that the address that would be shown is the address in the email's From field.
When I click on that from address in the archive view, I see all the email addresses for the user -- these do not match up with the ones in the django admin screen from .../admin/account/emailaddress/
They shouldn't, necessarily. The user's active emails will be maintained by the user in Postorius, which what I believe appears in the Django admin screen. However, HyperKitty needs to know *more*: in general, it needs to know every address by which that user was identified in the archives. This is valuable to the users of the archives -- if they try to mail an author at a defunct address, they can return to the profile to find an active one.
How can I as administrator get rid of bogus addresses? Or do I have to ask each user to do this?
I believe Mark has a script for getting rid of garbage addresses that have no root in user-visible data, but these are not garbage in that sense: they do appear in the archives. However, since that script refers only to the database, it would probably work for HyperKitty's addresses too. But it might require code modifications, inasmuch as there would be database errors if either the Address object doesn't exist or the User link in the Address object is null.
and how can I ensure that the email address displayed in the archive is the primary address, not some address that no longer works?
That's not necessarily your choice (I'm not speaking to your installation, I'm talking about design principles). Remember that users can associate specific addresses with specific lists, and you would be overriding that preference ex post. (I have no problem with you announcing a "real address only" rule in advance, of course.) Also, there may be a reason why that address is defunct: stalkers, termination of employment, etc. In those cases, the user may have a strong desire not to contacted about the post in question. If you are in a jurisdication that is under GDPR or other strong privacy legislation, there may be legal implications you should consider. In general you should consider whether possibly violating users' expectations in these ways are appropriate to your site.
In general, Mailman 3's design philosophy is to give users fine control of their user profiles and addresses and of their subscriptions' configurations, while list owners get the traditional features for their list configurations: control over access and default profiles, etc. So I suspect there is no way to impose the restrictions you want without writing new code. I don't have a particular objection to such features as long as the policies are transparently documented (users don't have to use those sites), but I'm not available to work on them for some time.
-- University of Tsukuba Faculty of Policy and Planning Sciences Tennodai 1-1-1, Tsukuba 305-8573 JAPAN tel/fax: +81-29-853-5091 turnbull@sk.tsukuba.ac.jp https://turnbull.sk.tsukuba.ac.jp/