Re: [Mailman-Developers] GSOC - Dashboard for Admins/Owners/Moderators
On Fri, Mar 13, 2015 at 7:20 AM, Yash Mehrotra wrote: > 6. One more cool feature would be to color code different types of things > for visual ease. Eg. Subscription requests can be color A. Held messages > can be color B. and so on. This will not only help the administrator but > also would visually good to look at. Make sure that if you DO do this, that it is accessible for those with disabilities (visual impairments, cognitive disabilities, etc.) -- Bryan Carbonnell - carbo...@gmail.com Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] HTML Headers
On 8/2/06, Andrew Nielson <[EMAIL PROTECTED]> wrote: > Hi, > > I have written some code to allow Mailman to add a header.html file (if it > exists) to the top of each web page. > > Basically it checks a new option called WEB_HEADER_FILE which is set as > follows in mm_cfg.py: > WEB_HEADER_FILE = os.path.join(PREFIX, 'Mailman/header.html') > > I just wanted to know: > 1. Would you like me to submit this patch? > 2. Is $prefix/Mailman/header.html the correct place for a html file or > should we add a html directory or put it in the Cgi one? > 3. Would people like me to move the footer stuff out into another footer > file and do the same for it? Just to let you know, I created a patch for 2.1.7 (and 2.1.8 but I apparently haven't uploaded it to Sourceforge yet, oops) that does both sitewide headers and footer, not to mention makes the HTML code XHTML 1.1 compliant. It's patch #1415956 at Sourceforge. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Anyone have a pickle / mbox to spare?
On 7/23/06, emf <[EMAIL PROTECTED]> wrote: > It would sincerely help me if I could test my UI against actual mailman > pickles to make sure I can deal with vagaries of configuration, etc. > I'd be happy to provide a script to randomize all users passwords before > you sent it over, but would prefer that the email addresses stay valid. > > I don't need generated archive files; just list pickles and mbox files, > if you've been generating them. I've got a 213MB mbox, and associated pickle although it's a public list. Just let me know where to send it. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, emf <[EMAIL PROTECTED]> wrote: > Bryan Carbonnell wrote: > > > I have to agree with Brad on this. > > > > An option may be to give the site admin the ability to turn the JS > > on/off site wide with a mm_cfg.py variable. > > I'm a little reluctant to add another bit flip to mm_cfg when you'll be > able to delete the .js files or forbid access to the js directory in > apache and get what you want. > > Or you could avoid subjecting all your users to your preference and use > the no-JS variant that will always be available, or just turn JS off in > your browser. > > Can you help me understand your opposition to Javascript in a webpage > you serve? Something specific rather than in principle, if you would be > so kind; I often have a hard time applying abstract concepts to code I'm > in the process of writing. Ethan, For me it's nothing specific. It's more philosophical. I am a very minimalist when it comes to the 'net. Plain text e-mail and no scripting or embeded audio/video on web pages. I think the content of the page should stand on its own legs and not rely on "fancy tricks" to make it appealing. I've seen WAY to much bad scripting (and I'm not implying that the code you are going to write is going to be bad) to actually want to implement and Javascript. I also know that quite a few of my users are going to be up in arms if scripting gets added to the pages. I just want to have the option to NOT use in in MM. I realize that I can just delete the JS file or disallow it with Apache, but I feel that since this is a MM endeavour I should be able to control it within MM and not have to resort to things like you mention to disable the JS. I know this sounds negative, it's not. I'm really glad the UI is getting overhauled. I have done what I could with the XHTML/CSS patch that I wrote, but I know the UI could be a LOT better. Just my $0.02 -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, Laura Carlson <[EMAIL PROTECTED]> wrote: > > An option may be to give the site admin the ability to turn the JS > > on/off site wide with a mm_cfg.py variable. > > Default set to off? That'd be my preference. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, Brad Knowles <[EMAIL PROTECTED]> wrote: > Ethan wrote: > > > One example is keeping extraneous text hidden until it is selected; I > > imagine that someone using a screen reader/portable device would > > appreciate being able to read a "overview" page variant and then being > > able to expand as necessary. > > I would much prefer to do this without JavaScript. Because you can't > guarantee that you know the way that page would be rendered if you send > all sorts of "hidden" text that isn't shown until such time as someone > does something to make it appear, and you can't control what kinds of > mailicious cross-scripting attacks people may throw at you, it's best to > simply not send anything that the user cannot currently see. I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] Acessibility Testing Tools (was Re: Hi! I'll be your intern for the summer :))
> --On Thursday, June 22, 2006 4:15 AM +0200 emf wrote: > > > If you know of a way that I can > > actually test JAWS or another screen reader, I would be grateful for > > the pointer. If you are a Firefox user, there is an extension called Fangs [1] that emulates the output from JAWS. It doesn't speak it, rather it dipslays in text what JAWS would speak. [1] http://www.standards-schmandards.com/fangs -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] Sitewide headers/footers & XHTML Compliant Web UI
I have just uploaded a patch to Sourforge that allows you to set sitewide headers and footers for the Mailman 2.1.7 web UI, [ 1415956 ] Sitewide headers/footers & XHTML Compliant Web UI This patch was borne out of a request I received to make the Mailman UI fit the look of the web site. This patch allows you to set a site wide header and footer. This allows you to pretty much make the MM UI look like any other site. While I was at it I also made the web UI XHTML compliant. Once you patch your source and install it, all you need to do is edit the html files in the templates/en directory. Most of the pages will get the header and footers from the site-header.html and site-footer.html files, but some of the HTML files already contain theor own header/footer so you will need ot edit some of these files as well. Since this also adds XHTML compliance, this superceeds patch #116035 You can dowload it (and a separate version that works with the ht://dig integration patches) from: https://sourceforge.net/tracker/index.php?func=detail&aid=1415956&group_id=103&atid=300103 You can see in use at http://databaseadvisors.com/mailman/listinfo -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] XHTML Compliant Web UI - 2.1.6 Patch
I have just uploaded an updated patch that will make the web UI for MM 2.1.6 XHTML 1.0 strict compliant. This patch allows for some CSS formatting as well. I have tried to make all the pages compliant, but I may have missed some combinations of pages and options, so if you find some that aren't compliant, please let me know which page isn't compliant and under which circumstances it's not. It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it,since this is my first attempt at creating a patch. -- Bryan Carbonnell - [EMAIL PROTECTED] The man who claims to be the boss in his own home will lie about other things as well. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: [Mailman-Developers] XHTML Compliant Web UI - 2.1.6 Patch
On 24 Apr 2005 at 8:31, Bryan Carbonnell wrote: > I have just uploaded a patch that will make the web UI for MM 2.1.6rc1 > XHTML 1 strict compliant. This patch allows for some CSS formatting as > well. > > I have tried to make all the pages compliant, but I may have missed > some combinations of pages and options, so if you find some that > aren't compliant, please let me know which page isn't compliant and > under which circumstances it's not. > > It it patch 1160353 in the Sourceforge Mailman patch repository. > http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group > _id=103&atid=300103 > > If anyone has any feedback on it, I'd love to hear it,since this is my > first attempt at something like this. Now updated for MM 2.1.6rc3 It also makes the archives XHTML1.0 Strict compliant. -- Bryan Carbonnell - [EMAIL PROTECTED] Never let a computer see you hurry. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
[Mailman-Developers] XHTML Compliant Web UI - 2.1.6 Patch
I have just uploaded a patch that will make the web UI for MM 2.1.6rc1 XHTML 1 strict compliant. This patch allows for some CSS formatting as well. I have tried to make all the pages compliant, but I may have missed some combinations of pages and options, so if you find some that aren't compliant, please let me know which page isn't compliant and under which circumstances it's not. It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it,since this is my first attempt at something like this. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "What a great ride!" ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&fileúq01.027.htp
[Mailman-Developers] XHTML Compliant Web UI 2.1.6b4 Patch
I have just uploaded a patch that will make the web UI for MM 2.1.6b4 XHTML 1 strict compliant. Well, the start of a patch. Currently only the listinfo pages are xhtml 1 compliant and some minor CSS formating ability. As time goes by, I'm going to update the patch to include more of the UI pages. Since this is my first atempt at something like this I thought I'd post it incrementally in case anyone finds something terrible wrong with what I'm doing :) It it patch 1160353 in the Sourceforge Mailman patch repository. http://sourceforge.net/tracker/index.php?func=detail&aid=1160353&group _id=103&atid=300103 If anyone has any feedback on it, I'd love to hear it. -- Bryan Carbonnell - [EMAIL PROTECTED] "When they put 'unknown' at the end of a quote, that means they probably don't know how to spell 'anonymous'." ~Author Unknown ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
Re: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem
On 5 Apr 2004 at 0:08, Brad Knowles wrote: > At 12:05 PM -0400 2004/04/04, Bryan Carbonnell wrote: > > And wouldn't it be easier for Barry to implement? > > Maybe. However, we have to consider more than just the > implementation cost -- there is also the support cost to consider. If > it costs 10x or 100x as much to support the regex feature because it's > too flexible and too confusing to too many people, then it's not worth > the effort. Fair enough. I never considered that. > > Do you see my point? If there are an absolutely fixed number of > > types of headers that could across, then I could see that going > > your way would work better, but since I can add any header to an > > outgoing mail that I want, with my e-mail client (like I did with > > this e-mail), then should the MM admins be given the opportunity to > > strip them with a RegEx? > > Okay, so a Keep-These-Headers option being restricted to just the > following: > > From: > Subject: > To: > Cc: > Date: > > Is not capable of stripping all possible headers that could > potentially be generated? Sorry, I don't buy it. I think that we are talking about 2 different things. Or at least I misunderstood what you were talking about. I was thinking from your description, From: would be selectable to keep or strip Subject: would be selectable to keep or strip To: would be selectable to keep or strip Cc: would be selectable to keep or strip Date: would be selectable to keep or strip etc. as SEPARATE individual choices to. Not as a group. Now that I understand your thinking, I think that this may be a very viable alternative. Maybe even less of a support issue. Maybe both what you are thinking and the RegEx would work well together. The keep/strip for those that want simple and RegEx for those that want the extra control. > I'm just not sure that it would be worth the effort to get this > relatively small additional functionality, given the potential > additional support cost that would result. Neither do I. Unfortunately I'm just learning Python, so I don't know who hard or how easy any of these suggestions are. > But only Barry could really answer this question. Absolutely. > No, "safety" would be to strip everything that is not known to be > safe, such as the minimal list of headers shown above. I can see that. I'm, personally, not convinced, but then I haven't been a mail admin as long as you have been. > > I'm not trying to argue, just trying to get thing straighened out > > in my mind. > > This is a point of deep discussion amongst the most experienced > people in the field. You are not expected to fully understand all the > nuances involved. I'm not worried about all the nuances involved. I was just trying to get what we, you and I were discussing, sorted out. And now I realize that we weren't quite talking about the same things. I was talking about controling individual headers, separately, and you are talking about controlling the "basic" headers as a group. Whose idea is better? Not my call, I'm glad to say. I guess we just need to wait and see what Barry has in store for us :) -- Bryan Carbonnell - [EMAIL PROTECTED] My reality check bounced. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: (Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem
On 3 Apr 2004 at 21:51, Brad Knowles wrote: > At 9:43 AM -0500 2004/04/03, Bryan Carbonnell wrote: > > > Why not just have a list of UserDefined RegEx's of headers to > > strip? > > Because most people don't properly understand regular > expressions. Since you can do the same thing in a different way and > have Mailman build the proper regular expressions based on user input, > it seems pretty obvious what the correct solution is. Yes, it may be true that RegExs are foreign to most people (myself included to a certain degree), but wouldn't it make MM more flexible? And wouldn't it be easier for Barry to implement? > If you have a "keep-these-headers/strip-these-headers" option, > then there shouldn't be any headers that either can't be stripped or > kept, depending on your particular type of choice. Well, would the X-Habeas headers be added as an option to strip, or the next X-Habeas type header that comes along? Or... Do you see my point? If there are an absolutely fixed number of types of headers that could across, then I could see that going your way would work better, but since I can add any header to an outgoing mail that I want, with my e-mail client (like I did with this e-mail), then should the MM admins be given the opportunity to strip them with a RegEx? > > If you go with keep these/strip these, I'd vote for keeping > > everything and let the admin HAVE to make the change for > > themselves. > > IMO, we should default to safety. Wouldn't safety be to not mess with the mail while passing through MM? > > Don't the RFCs say not to mess with the headers if possible? Or > > something like that? > > The RFCs regarding mail are intended primarily for MTAs and MUAs, not > mailing list management systems. Moreover, they make it clear that > you can add headers, but you can't change them, and under certain > circumstances you can remove them. Since the MLM is a gateway system > of sorts, there is more freedom with regards to what the authors are > allowed to do. I understand that the RFC are for MTA and MUAs, but shouldn't MM follow them as well? As well as we can anyway? I'm not trying to argue, just trying to get thing straighened out in my mind. -- Bryan Carbonnell - [EMAIL PROTECTED] It was difficult to code. So it damn well better be difficult to use. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
(Fwd) Re: [Mailman-Users] Re: [Mailman-Developers] How to rem
OOPS, Should have gone to the list and not Brad directly. Sorry Brad. --- Forwarded message follows --- From: Bryan Carbonnell <[EMAIL PROTECTED]> On 3 Apr 2004 at 11:46, Brad Knowles wrote: > At 2:24 AM -0500 2004/04/03, Terri Oda wrote: > > > At least making this an option would make quite a few people > > happy, I imagine, although a more configurable > > strip-these-headers/ keep-these-headers might be better. > > Okay, add a "strip-these-headers/keep-these-headers" option, but by > default select "keep-these-headers", and pre-fill in the minimum. Why not just have a list of UserDefined RegEx's of headers to strip? Kind of like the Spam Filtering Rules in Mailman. That way BArry won't get "Well why can you strip header x, but not header y?" If you go with keep these/strip these, I'd vote for keeping everything and let the admin HAVE to make the change for themselves. Don't the RFCs say not to mess with the headers if possible? Or something like that? -- Bryan Carbonnell - [EMAIL PROTECTED] Out of my mind. Back in five minutes. -- Bryan Carbonnell - [EMAIL PROTECTED] The man who claims to be the boss in his own home will lie about other things as well. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Re: [Mailman-Developers] SQL in MM3 issues
On 5 Feb 2004 at 23:08, Kevin McCann wrote: > I want to do this same kind of thing with Mailman 3. And so I want, at > the very least, to have those three aforementioned tables of data: > > lists > members > messages > > Can anyone think of any reason why we would not want to have these > three tables in a SQL-enabled Mailman 3. What other tables might you > want to see? Or fields that might not be found in the above three > tables? May I suggest that you be creative, think ahead, and don't > restrict yourself by notions of what an MLM is in the here-and-now. If > we can first agree on tables, maybe we can move forward and work on > the core field sets for each one. And this will in turn give us > something to chew on at the sprint. Barry does this approach make > sense? Funny you should mention this Kevin. :) I am a new Mailman admin and I was thinking about hacking something together to put my lists archives in a DB (MySQL more than likely). My first question to you is how normalized do you want to get? The archives, my gut is telling me that the message should be split over several tables. I'm just not sure how at the moment. I haven't really started planning anything, just rolling ideas around to myself., reading RFCs, Python Tutorials and the like. -- Bryan Carbonnell - [EMAIL PROTECTED] I've learned That one should keep his words both soft and tender, because tomorrow he may have to eat them. ___ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
