Answer I can provide that usefully add value are listed below:
I actually precisely wrote what I did. I started reverse engineering how to
solve the problem, using my other two preexisting lists. One was already
'public' (meaning browsable). Since I could delete the footer on that one
without changing to browsable, I tried eliminating the footer on the other
non-browsable list by changing it to browsable. That worked, but I couldn't do
the same magic on the non-browsable list I wanted to change, apparently because
of the same bug.
The fact that all three browsers installed on my PC demonstrate the same
misbehaviour suggest it is indeed NOT a browser issue.
You asked about how mailman is installed. This is a shared server running
Plesk. I have the right to install my own applications that are available as
installable packages. Once these are installed, I get nagged *frequently*
about upgrading these packages I install to the most recent version. But
mailman is part of the base package, so I never get invited to update that one.
I have suggested to the service provider that they do this, but so far they're
just thinking about it. They asked for access to the list so they could see
the behavior themselves.
To pick up on what Carl Zwanzig wrote and synthesize it with what you wrote,
the bug is probably in the code implementing the actions of the 'Submit my
changes' button. I suppose that would be the next place to look, but I
thought that, since this problem had been around so long, someone would know a
workaround that would save me an extended session of webpage archaeology.
Heck, if I knew where the footer data was stored, I'd be happy to go in and
edit the file by hand, the web page be damned. I just want to get this
delivered and out of the way. Watch it probably be in some DB for which there
was never any compelling need.
Ch.
-----Original Message-----
From: Mark Sapiro <m...@msapiro.net>
Sent: Wednesday, 5 July 2023 22:39
To: mailman-users@python.org
Subject: [Mailman-Users] Re: Mailman 2.1.15 doesn't allow admin changes on
private lists
On 7/5/23 1:27 AM, Charles Buckley wrote:
I experimented with this a bit, and found that I could eliminate the footer on
my public (browsable) list on the same server. So I tried converting my other
private (non-browsable) list to be browsable, at which point I could eliminate
the footer, and then switch the list back to being non-browsable.
You said in a reply that on this list you actually needed to set the list
`public` before you could successfully change msg_footer.
But once I tried to implement the workaround on the non-browsable list I wanted
to change, I got the same defective behaviour when trying to switch the list to
be browsable -- I would get redirected to the admin login page for the list in
question, log in successfully, only to come back and find myself on the same
privacy page, with no changes having been made.
This is quit strange. The behavior you observe is a result of your login
cookie being lost. I could conjecture that there's something in the
browser that's not saving the cookie when this list's name is in the
URL, but the fact that you can make some changes to the other list
including switching it from private to public but can change msg_footer
only when it's public belies that.
I have also posted this as a bug via the Mailman launchpad. This behaviour
appears to be browser-independent; I have tried it on Firefox, Chrome, and Edge.
More confirmation that it's not a browser issue. I have added a comment
to your bug report to see this thread.
Do you know how Mailman is installed on the server? Is it from source or
a third party package? I can't see anything in the admin UI code that
would effectively log you out upon submission of an update form, but
this is what's happening. Either your login cookie is being removed or
for some reason, not being saved.
Normally, I would suspect the issues in the FAQ at
<https://wiki.list.org/x/4030614>, but those normally affect all changes
to all lists, so that may not be relevant here.