Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
Hi Stephen, The CLI project would be a sub module for the mailman.client project. Since bzr does not have the submodule feature, I must be doing it either by using a new repository or as a new branch to mailman.client .The latter would be better as it would be easier to integrate the code into the mailman.client project when this project is completed. Now about the implementation part.As described in the project timeline, the first phase would be to build the command tools. I would be building two classes List and Domain, and identify the various methods that are to be given to them. Many of the methods are identified in my GSoC proposal. The command parsing would be handled by the python Optparse library. I would like to start building the Version 0, but not to throw away, but will be refining it further as per the feedback. If all this is OK I would start building the version and push it to the mailman.client project. And forget about the git vs bzr part. I am OK with using bzr :). *Regards,Rajeev S* *Government Engineering College,Thrissur* *http://rajeevs.tk http://rajeevs.tk* On Tue, Apr 22, 2014 at 9:01 PM, Stephen J. Turnbull step...@xemacs.orgwrote: Just to follow up quickly (I've got problems I need to deal with elsewhere over the next couple days). Abhilash Raj writes: Hey, thanks for jumping in, maxking! Hi Rajeev, Congratulations! We look forward to a great summer with you. Definitely! I would like to thank the Mailman community and mentors for their extensive support during my application process, You're very welcome. Also I have a few questions as part of the community bonding process. 1.Is the project to be developed as an independent project or as a part/branch of the Mailman Core repository That is supposed to be an implementation detail of your proposal. What do you think would be the best? I agree with Abhilash. You make a proposal, we'll criticize it (contructively; criticism is not necessarily negative, just as with literary critics we may give a positive review -- you should know when you're doing things right). 2.If it is an Independent project, Is it OK to use the git+gitorious/savannah or should I stick to bzr+launchpad? I have used git extensively,naturally more comfortable with git. However, I can pick up bzr if necessary. Even if it is an independent project we strongly encourage you to use bzr, as integration and code review might become a problem in later stages of your project( I am speaking from personal experience). Learning bzr and launchpad is not at all difficult if you know git. The CLI won't be *that* independent. It really needs to be on Launchpad. Note: It may be possible to use git-bzr to fetch and push from Launchpad. 3.Is it necessary for me to hangout in the IRC?If yes, when? It is not *necessary* for you to hangout on IRC. You just need to keep your mentors updated about what are you doing all the time. If you prefer email, I don't think that would be a problem. Your only responsibility is to deliver the project you proposed on time. It's generally a good idea to have interaction (brainstorming) when working on design. I can generally be available on IRC from about 01:00 UTC to 15:00 UTC. As Abhilash knows :-) I can often be convinced to stay around until about 17:00 UTC. yaseppochi @ freenode 4.Can I start coding right away? You can, but first be sure you know what you want to code. Your proposal does have a detailed description on working of the tool, however there is little mention about the details of implementation and design. It would be best if you first consult with your mentors and decide on something so that you don't waste time writing code that is not needed. Read Fred Brooks' /The Mythical Man-Month/, especially the essay Build One to Throw Away. Then think about whether you really believe him. :-) Regards and looking forward to working with you! 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/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
[Mailman-Developers] Mailman3: creating a user from an existing address
Hey people, I'm trying to create a User in Mailman 3 from an existing Address. If I were using the Python interface, that would be very easy: just create the user with no address and then link the existing address to it. However, I'm using the REST interface. In mailman.rest.users.AllUser.create(), there's a try/except block which explicitely looks for this case and raises an HTTP 400 error. Looking at the test_existing_user_error() test case, it's apparently to prevent creating a user twice, which is not my use case. Are you OK if I hack the code to automatically link to an existing address while still erroring-out if the user already exist? Or would it be better to allow linking to an existing address from the REST API? Cheers, Aurélien ___ 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] Mailman3: creating a user from an existing address
On Apr 25, 2014, at 04:55 PM, Aurelien Bompard wrote: I'm trying to create a User in Mailman 3 from an existing Address. If I were using the Python interface, that would be very easy: just create the user with no address and then link the existing address to it. So the address is currently unlinked? And you don't want to link it to an existing user, but to a new user you're about to create? However, I'm using the REST interface. In mailman.rest.users.AllUser.create(), there's a try/except block which explicitely looks for this case and raises an HTTP 400 error. Looking at the test_existing_user_error() test case, it's apparently to prevent creating a user twice, which is not my use case. Are you OK if I hack the code to automatically link to an existing address while still erroring-out if the user already exist? Or would it be better to allow linking to an existing address from the REST API? The other way to think about it is that you might want to create the user and link to it from the existing address resource, i.e. the AnAddress class. Right now, you cannot get directly from the address to its linked user, if it has one. Look at _AddressBase._resource_as_dict() in addresses.py. Sketching out an approach: - The address resource would gain a `user` key if there is a linked user. This would be a url to the user resource. If the address is unlinked, then there would be no such key. - AnAddress would gain a /user sub-resource which would either 404 if the address is unlinked or return the linked user's JSON data. - POSTing to /addresses/email/user would create a new user and link the address to it, but only if the address is not yet linked. If it's already linked, you'd get a 409 Conflict error. If the new user is created, you'd get 201 Created response. Additional use cases to consider: Q. What if the address is already linked and you want to unlink it? A. DELETE on the /addresses/email/user resource Q. What if you want to change the user the address is linked to? A. Currently, it's two operations: DELETE the existing link as above, then see below. The other option is to allow a PUT on the /addresses/email/user resource. Q. What if you want to link the unlinked address to an existing user? A. Maybe allow this in the POST to /addresses/email/user, i.e. the user would only be created if it doesn't yet exist. If it gets created, you'd get a 201 Created, but if it's just a link operation to an existing user, you'd get a 200 Success response. It's possibly you'd want to include POST boolean that specifies whether creating a new user is okay or not, with the appropriate response codes in the false case. -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] Mailman3: creating a user from an existing address
So the address is currently unlinked? And you don't want to link it to an existing user, but to a new user you're about to create? Exactly. The address is unlinked and unverified. I'd like to create a user for it. Sketching out an approach: [...] Interesting. I'll look into that at some point, but I have a few more urgent things to do, so if someone wants to beat me to it feel free... ;-) A. ___ 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] Mailman3: creating a user from an existing address
On Apr 25, 2014, at 06:31 PM, Aurelien Bompard wrote: Interesting. I'll look into that at some point, but I have a few more urgent things to do, so if someone wants to beat me to it feel free... ;-) Can you open a bug? -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] handler to auto detach attachment and link it to a website keeping html
Le 24/04/2014 01:27, Mark Sapiro a écrit : 1) Open Mailman/Defaults.py 2) Copy the definition of GLOBAL_PIPELINE 3) paste it into a new file changing the name from GLOBAL_PIPELINE to mlist.pipeline and add your handler so it becomes […] Note that if I understand the purpose of your handler, it should come (not necessarily immediately) after 'Hold'. You really don't want to archive attachments for messages you might reject or discard. Thanks I will explore that behavior. First version on github: https://github.com/Sylvain303/mailman-AttachmentMove I'll document the installation process and correct bugs still presents… - Detaching embedded image related part, - nesting related if already present … Thank you, so much for your help. Sylvain. ___ 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] Mailman3: creating a user from an existing address
Can you open a bug? Done: https://bugs.launchpad.net/mailman/+bug/1312884 :-) A. ___ 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 2014 : Proposal for the Mailman CLI project
On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S rajeevs1...@gmail.com wrote: Hi Stephen, The CLI project would be a sub module for the mailman.client project. Since bzr does not have the submodule feature, I must be doing it either by using a new repository or as a new branch to mailman.client .The latter would be better as it would be easier to integrate the code into the mailman.client project when this project is completed. Why do you want it to be a submodule in the first place? If you want to extend mailman.client they why not simply branch it? Now about the implementation part.As described in the project timeline, the first phase would be to build the command tools. I would be building two classes List and Domain, and identify the various methods that are to be given to them. Many of the methods are identified in my GSoC proposal. The command parsing would be handled by the python Optparse library. Are users not going to be a part of this? Or you have thought of something else for managing users? Also in your proposal I don't find any mention of user roles. How will you manage user roles? Is the command line tool that you want to build will only be accessible by the supersuser/admin? Or moderators and assigned list owners can also use it to do whatever it does? Also if you allow moderators and owners then you probably have to think of something about permissions to restrict everyone to use the features only specific to there role. From my point of view this project would (someday) be an command line alternative to postorius for admin roles. Not that you have to do everything in this summer, but it should be kept in mind while you work on it. Also may I suggest you to use argparse instead of optparse -- it is now depricated since py2.7. I would like to start building the Version 0, but not to throw away, but will be refining it further as per the feedback. If all this is OK I would start building the version and push it to the mailman.client project. You probably should figure out everything before you jump on to coding. The time till 19th May is allotted for community bonding and there is a reason for that. Try to understand how new features are discussed in here(mailman community) before becoming python statements. I don't know if you already have, but try to read the source code and understand the coding style Barry prefers. There is a style guide for mailman, find it out. And forget about the git vs bzr part. I am OK with using bzr :). Great. thanks, Abhilash Raj ___ 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
