[Mailman-Developers] [GSoC 2014] Mailman CLI Project

[Rajeev S]

Hi,

I have made more additions to the CLI, like the `delete` command and the
`user` scope.

Following is the list of changes brought about

1.Introduce User scope

Actions supported by User scope currently are create, show and delete.
show users, like other scopes, supports verbose and no-header flags. However
the detailed listing of users is not quite effective as most of the fields
are lists
rather than single valued attributes. The non detailed version prints one
of the
email ids of each user. The show list command takes an optional argument
list name that gives the users who are members of the list.


2.Introduce a cli/lib directory, to store procedures common across the
application.

The directory is to hold the procedures and classes that are reused among
scripts.
It currently holds a class that is used to colorize the output printed on
the terminal.

3.Updated and improved docs/using.txt. It was obsolete in r54.


4.Added delete action for all objects

The action is confirmed by a question to user, which can be overridden by a
--yes switch.

I will be committing and pushing r55 tonight (30/05/2014 around 16:30 UST,
I am away from
the computer right now).
____

As mentioned by Steve and agreed by Barry, I too believe that, in the
scenario of the CLI
multiple confirmations won't be necessary. In a situation in which such
multiple confirmations
come necessary, I believe that the commands will be better if the
confirmations are replaced
by switches.

I agree that an override for the confirmation message is necessary so that
the CLI
commands can be used in scripts and I would like to follow Barry's
suggestion of using
a `--yes` or `--force` switch. (Isn't --force more common than --yes, as in
`rm -f` ?)

About the create domain suggestion, Is the follow up question on `*create
domain*`, upon missing domain,
such a bad idea? A user already can `add a domain` by using the web
interface. If that is not ambiguous,
neither is this, right?

However I see this issue, if a newbie user types in an email address in
place of the list name, probably
on misreading the command format, he would end up creating a domain for his
mail provider.

*$./mmclient create list --help*
*Creates the list list at domain.org <list at domain.org>*
 *$./mmclient create list user at gmail.com <user at gmail.com>*
*The domain gmail.com <http://gmail.com> does not exist.Create one?[y/n] y*
 *$*

@Abhilash

I have written unittests for methods like connect and create, but have to
refine them more.
Hence the tests won't come up in this revision.

Also, I would like to ask how the tests should be triggered. Should
there be a `mmclient test` with a set of possible switches like `all`
,`domain`, `list`, `user` etc?
Or should the customary `python setup.py test` be used?


I also propose to build a a *`describe user`* command that gives a detailed
profile of the user.
Verbose listing using tables is not so effective users as most of the
attributes are lists.

Thanks!