Edit List Config menu items appear ordered by scenario name instead of by gettext description

[qosobrin]

When trying to define the properties of a list in "Edit List Config" you have to face many drop down menus that have their options ordered by the scenario name instead of by the appropriate gettext description. This makes very odd, if not difficult, to figure out the best option to use.

For example, if you try to set the "send" option in a list you are faced with this list:

closed (closed)
restricted to subscribers (confidential)
restricted to subscribers (default)
Moderated, no authentication needed if DKIM signature from editor is OK (editordkim)
Moderated (editorkey)
Moderated, even for moderators (editorkeyonly)
Moderated, need authentication from editor (editorkeyonlyauth)
restricted to local domain (intranet)
restricted to local domain and subscribers (intranetorprivate)
Newsletter, restricted to moderators (newsletter)
Newsletter, restricted to moderators after confirmation (newsletterkeyonly)
restricted to subscribers (private)
Moderated, restricted to subscribers (privateandeditorkey)
Moderated, for non subscribers sending multipart messages (privateandnomultipartoreditorkey)
restricted to subscribers with previous md5 authentication (privatekey)
Moderated, for subscribers and even moderators themself (privatekeyandeditorkeyonly)
Private, moderated for non subscribers (privateoreditorkey)
Private, confirmation for non subscribers (privateorpublickey)
restricted to subscribers and checked smime signature (private_smime)
public list (public)
anyone no authentication if DKIM signature is OK (publickey)
public list multipart/mixed messages are forwarded to moderator (publicnoattachment)
public list, Bcc rejected (anti-spam) (public_nobcc)
public list multipart messages are rejected (publicnomultipart)

As you can see, several related or similar options are scattered across the whole list. A more useful approach would be to have the options sorted by their gettext description. The same list would show like this:

anyone no authentication if DKIM signature is OK (publickey)
closed (closed)
Moderated (editorkey)
Moderated, even for moderators (editorkeyonly)
Moderated, for non subscribers sending multipart messages (privateandnomultipartoreditorkey)
Moderated, for subscribers and even moderators themself (privatekeyandeditorkeyonly)
Moderated, need authentication from editor (editorkeyonlyauth)
Moderated, no authentication needed if DKIM signature from editor is OK (editordkim)
Moderated, restricted to subscribers (privateandeditorkey)
Newsletter, restricted to moderators (newsletter)
Newsletter, restricted to moderators after confirmation (newsletterkeyonly)
Private, confirmation for non subscribers (privateorpublickey)
Private, moderated for non subscribers (privateoreditorkey)
public list (public)
public list multipart messages are rejected (publicnomultipart)
public list multipart/mixed messages are forwarded to moderator (publicnoattachment)
public list, Bcc rejected (anti-spam) (public_nobcc)
restricted to local domain (intranet)
restricted to local domain and subscribers (intranetorprivate)
restricted to subscribers (confidential)
restricted to subscribers (default)
restricted to subscribers (private)
restricted to subscribers and checked smime signature (private_smime)
restricted to subscribers with previous md5 authentication (privatekey)

IMHO if not perfect it is, at least, more readable.

[racke]

Yes that makes sense to me.

[qosobrin]

I would accompany this change with rewriting the every gettext descriptions for all the scenarios, to make them consistent in nomenclature and capital/lower case use.

Not to mention the overwhelming number of scenarios created for some configuration options. For example, there are 23 different scenarios for the "send" option. I would take a "simpler is better" approach, leaving the most basic of them and moving the rest to some kind of repository outside. I know sysadmins can hide the scenarios they do not want to be displayed, but this would allow for a better out of the box experience with simpler options and a leaner menus.

[racke]

Yes, I definitely agree with make the descriptions consistent.

Simpler options is a good idea too, we could accompany it with a tool in the Web UI to click additionals ones together based on the standard ones :-).

[ikedas]

Order of options for most of parameters are hardcoded in Sympa::ListDef module (e.g. options of verp_rate are ordered sanely). "Most of" means that currently this feature isn't applied to scenario names, but I suppose it is possible.

This (hardcoded order) is not the simplest way. However it is not affected by language context (e.g. in japanese or korean, words corresponding to "moderated" and "restricted" can be placed at the end of description) and gives consistent ordering.