Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-41819

Grades lost when editing in the grader report due to max_input_vars

    Details

    • Testing Instructions:
      Hide

      Note: this requires some recent PHP, not 5.3.3.

      1/ set max_input_vars = 20 in your php.ini and restart apache
      2/ create course and enrol a few students (min 5)
      3/ go to gradebook and create some manual grade items
      4/ try to edit grades on grader report
      5/ you should get notice (if debug on - or read error log), but the saving should still work for all grades (especially at the end of the form)
      6/ verify the students per page preference works on grader report
      7/ repeat with backup and restore of course (course should have more than 20 activities)

      PS Do not forget to reset max_input_vars to default 1000 or unlimited after the test or you will start noticing critical bugs in moodle behaviour and create issues like I did ( – Marina )

      Show
      Note: this requires some recent PHP, not 5.3.3. 1/ set max_input_vars = 20 in your php.ini and restart apache 2/ create course and enrol a few students (min 5) 3/ go to gradebook and create some manual grade items 4/ try to edit grades on grader report 5/ you should get notice (if debug on - or read error log), but the saving should still work for all grades (especially at the end of the form) 6/ verify the students per page preference works on grader report 7/ repeat with backup and restore of course (course should have more than 20 activities) PS Do not forget to reset max_input_vars to default 1000 or unlimited after the test or you will start noticing critical bugs in moodle behaviour and create issues like I did ( – Marina )
    • Workaround:
      Hide

      set appropriate max_input_vars in your php.ini

      Show
      set appropriate max_input_vars in your php.ini
    • Affected Branches:
      MOODLE_24_STABLE, MOODLE_25_STABLE
    • Fixed Branches:
      MOODLE_24_STABLE, MOODLE_25_STABLE, MOODLE_26_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      w48_MDL-41819_m27_maxinputvars
    • Sprint:
      BACKEND Sprint 7
    • Story Points (Obsolete):
      40
    • Sprint:
      BACKEND Sprint 7

      Description

      I have a number of manual grade items used to track offline assignments. Recently I've found with the latest moodle version that the last 4-7 students in the grader report do not have their entered grades saved. This seems to be something related to sort - if I sort by their first names and enter the grades again, they are saved properly. If I reverse sort last names, grades are saved properly as well.

      Procedure:

      1. Create a new manual grade item named "Pop Quiz 1 - Neural & Hormonal Lecture"
      2. Have a class of approximately 27 students.
      3. Enter grades using the Grader Report with editing turned on.
      4. Hit update.

      I've noticed that this does not happen when AJAX grading is turned on & working (i.e. the cells are changing color).

      This happens both in Google Chrome (with a variety of extensions) and Safari (with no extensions), on a Mac running Mountain Lion.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            jonwestfall Jon Westfall added a comment -

            Resolved by increasing max input vars in php.ini to 20000 from 1000 default.

            Show
            jonwestfall Jon Westfall added a comment - Resolved by increasing max input vars in php.ini to 20000 from 1000 default.
            Hide
            timhunt Tim Hunt added a comment -

            Here is the history of this issue:

            1. In PHP 5.3.9, they introduced the max_input vars limit, to avoid a particular hacking attack.

            2. This cased the symptoms described here for the first time. This lead to MDL-26275, in which Andrew Davis made it automatically reduced to number of rows shown in the gradebook to ensure we did not exceed the limit. That displayed a message like "Reduced maximum students per page from {$a->originalstudentsperpage} to {$a->studentsperpage}. Consider increasing the PHP setting max_input_vars from {$a->maxinputvars}."

            3. Then in MDL-35074, Paul Nicholls found a cleverer way to work within the limit, which meant that we could show more rows in the gradebook without exceeding the limit.

            4. Then, in PHP 5.4 they changed how the limit was implemented, so that the work-around done in MDL-35074 no longer works, and we have this problem again.

            5. In MDL-41451, for formslib forms, but not for the gradebook, Paul Nicholls did a much cleverer work-around to get around the limit.

            Our choices now seem to be either:

            A. Do a fix like MDL-41451 in the grader report. Hard, but should be possible.

            B. Go back to the situation in Step 2. in the case where we detect we are running PHP 5.4.

            Opinions welcome. I can probably do B. I probably cannot do A., but if someone else could, that would be the best solution.

            Show
            timhunt Tim Hunt added a comment - Here is the history of this issue: 1. In PHP 5.3.9, they introduced the max_input vars limit, to avoid a particular hacking attack. 2. This cased the symptoms described here for the first time. This lead to MDL-26275 , in which Andrew Davis made it automatically reduced to number of rows shown in the gradebook to ensure we did not exceed the limit. That displayed a message like "Reduced maximum students per page from {$a->originalstudentsperpage} to {$a->studentsperpage}. Consider increasing the PHP setting max_input_vars from {$a->maxinputvars}." 3. Then in MDL-35074 , Paul Nicholls found a cleverer way to work within the limit, which meant that we could show more rows in the gradebook without exceeding the limit. 4. Then, in PHP 5.4 they changed how the limit was implemented, so that the work-around done in MDL-35074 no longer works, and we have this problem again. 5. In MDL-41451 , for formslib forms, but not for the gradebook, Paul Nicholls did a much cleverer work-around to get around the limit. Our choices now seem to be either: A. Do a fix like MDL-41451 in the grader report. Hard, but should be possible. B. Go back to the situation in Step 2. in the case where we detect we are running PHP 5.4. Opinions welcome. I can probably do B. I probably cannot do A., but if someone else could, that would be the best solution.
            Hide
            skodak Petr Skoda added a comment -

            Forgive my ignorance, but why not simply ask admins to increase value in php.ini?

            Show
            skodak Petr Skoda added a comment - Forgive my ignorance, but why not simply ask admins to increase value in php.ini?
            Hide
            timhunt Tim Hunt added a comment -

            Because if that is all you do, you have to ask every Moodle admin everywhere in the whole world. And some of those admins are using shared hosting where they are not allowed to change that setting.

            Show
            timhunt Tim Hunt added a comment - Because if that is all you do, you have to ask every Moodle admin everywhere in the whole world. And some of those admins are using shared hosting where they are not allowed to change that setting.
            Hide
            skodak Petr Skoda added a comment -

            Sorry, but your logic is weird, the change of php.ini is the only real safe solution of this problem. The PHP developers introduced the setting so that admins may set it based on the needs of software running on their servers. I think the first step should be to add warning to environment test because it would solve it for everybody who can modify their php.ini, now they simply do not know and things fail...

            Show
            skodak Petr Skoda added a comment - Sorry, but your logic is weird, the change of php.ini is the only real safe solution of this problem. The PHP developers introduced the setting so that admins may set it based on the needs of software running on their servers. I think the first step should be to add warning to environment test because it would solve it for everybody who can modify their php.ini, now they simply do not know and things fail...
            Hide
            paul.n Paul Nicholls added a comment -

            Will pull the function written in MDL-41451 out into weblib.php so that it can be used by data_submitted() as well as formslib.

            Show
            paul.n Paul Nicholls added a comment - Will pull the function written in MDL-41451 out into weblib.php so that it can be used by data_submitted() as well as formslib.
            Hide
            timhunt Tim Hunt added a comment -

            Great. Thanks Paul.

            I have just thought of a Plan C.

            C. Get rid of the old editing interface, and only allow ajax editing of the gradebook.

            That is probably the best long-term plan. The way it works at the moment is not great. If two different teachers open the gradebook, turn editing on, and just alter one grade and then save, then you have a classic race condition. One teacher's save will overwrite the other. Just sending back one edited grade at a time is much safer.

            Show
            timhunt Tim Hunt added a comment - Great. Thanks Paul. I have just thought of a Plan C. C. Get rid of the old editing interface, and only allow ajax editing of the gradebook. That is probably the best long-term plan. The way it works at the moment is not great. If two different teachers open the gradebook, turn editing on, and just alter one grade and then save, then you have a classic race condition. One teacher's save will overwrite the other. Just sending back one edited grade at a time is much safer.
            Hide
            paul.n Paul Nicholls added a comment -

            Requesting peer review - branches for 2.4, 2.5 and master supplied (same as for MDL-41451). I also had to add a second function which recursively merges arrays whilst preserving numerical indices, as the grader report uses actual IDs as indices; array_merge_recursive() will switch to sequential numbers as soon as it hits an index lower than the previous one.

            Show
            paul.n Paul Nicholls added a comment - Requesting peer review - branches for 2.4, 2.5 and master supplied (same as for MDL-41451 ). I also had to add a second function which recursively merges arrays whilst preserving numerical indices, as the grader report uses actual IDs as indices; array_merge_recursive() will switch to sequential numbers as soon as it hits an index lower than the previous one.
            Hide
            paul.n Paul Nicholls added a comment -

            Tim, I like the sound of option C - all interfaces in Moodle which currently generate large/long forms ought to be replaced with ones which don't (i.e. grader report, backup/restore). In the short term, though, option A seems like the best option to me (hence the patch I just put up for peer review).

            Petr, one of the problems with instructing people to increase max_input_vars is that there isn't one right value for it. There are several different ways in which the limit can currently be reached, too - so it's not even straightforward to suggest a few different values based on some characteristic of your environment (number of courses, number of students, etc). Not having to bother people with it at all seems like a nicer solution than "you need to change this setting, but we can't tell you how high you'll need to set it" or some complex set of rules to determine a value which will hopefully be sufficient for your situation.

            Show
            paul.n Paul Nicholls added a comment - Tim, I like the sound of option C - all interfaces in Moodle which currently generate large/long forms ought to be replaced with ones which don't (i.e. grader report, backup/restore). In the short term, though, option A seems like the best option to me (hence the patch I just put up for peer review). Petr, one of the problems with instructing people to increase max_input_vars is that there isn't one right value for it. There are several different ways in which the limit can currently be reached, too - so it's not even straightforward to suggest a few different values based on some characteristic of your environment (number of courses, number of students, etc). Not having to bother people with it at all seems like a nicer solution than "you need to change this setting, but we can't tell you how high you'll need to set it" or some complex set of rules to determine a value which will hopefully be sufficient for your situation.
            Hide
            skodak Petr Skoda added a comment - - edited

            The patch is unacceptable, it creates regressions and nasty security issues. You cannot sidestep $_POST in the middle of page processing, sorry.

            Few examples:

            • magic quotes hack is completely ignored
            • optional_param() and friends get out of sync with forms and data_submitted() - huge security hole because our param validation depends on them being in sync

            Let me propose a different solution:
            1/ Move the hack into lib/setup.php and instead put the missing values into $_POST, $_GET and $_REQUEST.
            2/ Log all oversized requests just in case so that admins know they should ideally increase the max_input_vars.
            3/ The current _get_post_params() hack in forms needs to be reverted.
            4/ I still think some large enough minimal max_input_vars should be mentioned on our environment page - the workaround looks like a performance issue to me.
            5/ Somebody must do proper security analysis of using file_get_contents("php://input") hack - working around security "fixes" in PHP often leads to even bigger holes... (the hack smells, there does not seem to be any validation or sanity checks in there)

            Show
            skodak Petr Skoda added a comment - - edited The patch is unacceptable, it creates regressions and nasty security issues. You cannot sidestep $_POST in the middle of page processing, sorry. Few examples: magic quotes hack is completely ignored optional_param() and friends get out of sync with forms and data_submitted() - huge security hole because our param validation depends on them being in sync Let me propose a different solution: 1/ Move the hack into lib/setup.php and instead put the missing values into $_POST, $_GET and $_REQUEST. 2/ Log all oversized requests just in case so that admins know they should ideally increase the max_input_vars. 3/ The current _get_post_params() hack in forms needs to be reverted. 4/ I still think some large enough minimal max_input_vars should be mentioned on our environment page - the workaround looks like a performance issue to me. 5/ Somebody must do proper security analysis of using file_get_contents("php://input") hack - working around security "fixes" in PHP often leads to even bigger holes... (the hack smells, there does not seem to be any validation or sanity checks in there)
            Hide
            skodak Petr Skoda added a comment -

            ohoho, the php://input parsing seems to be producing invalid data that does not match the original _POST request submitted from browser, I hope I am wrong...

            Show
            skodak Petr Skoda added a comment - ohoho, the php://input parsing seems to be producing invalid data that does not match the original _POST request submitted from browser, I hope I am wrong...
            Hide
            skodak Petr Skoda added a comment -

            right, array_merge_recursive() completely borks array parameters such as those found on the grader report, we need a custom merging function there...

            Show
            skodak Petr Skoda added a comment - right, array_merge_recursive() completely borks array parameters such as those found on the grader report, we need a custom merging function there...
            Show
            skodak Petr Skoda added a comment - here is my take: https://github.com/skodak/moodle/compare/master...w44_MDL-41819_m26_maxinputvars
            Hide
            paul.n Paul Nicholls added a comment -

            Thanks, Petr. I'm not familiar with all the intricacies of how Moodle handles forms, so it's good to have your input (and obviously would've been good to have it in MDL-41451). As for array_merge_recursive, yes, I discovered that in the course of working on this ticket (as per my earlier comment) and similarly wrote a function to merge while preserving numeric indices.

            Your patch looks good for the most part - but your change to get_students_per_page() should result in the method body being return $this->get_pref('studentsperpage'); rather than $studentsperpage = $this->get_pref('studentsperpage'); - as it stands, the limit gets completely ignored, which made my test auto-generated "large" course eat huge amounts of RAM building a grader report for all 10,000 students!

            Show
            paul.n Paul Nicholls added a comment - Thanks, Petr. I'm not familiar with all the intricacies of how Moodle handles forms, so it's good to have your input (and obviously would've been good to have it in MDL-41451 ). As for array_merge_recursive, yes, I discovered that in the course of working on this ticket (as per my earlier comment ) and similarly wrote a function to merge while preserving numeric indices. Your patch looks good for the most part - but your change to get_students_per_page() should result in the method body being return $this->get_pref('studentsperpage'); rather than $studentsperpage = $this->get_pref('studentsperpage'); - as it stands, the limit gets completely ignored, which made my test auto-generated "large" course eat huge amounts of RAM building a grader report for all 10,000 students!
            Hide
            skodak Petr Skoda added a comment -

            thanks! I have fixed the return, I will try to get this through master integration asap and we can consider backport after a few weeks.

            Show
            skodak Petr Skoda added a comment - thanks! I have fixed the return, I will try to get this through master integration asap and we can consider backport after a few weeks.
            Hide
            skodak Petr Skoda added a comment -

            please shout if you find any problems or better solution, ciao

            Show
            skodak Petr Skoda added a comment - please shout if you find any problems or better solution, ciao
            Hide
            paul.n Paul Nicholls added a comment -

            That's better, now I can actually use the Grader report

            All looks good to me now.

            Show
            paul.n Paul Nicholls added a comment - That's better, now I can actually use the Grader report All looks good to me now.
            Hide
            poltawski Dan Poltawski added a comment -

            Seems like this should be backported?

            Show
            poltawski Dan Poltawski added a comment - Seems like this should be backported?
            Hide
            damyon Damyon Wiese added a comment -

            +1 for backport - or one of the other options implemented for stables if you are not comfortable with a backport. Silently losing grades is a major bug that needs fixing on stables.

            Show
            damyon Damyon Wiese added a comment - +1 for backport - or one of the other options implemented for stables if you are not comfortable with a backport. Silently losing grades is a major bug that needs fixing on stables.
            Hide
            poltawski Dan Poltawski added a comment -

            The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

            TIA and ciao

            Show
            poltawski Dan Poltawski added a comment - The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week. TIA and ciao
            Hide
            skodak Petr Skoda added a comment -

            Please create separate backport if necessary, we need to test this on more servers and new major release is ideal for this...

            Show
            skodak Petr Skoda added a comment - Please create separate backport if necessary, we need to test this on more servers and new major release is ideal for this...
            Hide
            marina Marina Glancy added a comment -

            Hi Petr,
            this looks very good. I agree there should be separate issue for backporting, we will create it when this one is integrated.

            Can you please not remove protected function _get_post_params() completely but follow the usual process of deprecation? Since it is protected it could be used in 3rd party plugins extending moodleform. And it should be mentioned in upgrade.txt

            I will run all automated tests before integrating this.

            Show
            marina Marina Glancy added a comment - Hi Petr, this looks very good. I agree there should be separate issue for backporting, we will create it when this one is integrated. Can you please not remove protected function _get_post_params() completely but follow the usual process of deprecation? Since it is protected it could be used in 3rd party plugins extending moodleform. And it should be mentioned in upgrade.txt I will run all automated tests before integrating this.
            Hide
            skodak Petr Skoda added a comment -

            Done, the method is back in new commit and everything rebased on top of integration.

            Show
            skodak Petr Skoda added a comment - Done, the method is back in new commit and everything rebased on top of integration.
            Hide
            marina Marina Glancy added a comment - - edited

            Hi Petr, I have some doubts about your merge_query_params() function

            Test:

             
                public function test_merge_query_params2() {
                    $str = 'key[]=value1&key[]=value2&key[]=value3&key[]=value4&key[]=value5&key[]=value6&key[]=value7&key[]=value8';
                    
                    $array1 = array();
                    parse_str($str, $array1);
                    
                    $max = 3;
                    $delim = '&';
                    $fun = create_function('$p', 'return implode("'.$delim.'", $p);');
                    $chunks = array_map($fun, array_chunk(explode($delim, $str), $max));
             
                    $array2 = array();
                    foreach ($chunks as $chunk) {
                        $values = array();
                        parse_str($chunk, $values);
                        merge_query_params($array2, $values);
                    }
                    
                    $this->assertSame($array1, $array2);
                }
            

            Result:

            There was 1 failure:
             
            1) core_setuplib_testcase::test_merge_query_params2
            Failed asserting that Array (
                'key' => Array (
                    0 => 'value7'
                    1 => 'value8'
                    2 => 'value6'
                )
            ) is identical to Array (
                'key' => Array (
                    0 => 'value1'
                    1 => 'value2'
                    2 => 'value3'
                    3 => 'value4'
                    4 => 'value5'
                    5 => 'value6'
                    6 => 'value7'
                    7 => 'value8'
                )
            ).
            

            Show
            marina Marina Glancy added a comment - - edited Hi Petr, I have some doubts about your merge_query_params() function Test:   public function test_merge_query_params2() { $str = 'key[]=value1&key[]=value2&key[]=value3&key[]=value4&key[]=value5&key[]=value6&key[]=value7&key[]=value8'; $array1 = array(); parse_str($str, $array1); $max = 3; $delim = '&'; $fun = create_function('$p', 'return implode("'.$delim.'", $p);'); $chunks = array_map($fun, array_chunk(explode($delim, $str), $max));   $array2 = array(); foreach ($chunks as $chunk) { $values = array(); parse_str($chunk, $values); merge_query_params($array2, $values); } $this->assertSame($array1, $array2); } Result: There was 1 failure:   1) core_setuplib_testcase::test_merge_query_params2 Failed asserting that Array ( 'key' => Array ( 0 => 'value7' 1 => 'value8' 2 => 'value6' ) ) is identical to Array ( 'key' => Array ( 0 => 'value1' 1 => 'value2' 2 => 'value3' 3 => 'value4' 4 => 'value5' 5 => 'value6' 6 => 'value7' 7 => 'value8' ) ).
            Hide
            skodak Petr Skoda added a comment -

            oh, right, I need to spend a lot more time on this, please reopen

            Show
            skodak Petr Skoda added a comment - oh, right, I need to spend a lot more time on this, please reopen
            Hide
            marina Marina Glancy added a comment -

            Reopening as requested

            Show
            marina Marina Glancy added a comment - Reopening as requested
            Hide
            cibot CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            cibot CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            skodak Petr Skoda added a comment -

            Arrggh, it looks like it is impossible to merge the arrays if you split the string with nested []. I am afraid we either need to drop this or implement custom parse_str() instead.

            Show
            skodak Petr Skoda added a comment - Arrggh, it looks like it is impossible to merge the arrays if you split the string with nested []. I am afraid we either need to drop this or implement custom parse_str() instead.
            Hide
            marina Marina Glancy added a comment - - edited

            Hi Petr, this looks good.
            It would not process correctly odd cases like a[]=b1&b[3]=b2 but I hope nobody uses things like that.
            Do you think we can add the enctype="application/x-www-form-urlencoded" to restore/backup forms, they may have lots of elements too?

            Show
            marina Marina Glancy added a comment - - edited Hi Petr, this looks good. It would not process correctly odd cases like a[]=b1&b [3] =b2 but I hope nobody uses things like that. Do you think we can add the enctype="application/x-www-form-urlencoded" to restore/backup forms, they may have lots of elements too?
            Hide
            skodak Petr Skoda added a comment -

            sure, I will look at the backup/restore code and add those tweaks if necessary

            Show
            skodak Petr Skoda added a comment - sure, I will look at the backup/restore code and add those tweaks if necessary
            Hide
            skodak Petr Skoda added a comment -

            updated, submitting for integration

            to integrators: I have not created a backport branch intentionally, feel free to create a backport request for 2.5

            Show
            skodak Petr Skoda added a comment - updated, submitting for integration to integrators: I have not created a backport branch intentionally, feel free to create a backport request for 2.5
            Hide
            timhunt Tim Hunt added a comment -

            The OU is on 2.5 until next June, and we are being hit by this. Backport would be greatly appreciated, but I guess it is best to wait for it to prove itself in master before we backport. (For now we just raised max_input_vars for that one script.)

            Show
            timhunt Tim Hunt added a comment - The OU is on 2.5 until next June, and we are being hit by this. Backport would be greatly appreciated, but I guess it is best to wait for it to prove itself in master before we backport. (For now we just raised max_input_vars for that one script.)
            Hide
            marina Marina Glancy added a comment -

            Thanks Petr.

            I would vote for backporting noting that:
            1. Forms with number of elements less than max_input_vars are not affected by this patch at all.
            2. Forms without enctype="application/x-www-form-urlencoded" are not affected.

            But still we should better wait for a month before backporting.

            Show
            marina Marina Glancy added a comment - Thanks Petr. I would vote for backporting noting that: 1. Forms with number of elements less than max_input_vars are not affected by this patch at all. 2. Forms without enctype="application/x-www-form-urlencoded" are not affected. But still we should better wait for a month before backporting.
            Hide
            poltawski Dan Poltawski added a comment -

            Petr, this is a bug and we've said 3 times that we want this back porting. If its going into 2.6, it should go in the other stable branches too. Please can you provide branches for 2.4 and 2.5?

            Show
            poltawski Dan Poltawski added a comment - Petr, this is a bug and we've said 3 times that we want this back porting. If its going into 2.6, it should go in the other stable branches too. Please can you provide branches for 2.4 and 2.5?
            Hide
            skodak Petr Skoda added a comment -

            Dan: This is a bug in PHP design or server configuration. This change does not fix it for all forms, it is just a nasty workaround.

            I will not provide changes for older stable branches right now, sorry.

            Show
            skodak Petr Skoda added a comment - Dan: This is a bug in PHP design or server configuration. This change does not fix it for all forms, it is just a nasty workaround. I will not provide changes for older stable branches right now, sorry.
            Hide
            poltawski Dan Poltawski added a comment -

            There are two options to proceed with this:

            1/ This lands master only (when master is unfrozen)
            2/ This lands on all supported branches

            Landing on one stable branch and not the others is not an option - 26_STABLE is STABLE

            Show
            poltawski Dan Poltawski added a comment - There are two options to proceed with this: 1/ This lands master only (when master is unfrozen) 2/ This lands on all supported branches Landing on one stable branch and not the others is not an option - 26_STABLE is STABLE
            Hide
            cibot CiBoT added a comment -

            Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

            Show
            cibot CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Petr, your branches are not available presently, could you please push them up.

            Cheers
            Sam

            Show
            samhemelryk Sam Hemelryk added a comment - Petr, your branches are not available presently, could you please push them up. Cheers Sam
            Hide
            skodak Petr Skoda added a comment -

            oops, fixed

            Show
            skodak Petr Skoda added a comment - oops, fixed
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Thanks Petr - this has been integrated now.

            Show
            samhemelryk Sam Hemelryk added a comment - Thanks Petr - this has been integrated now.
            Hide
            markn Mark Nelson added a comment -

            Thanks Petr, works as expected.

            Show
            markn Mark Nelson added a comment - Thanks Petr, works as expected.
            Hide
            poltawski Dan Poltawski added a comment -

            Thanks for your contributions, this change is now upstream!

            “ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” - Edsger Dijkstra

            Show
            poltawski Dan Poltawski added a comment - Thanks for your contributions, this change is now upstream! “ If debugging is the process of removing software bugs, then programming must be the process of putting them in. ” - Edsger Dijkstra

              People

              • Votes:
                2 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  13/Jan/14

                  Agile