Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In edit_list_request page, sort scenario on titles #1659

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

salaun-urennes1
Copy link
Collaborator

Currently scenario in edit_list_request pages are sorted on scenario filenames.
As reported in https://lists.sympa.community/msg/fr/2023-04/1TZ5Q-_qRxSqJkG0zscNjQ, it would make sense to sort them on scenario titles.

This PR does the sort in TT2 file

@ikedas
Copy link
Member

ikedas commented Apr 21, 2023

I have an objection.

  • Sorting text in descending order by character code does not always result in an intuitively acceptable order (this is especially true for some languages including Japanese and Chinese).

  • Furthermore, changing the order of items according to language may cause embarrassment during user support. --- "Select the first item in the dropdown list. ...Yes. If the item is written in English, it is the first item".

@salaun-urennes1
Copy link
Collaborator Author

Would it make sense to have a configuration parameter to control this behavior, thus responding to the need of european users, while leaving the freedom for others to keep the current behavior?

@ikedas
Copy link
Member

ikedas commented Apr 21, 2023

However, sorting by character code may not necessarily be convenient for many European users either. IMO the "à" seems placed after the "z".

@salaun-urennes1
Copy link
Collaborator Author

That's true, alphabetical sort is not perfect, but still better than the current situation.

Here is an example on our Sympa main server :
image

@ikedas
Copy link
Member

ikedas commented Apr 21, 2023

That's just why that English and French share many of the same word roots, so the sort order is often the same. In other words, your language is too specific. Check by changing the language setting to Russian, Finnish, Magyar and so on.

If we want to allow users to choose the order they prefer, I think, we need the way something else.

@ikedas
Copy link
Member

ikedas commented Apr 21, 2023

Using Unicode Collate algorthm may solve the problem better for European and other languages (Still only sorting by character code is possible for Kanji, though).

@salaun-urennes1
Copy link
Collaborator Author

Thanks for suggesting this alternative.

It seems Unicode::Collate is installed on my server. Does it come with Perl?

Using this module for sorting would however require to write a custom sort subroutine to be used in TT2 templates...

@ikedas
Copy link
Member

ikedas commented Apr 21, 2023

Currently Unicode::Collate is not a core module of Perl, but we may be able to add it to our cpanfile, i.e. we may add it as one of dependency module of Sympa. Of course we need to write any code to use this module in Sympa, but when at last we do, it may be used as easy as builtin sort().

It's midnight here. See you in the next week!

@ikedas
Copy link
Member

ikedas commented Apr 22, 2023

The following opinion is separate from the pros and cons of this PR and may be continued later in a different location.

Currently, users need to distinguish slightly different titles in order to find the appropriate scenario. Sorting would make it easier to distinguish between similar titles by placing them in close proximity to each other. In other words, the fundamental problem may be that there are too many scenarios for each function.

For example, for the send scenario, it would be much easier to understand if several conditions were selected individually, such as:

  • Who can post?
  • Does the posting require the confirmation of the author?
  • What to do if a post cannot be submitted: Moderation or rejection
  • Authentication method: No authentication (smtp), confirmation (md5), S/MIME (smime)
  • and so on.

All possible combinations of these conditions are made into separate scenarios, which means that we have to prepare many scenarios with similar titles.

@salaun-urennes1
Copy link
Collaborator Author

Thank you for summarizing the problem.
I'm on off next week.
We can go on this discussion in May...

@salaun-urennes1
Copy link
Collaborator Author

I agree with you comment; scenario titles are too heterogeneous. Given the number of scenarios, especially for send, it is hard for list owners to make a clever configuration choice for their list.

At our University we recently made a significant work to simplify the situation:

  1. we analyzed all default and custom send scenarios to find out a) how many lists use each scenario and b) compare the behavior of each scenario. All these informations were summarized in a spreadsheet that looks like this
    image
  2. we listed what send scenario is really worth maintaining (in our context). Others have been hidden using :ignore files;
  3. we have renamed remaining send scenarios using a consistent schema. Here is an example: send.ur1modereetrejetsinon:title.fr Owners/Editors: moderated ; staff: mederated ; other: reject

@ikedas
Copy link
Member

ikedas commented May 16, 2023

@salaun-urennes1 , I was in the process of doing exactly the same thing (and had given up because I got fed up with the complexity)!
If you don't mind, please share the results of your work.

@ikedas
Copy link
Member

ikedas commented Nov 26, 2023

I convert this PR to Draft once. Let's continue discuttion.

@ikedas ikedas marked this pull request as draft November 26, 2023 07:47
@salaun-urennes1
Copy link
Collaborator Author

Here are further details about our send scenario reorganization:

  • to help me analyze what out what does each scenario, I used a custom script that parses each send scenario file and summarize what it does with 6 letters. For exemple DDDMMR means : Accepted ('D') for Owners+Editor+Member, moderated ('M') for staff+students and rejected ('R') for others.
  • we ended up hidding many send scenarios, by creating default/scenari/send.xx:ignore files,
  • we customized the send scenarios considered as useful, to have a consistant kind of titles. It looks like this :
/data/sympa/etc/scenari/send.confidential:title.gettext Propriétaires/modérateurs: autorisés ; membres: autorisés ; autres: rejet 
/data/sympa/etc/scenari/send.editorkey:title.gettext Modérateurs: autorisés ; autres: modérés 
/data/sympa/etc/scenari/send.editorkeyonly:title.gettext Tous: modérés
/data/sympa/etc/scenari/send.editorkeyonlyauth:title.gettext Modérateurs: confirmation ; autres: modérés 
/data/sympa/etc/scenari/send.newsletter:title.gettext Modérateurs: autorisés ; autres: modérés
/data/sympa/etc/scenari/send.newsletterkeyonly:title.gettext Modérateurs: modérés ; autres: rejet
/data/sympa/etc/scenari/send.private:title.gettext Propriétaires/modérateurs: autorisés ; membres: autorisés ; autres: rejet 
/data/sympa/etc/scenari/send.privateandeditorkey:title.gettext Modérateurs: autorisés ; membres: modérés ; autres: rejet 
/data/sympa/etc/scenari/send.privatekey:title.gettext Membres: confirmation ; autres: rejet 
/data/sympa/etc/scenari/send.privatekeyandeditorkeyonly:title.gettext Modérateurs: confirmation ; membres: modérés ; autres: rejet 
/data/sympa/etc/scenari/send.privateoreditorkey:title.gettext Modérateurs: autorisés ; membres: autorisés ; autres: modérés 
/data/sympa/etc/scenari/send.privateorpublickey:title.gettext Membres: autorisés ; autres: confirmation 
/data/sympa/etc/scenari/send.public:title.gettext Tous: autorisés 
/data/sympa/etc/scenari/send.public_nobcc:title.gettext Tous: autorisés ; copie cachée: rejet

@salaun-urennes1
Copy link
Collaborator Author

Here is the list of scenarios we ignore :

./default/scenari/send.owner:ignore
./default/scenari/send.private_smime:ignore
./default/scenari/send.newsletterkeyonly:ignore
./default/scenari/send.privateoreditorkey:ignore
./default/scenari/send.privateandnomultipartoreditorkey:ignore
./default/scenari/send.intranetorprivate:ignore
./default/scenari/send.privateandeditorkey:ignore
./default/scenari/send.private:ignore
./default/scenari/send.editorkey:ignore
./default/scenari/send.editorkeyonlyauth:ignore
./default/scenari/send.publicnomultipart:ignore
./default/scenari/send.default:ignore
./default/scenari/send.privateorpublickey:ignore
./default/scenari/send.public:ignore
./default/scenari/send.ownerauth:ignore
./default/scenari/send.editordkim:ignore
./default/scenari/send.publicnoattachment:ignore
./default/scenari/send.publickey:ignore
./default/scenari/send.newsletter:ignore
./default/scenari/send.public_nobcc:ignore
./default/scenari/send.privatekey:ignore
./default/scenari/send.privatekeyandeditorkeyonly:ignore
./default/scenari/send.closed:ignore
./default/scenari/send.intranet:ignore
./default/scenari/send.editorkeyonly:ignore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants