Make web_page_url visible in the admin GUI?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've taken over responsibility for an old Mailman installation which used to be configured with incorrect vhost information. As a result, web_page_url is incorrect for many lists.
I have found the info about using config_list to adjust web_page_url, and now I have some questions/suggestions:
Is there any reason not to add web_page_url to the configurable options in the admin GUI? Right below host_name in the general category would be a good place.
Or, if the web_page_url is to remain hidden, should it not be re-calculated based on the current mm_cfg.py settings whenever the host_name setting for a list is changed - or even, calculated every time that information is required?
Thanks,
Max.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDh35bfFNSmcDyxYARAnY/AJwIKOQvvDevwtunG2+iLhOBI/AUiACfZAoS Hth3dW+nc6NWmFNax7cndf0= =KsI8 -----END PGP SIGNATURE-----
"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> Is there any reason not to add web_page_url to the
Max> configurable options in the admin GUI? Right below host_name
Max> in the general category would be a good place.Yes, please!
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
On 11/26/05 1:25 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> Is there any reason not to add web_page_url to the Max> configurable options in the admin GUI? Right below host_name Max> in the general category would be a good place.Yes, please!
Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago.
Thought experiment:
Make a typo which cripples the URL such that you can't reach the admin web page.
Now fix it from the browser.
The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable.
One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please).
--John
"John" == John W Baxter <jwblist@loricamail.com> writes:
John> Thought experiment: 1. Make a typo which cripples the URL
John> such that you can't reach the admin web page.I actually don't care what the admin URL(s) are. That's what bookmarks are for, and my list admins can learn to use them, too, or they can be ex-admins.
What I would like is for it to be (a lot) easier to change the user URLs, because there presentation matters.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen J. Turnbull wrote:
"John" == John W Baxter <jwblist@loricamail.com> writes:
John> Thought experiment: 1. Make a typo which cripples the URL John> such that you can't reach the admin web page.I actually don't care what the admin URL(s) are. That's what bookmarks are for, and my list admins can learn to use them, too, or they can be ex-admins.
What I would like is for it to be (a lot) easier to change the user URLs, because there presentation matters.
Actually, I think the point John was making was that if web_page_url is set incorrectly, the admin UI becomes inoperable, because it uses absolute URLs generated using web_page_url to make links and form submission URLs.
Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiLH4fFNSmcDyxYARAo3HAJ9X7Fwb90Yha27+iEHjaunmWV4mmACgw9Hk A7a/TYYAo63ITW+nVf1YOIA= =jHQf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John W. Baxter wrote:
On 11/26/05 1:25 AM, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
>"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> Is there any reason not to add web_page_url to the Max> configurable options in the admin GUI? Right below host_name Max> in the general category would be a good place.
Yes, please!
Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago.
Thought experiment:
Make a typo which cripples the URL such that you can't reach the admin web page.
Now fix it from the browser.
The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable.
One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please).
OK, that is a good reason.
Still, sometimes it really is necessary to change web_page_url. So here are two different possibilities for providing some amount of web_page_url control through the admin GUI, whilst avoiding the possibility of typos blocking web admin access:
OPTION ONE: Whenever the host_name configvar is changed, *if* the new value can be found in mm_cfg.VIRTUAL_HOSTS, *then* recalculate web_page_url based on mm_cfg.DEFAULT_URL_PATTERN and mm_cfg.VIRTUAL_HOSTS.
OPTION TWO: Make links and form action URLs within the admin interface relative, so that an incorrect web_page_url does not render the admin interface inoperable.
What do you think? Either? Both?
Thanks,
Max.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiLGVfFNSmcDyxYARAhZyAJ4n9mKI7AgnHiVbLLFjFG6nt5UE1ACgwyT+ AvLCTzCXVRxKx8Q3l6f+dBs= =Di43 -----END PGP SIGNATURE-----
On Sat, 2005-11-26 at 19:03 +0000, Max Bowsher wrote:
OPTION TWO: Make links and form action URLs within the admin interface relative, so that an incorrect web_page_url does not render the admin interface inoperable.
I think ultimately, it would be great if the urls could all be relative, but that was tried in the past and caused worlds of hurt, so everything was changed to absolute urls.
-Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote:
On Sat, 2005-11-26 at 19:03 +0000, Max Bowsher wrote:
OPTION TWO: Make links and form action URLs within the admin interface relative, so that an incorrect web_page_url does not render the admin interface inoperable.
I think ultimately, it would be great if the urls could all be relative, but that was tried in the past and caused worlds of hurt, so everything was changed to absolute urls.
Can you elaborate?
I'd quite like to have a go at fixing this, but obviously I'd rather not spend time on it if there are reasons I haven't thought about which would make such a patch unacceptable.
Max.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDivCjfFNSmcDyxYARAoiEAJ44LdqS+2WmmKqQ0ntP8RBjYpzvqgCfVgCH ffOcvF9ZRChC/MZ6EzQj31w= =nEDD -----END PGP SIGNATURE-----
On Mon, 2005-11-28 at 11:57 +0000, Max Bowsher wrote:
Can you elaborate?
I'd quite like to have a go at fixing this, but obviously I'd rather not spend time on it if there are reasons I haven't thought about which would make such a patch unacceptable.
I don't remember too many details, but I do remember that it was very difficult to get everything working correctly and we had lots of related bug reports. Maybe you'll have better luck. ;)
-Barry
John W. Baxter wrote:
>"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> Is there any reason not to add web_page_url to the Max> configurable options in the admin GUI? Right below host_name Max> in the general category would be a good place.
Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago.
Thought experiment:
- Make a typo which cripples the URL such that you can't reach the admin web page.
As I read it, Max's request is to be able to set the URL to the user webpage, not for the admin webpage. Then the right URL will show up in the list footer, etc.
- Now fix it from the browser.
The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable.
One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please).
How about an option to set a new URL as the "default for displaying in the footer" (and archives, and elsewhere within your list's web structure), while still maintaining an alias (or having the new URL be the alias) to the machine address.
That way the machine address will always work and give you a way to reach your list via the default machine name/listname path if you make a typo or otherwise change the URL in a way that doesn't work.
As an example, this list is at:
http://mail.python.org/mailman/listinfo/mailman-developers
We could add a function to let the list admin set a "default URL". If Barry wanted to change this list to:
http://www.list.org/mailman/listinfo/mailman-developers
Then this would be the new URL displayed in the list footer, and mail sent to mailman-developers@list.org would be sent on to the list membership etc, BUT we could still always reach the list thru the original (default servername) URL and email address.
jc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
JC Dill wrote:
John W. Baxter wrote:
>>"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> Is there any reason not to add web_page_url to the Max> configurable options in the admin GUI? Right below host_name Max> in the general category would be a good place.
Yes, there is a reason. It is the same reason that the ability was taken out many Mailman versions ago.
Thought experiment:
- Make a typo which cripples the URL such that you can't reach the admin web page.
As I read it, Max's request is to be able to set the URL to the user webpage, not for the admin webpage. Then the right URL will show up in the list footer, etc.
No, not at all.
Mailman doesn't really have two distinct web interfaces. It has a single web interface, portions of which are restricted to administrators.
- Now fix it from the browser.
The sort of thing in #1 (sometimes not a typo but a more fundamental mistake) happened often enough to make removing the ability seem quite desirable.
One thing which has changed since the decision is that a much higher proportion of list operators don't have command line access than was the case then. So *perhaps* it would make sense to revisit the decision (making it a site option, please).
How about an option to set a new URL as the "default for displaying in the footer" (and archives, and elsewhere within your list's web structure), while still maintaining an alias (or having the new URL be the alias) to the machine address.
That way the machine address will always work and give you a way to reach your list via the default machine name/listname path if you make a typo or otherwise change the URL in a way that doesn't work.
As an example, this list is at:
http://mail.python.org/mailman/listinfo/mailman-developers
We could add a function to let the list admin set a "default URL". If Barry wanted to change this list to:
http://www.list.org/mailman/listinfo/mailman-developers
Then this would be the new URL displayed in the list footer, and mail sent to mailman-developers@list.org would be sent on to the list membership etc, BUT we could still always reach the list thru the original (default servername) URL and email address.
So, then you have one address considered canonical for users and another considered canonical for administrators?
Umm... sounds like a recipe for confusion to me.
See my previous mail containing proposals for "OPTION ONE" and "OPTION TWO", for two ways I think would be a better approach.
Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiMzPfFNSmcDyxYARAmhaAJ9IMj+jLEyaMLhPR4GRpz1qOpiDZgCgua4w DRqb+MDr8gqvbbJVRcryd9U= =qVYS -----END PGP SIGNATURE-----
Max Bowsher wrote:
Mailman doesn't really have two distinct web interfaces. It has a single web interface, portions of which are restricted to administrators.
That isn't important to the issue, is it?
As I understand it, your issue is what URL is "shown". My suggestion is that we make a change to the code that allows list administrators to change what URL is "shown" to list users. The new URL will also work for list administrators, but the default URL will *also* continue to work.
So, then you have one address considered canonical for users and another considered canonical for administrators?
No. You have one address that *always* works (the server name address) and the option to add another address that also works (assuming you didn't make any errors when you configured the additional URL) and which is the address displayed on the email footer, list help pages, etc.
For instance, many websites that are hosted on virtual domains can be reached thru several different URLs (options vary from host to host):
www.domain.com (the preferred URL, obviously) www.host.com/domain.com www.host.com/~username www.host.com/user/~username www.host.com/user/domain.com
Etc. Only one of these (at most) is the "real" URL to the directory to the domain files on the server. The others are aliases to the same directory. We can do the same thing with mailman, add an alias and mark the alias as the "preferred" URL to be used and displayed on the list webpages and mail footers.
jc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
JC Dill wrote:
Max Bowsher wrote:
Mailman doesn't really have two distinct web interfaces. It has a single web interface, portions of which are restricted to administrators.
That isn't important to the issue, is it?
You said: "As I read it, Max's request is to be able to set the URL to the user webpage, not for the admin webpage."
My point in saying what I did was that 'the URL to the user webpage' and 'the URL for the admin webpage' are not independently settable entities. They are, in fact, identical, just one has things like 'listinfo' or 'options' appended, whilst the other has things like 'admin' or 'admindb' appended.
As I understand it, your issue is what URL is "shown". My suggestion is that we make a change to the code that allows list administrators to change what URL is "shown" to list users. The new URL will also work for list administrators, but the default URL will *also* continue to work.
So, then you have one address considered canonical for users and another considered canonical for administrators?
No. You have one address that *always* works (the server name address) and the option to add another address that also works (assuming you didn't make any errors when you configured the additional URL) and which is the address displayed on the email footer, list help pages, etc.
For instance, many websites that are hosted on virtual domains can be reached thru several different URLs (options vary from host to host):
www.domain.com (the preferred URL, obviously) www.host.com/domain.com www.host.com/~username www.host.com/user/~username www.host.com/user/domain.com
Etc. Only one of these (at most) is the "real" URL to the directory to the domain files on the server. The others are aliases to the same directory. We can do the same thing with mailman, add an alias and mark the alias as the "preferred" URL to be used and displayed on the list webpages and mail footers.
You are talking about very approximately the same issue as I am, but you are approaching it from a different direction, and speaking about it in abstract ways, which, as far as I can see, become partially irrelevant and/or incompatible when applied to Mailman specifically.
First incompatibility: At the moment, the Mailman interface uses absolute URLs based on web_page_url all over the place. This has two consequences: First, even if you have multiple URLs configured in your web server to reach the Mailman interface, the moment follow a link or submit a form, you will end up using the URL defined by web_page_url. Second: If Mailman isn't actually visible at the URL defined by web_page_url, the web interface will be inoperable, even if you manually type an URL at which it is visible, since all links and form submission destinations will be invalid.
Second incompatibility: You are talking about adding a feature to set the preferred URL. But this is what web_page_url already is!!!
Taking account of those incompatibilities and modifying your suggestion accordingly, I think what is reached is essentially what I suggested headed by "OPTION TWO" in my mail that I previously referred you to.
Restating: Make links and form action URLs within the admin interface relative, so that an incorrect web_page_url does not render the admin interface inoperable.
and the earlier context in that mail implied '... and then it will be safe for web_page_url to be a normally accessible configvar in the web UI.
Max. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDiO44fFNSmcDyxYARAkQwAJ4ts7WFBg8IGpEFrnSfn/iicYKjIwCg3huT rCb7rzTiNA9KewHMZR/v5Yc= =4LCB -----END PGP SIGNATURE-----
-On [20051127 00:23], Max Bowsher (maxb1@ukf.net) wrote:
Second incompatibility: You are talking about adding a feature to set the preferred URL. But this is what web_page_url already is!!!
Read again, he is not talking about adding a preferred URL option, but rather explaining what the web_page_url feature could accomplish (since there seemed to be confusion about what it would do).
-- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai Free Tibet! http://www.savetibet.org/ | http://www.andf.info/ http://www.tendra.org/ | http://www.in-nomine.org/ | catcher@in-nomine.org Felix, qui potuit rerum cognoscere causas...
"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> My point in saying what I did was that 'the URL to the user
Max> webpage' and 'the URL for the admin webpage' are not
Max> independently settable entities. They are, in fact,
Max> identical, just one has things like 'listinfo' or 'options'
Max> appended, whilst the other has things like 'admin' or
Max> 'admindb' appended.Right. That has to be changed for me to get what I want.
What I would like to see is a structure where we have
# sitewide site_base_url # the default URL for all Mailman stuff at the site # used for all admin pages at the site # list-specific list_base_url # the URL for the list member stuff, archives, etc # defaults to site_base_url
It seems like that's not what you want, and that's OK with me. I can live without this and it would probably be a fair amout of work to get right.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Stephen J. Turnbull wrote:
"Max" == Max Bowsher <maxb1@ukf.net> writes:
Max> My point in saying what I did was that 'the URL to the user Max> webpage' and 'the URL for the admin webpage' are not Max> independently settable entities. They are, in fact, Max> identical, just one has things like 'listinfo' or 'options' Max> appended, whilst the other has things like 'admin' or Max> 'admindb' appended.Right. That has to be changed for me to get what I want.
What I would like to see is a structure where we have
# sitewide site_base_url # the default URL for all Mailman stuff at the site # used for all admin pages at the site # list-specific list_base_url # the URL for the list member stuff, archives, etc # defaults to site_base_url
It seems like that's not what you want, and that's OK with me. I can live without this and it would probably be a fair amout of work to get right.
OK. I agree that this is considerably beyond the scope of what I have in mind.
I suggest you start a separate thread if you want to pursue this.
If you do pursue it, one note:
Currently, all the the list-specific configvars are lower_case, but all the sitewide configvars (in mm_cfg.py) are UPPER_CASE.
Max.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFDivO8fFNSmcDyxYARAiU3AJ9CPnaZxhYjTdyiiI89bqv8NwTxHACfVWP6 TZ5EsJDFzNMHnJUB/2h2brc= =ZVv5 -----END PGP SIGNATURE-----
On Sat, 2005-11-26 at 13:16 -0800, JC Dill wrote:
As I understand it, your issue is what URL is "shown". My suggestion is that we make a change to the code that allows list administrators to change what URL is "shown" to list users. The new URL will also work for list administrators, but the default URL will *also* continue to work.
Of course, it's currently easy to do this at least for message footers.
-Barry
participants (6)
-
Barry Warsaw -
JC Dill -
Jeroen Ruigrok/asmodai -
John W. Baxter -
Max Bowsher -
Stephen J. Turnbull