[Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project

[Rajeev S]

Hi Abhilash,

I did not quite get the user role part.A command line utility runs on the
server on which a software instance runs, just like a MySQL command line
utility.You will need physical access to the system or atleast the shell.I
believe you cannot expect every moderator of the list to have that kind of
access. From my point of view, the tool will be used by the list owner or
the server admin, just like the MySQL shell,which can be used only if you
have access to system shell.However, User/Role management can be imposed by
including a login for the shell,if necessary.Again,that's not possible for
the command tools.

And Yes.Users will be a part of this. I prefer to build the other two
first.Many methods that can come under User class is better suited under
the other two.For eg, for adding a moderator to the list, you can do, *list
--addmoderator user_id , *which should be under the List class*. *But the
same from user point of view, would  be a complicated and less intuitive
command, *user **user_id **--addmoderator **--list list_id *. So, after the
list and domain functions are built, It will be more clear what the user
class must do.

About optparse, I actually meant argparse,sorry about that :). And thanks
for the style guide tip.


*Regards,Rajeev S*
*Government Engineering College,Thrissur*
*http://rajeevs.tk <http://rajeevs.tk>*


On Sat, Apr 26, 2014 at 10:42 AM, Abhilash Raj <raj.abhilash1 at gmail.com>wrote:

> On Fri, Apr 25, 2014 at 6:14 PM, Rajeev S <rajeevs1992 at 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
>