Owner and editors edition through the command line

[dverdin]

Expected Behavior

A lot of administrators have built scripts to mass edit config files, especially for owners provisioning.

Current Behavior

These scripts are broken as of Sympa 6.2.34 due to the fact that editors and owners are now located in the database only. These are the only list parameters having such an exception.

Possible Solution

I plan to add options to sympa.pl to manage list adminsitrators. That way, these scripts will keep on working, simply by replacing the sed or whatever command the admins were using by the relevant sympa.pl command.

These options would make usage of the new Sympa code and use the new primitives to add / replace / delete adminstrators.

Actually, this would even be an improvement to previous Sympa versions because such options would have been very usefull before, for example when somebody leaves an institution and her replacement needs to take over the leaver's list.

Here is the intended interface I want to provide:

sympa.pl --add-admin --list= --vhost= --email=an@email --role=<owner|editor> --visibility= --profile=<privileged|normal> --reception_mode=<reception_mode> --gecos

sympa.pl --delete-admin --list= --vhost= --email=an@email --role=<owner|editor>

sympa.pl --replace-admin --list= --vhost= --previous_admin=an@email --new_admin=an.other@email

In each case, the "last modified by" list parameter would contain "listmaster@domain.tld" email.

What do you think? I could do this easily and quickly using the current codebase.

Context

I'm in contact with a lot of listmasters through the lists and a lot complained about the lost functionnality, while agreeing the vanishing of the cache problem was very cool.

[racke]

Wouldn't it be better to include the owners from SQL/LDAP/... like we do for subscribers?

[dverdin]

We already can.
But you do know that a lot of Sympa instances don't have such datasources, don't you?
For these, only scripts can do the trick. And the command line.

[ikedas]

Providing Sympa::Request handler at first seems better. It may be useful for the other components than command line (e.g. SOAP: See #526).

[racke]

Yes, definitely. That's the way to go.

[dverdin]

OK. The Request Handler is needed to treat this.
I'll do it too.
Do you agree with the principle? I mean, the interface provided by the Handler:

Three operations accessible to users :

• add
• del
• replace

Range : either a single list or a virtual host

Parameters: the kind of role to edit and its accompanying optional details (gecos, visibility, etc.)

The idea is to reuse other command line option (I would certainly rename vhost to robot, by the way).

[ikedas]

Hi @dverdin,

Alternative solution

If you seek a quick solution, you'd be better to consider using dump files.

Previously administrators edited config file to change owners/moderators directly. Instead, with current version, they may do

sympa.pl --dump_users --list LISTNAME --role owner,editor
(Edit owner.dump and/or editor.dump)
sympa.pl --restore_users --list LISTNAME --role owner,editor

Contents of owner.dump and editor.dump are the same as owner and editor paragraphs in config with earlier versions. Editing them can be easier for administrators than learning new command line tools.

[dverdin]

Hi @ikedas ,
That's a perfectly valid solution indeed! And I'll propose it to the French mailing list where the question arose first.
I had not spotted this option before. sorry. Otherwise, I wouldn't have bothered you.

That questions the pertinence of my proposal. If the primary problem has a solution, it might be pointless to develop it. Then again, there is the correlated issue with SOAP/REST API. And for it, we need the Request Handler, that could be reused for the command line.

So I'll think I'll still do it, following your proposal of a Request Handler. But it's good to knwo there is short term solution - that could perfectly remain the long term solution.

Thanks, Soji!

[dverdin]

Dear all,
I just committed a request handler for adding list admins.
Do you agree with how I did it?
Any comment would be appreciated.
Thanks!

[dverdin]

Aaaaaaand I forgot to put a link towards the commit...
Here it is: dverdin@db273b5

[ikedas]

I think add and del are sufficient. replace may not required.

BTW, you'd be better to work on cleaner branch on your fork.
sympa-6.2...dverdin:add_list_admin_request_handler
Due to (no-ff) merge, your branches on your fork is separated from master repo.
https://github.com/sympa-community/sympa/network

[dverdin]

Thanks for your comment @ikedas !
Yes, I think I have to organize my branches better than that. I'll work on it.
About replace, there are use cases actually: when somebody leaves a community and is replaced by somebody else. It happens often in large organizations.
But, indeed, we do something similar with replace for a normal user.
OK. I'll wait for this one and implement the two others in the meantime.
Any advice about how I implemented add? If it's OK, I'll implement a similar del, then add the command line options. I can do the SOAP part on a separate PR.
Cheers!
David

[ikedas]

replace may be replaced with add then del, I thought.

[dverdin]

That's certainly a possibility.
However, as these data are in database, it feels easier to run an "update" query than a bunch of call to add and del. And also, replacing is different from adding or deleting from an end user point of view. That's why I wanted to implement this function explicitely.
But this can be seen later.

[dverdin]

Dear all,
I fixes my branch. that looks better, doesn't it? https://github.com/sympa-community/sympa/network
Here is the new commit: dverdin@e80f799

I'll keep working on this basis.
Regards,