View Issue Details

This bug affects 1 person(s).
 6
IDProjectCategoryView StatusLast Update
10196Bug reportsCentral participant databasepublic2016-02-06 00:35
Reporterttenbergen Assigned Toollehar  
PrioritynormalSeverityminor 
Status closedResolutionfixed 
Product Version2.06+ 
Fixed in Version2.50.x 
Summary10196: Can't share more than 500 participants at a time
Description

I made all my survey coordinators super admins, but they still can't edit each others participants. So, I wanted to share all the 1000+ participants with each of 16 admins. 0 participants are shared

Steps To Reproduce

There are 1158 participants
Set CPDB display to >500
check the "check all" checkbox
click the share button, pick a coordinator
Click "share the selected participants"

For 500 or less I get a message "500 participants have been shared.You can see and edit settings for shared participants in share panel"
For 1000 or more I get a msg "0 participants have been shared.You can see and edit settings for shared participants in share panel."

TagsNo tags attached.
Bug heat6
Complete LimeSurvey version number (& build)Version 2.06+ Build 151215
I will donate to the project if issue is resolvedNo
Browser
Database type & version?
Server OS (if known)?
Webserver software & version (if known)?
PHP Version?

Relationships

related to 10236 closedollehar sharing participants for super admins 

Users monitoring this issue

There are no users monitoring this issue.

Activities

c_schmitz

c_schmitz

2016-01-08 15:54

administrator   ~34251

This is a server setting issue. Your PHP configuration must be able to accept a number of POSTed values that high.

ttenbergen

ttenbergen

2016-01-11 18:37

reporter   ~34263

I have googled this a bit but don't know much about PHP server setup.
Is adding the following what you are suggesting
post_max_size = 5001
max_input_vars = 5001
If so, it doesn't seem to fix the problem.

c_schmitz

c_schmitz

2016-01-22 09:02

administrator   ~34339

Well, it is not a bug of LimeSurvey. Try to check the available memory, maybe it is too low.

ttenbergen

ttenbergen

2016-01-22 22:09

reporter   ~34366

Hi Carsten,
Isn't unintended behavior without explanation is a bug? If it comes with some explanation, even as little as "bad configuration", then maybe not, but without any explanation, it's a bug. Or how do you define bug?

"free" at the console gives me
total used free shared buffers cached
Mem: 1024000 500952 523048 0 0 408616
-/+ buffers/cache: 92336 931664
Swap: 0 0 0

Is that too low?

ttenbergen

ttenbergen

2016-02-03 18:42

reporter   ~34553

I am now using the following:
memory_limit = 128M
post_max_size = 64M
max_execution_time = 500
max_input_time = 500
Still having the same problem. What settings should I use?

ollehar

ollehar

2016-02-04 10:45

administrator   ~34563

Hi ttenbergen. I'll have a look at this. The root of the problem is that admins can't edit each others participants, right?

ttenbergen

ttenbergen

2016-02-04 16:54

reporter   ~34574

That's the root, yes. For me. It goes a step further in its bugginess, though, because it looks like you are changing e.g. emails or attributes, but the edits don't stick.

But fundamentally, if you can't assign rights for more than 500 at a time that will still be a bug for anyone trying to use user rights on CPDB.

Thanks for having a look Olle!

ollehar

ollehar

2016-02-04 17:27

administrator   ~34579

Thanks for your info. I'll try to fix the root problem first.

ollehar

ollehar

2016-02-04 17:52

administrator   ~34583

If you make users superadmin AND share the CPDB participants with everyone, then everyone can edit.

ttenbergen

ttenbergen

2016-02-04 18:12

reporter   ~34584

You are correct. Yet right now, sharing all participants is painful because I can only do it 500 at a time. We have ~1100 so I need to do it in three steps for each user. And every few weeks I have to do it again because new participants are added that non-owning users don't have rights to. So, yes, I have an awkward work-around, but it keeps leading to support calls.
Doesn't help that you can't share a participant with yourself, even as a super user, so I can't even give instructions to my superusers how to do this themselves.

c_schmitz

c_schmitz

2016-02-04 19:36

administrator   ~34592

We will change it for 2.50 so superadmin can see everyones participants.
Superadmins should have no limitation in general.

c_schmitz

c_schmitz

2016-02-04 19:38

administrator   ~34593

BTW; memory_limit is a bit low - also have a look at this page

https://manual.limesurvey.org/Troubleshooting#After_submitting_a_page_with_big_number_questions.2Fanswer_options.2Fsubquestions_they_are_not_saved

Probably max_input_vars needs to be raised.

ttenbergen

ttenbergen

2016-02-04 23:28

reporter   ~34605

OK, there were extra variables in there that did the trick. I now use the following, and was able to share all 1150 participants in one go. Likely not all were necessary, but won't mess with that system now it works. Thanks Carsten!
memory_limit = 128M
max_value_length = 5000000
max_vars = 5000
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 500
max_input_time = 500
max_input_vars = 5000

ttenbergen

ttenbergen

2016-02-04 23:29

reporter   ~34606

Suggestion: would it be worth putting a test for that into the install script?

ollehar

ollehar

2016-02-05 11:05

administrator   ~34623

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=17164

ollehar

ollehar

2016-02-05 11:08

administrator   ~34624

Fixed by letting superadmins edit participants without sharing.

c_schmitz

c_schmitz

2016-02-06 00:35

administrator   ~34655

2.50+ Build 160206 released

Related Changesets

LimeSurvey: master 433252f5

2016-02-05 10:05:08

ollehar

Details Diff
Fixed issue 10196: Superadmins should be able to edit participants without sharing Affected Issues
10196
mod - application/models/Participant.php Diff File

Issue History

Date Modified Username Field Change
2016-01-04 23:02 ttenbergen New Issue
2016-01-08 15:54 c_schmitz Note Added: 34251
2016-01-11 18:37 ttenbergen Note Added: 34263
2016-01-22 09:02 c_schmitz Note Added: 34339
2016-01-22 09:02 c_schmitz Status new => closed
2016-01-22 09:02 c_schmitz Assigned To => c_schmitz
2016-01-22 09:02 c_schmitz Resolution open => unable to reproduce
2016-01-22 14:53 ollehar Assigned To c_schmitz => ollehar
2016-01-22 14:53 ollehar Status closed => feedback
2016-01-22 14:53 ollehar Resolution unable to reproduce => reopened
2016-01-22 14:53 ollehar Status feedback => acknowledged
2016-01-22 15:13 ollehar Status acknowledged => assigned
2016-01-22 22:09 ttenbergen Note Added: 34366
2016-02-03 18:42 ttenbergen Note Added: 34553
2016-02-04 10:45 ollehar Note Added: 34563
2016-02-04 16:54 ttenbergen Note Added: 34574
2016-02-04 17:27 ollehar Note Added: 34579
2016-02-04 17:52 ollehar Note Added: 34583
2016-02-04 18:12 ttenbergen Note Added: 34584
2016-02-04 19:36 c_schmitz Note Added: 34592
2016-02-04 19:38 c_schmitz Note Added: 34593
2016-02-04 20:33 c_schmitz Relationship added related to 10236
2016-02-04 23:28 ttenbergen Note Added: 34605
2016-02-04 23:29 ttenbergen Note Added: 34606
2016-02-05 11:05 ollehar Changeset attached => LimeSurvey master 433252f5
2016-02-05 11:05 ollehar Note Added: 34623
2016-02-05 11:08 ollehar Note Added: 34624
2016-02-05 11:08 ollehar Status assigned => resolved
2016-02-05 11:08 ollehar Fixed in Version => 2.5
2016-02-05 11:08 ollehar Resolution reopened => fixed
2016-02-06 00:35 c_schmitz Note Added: 34655
2016-02-06 00:35 c_schmitz Status resolved => closed