moderation UI doesn't allow mass operations

[mhow2]

Hi,
I am refering to this post (and their replies) https://listes.renater.fr/sympa/arc/sympa-fr/2017-01/msg00005.html

It is a regression from the previous versions of sympa and very annoying when it's needed to delete hundred of spam messages from the UI.

At some point the UI could provide a way to "moderate selected messages, reject others"

Regards,

[sivertkh]

+1 Our users complain about this as well.

[ikedas]

wwsympa.fcgi itself accepts multiple items to process. If templates are changed appropriately, requested feature will be realized. Issue #27 is alike.

PR is awaited.

[mhow2]

@ikedas : as it is a regression, maybe we can take a look to what was the template before ? Could you lead potential contributors to the related files to alter ?

[ikedas]

@mhow2, The template is web_tt2/modindex.tt2. Its content has been changed during development of 6.2.

[mhow2]

@ikedas : to be perfectly clear, from who do we wait a PR ? Is this bug going to be processed by the core team or by contributors ? I'm totally new with templating in sympa, I think it could go way faster with someone used to it. @dverdin maybe ?

[l4uc3]

Hi everyone,
We had the same pb in university of Strasbourg. We changed the modindex.tt2 to improve the mass moderation. Enclosed is the modindex.tt2 we use.
modindex.tt2.gz
I added a pull request with the file. Up to you to merge it.
Have a good one !
Laurence

[dverdin]

Thanks Laurence!
This was becoming worrying...
It's good to see you back to Sympa contribution, by the way. ;-)

[ikedas]

Hi @l4uc3,

• By your modification <form> elements are nested. Standards says this element should be "with no form element descendants".
• On 6.1.x, it was sometimes reported that, with a form including a table having many (20, 30 or so) rows, some of checkboxes were omitted, and not all selected messages were distributed/rejected.

[l4uc3]

Hello,

On 16/12/2017 08:06, IKEDA Soji wrote: Hi @l4uc3 <https://github.com/l4uc3>, * By your modification |<form>| elements are nested. Standards says this element should be "with no form element descendants <https://www.w3.org/TR/2017/REC-html52-20171214/sec-forms.html#the-form-element>".

I was careful not to put a form inside a form. Could you point me inside the code where you see a nested element ?

* On 6.1.x, it was sometimes reported that, with a form including a table having many (20, 30 or so) rows, some of checkboxes were omitted, and not all selected messages were distributed/rejected.

I didn't know. I will test and think of a solution if I see a problem. Was it reproducible ?

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMEvJlOksiyk4I8R-IdIB5Z2zP0L3EJRks5tA2vsgaJpZM4QgLAo>.

[ikedas]

@l4uc3,

I was careful not to put a form inside a form. Could you point me inside
the code where you see a nested element ?

I misunderstood. Indeed <form> are not nested.

But I still concerned: form attribute of <fieldset> element is widely supported? (several contemporary UAs support it, but some UAs not fully HTML5-compliant may not).

• On 6.1.x, it was sometimes reported that, with a form including a
  table having many (20, 30 or so) rows, some of checkboxes were
  omitted, and not all selected messages were distributed/rejected.

I didn't know. I will test and think of a solution if I see a problem.
Was it reproducible ?

I personally could not reproduce, but more than one persons complained.

[ikedas]

PR above seems to be able to avoid problem I pointed out:

• Use of <table> in <form>.
• Separate <fieldset> compliant to HTML5.

[l4uc3]

@ikedas : thanks for your help. I put the new files on our servers.

[ikedas]

Thanks for checking my addition. If no problem is found in a few days, merge commits and close this issue.

[ikedas]

Merged. Thanks again l4uc3.