Re: [Mailman-Developers] unsubscriptions requiring approval
[Thomas Wouters]
So instead I hacked the same behaviour into mailman -- include a seperate file. Not intended for general use, which is why I didn't post it here, and it has _no_ security, but it works ;)
Random thought: Would it be a good idea to add
<INPUT TYPE="file" NAME="posters_file" VALUE="filename" SIZE=50 MAXLENGTH=80>
type thingies for some of the text boxes which have to take rather large amounts of text, or would it just clutter things?
A colleague of mine found a bug, though (the hard way ;). MailList.MailList.DeleteMember() tries to call 'ApprovedDeleteMember()' instead of 'self.ApprovedDeleteMember()'.
Thanks for letting me know, I've fixed this in my local copy too, now.
regarding patch: you need to do 'patch -p0'.
Hmmmm, I already knew about -p0, and had tried that, but I get this (when standing in the toplevel Mailman directory, i.e. the one containing INSTALL etc.):
octarine$ patch -p0 --dry-run < ~/mailman-unsub-approval.diff can't find file to patch at input line 9 Perhaps you used the wrong -p or --strip option? The text leading up to this was:
|? templates/unsubauth.txt |Index: Mailman/Bouncer.py |=================================================================== |RCS file: /projects/cvsroot/mailman/Mailman/Bouncer.py,v |retrieving revision 1.37 |diff -u -r1.37 Bouncer.py |--- Bouncer.py 1999/12/16 17:11:04 1.37 |+++ Bouncer.py 2000/02/08 00:57:47
File to patch: ^C
etc. Thus my suspicion that patch isn't recognizing the Index: stuff, which I believe was put there by CVS. This is with GNU patch 2.5.
My immediate comment would be: How fast can we get this guy to sign the appropriate papers?
Me ? Are they the grep-able or the dead-tree kind of papers ?
Well, that depends on whether anyone has finished work on that wetware grep yet ;)
I'm talking about the stuff explained in <URL: http://www.gnu.org/prep/maintain_3.html#SEC3> -- I suspect that both you and a few others are (at least) bordering on "significant changes" to Mailman if most of the (very nice) patches you have submitted get checked in.
do I need to fax, or do you need to fax me something ? I have access to such things here at work, thankfully ;)
I don't have access to any GNU machines, so I won't be able to help you with this stuff. Barry is the official maintainer, so he should be able to sort this out (but please do give him some time to respond, in case he is heavily swamped at the moment).
For what it's worth: When I did this, I received the appropriate templates[1] by email, printed them out, filled them in by hand, and then snail-mailed them (the originals) back across the Atlantic.
[1] two, IIRC -- one (disclaim.future) to say my employer disclaims any ownership on the work I do on Mailman (signed by my boss), and one (assign.future) to say that I transfer copyright of my future work (either for all future, or for X years, IIRC) work on Mailman to the FSF (signed by me).
Harald
On Wed, Feb 09, 2000 at 07:13:03PM +0100, Harald Meland wrote:
So instead I hacked the same behaviour into mailman -- include a seperate file. Not intended for general use, which is why I didn't post it here, and it has _no_ security, but it works ;)
Random thought: Would it be a good idea to add
<INPUT TYPE="file" NAME="posters_file" VALUE="filename" SIZE=50 MAXLENGTH=80>
type thingies for some of the text boxes which have to take rather large amounts of text, or would it just clutter things?
I'm not sure. It might certainly be a good idea, even though in my case it wouldn't help (the problem was not the initial insertion, but rather keeping multiple lists in sync.) Clutterage is a problem in general, i think. Perhaps, if we want to give every textbox an upload field, a simple button next to the input field would suffice -- a button that would pop up a new window.
(It might be even worth it to take a look at a frames interface, possibly ?)
regarding patch: you need to do 'patch -p0'.
Hmmmm, I already knew about -p0, and had tried that, but I get this (when standing in the toplevel Mailman directory, i.e. the one containing INSTALL etc.):
octarine$ patch -p0 --dry-run < ~/mailman-unsub-approval.diff can't find file to patch at input line 9 Perhaps you used the wrong -p or --strip option? The text leading up to this was:
|? templates/unsubauth.txt |Index: Mailman/Bouncer.py
etc. Thus my suspicion that patch isn't recognizing the Index: stuff, which I believe was put there by CVS. This is with GNU patch 2.5.
Ok, found it. It's a bug in patch, or in patch's manpage:
If there is an Index: line in the leading garbage and if either the
old and new names are both absent or the POSIXLY_CORRECT environment
variable is set, patch takes the name in the Index: line.Apparently, patch doesn't work like this; even if both the old and the new name are absent, it refuses to regard the Index line. I found a patch to patch that added a '--use-index-line' option, but it doesn't seem to be added to patch 2.5 yet. As a workaround, you can set the 'POSIXLY_CORRECT' environment variable. It works, I just tested it with this very same boutique. Err, patch. The only problem with that is that this makes patch behave completely posix-compliant:
POSIXLY_CORRECT
If set, patch conforms more strictly to the POSIX standard: it takes
the first existing file from the list (old, new, index) when
intuiting file names from diff headers, it does not remove files
that are empty after patching, it does not ask whether to get files
from RCS or SCCS, it requires that all options precede the files in
the command line, and it does not backup files when there is a
mismatch.I'll try to keep this in mind when sending patches, noting added/removed files, and keeping an eye on situations where both 'file.py' and 'foo/bar/file.py' exist. ;)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote on 950200274: ...
(It might be even worth it to take a look at a frames interface, possibly ?)
Noooo! Please don't! Sorry, but I really, really hate frames for several reasons. * I want to be able to admin my site in lynx, since I often haven't booted X and want to administrate fast, * it's not possible to bookmark a frames page, you can't bookmark the combination of the frames, * in netscape, the images button doesn't work on frames, * the sidebar needs to use javascript, and javascript is hard to maintain, * it's often unclear which frame you selected, so scrolling is hard, * it's neither in the HTML 4.01, nor in the XHTML 1.0 dtd. There's a seperate DTD for it. I think we should conform the HTML to XHTML 1.0 anyway (comments?), * you can't have a quick look at the HTML source code (I use to do that very often).
I'd rather administrate my lists by email than using frames! Okay, maybe I'm exaggerating, but please, no frames!
regards, Gerrit.
-- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth
"GH" == Gerrit Holl <gerrit.holl@pobox.com> writes:
>> (It might be even worth it to take a look at a frames
>> interface, possibly ?)
| Noooo! Please don't!
| Sorry, but I really, really hate frames for several reasons.I concur 100%. To get largely the same effect without the headaches, see what we do on Python.Org.
-Barry
On Thu, Feb 10, 2000 at 09:14:52PM +0100, Gerrit Holl wrote:
Thomas Wouters wrote on 950200274:
(It might be even worth it to take a look at a frames interface, possibly ?)
Noooo! Please don't! Sorry, but I really, really hate frames for several reasons.
I hate the whole smegging world wide web for mostly the same sort of reasons. Nevertheless, the Common User might appreciate, might even greatly appreciate, a frame-style interface.
* I want to be able to admin my site in lynx, since I often haven't booted X and want to administrate fast,
This i consider a valid reason, and i concur. But the frame-style interface would, of bloody course, be _optional_.
* it's neither in the HTML 4.01, nor in the XHTML 1.0 dtd. There's a seperate DTD for it. I think we should conform the HTML to XHTML 1.0 anyway (comments?),
This might be a valid reason, but i dont follow the standards business regarding the WWW anymore. HTML 1.0 was ok, 1.1 had neat tricks but wasn't a real standard, and it just went downhill from there ;)
* it's not possible to bookmark a frames page, you can't bookmark the combination of the frames, * in netscape, the images button doesn't work on frames, * the sidebar needs to use javascript, and javascript is hard to maintain, * it's often unclear which frame you selected, so scrolling is hard, * you can't have a quick look at the HTML source code (I use to do that very often).
These are pure browser bugs. Fix the browser, get a different one, complain to the author, or avoid frame-based pages ;)
I'd rather administrate my lists by email than using frames! Okay, maybe I'm exaggerating, but please, no frames!
Hey, like I said, I dont like the web. I would honestly prefer an (optional, etc, yahdah yahdah) email-based administration system for everything but the configuration. (In fact, email-based responses to admin-requests are one thing still on my personal TODO-drool-list) And the configuration is preferably done via a text file, not a webpage ;) (i wont be adding that to my TODO list, though.) The reason I like mailman, and one of the reason we are changing from majordomo to mailman, is that we run the service for customers as well as for ourselves, and our customers would be in heaven with Mailman. (Will be in heaven. ;)
And I'm not talking about frames just for the layout, by the way. You can use frames to change part of the displayed page without reloading the whole thing, without erasing parts of a form you have filled in in another part of the page.
For instance (just a thing i just made up now) the posting-approve admin interface could be a list of requests, each with the same buttons as now, plus three extra buttons per posting: display headers, body, or both (and perhaps a 'limited headers' setting with the body to show only the headers most email programs show) -- and the requested parts would be shown in a seperate frame.
In order to do that without frames, and not lose form data, would be either to make the things pop up in another browser window (is that a standard HTML extention, by the way ? Mailman already uses it) which is, IMHO, worse than frames, or by making all those 'view' buttons be form submit buttons, and have the python script display the requested parts plus all form data.
I agree with everyone who says 'HTML is not intended for interactive use', I agree completely. The problem is, Mailman _is_ using it interactively ;)
Asbestos-ly y'rs,
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote on 950230906:
On Thu, Feb 10, 2000 at 09:14:52PM +0100, Gerrit Holl wrote:
Thomas Wouters wrote on 950200274:
(It might be even worth it to take a look at a frames interface, possibly ?)
Noooo! Please don't! Sorry, but I really, really hate frames for several reasons.
I hate the whole smegging world wide web for mostly the same sort of reasons. Nevertheless, the Common User might appreciate, might even greatly appreciate, a frame-style interface.
The Common User might appreciate flash also. www.nielsonline.nl is a perfect example of a page from hell.
* I want to be able to admin my site in lynx, since I often haven't booted X and want to administrate fast,This i consider a valid reason, and i concur. But the frame-style interface would, of bloody course, be _optional_.
Optional per list or optional per site? I hope the former, since I wouldn't want to administer a list through frames...
* it's neither in the HTML 4.01, nor in the XHTML 1.0 dtd. There's a seperate DTD for it. I think we should conform the HTML to XHTML 1.0 anyway (comments?),This might be a valid reason, but i dont follow the standards business regarding the WWW anymore. HTML 1.0 was ok, 1.1 had neat tricks but wasn't a real standard, and it just went downhill from there ;)
Put www.yahoo.com in validator.w3.org :)
* it's not possible to bookmark a frames page, you can't bookmark the combination of the frames, * in netscape, the images button doesn't work on frames, * the sidebar needs to use javascript, and javascript is hard to maintain, * it's often unclear which frame you selected, so scrolling is hard, * you can't have a quick look at the HTML source code (I use to do that very often).These are pure browser bugs. Fix the browser, get a different one, complain to the author, or avoid frame-based pages ;)
I _do_ have the source code, but my computer isn't fast enough to compile, let alone to debug... and I don't know enough C to understand Mozilla... Let's wait til the others fix it :)
I'd rather administrate my lists by email than using frames! Okay, maybe I'm exaggerating, but please, no frames!
Hey, like I said, I dont like the web. I would honestly prefer an (optional, etc, yahdah yahdah) email-based administration system for everything but the configuration. (In fact, email-based responses to admin-requests are one thing still on my personal TODO-drool-list) And the configuration is preferably done via a text file, not a webpage ;) (i wont be adding that to my TODO list, though.) The reason I like mailman, and one of the reason we are changing from majordomo to mailman, is that we run the service for customers as well as for ourselves, and our customers would be in heaven with Mailman. (Will be in heaven. ;)
It also just has more features.
And I'm not talking about frames just for the layout, by the way. You can use frames to change part of the displayed page without reloading the whole thing, without erasing parts of a form you have filled in in another part of the page.
Oh... Inline frames??
For instance (just a thing i just made up now) the posting-approve admin interface could be a list of requests, each with the same buttons as now, plus three extra buttons per posting: display headers, body, or both (and perhaps a 'limited headers' setting with the body to show only the headers most email programs show) -- and the requested parts would be shown in a seperate frame.
In order to do that without frames, and not lose form data, would be either to make the things pop up in another browser window (is that a standard HTML extention, by the way ? Mailman already uses it)
If it isn't javascript, it's HTML 3.2.
which is, IMHO, worse than frames, or by making all those 'view' buttons be form submit buttons, and have the python script display the requested parts plus all form data.
I agree with everyone who says 'HTML is not intended for interactive use', I agree completely. The problem is, Mailman _is_ using it interactively ;)
Hmm... what about using sockets for clients? We could write a socket server with commands like "SUBSCRIBE", "UNSUBSCRIBE", "SET" or "UNSET" for users or "PASSWORD", "SET", "UNSET" or "POSTERS". We could create a client for the people not wanting frames than...
regards, Gerrit.
-- Homepage: http://www.nl.linux.org/~gerrit -----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com Version: 3.12 GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE? Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y -----END GEEK CODE BLOCK----- moc.edockeeg.www//:ptth
participants (4)
-
Barry A. Warsaw -
Gerrit Holl -
Harald Meland -
Thomas Wouters