[Mailman-Developers] Query regarding ambiguous behavior of REST API due to case-sensitivity of email addresses
Hello people, I want to report an issue in Mailman core that drives a bug in the Mailman REST API. I was testing Postorius's *mass subscribe* feature. When an email address associated with an already existing member is used for subscription, the REST API returns a 409 code saying `Member already subscribed` which is good. But, when we use the same email with some letters in different cases, the REST API returns `500' i.e server error occurred which should also return `409`. The Mailman core raises the error *User should have had linked address*, i.e a 500 error code occurs. The screenshots of the above issue:- Case-insensitive email usage: http://postimg.org/image/qgl2piepj/ http://postimg.org/image/s5u5xkuev/ Case-sensitive email usage: http://postimg.org/image/okyaecpvb/ As far as I can understand from the mailman docs http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/addresses.html#case-preserved-addresses <http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/addresses.html#case-preserved-addresses> mailman keeps all email addresses in small cases internally. I tested this again using CURL and REST clients and found that the REST API is failing to return `409' in the latter case. That is, something is wrong with mailman core. Later, I dug in the Mailman core and found out the following things: 1. In /src/mailman/app/membership.py `add_member` function uses *user = user_manager.get_user(email) *to check if the user corresponding the email address already exists or not. Here email is in *preserved case *and it returns the user associated with this email address. Here it does not matter if the email is in *lower case *itself. 2. Later on, in the same function the following code checks if the email is matched: *for address in user.addresses:* *if address.email == email:* * break* Here *email* is in *preserved case* while *address.email *returns a lower case version of email and an *unmatch* occurs. ( s...@gmail.com and s...@gmail.com do not matches ofcourse ) But, the thing confuses me is the *assertion error* in case of an unmatch, *User should have had linked address.* What does it signify, as you are using the same email to get the user object and later on matching should be done by bringing the *passed *email in the *lower case *too, i.e ( s...@gmail.com should be brought down to s...@gmail.com ) *for address in user.addresses:* *if address.email == email.lower():* * break* It also makes the REST API return `409` in both cases and it should return it too. I have filed a bug ( Bug #1425359 ) for this. I may be interpreting things wrong. In case if it is an architectural aspect related to Mailman core, please explain. In case it is a bug in real, I would love to submit a patch for it. Thanks, Ankush Sharma github.com/black-perl ___ 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] Query regarding ambiguous behavior of REST API due to case-sensitivity of email addresses
Hello people, I guess you guys might be busy. I am unable to figure out this issue yet, can anyone help ? Thanks, Ankush Sharma github.com/black-perl On Sun, Mar 1, 2015 at 2:43 PM, Ankush Sharma < ankush.sharma.ec...@iitbhu.ac.in> wrote: > Hello people, > > I want to report an issue in Mailman core that drives a bug in the Mailman > REST API. I was testing Postorius's *mass subscribe* feature. When an > email address associated with an already existing member is used for > subscription, the REST API returns a 409 code saying `Member already > subscribed` which is good. But, when we use the same email with some > letters in different cases, the REST API returns `500' i.e server error > occurred which should also return `409`. The Mailman core raises the error > *User > should have had linked address*, i.e a 500 error code occurs. > > The screenshots of the above issue:- > > Case-insensitive email usage: > http://postimg.org/image/qgl2piepj/ > http://postimg.org/image/s5u5xkuev/ > Case-sensitive email usage: > http://postimg.org/image/okyaecpvb/ > > As far as I can understand from the mailman docs > > http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/addresses.html#case-preserved-addresses > <http://gnu-mailman.readthedocs.org/en/latest/src/mailman/model/docs/addresses.html#case-preserved-addresses> > mailman > keeps all email addresses in small cases internally. > > I tested this again using CURL and REST clients and found that the REST > API is failing to return `409' in the latter case. That is, something is > wrong with mailman core. Later, I dug in the Mailman core and found out the > following things: > > 1. In /src/mailman/app/membership.py `add_member` function uses *user = > user_manager.get_user(email) *to check if the user corresponding the > email address already exists or not. Here email is in *preserved case *and > it returns the user associated with this email address. Here it does not > matter if the email is in *lower case *itself. > > 2. Later on, in the same function the following code checks if the email > is matched: > > *for address in user.addresses:* > *if address.email == email:* > * break* > > Here *email* is in *preserved case* while *address.email *returns a lower > case version of email and an *unmatch* occurs. ( s...@gmail.com and > s...@gmail.com do not matches ofcourse ) > But, the thing confuses me is the *assertion error* in case of an > unmatch, *User should have had linked address.* What does it signify, as > you are using the same email to get the user object and later on matching > should be done by bringing the *passed *email in the *lower case *too, > i.e ( s...@gmail.com should be brought down to s...@gmail.com ) > > *for address in user.addresses:* > *if address.email == email.lower():* > * break* > > It also makes the REST API return `409` in both cases and it should return > it too. I have filed a bug ( Bug #1425359 ) for this. > > I may be interpreting things wrong. In case if it is an architectural > aspect related to Mailman core, please explain. In case it is a bug in > real, I would love to submit a patch for it. > > Thanks, > Ankush Sharma > github.com/black-perl > > ___ 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] GSoC 2015: brainstorming ideas suitable for beginners?
Thanks. Barry for the detailed explanation. I will surely have a look on that part as you mentioned. Thanks, Ankush Sharma github.com/black-perl On Fri, Feb 27, 2015 at 9:47 PM, Barry Warsaw wrote: > On Feb 27, 2015, at 01:02 PM, Ankush Sharma B.Tech. Electronics Engg, > IIT(BHU), Varanasi (U.P.), INDIA wrote: > > >A personalized mailing list will allow mailman users to send personalized > >emails to all the list members from a common email template. > > Almost all the pieces are already there to support mail merging, at least > as > a plugin. There's quite a bit of functionality in place to allow for > pluggable MTA delivery methods. Right now, there's only one. Search > src/mailman/config/schema.cfg for the [mta]outgoing variable. > > We also already do a bit of mixin class composition to implement various > aspects of the existing personalized delivery machinery. The proper class > is > chosen (based on the default [mta]outgoing value) from the value of > mlist.personalize. > > To support mail merge, we'd need a little more flexibility in composing > these > basic bits. You'd like for individual mailing lists to be able to choose a > custom delivery mechanism from a set of site-defined choices, for example. > > Then a plugin could define a new delivery class which does the database > lookups and the mail merge into the template at the point where the VERP'd > message is handed off to the upstream MTA. You'd register this new > delivery > class with the system and them mailing lists could opt into it. > > Cheers, > -Barry > ___ 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] GSoC 2015: brainstorming ideas suitable for beginners?
Yes, Stephen also mentioned about its separate working and not being able to get integrated with mailman. But, I guess it would be cool if this metrics project can be integrated with postorius or hyperkitty as you mentioned. Thanks, Ankush Sharma github.com/black-perl On Sat, Feb 28, 2015 at 1:50 AM, Terri Oda wrote: > On 2015-02-27 1:06 AM, Stephen J. Turnbull wrote: > >> Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), Varanasi (U.P.), INDIA >> writes: >> >> > I was wondering if there is a sort of tool that generates summaries >> > for mailing list activity and charts like number of users, number >> > of active users, etc. Would something like this be a good idea or >> > is it already done? >> >> There are such tools but they're not integrated into the Mailman 2 web >> interface, and I think they're not in Postorius or Hyperkitty yet, >> either. They're frequently requested and I think Postorius provides >> some infrastructure for such things. >> > > We actually have a whole summer of code project that was on metrics from a > few years ago. I believe it worked as separate add-in for Mailman, but > perhaps we should take a look at integrating it better into hyperkitty (or > maybe postorius?) if people are unaware that it exists. I'd like to see > that code integrated part of any new effort in this area. > > Terri > > > ___ 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
[Mailman-Developers] Bug in postorius, client not defined after shell invokation
Hello everyone, I started going through the postorius docs and found an issue while following this http://postorius.readthedocs.org/en/latest/development.html#accessing-the-mailman-api . The *client *is not defined after the shell invokation by doing *python manage.py mmclient*. The issue is because the *client *is not present in the *globals() *dictionary when it was used to invoke the interpreter. I have filed a bug regarding this issue: https://bugs.launchpad.net/postorius/+bug/1428169 . The issue can be solved by putting *client *in the scope i.e add *client *to the *globals() *dictionary. I have discussed the bug with people on irc and they also faced the same behavior. I have patched it and will send a pull request shortly. Any views regarding this will be helpful. Thanks, Ankush Sharma github.com/black-perl ___ 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] Bug in postorius, client not defined after shell invokation
Sure, Florian. Thanks for giving time to answer my question. On Wed, Mar 4, 2015 at 10:37 PM, Florian Fuchs wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > Am 04.03.2015 um 16:25 schrieb Ankush Sharma: > > Hello everyone, > > > > I started going through the postorius docs and found an issue > > while following this > > > http://postorius.readthedocs.org/en/latest/development.html#accessing-the-mailman-api > > > > > . > > > > The *client *is not defined after the shell invokation by doing > > *python manage.py mmclient*. The issue is because the *client *is > > not present in the *globals() *dictionary when it was used to > > invoke the interpreter. I have filed a bug regarding this issue: > > https://bugs.launchpad.net/postorius/+bug/1428169 . The issue can > > be solved by putting *client *in the scope i.e add *client *to the > > *globals() *dictionary. I have discussed the bug with people on irc > > and they also faced the same behavior. I have patched it and will > > send a pull request shortly. > > > > Any views regarding this will be helpful. > > Thanks for pointing that out. I have to admit I totally forgot about > this particular manage.py command, since it's more or less just a > shortcut to create a mailman.client instance using the given Django > settings. So it's nice to see someone actually read the documentation > in full and gave it a test! :-) > > Let me have a look at the merge proposal. I'll add further comments > there if necessary... > > Thanks! > > Florian > > > > > > Thanks, > > > > Ankush Sharma github.com/black-perl > > ___ 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/f%40florianfuchs.com > > > > Security Policy: http://wiki.list.org/x/QIA9 > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJU9zu0AAoJEEceGbPdavl72HUH/RqFw0c2cvB7NobDnGBbBahY > eoXX9flHeEczcxmUA7QdY8a0igyy7Y15l1oZHZATDbZIumQ7UoLqwvn6IyWmazUB > lUyFqT4mWQBWukjcyu4RODnlk5CDQxX0kTHSqY4ltNX+AF+aMht5Jv2ruaNI3zZS > 6/rRUzY82nGDZThow4RnfZMaaAftyEgAnntYuJt2/UPeUTRRsHF6k0oFsORnEZk0 > /sW4c9F4OfdmafjndRBcyAWIgxqhMJnEQcXqkm0L1oOjSI35APa/BmjdXzJXEQyt > suXYZDHCcTHn3ssRiOpvdTK0ZzJAwVZaDxkbiqt2MKbwWvk6aMx0Cj5aLo9e/G8= > =A42d > -END PGP SIGNATURE- > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > ___ 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
[Mailman-Developers] Anatomy of list ids does not keep with that of urls causes some REST end points to return 404 always
Hello everyone, I want to discuss a serious issue regarding mailman architecture in context with bug #1429366 <https://bugs.launchpad.net/mailman/+bug/1429366>. The *hash(#) *is a valid character as far as the local part of the email addresses is concerned as per the email RFCs. So, as the mailing list addresses are email addresses too, we can use # in the list names too. And, in context with mailman it works well. We can create a list with list_id *sam#hashed.host.org <http://hashed.host.org>* for the address *sam#has...@host.org *. This works fine. But it makes the *list_id *to contain the hash character and therefore the REST endpoint for retrieving list wise info becomes invalid, i.e : */lists/sam#hashed.host.org <http://hashed.host.org>* Because in an URL the stuff after # is treated as *document starting point* i.e an id identifier or something of a dom element. This is not a valid PATH for the server. Therefore the *falcon wsgi request object* does not contain information of that and the *req.path* simply returns *sam* as the *list_id* ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/view/head:/src/mailman/rest/wsgiapp.py#L65 ) giving a 404 because there is no any list with list id *sam*. The mailman client works fine, it sends a GET to *lists/sam#hashed.host.org <http://hashed.host.org>. * This causes the REST end points which needs *list_id* to return 404 or in worse we can have a list_id clash between ids* sam#X* and *sam*. Further more if the list_id starts with a # character then the server finds list_id to be *empty string* and therefore we get a KEY ERROR because *fqdn_listname *is not set too. The bug highly effects postorius too. The lists index template at */postorius/lists/ *cannot be rendered as it uses the former REST endpoint and again a 404 is given. And, until we delete this list from the database, we can't do anything except of getting a 404 and KEY ERROR each time. As far as security is concerned, if an another user created a public list using a hash character, then public list indexing would also fail. *Possible fixes:* 1. Put a constraint over the use of this kind of characters, but it's like falling back. 2. Do not derive list ids directly from the list addresses, use some kind of hashing or encoding technique to generate list_ids. Need to change a lot in architecture; :( . 3. Use obscure techniques to retain the hash part as discussed here http://stackoverflow.com/questions/317760/how-to-get-url-hash-from-server-side . I think this is quite a serious issue in mailman architecture; i.e obtaining list_ids directly from list addresses. I have been trying to fix this bug using some obscure techniques. But as it is related to mailman architecture, I thought it should be worthy to discuss on the mailing list first. Thanks, Ankush Sharma github.com/black-perl ___ 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
[Mailman-Developers] Fwd: Anatomy of list ids does not keep with that of urls causes some REST end points to return 404 always
-- Forwarded message -- From: Ankush Sharma Date: Sun, Mar 8, 2015 at 3:49 PM Subject: Re: [Mailman-Developers] Anatomy of list ids does not keep with that of urls causes some REST end points to return 404 always To: Richard Damon Well, thanks Richard for replying. On Sat, Mar 7, 2015 at 8:04 PM, Richard Damon wrote: > On 3/7/15 5:27 AM, Ankush Sharma wrote: > >> Hello everyone, >> >> I want to discuss a serious issue regarding mailman architecture in >> context >> with bug #1429366 <https://bugs.launchpad.net/mailman/+bug/1429366>. >> The *hash(#) >> *is a valid character as far as the local part of the email addresses is >> concerned as per the email RFCs. So, as the mailing list addresses are >> email addresses too, we can use # in the list names too. And, in context >> with mailman it works well. We can create a list with list_id >> *sam#hashed.host.org >> <http://hashed.host.org>* for the address *sam#has...@host.org >> *. This works fine. But it makes the *list_id *to >> contain >> the hash character and therefore the REST endpoint for retrieving list >> wise >> info becomes invalid, i.e : >> >> */lists/sam#hashed.host.org <http://hashed.host.org>* >> >> Because in an URL the stuff after # is treated as *document starting >> point* >> i.e an id identifier or something of a dom element. This is not a valid >> PATH for the server. Therefore the *falcon wsgi request object* does not >> contain information of that and the *req.path* simply returns *sam* as the >> *list_id* ( http://bazaar.launchpad.net/~mailman-coders/mailman/3.0/ >> view/head:/src/mailman/rest/wsgiapp.py#L65 >> ) giving a 404 because there is no any list with list id *sam*. >> The mailman client works fine, it sends a GET to >> *lists/sam#hashed.host.org >> <http://hashed.host.org>. * >> >> This causes the REST end points which needs *list_id* to return 404 or in >> worse we can have a list_id clash between ids* sam#X* and *sam*. >> Further more if the list_id starts with a # character then the server >> finds >> list_id to be *empty string* and therefore we get a KEY ERROR because >> *fqdn_listname >> *is not set too. The bug highly effects postorius too. The lists index >> template at */postorius/lists/ *cannot be rendered as it uses the former >> REST endpoint and again a 404 is given. And, until we delete this list >> from >> the database, we can't do anything except of getting a 404 and KEY ERROR >> each time. >> As far as security is concerned, if an another user created a public list >> using a hash character, then public list indexing would also fail. >> >> *Possible fixes:* >> 1. Put a constraint over the use of this kind of characters, but it's like >> falling back. >> 2. Do not derive list ids directly from the list addresses, use some kind >> of hashing or encoding technique to generate list_ids. Need to change a >> lot >> in architecture; :( . >> 3. Use obscure techniques to retain the hash part as discussed here >> http://stackoverflow.com/questions/317760/how-to-get- >> url-hash-from-server-side >> . >> >> I think this is quite a serious issue in mailman architecture; i.e >> obtaining list_ids directly from list addresses. I have been trying to fix >> this bug using some obscure techniques. But as it is related to mailman >> architecture, I thought it should be worthy to discuss on the mailing list >> first. >> >> Thanks, >> Ankush Sharma >> github.com/black-perl >> >> The simple, and standard complient, solution would seem to be to define > that special characters get URL encoded as needed (and decoded on the > receiving end. I had a feeling of using URL encoding universally for all the URL building routines but the issue I faced is of identifying the set of URL building routines that actually require to encode URLs to prevent chaos. That's why I didn't listed in on the possible fixes list. Because in that case it would be difficult to identify these guys with full confidence. > It should be standard procedure that ANY routine building a URL would use > URL encoding on the pieces unless it is positive that it is not needed. But now are things more clear. I will try to keep a positive approach towards all these URL building routines keeping them in the suspected list till I am not sure about one. (URL encoding is replacing the problem chars with %nn where nn is the hex value of the character, this now makes % a problem char so it is sent as part of the URL as %25) > > -- > Richard Damon > >
[Mailman-Developers] Fast development environment setup for newbies using mmdev_bootstrap
Hello everyone, The newbies starting to contribute to mailman sometimes face difficulty in setting up the dev environment for Mailman. I created a repo <https://github.com/black-perl/mmdev_bootstrap> to automate setting up mailman for usage and dev environment interactively. It automatically creates and manages the virtual environments for you. It saves a lot of time consumed in setting up dev environment for the new branch created each time you need to work on a new feature and wants to fix a bug. You just need to do changes and push your work. Have a read out more on this: https://github.com/black-perl/mmdev_bootstrap#description <https://github.com/black-perl/mmdev_bootstrap#description> to know more about it. Hope it would prove helpful to newbies and to oldies too :) Thanks. Ankush Sharma github.com/black-perl ___ 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
[Mailman-Developers] [Bug + Query] Does delete_list ever used in the mailman REST client ?
Hey everyone, I want to know whether *delete_list *method in the Mailman REST client at http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L254 ever used ? As per deleting the list is considered the List object returned from the models API which calls the REST API on the back has delete method of its own at http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L549. Therefore, we do not require this *delete_list *at all and this is simply unused code. In case it is unused, I would like to file a bug and fix it. And the possible *fixes *would be: 1. Use this *delete_list* method of the Client <http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L121> class and call the other by doing something like `_List(self._connection,fqdn_listname, None).delete()` in it and that would require changing MailmanRestManager class in postorius models also. 2. Remove the unused code. In case it is used, I want to know the parts of the code using it. Thanks, Ankush Sharma github.com/black-perl ___ 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] [Bug + Query] Does delete_list ever used in the mailman REST client ?
Well discussed this on the mailing list with Abhilash Raj and have no more queries regarding this. On Thu, Mar 12, 2015 at 11:43 AM, Ankush Sharma < ankush.sharma.ec...@iitbhu.ac.in> wrote: > Hey everyone, > > I want to know whether *delete_list *method in the Mailman REST client at > http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L254 > ever > used ? > As per deleting the list is considered the List object returned from the > models API which calls the REST API on the back has delete method of its > own at > http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L549. > Therefore, we do not require this *delete_list *at all and this is simply > unused code. > > In case it is unused, I would like to file a bug and fix it. And the > possible *fixes *would be: > > 1. Use this *delete_list* method of the Client > <http://bazaar.launchpad.net/~mailman-coders/mailman.client/trunk/view/head:/src/mailmanclient/_client.py#L121> > class > and call the other by doing something like > `_List(self._connection,fqdn_listname, None).delete()` in it and that would > require changing MailmanRestManager class in postorius models also. > 2. Remove the unused code. > > In case it is used, I want to know the parts of the code using it. > > Thanks, > Ankush Sharma > github.com/black-perl > ___ 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] Javascript Client for Mailman
Hey, On Wed, Mar 25, 2015 at 12:21 PM, Ana Badescu wrote: > Hello, > > While writing my proposal I came across 2 important issues related to the > Javascript Client for the Mailman project that have yet to be raised: > > 1. What I initially had in mind, was to build a Mailman client in > Javascript that provides the same API and functionality that the current > one in Python does. The Python client API can be fully mimicked using a > number of design patterns even though Javascript doesn't offer properties > capability for example. However, node.js modules tend to take advantage of > Javascript's asynchronous nature and have adopted sort of a standard > practice to achieve it: it's called error-first callbacks, and most if not > all APIs enforce it. You can read about it here > http://thenodeway.io/posts/understanding-error-first-callbacks/ > and here > https://docs.nodejitsu.com/articles/errors/what-are-the-error-conventions > > This boils down if we want to provide a client API that adopts the node.js > conventions and works the same way most modules do or do we want to offer > something almost similar to the current Python client API. There's a lot > more to be said on this matter (for eg: callbacks being the reason why > "callback-hell" exists) but I'd like to get your input first. > Since, you will be working with Node,js ; you cannot get away from callbacks. This JavaScript port is not a simple port :) 2. I'd also like to make part of the project, a node.js application that > uses the Mailman Javascript client and offers all the functionality > Postorious does. Is that a good idea? This doesn't make the scope of the > project too large or unattainable. I cannot comment on this as I am a student just like you. > > > Thank you, > Ana > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > Thanks, Ankush Sharma ___ 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] Javascript Client for Mailman
Hello, Well, thanks Stephen for adding and clarifying things. Actually, I have also submitted a proposal on the same and have been doing a lot of research work on this for the past few weeks. So, I added up on the callback stuff. Actually, I felt that it would be lots of work if someone want to have a entire postorius like thing for node as part of the GSoC project. So, for the time focusing on the port will be the best thing. So, I agree with Florian here. As far as the reasons you have suggested for not commenting, I will go with (c) option and the reason being I was lacking on the term "Student" but now things are more clear :-) On Thu, Mar 26, 2015 at 7:21 AM, Stephen J. Turnbull wrote: > Ankush Sharma writes: > > > I cannot comment on this as I am a student just like you. > > First, thank you very much for commenting in the first place! > Students helping each other is one of the most exciting aspects of > GSoC. > > But I think you misunderstand "student" in the context of GSoC. It's > an accounting term. "Students" get paid, mentors get tired, er, > "T-shirts", that's it! Mentors get T-shirts! > > Other than that, we're all Mailman developers. You can and should > comment on anything where you have an opinion. Some developers have > more experience and skills, some have a natural talent for programming > or design or building UIs and others don't have any of the above but > need a feature or bugfix, and nobody else seems to want to do it. The > good reasons for not giving your opinion are (a) you don't have one (a > common reason for those with less experience in the project), (b) > somebody's already expressed pretty much the same opinion (in cases > where values differ, you might even add a "+1" here), and (c) you're > waiting for somebody else to comment first for some reason. > > That's a little bit oversimplified, but it's important. I don't know > if it's made explicit in the GSoC handbooks, but if you get a chance > to talk to Carol or Cat you'll hear that one of the things they enjoy > most is hearing about students who become mentors. That's a core > value in GSoC: the kind of professional growth that turns students > into teachers. And it happens in just one or two years for many > students. New members normally don't get that experience in a company > (unless you're running it :-). > > They also hear stories about how that assumption of responsibility > carries over to the new mentor's school and employment opportunities. > > ___ 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
[Mailman-Developers] Approach for making Editable fields in user profile
Hello everyone, I need to discuss in context with the feature request https://bugs.launchpad.net/postorius/+bug/1432383. The point is to make the fields like irc handle, first-name, last-name etc. editable in the user profile. User registration is currently done using *django-browserid *with the default *User Model. *There are no schema rules for these *extra *fields in the *auth_user *table of the underlying Postorius database due to the use of the default *User Model*. I am thinking of using a CustomBackend class overriding the BrowserIdBackend class for adding customisation *[1]*. Also, I think it would be required to have a *new *User model for these extra fields which can be used by django-browserid for the initial user registration. Initially, these *extra *fields can be set to *empty*. Later on, with the help of an update view users can be asked to update their profiles when they login. This would require the use of database migrations. Other option is to use to create an extra table for these fields and for it the default *User model *would be suffice. In this case, an extra form would do the job. I want to ask whether my approach is correct ? Or it would be more meaningful to take input for these fields during the first time when the user registers by using Persona ? ( I guess it would require some ugly tweaks ) Waiting for your opinion on it ! Thanks, Ankush Sharma IIT-BHU, Varanasi India *github.com/black-perl <http://github.com/black-perl>* [1] : http://django-browserid.readthedocs.org/en/latest/user/customization.html#automatic-user-creation ___ 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
[Mailman-Developers] [ Query ] Some bugs in postorius that needs to be addressed
Hello everyone, I have found a good some bugs in postorius. Needs your review before fixing them. *1.* The *list_moderator* is not able to access the list of held messages as visiting at /postorius/lists/*/held_messages *gives a *403 *i.e *Forbidden* Status code because it is simply not allowed to access it. I have discussed the cause and fix for this issue here https://bugs.launchpad.net/postorius/+bug/1443433 . I am assuming the *list_owner* to be a *list_moderator* in my fix as indicated by http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/auth/decorators.py#L88 *2. *At http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18 ; why a *list_moderator *is allowed to view the `*Mass Subscribe`* link on the list navigation bar ? Though clicking it will give a *403* again as he has not permission for it. I think it should be *list_owner. * *3. *The *list_navigation menu *containing the links to Info, Settings, Mass Subscribe, Delete etc. options for a list are only visible to the *super_user. *Though, a *list_owner *should be able to see these for his *owned lists *and similarly a *list_moderator *should be able to see the *held messages *option in his navigation menu. This can be fixed by replacing the line: http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/lists/summary.html#L10 by % if user.is_superuser or user.is_list_owner or user.is_moderator %} As we have a second level permission check before rendering the respective options implemented in the file : http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html <http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18> . Doing this will cause proper person to see the options that he is allowed to do in his navigation menu. More on this here : https://bugs.launchpad.net/postorius/+bug/1443400 Thanks, Ankush Sharma IIT-BHU,Varanasi India github.com/black-perl ___ 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] [ Query ] Some bugs in postorius that needs to be addressed
Sorry for the typo `good` is not required in the first line. On Mon, Apr 13, 2015 at 7:01 PM, Ankush Sharma < ankush.sharma.ec...@iitbhu.ac.in> wrote: > Hello everyone, > > I have found a good some bugs in postorius. Needs your review before > fixing them. > > *1.* The *list_moderator* is not able to access the list of held messages > as visiting at /postorius/lists/*/held_messages *gives > a *403 *i.e *Forbidden* Status code because it is simply not allowed to > access it. I have discussed the cause and fix for this issue here > https://bugs.launchpad.net/postorius/+bug/1443433 . > I am assuming the *list_owner* to be a *list_moderator* in my fix as > indicated by > http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/auth/decorators.py#L88 > > *2. *At > http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18 > ; why > a *list_moderator *is allowed to view the `*Mass Subscribe`* link on the > list navigation bar ? Though clicking it will give a *403* again as he > has not permission for it. I think it should be *list_owner. * > > *3. *The *list_navigation menu *containing the links to Info, Settings, > Mass Subscribe, Delete etc. options for a list are only visible to the > *super_user. > *Though, a *list_owner *should be able to see these for his *owned lists *and > similarly a *list_moderator *should be able to see the *held messages *option > in his navigation menu. This can be fixed by replacing the line: > http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/lists/summary.html#L10 > by > > % if user.is_superuser or user.is_list_owner or user.is_moderator %} > > As we have a second level permission check before rendering the respective > options implemented in the file : > http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html > <http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18> > . > Doing this will cause proper person to see the options that he is allowed > to do in his navigation menu. More on this here : > https://bugs.launchpad.net/postorius/+bug/1443400 > > Thanks, > > Ankush Sharma > IIT-BHU,Varanasi > India > github.com/black-perl > > ___ 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] [ Query ] Some bugs in postorius that needs to be addressed
The above bugs have been discussed in detail with Bhavesh Goyal with involvement of Terri. I think fixing https://code.launchpad.net/~bhavesh-goyal093/postorius/fixed-nav-role-identification would work ! On Mon, Apr 13, 2015 at 7:05 PM, Ankush Sharma < ankush.sharma.ec...@iitbhu.ac.in> wrote: > Sorry for the typo `good` is not required in the first line. > > On Mon, Apr 13, 2015 at 7:01 PM, Ankush Sharma < > ankush.sharma.ec...@iitbhu.ac.in> wrote: > >> Hello everyone, >> >> I have found a good some bugs in postorius. Needs your review before >> fixing them. >> >> *1.* The *list_moderator* is not able to access the list of held >> messages as visiting at /postorius/lists/*/held_messages >> *gives a *403 *i.e *Forbidden* Status code because it is simply not >> allowed to access it. I have discussed the cause and fix for this issue >> here https://bugs.launchpad.net/postorius/+bug/1443433 . >> I am assuming the *list_owner* to be a *list_moderator* in my fix as >> indicated by >> http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/auth/decorators.py#L88 >> >> *2. *At >> http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18 >> ; why >> a *list_moderator *is allowed to view the `*Mass Subscribe`* link on the >> list navigation bar ? Though clicking it will give a *403* again as he >> has not permission for it. I think it should be *list_owner. * >> >> *3. *The *list_navigation menu *containing the links to Info, Settings, >> Mass Subscribe, Delete etc. options for a list are only visible to the >> *super_user. >> *Though, a *list_owner *should be able to see these for his *owned >> lists *and similarly a *list_moderator *should be able to see the *held >> messages *option in his navigation menu. This can be fixed by replacing >> the line: >> http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/lists/summary.html#L10 >> by >> >> % if user.is_superuser or user.is_list_owner or user.is_moderator %} >> >> As we have a second level permission check before rendering the >> respective options implemented in the file : >> http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html >> <http://bazaar.launchpad.net/~mailman-coders/postorius/trunk/view/head:/src/postorius/templates/postorius/menu/list_nav.html#L18> >> . >> Doing this will cause proper person to see the options that he is allowed >> to do in his navigation menu. More on this here : >> https://bugs.launchpad.net/postorius/+bug/1443400 >> >> Thanks, >> >> Ankush Sharma >> IIT-BHU,Varanasi >> India >> github.com/black-perl >> >> > > ___ 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] Welcome to GSoC 2015
Congratulations everybody and thanks to all Mailman mentors for their constant support. Thanks, Ankush Sharma http://github.com/black-perl On Tue, Apr 28, 2015 at 7:06 AM, Stephen J. Turnbull wrote: > Florian Fuchs writes: > > Fellow friends of Mailman, dear students, > > > > welcome to GSoC 2015 (the Mailman edition)! > > Congratulations to all of the applicants on the high quality of > applications! > > For those who were not selected, I'd be happy to discuss your > applications off-list (and by mail, not IRC, I'm still catching up on > $DAYJOB so replies may take a few days). > > > But now, without further ado, let's welcome our three GSoC > > students: > > Congratulations to the selected students! > > And a personal note: > > > Bhavesh Goyal - A Dashboard for Admins/Owners/Moderators > > Mentors: Abhilash Raj, Sneha Priscilla Makini > > I've mentored a similar project in the past (Shanu Salunke's "Mailman > Interface" for Systers), so feel free to include me in discussions. > > That said, speaking as an individual mentor, I would really like to > see most technical discussions take place on this list, or at least be > summarized here. I hope folks not participating in GSoC will bear > with us (hi, Andrew! some of your older posts are in my queue, someday > soon...). Besides wanting to see what students I'm *not* mentoring > are up to, we've had issues in the past where a project went off in an > unprofitable (ie, hard to integrate) direction when the mentor and > student were communicating almost exclusively in personal mail and IRC > direct messages. > > Although your mentor has a *responsibility* to answer you, the rest of > us care and want to contribute, and that's easiest if you post to this > list. > > Here's to a fun and productive summer for everyone! > > Steve > > > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > ___ 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
[Mailman-Developers] GSOC - Mailman Client in JS update
Hey, I have wrote a blog post regarding my work on the project till date. Interested people can have a look. Link : http://black-perl.me/black-perl-gsoc-with-mailman-week-i Thanks, Ankush Sharma ___ 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
[Mailman-Developers] [GSOC'15] Mid term blog report
Hello everyone, I have put up a blog post regarding my GSoC project *Mailman Client in JS. *Interested people can follow this link : http://black-perl.me/black-perl-gsoc-with-mailman-mid-term-report Expecting feedback from your side ! Thanks, Ankush Sharma IIT-BHU, Varanasi http://black-perl.me ___ 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] [GSOC'15] Mid term blog report
Hi, Thanks Terri for giving feedback on the report. I have written the tests from scratch for the implementation of the mailman-client in JS. So, I got to a point where I need to do a bit of refactoring to the code base to remove some redundant logic. Due to this some minor issues are coming with the testing. Yeah, I agree with you that these things could provide opportunities for beginners. So, I will try to work on the tough one's first that require deeper understanding of code and later on may be the easy ones' or may be leave them for beginners. Thanks, Ankush Sharma https://black-perl.me On Tue, Jul 7, 2015 at 11:22 PM, Terri Oda wrote: > On 2015-07-02 11:17 AM, Ankush Sharma wrote: > >> Hello everyone, >> >> I have put up a blog post regarding my GSoC project *Mailman Client in >> JS. *Interested >> people can follow this link : >> >> http://black-perl.me/black-perl-gsoc-with-mailman-mid-term-report >> >> Expecting feedback from your side ! >> > > You mention that a bunch of the tests are failing due to code changes. Is > this something the rest of us can help you out on? There's no requirement > in GSoC that you write and fix every single test personally, and sometimes > test fixes are tasks suitable for people who want a small, self-contained > contribution opportunity or a quick thing to do. Would these maybe be > something like that, or would you need to understand your code really > deeply to work on the fixes? > > Terri > > > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > ___ 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
[Mailman-Developers] GSOC'15 blog report - mailman client in JS
Hello everyone, I have put up a blog report <http://black-perl.me/black-perl-gsoc-with-mailman-pre-end-term-report/> . Interested people can have a look and any feedback is always welcomed. Thanks, Ankush Sharma IIT-BHU Varanasi, India - 221005 http://black-perl.me ___ 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] Authorization System in Core
Hi Harshit, Their is no authentication system(OAuth etc.) set up between core and client for now. The client uses plain HTTP calls to communicate to the core. So, anyone with the credentials can alter any such permissions in the core. So, for now core and client should reside on the same host. So, I guess it would be better to implement the permissions stuff on the postorius side as others pointed out ! PS : I worked on the Node.js mailman client last year. You can refer it here <https://gitlab.com/black-perl/mailman-client.js>. Thanks ! Ankush Sharma ECE IV IIT-BHU Varanasi-221005 http://black-perl.in Linkedin <https://www.linkedin.com/in/ankushsharma003> On Sun, May 22, 2016 at 3:20 AM, Harshit Bansal wrote: > Hi, > Earlier, while discussing the permission system for manging styles, it was > decided that the permissions system should be enforced in the core rather > than in the postorius since otherwise it can be bypassed(deliberately or > undeliberately). But one thing that I think I forgot to discuss was that > currently there is no authorisation system in the core and now I am unable > to figure out that how could the permissions be enforced in the core > without an authorisation system. > Should I workout an authorisation system for the core first or enforce > permissions in postorius only? > > Thanks, > Harshit Bansal > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > ___ 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
[Mailman-Developers] Interested in contributing to Mailman
Hi everyone, I am Ankush Sharma from India, currently an undergrad at IIT-BHU,Varanasi. I am a python aficionado and a die hard linux fan. I love to spent my time automating things on the web. Apart from that, I delivered a talk at PyCon India 2014 about *powering apps with gesture control using python programming language *[1]*. *I have earlier experience of working with SMTP libraries of python and SMTP protocol while developing makemymails.com, finalists of India zone for the Google Cloud Developer Challenge-2014. I found mailman quite interesting. I have already set up the development environment for the Mailman core and Postorius; thanks to @maxking and other devs for reaching out at IRC. Currently, I am going through the codebase and the mail archives. The idea list for this year's GSOC program is quite versatile and I would love to suggest any other ideas. The idea of having a mailman client written in Javascript is a good project to work on. I have noticed a few things but it would be better to go through the whole architecture, docs and archives before pointing them out. Looking forward to contributing to Mailman through this year's GSOC program. Thanks, Ankush Sharma Btech Part-III IIT-BHU,Varanasi-221005 GITHUB : github.com/black-perl [1] in.pycon.org/funnel/2014/208-python-the-eyes-of-real-world-computer-applications ___ 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] GSoC 2015: brainstorming ideas suitable for beginners?
On Fri, Feb 27, 2015 at 1:13 PM, Terri Oda wrote: > Honestly, I don't love this idea. I would be technically feasible with > VERP, I don't know about VERP. I will surely have a look. > but it edges into features that are very popular for people sending spam. Spamming would be the case when you are sending the emails to people who don't want to receive such emails. While if we control the variable to take value from the set of emails of the list members only and not allowing the use of template variables i.e < .. > stuff in the *To: *field. > > > > On 2015-02-26 11:32 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), > Varanasi (U.P.), INDIA wrote: > >> How about having personalized announcement mailing lists ? >> >> A personalized mailing list will allow mailman users to send >> personalized emails to all the list members from a common email >> template. Suppose I am the manager of a company and I need to ask all >> the workers for a meeting. I want each of my workers to prepare a topic >> to speak on during the meeting. For this I need to send each of them a >> message separately mentioning the topic he/she has to speak on. >> >> Suppose the email /template/ is like this: >> >> *To : * >> *Subject: * >> * >> * >> *Hello ,* >> * >> * >> *Hope you are having fun at . I am arranging a meeting at >> 5 p.m. on Saturday. I want you to speak on during the meeting. >> So, come prepared for that.* >> ** >> * >> * >> *Best wishes,* >> * >> * >> *Ankush Sharma* >> *Manager* >> *foo-bar* >> >> >> And I have a spreadsheet data on the mailing list server like this: >> https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_ >> zB67qEvgmX8Jr3xYyGxPdwdU/pubhtml >> >> Mailman can have a functionality of flooding the /template/ by using the >> spreadsheet data. The variables in the /template/ (< -- > stuff) would >> be replaced by the corresponding row data in the spreadsheet >> corresponding to the emails of the list members. This can provide great >> flexibility to mailman users who use mailman as announcement list. >> >> Later on, mailman can have the functionality of saving email templates >> and choosing one of them in a certain scenario. Mailing lists can be >> made more personalized and powerful in this way. >> >> Expecting further feedback or suggestions on this idea. >> >> Ankush Sharma >> IIT-BHU,Varanasi >> github.com/black-perl <http://github.com/black-perl> >> >> >> >> On Thu, Feb 26, 2015 at 4:40 AM, Barry Warsaw > <mailto:ba...@list.org>> wrote: >> >> On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote: >> >> >I’m looking forward to being able to set and get domainowner and >> serverowner >> >(or siteowner or whatever its called). It will allow me to delete >> lots of >> >code and there’s no greater joy than deleting code. >> > >> >Are you anticipating this will be in V3.0? >> >> Please file a bug and we'll see. ;) >> >> Cheers, >> -Barry >> >> ___ >> Mailman-Developers mailing list >> Mailman-Developers@python.org <mailto: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/ankush.sharma.ece12%40itbhu.ac.in >> >> Security Policy: http://wiki.list.org/x/QIA9 >> >> >> > ___ 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] GSoC 2015: brainstorming ideas suitable for beginners?
How about having personalized announcement mailing lists ? A personalized mailing list will allow mailman users to send personalized emails to all the list members from a common email template. Suppose I am the manager of a company and I need to ask all the workers for a meeting. I want each of my workers to prepare a topic to speak on during the meeting. For this I need to send each of them a message separately mentioning the topic he/she has to speak on. Suppose the email *template* is like this: *To : * *Subject: * *Hello ,* *Hope you are having fun at . I am arranging a meeting at 5 p.m. on Saturday. I want you to speak on during the meeting. So, come prepared for that.* ** *Best wishes,* *Ankush Sharma* *Manager* *foo-bar* And I have a spreadsheet data on the mailing list server like this: https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_zB67qEvgmX8Jr3xYyGxPdwdU/pubhtml Mailman can have a functionality of flooding the *template* by using the spreadsheet data. The variables in the *template* (< -- > stuff) would be replaced by the corresponding row data in the spreadsheet corresponding to the emails of the list members. This can provide great flexibility to mailman users who use mailman as announcement list. Later on, mailman can have the functionality of saving email templates and choosing one of them in a certain scenario. Mailing lists can be made more personalized and powerful in this way. Expecting further feedback or suggestions on this idea. Ankush Sharma IIT-BHU,Varanasi github.com/black-perl On Thu, Feb 26, 2015 at 4:40 AM, Barry Warsaw wrote: > On Feb 25, 2015, at 04:12 PM, Andrew Stuart wrote: > > >I’m looking forward to being able to set and get domainowner and > serverowner > >(or siteowner or whatever its called). It will allow me to delete lots of > >code and there’s no greater joy than deleting code. > > > >Are you anticipating this will be in V3.0? > > Please file a bug and we'll see. ;) > > Cheers, > -Barry > > ___ > 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/ankush.sharma.ece12%40itbhu.ac.in > > Security Policy: http://wiki.list.org/x/QIA9 > ___ 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] GSoC 2015: brainstorming ideas suitable for beginners?
I realize the feature I proposed earlier is more of a commercial feature and might not be be so useful for Mailman as you mentioned it's pitfalls. Are there other directions that I should think in? I am good with Python, Javascript, HTML5. I was wondering if there is a sort of tool that generates summaries for mailing list activity and charts like number of users, number of active users, etc. Would something like this be a good idea or is it already done? On Fri, Feb 27, 2015 at 1:54 PM, Terri Oda wrote: > I am quite aware of the definition of spam (in fact, I have a master's > thesis on the subject). > > What I'm concerned about is that in the past, mail merges (which is what > you're describing) is a feature that has often been requested by people > doing marketing lists. It's not a subset of users I'm eager to attract, > since a few bad apples could cause some unfortunate fallout for Mailman as > users start marking messages as spam and, inevitably, sending us angry > messages. (As the person who wrote the 2.1 documentation, I can tell you > that I already get these on occasion as upset folk will send to basically > any address they can find associated with the project.) > > It's not that it's a bad feature in isolation. But there are so *many* > potential features for Mailman, and I'd like to see ideas that are less > socially problematic get implemented first. > > Terri > > > > On 2015-02-26 11:52 PM, Ankush Sharma B.Tech. Electronics Engg, IIT(BHU), > Varanasi (U.P.), INDIA wrote: > >> >> On Fri, Feb 27, 2015 at 1:13 PM, Terri Oda > <mailto:te...@toybox.ca>> wrote: >> >> Honestly, I don't love this idea. I would be technically feasible >> with VERP, >> >> I don't know about VERP. I will surely have a look. >> >> but it edges into features that are very popular for people sending >> spam. >> >> Spamming would be the case when you are sending the emails to people who >> don't want to receive such emails. While if we control the >> variable to take value from the set of emails of the list members only >> and not allowing the use of template variables i.e < .. > stuff in the >> *To: *field. >> >> >> >> >> >> On 2015-02-26 11:32 PM, Ankush Sharma B.Tech. Electronics Engg, >> IIT(BHU), Varanasi (U.P.), INDIA wrote: >> >> How about having personalized announcement mailing lists ? >> >> A personalized mailing list will allow mailman users to send >> personalized emails to all the list members from a common email >> template. Suppose I am the manager of a company and I need to >> ask all >> the workers for a meeting. I want each of my workers to prepare >> a topic >> to speak on during the meeting. For this I need to send each of >> them a >> message separately mentioning the topic he/she has to speak on. >> >> Suppose the email /template/ is like this: >> >> *To : * >> *Subject: * >> * >> * >> *Hello ,* >> * >> * >> *Hope you are having fun at . I am arranging a >> meeting at >> 5 p.m. on Saturday. I want you to speak on during the >> meeting. >> So, come prepared for that.* >> ** >> * >> * >> *Best wishes,* >> * >> * >> *Ankush Sharma* >> *Manager* >> *foo-bar* >> >> >> And I have a spreadsheet data on the mailing list server like >> this: >> https://docs.google.com/__spreadsheets/d/1cAbdSmc1NA-__C9IZFjc___ >> zB67qEvgmX8Jr3xYyGxPdwdU/__pubhtml >> <https://docs.google.com/spreadsheets/d/1cAbdSmc1NA-C9IZFjc_ >> zB67qEvgmX8Jr3xYyGxPdwdU/pubhtml> >> >> Mailman can have a functionality of flooding the /template/ by >> using the >> spreadsheet data. The variables in the /template/ (< -- > stuff) >> would >> be replaced by the corresponding row data in the spreadsheet >> corresponding to the emails of the list members. This can >> provide great >> flexibility to mailman users who use mailman as announcement list. >> >> Later on, mailman can have the functionality of saving email >> templates >> and choosing one of them in a certain scenario. Mailing lists can >> be >>
