Best practice forum (Archived)
This forum discussion has been removed
Hi Chris
Just a quick message, the sesskey parameter is used for security. Not sure why it has dissappeared though, it might be because of the session time. I think a quick fix would be to log out and back in again, hopefully that will reset the sesskey.
Cheers, Russ
Hi Chris,
Curiously someone else just reported this exact same bug, so we are already working on a fix!
To explain what happened, there is a server limit on the number of parameters that can be passed through between pages within the site. Because of the way that particular page was coded it was using too many of those parameters so if you tried to add too many people at the same time it would run out and cut some off the end. The sesskey parameter ended up not being passed through, which causes an error as it is required. The solution is to refactor the page so it doesn't need to pass so many parameters.
I'm not sure why this has only just come up, it seems like something we would have discovered ages ago, but there you go!
Anyway, we hope to have a fix soon, in the mean time, you could try grouping some of the users together into an audience and assigning that to the program instead and it should work.
Simon
Have you looked at the relative date options when setting completion dates?
If the hire date is set using a date custom profile field then you can do this:
- Click set completion
- Choose number of days/weeks/months from their hire date
- Select "custom date field" from the pulldown menu
- Pick the custom field that contains their hire date
This way each user will have the same time period from when they were hired.
Simon
On a related note, I put in an enhancement request a while ago for more options on the date options within audience rules.
My suggestion was to add criteria similar to the ones you get on 'position start date' for all date fields. Rather than just being able to pick before or after a fixed date, it would be great to select based on timescale like "before the previous"; "within the previous" etc:
If this was available on completion dates, you could create an audience containing everyone who completed learning more than a x days ago and use that to automatically enrol them a new instance of the course/program.
I don't know if it would help in this exact case, but would definitely be a great feature.
Unless it proves to be particularly difficult it should make it into the next release - so it should be in 2.2.22 (due out 27th August) and 2.4.9 (due out 3rd September).
Simon
Hi Chris,
We did redesign the page to minimise the data that is passed through so if you are still hitting the limits then probably the best thing to do is to increase the server limit.
There is a good article describing what you need to do here:
http://techtalk.virendrachandak.com/big-forms-and-php-max_input_vars/
Simon
Hi Chris,
May be suhosin is limiting the max post variables. You can check this on Site admin->Server->Php info. Search for suhosin.post.max_vars. The default value is 1000.
If this is correct, you can change it to 2000 on suhosin.ini (usualy at /etc/php5/apache2/conf.d/suhosin.ini).
Hope that helps,
André Yamin.
The max_input_vars PHP setting was added in PHP 5.3.9 so it wouldn't work if you were running an older version of PHP - can you confirm if that's the case? If so are you able to upgrade PHP to 5.3.9 or above?
If that's not it, can you please post a screenshot of your phpinfo page?
Simon
Yes, although you set the setting in php.ini, and phpinfo displays the value you set, the actual value set is ignored pre 5.3.8 due to this issue:
https://bugs.php.net/bug.php?id=65778
Simon
Hi Chris,
I'm afraid we can't help with server configuration issues like that. You may need to upgrade SUSE to get a more recent version of PHP.
We will see if there is anything else we can do to further reduce the number of variables being sent by that page.
Simon
Hi Chris,
Attached is a simple PHP form which creates a hidden form with 5000 inputs, then outputs how many actually arrived at the server end. Run it from anywhere on the web server. Just browse to the location of the file and click the button and it should let you know if your server is actually properly configured now and allowing large amounts of data to be sent.
Hi Chris,
On my server, which is running PHP 5.4.9, setting
max_input_vars = 3000
in php.ini and restarting apache works as expected.
If your server is using the Suhosin patch then you probably also need these lines in php.ini immediately after max_input_vars:
suhosin.post.max_vars = 3000
suhosin.request.max_vars = 3000
You also might want to check max_input_vars is not being overridden by any .htaccess files or the apache httpd.conf your server might have. Or that max_input_vars isn't being defined twice in two different places in the php.ini, as most likely the second one will the the one that is accepted!
If none of that works then you'll have to obtain a sysadmin from somewhere - sorry but server configuration issues really aren't covered by the support team here at Totara Core as we are focused on bug fixes and improvements to the actual Totara codebase.
Hi Chris,
As well as running Ciaran's script to see if you server is configured right, you might be able to make use of a new feature we added in 2.5.4. It is now possible to set completion dates relative to the date the user is assigned, so you may now be able to use an audience and "1 year after assignment" as the completion date. This should automatically give all new users in the audience 1 year to complete the program.
Simon