But, just use the grid view filter instead?

There are 2 lack of option actually

• The "Add particpant to survey" is here only for 'checked' participant
• We can only do filter on attribute show in list and simple AND filt

Before

"Add participant" allow to whole partcipant 'filtered' not only 'checked' : even if you show 10 partcipant : you can transfert 1000 of them

We have attribute not shown in "table" but shown in "advanced filter".

Actually :! must work with external tools to do same thing.

Sincerely : you CAN not

• Assign 1000 participant in one click
• Filter with "not shown" attribute in table

1. Display 1000 rows in grid view
2. Filter
3. Mark all
4. Use massive action to add all marked to survey

No?

But yes, there's only AND-filtering, no OR-filtering.

And 5000 ?
And 10000 ?
And 100000 ?

1000 : a lot more long time to show.

I test it in real situation.

The partcipant DB come from another tool, some column are hidden in table : then can not be filtered.

In real situation : i go on phpMyAdmin to filter/export import hacked CSV

OR/AND : yes, but it's not major: can do it in 2/3 step.

1000 : you can not show 1000 partcipant (in 2.55.0 version) only 100
With 100 : you have javascript time alert.
And 9 second to take it

See Real-situation-2.55.png

If I remember well, Markus unactivate the JavaScript when the number of participants shown are up to a certain amount. So the problem should be fixed.
Markus, can you confirm please?

Yep it the case:
https://bugs.limesurvey.org/view.php?id=11971

So we can close this bug report, right?

@LouisGac: you don't read the bug report:

Please compare the 2.50 CPDB feature and the new one. The actual fix are only a workaround.

1: apply a filter to the list : 250_1.png : complex filter, filter on hidden columns etc ....
2: Send the filtered participant to a survey even if there are 10000 filtered partcipant : in 2.50 : if no line are checked : then we allow to send all user (filtered by actual filter) in another survey : 250_2.png The Add all (number) participant in you current list ....

No : can not close ..... 2 previous feature are lost ....

I worked on this bug, there's a branch for it: cpdb_filter. Sadly I got interrupted, did not have time to finish it yet.

I compared the features, and they are logically equivalent.

No need to spend too much time on it. The only problem is the 'OR' statement, and has you told it yourself, it's just about doing multiple requests instead of one. Maybe also the operator 'not contains', but it should not be necessary if the users are created with a strong logic.

So basically: if it's possible to show an unlimited number of users in the list without causing the javascript crash, the problem is fixed.

logically equivalent : you kidding ?

Usage : 100 columns + more than 100 000 participant.
with 2.50 : less than 1 minutes to filter and move 10 000 participant
with 2.58 : show needed column, filter 1000 by 1000 (else time issue (not by js, by server)) : more than 10 minutes

ANd if it's equivlent : why 2 other user's post a feature/bug report ?

logically equivalent: for the operators (>, =, <). Like I said, the only missing operator is "not contains" and "or".

10 minutes to show 1000 entries: wow.That's a problem. I didn't wrote the model for that part, it's probably possible to get it working faster.

Also, I remember that jQgrid was having a huge speed problems. Eg: in survey list, when having a lot of surveys, it took a very long time to load.

There are some nested queries within queries to fetch active surveys for each participant. It could be lazily loaded instead, I guess. I thought about that.

ok I see.

Maybe it would be easier to do as denis suggested, to provide a way to export all the users corresponding to the current filter without selecting them (it's just about relaunching the query without limit)... but: I bet it would take the very same time to export them than to show them.

My solution was to let the massive action button show "Filtered" instead of "Selected" when nothing is selected.

yep good idea. But I bet it would take the very same time to export them than to show them (and could crash in the middle of the request because of time limit of the script)

See https://bugs.limesurvey.org/view.php?id=12218

Move partcipant id only or display whole participant information are really different in memory.

https://demo.andmemasin.eu/yii1-querybuilder/ :)

This version of LimeSurvey is not longer supported. Please check so that the issue is fixed in a more recent version of LimeSurvey. If it's not, please reopen this bug report. Thank you.

It still not fixed.

2.6lts filter system din't work in any 3 and up versin