Moodle
  1. Moodle
  2. MDL-36204

moodle1 backup converter doesn't handle files with names containing spaces

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.8, 2.2.5, 2.3.2
    • Fix Version/s: 2.2.7, 2.3.4
    • Component/s: Backup
    • Labels:
    • Testing Instructions:
      Hide

      Restore the attached 1.9 backup (backup-mdl-36204-20121026-1201.zip) as a new course.
      Click both "This one" links in the label in the first section, and confirm that both files open correctly (i.e. neither of them results in the "Sorry, the requested file could not be found" message).

      Show
      Restore the attached 1.9 backup (backup-mdl-36204-20121026-1201.zip) as a new course. Click both "This one" links in the label in the first section, and confirm that both files open correctly (i.e. neither of them results in the "Sorry, the requested file could not be found" message).
    • Affected Branches:
      MOODLE_21_STABLE, MOODLE_22_STABLE, MOODLE_23_STABLE
    • Fixed Branches:
      MOODLE_22_STABLE, MOODLE_23_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-36204_master
    • Rank:
      44984

      Description

      Neither the find_referenced_files function nor the migrate_referenced_files function bothers to urldecode the file paths that they work with, so file with names containing spaces (or any other character that gets urlencoded) won't be handled properly (the file won't make it into the correct file area, so the link just won't work).

        Activity

        Hide
        Michael de Raadt added a comment -

        Thanks for spotting that and taking on the job.

        Show
        Michael de Raadt added a comment - Thanks for spotting that and taking on the job.
        Hide
        Paul Nicholls added a comment -

        Added patches, test backup and testing instructions.

        Show
        Paul Nicholls added a comment - Added patches, test backup and testing instructions.
        Hide
        David Mudrak added a comment -

        Hi Paul, and thanks for the patch! We did not realize this before as Moodle 1.x does not let you upload a file containing spaces by default. However, it is pretty easy to get such a file into course files in 1.x - for example by unzipping a zip with that file.

        So yes, this makes perfect sense. Well spotted!

        Show
        David Mudrak added a comment - Hi Paul, and thanks for the patch! We did not realize this before as Moodle 1.x does not let you upload a file containing spaces by default. However, it is pretty easy to get such a file into course files in 1.x - for example by unzipping a zip with that file. So yes, this makes perfect sense. Well spotted!
        Hide
        David Mudrak added a comment -

        Paul, let me suggest to add a unit test for this bug to your branches yet. Please see backup/converter/moodle1/tests/lib_test.php. There is a test method test_referenced_course_files(). What about adding a new one like test_referenced_files_urlencoded() that would explicitly test the behaviour of moodle1_converter::find_referenced_files().

        Please note that for master and 2.3, we use PHPUnit (http://docs.moodle.org/dev/PHPUnit) and for previous versions, there is SimpleTest.

        Show
        David Mudrak added a comment - Paul, let me suggest to add a unit test for this bug to your branches yet. Please see backup/converter/moodle1/tests/lib_test.php. There is a test method test_referenced_course_files(). What about adding a new one like test_referenced_files_urlencoded() that would explicitly test the behaviour of moodle1_converter::find_referenced_files(). Please note that for master and 2.3, we use PHPUnit ( http://docs.moodle.org/dev/PHPUnit ) and for previous versions, there is SimpleTest.
        Hide
        Paul Nicholls added a comment -

        Hi David,
        I've rebased all the branches (since they were a few weeks old now), and added a unit test to each. I haven't written any Moodle unit tests before, so please enlighten me if I've done anything wrong.

        -Paul

        Show
        Paul Nicholls added a comment - Hi David, I've rebased all the branches (since they were a few weeks old now), and added a unit test to each. I haven't written any Moodle unit tests before, so please enlighten me if I've done anything wrong. -Paul
        Hide
        David Mudrak added a comment -

        Yay! The unit tests look exactly as I would write them (not that it means anything). Thanks a lot for the patches Paul! I'm now passing them to the integration team.

        Show
        David Mudrak added a comment - Yay! The unit tests look exactly as I would write them (not that it means anything). Thanks a lot for the patches Paul! I'm now passing them to the integration team.
        Hide
        Dan Poltawski added a comment -

        Thanks Paul - Great to see the unit test with this

        I've integrated this to 22, 23 and master. I've not integrated it to 2.1 as we are supporting this for security fixes only now.

        Show
        Dan Poltawski added a comment - Thanks Paul - Great to see the unit test with this I've integrated this to 22, 23 and master. I've not integrated it to 2.1 as we are supporting this for security fixes only now.
        Hide
        Adrian Greeve added a comment -

        I tested this on the 2.2, 2.3 and master integration branches.
        The restore worked fine.
        I clicked the first file and that displayed fine.
        The second file still came up with the error (Sorry, the requested file could not be found)
        I double checked that the code had been integrated (which it had).
        I re-ran the unit tests (which passed).
        Test failed.

        Show
        Adrian Greeve added a comment - I tested this on the 2.2, 2.3 and master integration branches. The restore worked fine. I clicked the first file and that displayed fine. The second file still came up with the error (Sorry, the requested file could not be found) I double checked that the code had been integrated (which it had). I re-ran the unit tests (which passed). Test failed.
        Hide
        David Mudrak added a comment -

        OK. I tried myself and for me, the second link worked fine. But. I noticed that link in the HTML itself is not converted to use pluginfile.php so it remains using file.php (Legacy course file). The file 2.txt gets converted into Legacy course files so it works. Still, it would be nice if file 2.txt restore worked fully. I am working on a patch that adds this on top of Paul's work.

        Adrian - the reason why the second file did not work for you might be that you have Legacy files disabled at your site (in other words, the Settings block in the restored course does not contain "Legacy course files" link).

        Show
        David Mudrak added a comment - OK. I tried myself and for me, the second link worked fine. But. I noticed that link in the HTML itself is not converted to use pluginfile.php so it remains using file.php (Legacy course file). The file 2.txt gets converted into Legacy course files so it works. Still, it would be nice if file 2.txt restore worked fully. I am working on a patch that adds this on top of Paul's work. Adrian - the reason why the second file did not work for you might be that you have Legacy files disabled at your site (in other words, the Settings block in the restored course does not contain "Legacy course files" link).
        Hide
        Dan Poltawski added a comment -

        Please can we have legacy course files in the testing instructions

        Show
        Dan Poltawski added a comment - Please can we have legacy course files in the testing instructions
        Hide
        David Mudrak added a comment -

        Attaching a modified version of the test backup file. Not only the file has the space in the file name, but it is also in a subfolder which contains the space in the name, too (course_files/sub folder/file 2.txt). The expected result is that the file is still converted into the label's file area.

        Show
        David Mudrak added a comment - Attaching a modified version of the test backup file. Not only the file has the space in the file name, but it is also in a subfolder which contains the space in the name, too (course_files/sub folder/file 2.txt). The expected result is that the file is still converted into the label's file area.
        Hide
        Paul Nicholls added a comment -

        Ah - that's an annoying one. It's down to rewrite_filephp_usage - because it uses the list of files retrieved by find_referenced_files, it doesn't perform the replacement since the urldecoded version isn't in the original text.

        I'd originally assumed that it would be better done in find_referenced_files, since that seemed tidier - but I hadn't noticed that it was failing to rewrite the link (as I have legacy files enabled). With that in mind, it seems like the best/simplest solution might be to just revert the find_referenced_files change, and instead add $file = urldecode($file); at the top of the foreach in migrate_referenced_files. I just gave that a quick shot, and it migrated the file and rewrote the link - both in the original test, and in David's test with a space in the path.

        I'm happy to provide replacement branches which do the urldecode in migrate_referenced_files instead. It'll render the new unit test unnecessary/incorrect, so I wouldn't include that - and there isn't currently a test for the entire migrate_referenced_files function, so I can't augment it or create a new one based off it. I don't have time to write one from scratch right now, sorry - so if you'd like one, you might have to write one yourself (with the existing tests for find_referenced_files and $fileman->migrate_file in mind, I'm not sure how you'd do that without effectively re-testing those)

        Show
        Paul Nicholls added a comment - Ah - that's an annoying one. It's down to rewrite_filephp_usage - because it uses the list of files retrieved by find_referenced_files, it doesn't perform the replacement since the urldecoded version isn't in the original text. I'd originally assumed that it would be better done in find_referenced_files, since that seemed tidier - but I hadn't noticed that it was failing to rewrite the link (as I have legacy files enabled). With that in mind, it seems like the best/simplest solution might be to just revert the find_referenced_files change, and instead add $file = urldecode($file); at the top of the foreach in migrate_referenced_files. I just gave that a quick shot, and it migrated the file and rewrote the link - both in the original test, and in David's test with a space in the path. I'm happy to provide replacement branches which do the urldecode in migrate_referenced_files instead. It'll render the new unit test unnecessary/incorrect, so I wouldn't include that - and there isn't currently a test for the entire migrate_referenced_files function, so I can't augment it or create a new one based off it. I don't have time to write one from scratch right now, sorry - so if you'd like one, you might have to write one yourself (with the existing tests for find_referenced_files and $fileman->migrate_file in mind, I'm not sure how you'd do that without effectively re-testing those)
        Hide
        Petr Škoda added a comment -

        sorry for the noise, I did not study the details when David asked me to flip the status.

        Show
        Petr Škoda added a comment - sorry for the noise, I did not study the details when David asked me to flip the status.
        Hide
        David Mudrak added a comment -

        Soooo...

        I re-assigned this to myself so I was able to submit additional patches. We can re-assign it back to Paul once it is finished (so he does not loose a resolved issue in JIRA stats).

        I have prepared three patches for master, 2.3 and 2.2 (this is not a security issue so it won't find its way to 2.1 - the 2.2 commit can be cherry-picked easily though) in integration.git with following improvements:

        1. It modifies Paul's already integrated patch to use rawurldecode() - which is the variant that actually encodes spaces as %20. urlencode() replaces spaces with plus signs.
        2. It fixes rewrite_filephp_usage() so that it takes file names encoding into account when it modifies the original HTML text.
        3. It extends Paul's unit tests for this case.

        As a result, files with the space in the names are not only found by moodle1 converter (which is what Paul found and fixed) but they are also properly migrated to use pluginfile.php instead of the legacy file.php

        DEAR INTEGRATORS,

        the patches are for integration.git that already contains Paul's changes. Please see them here:

        Pull From Repository: git://github.com/mudrd8mz/moodle.git
        Pull Branch: MDL-36204-files-with-spaces
        Pull Branch: MDL-36204-files-with-spaces_23
        Pull Branch: MDL-36204-files-with-spaces_22

        Show
        David Mudrak added a comment - Soooo... I re-assigned this to myself so I was able to submit additional patches. We can re-assign it back to Paul once it is finished (so he does not loose a resolved issue in JIRA stats). I have prepared three patches for master, 2.3 and 2.2 (this is not a security issue so it won't find its way to 2.1 - the 2.2 commit can be cherry-picked easily though) in integration.git with following improvements: It modifies Paul's already integrated patch to use rawurldecode() - which is the variant that actually encodes spaces as %20. urlencode() replaces spaces with plus signs. It fixes rewrite_filephp_usage() so that it takes file names encoding into account when it modifies the original HTML text. It extends Paul's unit tests for this case. As a result, files with the space in the names are not only found by moodle1 converter (which is what Paul found and fixed) but they are also properly migrated to use pluginfile.php instead of the legacy file.php DEAR INTEGRATORS, the patches are for integration.git that already contains Paul's changes. Please see them here: Pull From Repository: git://github.com/mudrd8mz/moodle.git Pull Branch: MDL-36204 -files-with-spaces Pull Branch: MDL-36204 -files-with-spaces_23 Pull Branch: MDL-36204 -files-with-spaces_22
        Hide
        David Mudrak added a comment -

        Here is a quick diff for my additional patch over Paul's work: https://github.com/mudrd8mz/moodle/commit/42781c9977303f389bba7b9526e15b9870e997bd

        Show
        David Mudrak added a comment - Here is a quick diff for my additional patch over Paul's work: https://github.com/mudrd8mz/moodle/commit/42781c9977303f389bba7b9526e15b9870e997bd
        Hide
        Paul Nicholls added a comment - - edited

        Hi David,
        The urldecode/rawurldecode difference is pretty minor - urldecode is basically the same as rawurldecode except that it also converts raw + signs into spaces. It might be possible (though I'd imagine it would be very uncommon) for some URLs to have spaces encoded as plus signs instead of %20 - for instance, if somebody has been editing raw HTML. If there are plus signs in the actual file names, they should have been encoded as %2B, so we shouldn't have to worry about accidentally mangling filenames containing plus signs by using urldecode - meaning that urldecode might be a slightly safer option.

        While your patches work, it might be better to take the simpler and slightly more efficient approach I suggested in my previous comment - shifting the decoding into migrate_referenced_files, so that it only happens in the place that it's actually necessary. Decoding it and then going through and re-encoding it chunk-by-chunk seems like a waste of time (and unnecessary complexity) when we can just decode it in the one place that actually needs it decoded - the bit that deals with the actual files.

        Edited to add: It's also possible that, due to differences in how a URL was originally encoded and how (raw)urlencode works, some links might not get rewritten with your approach. It wouldn't be very likely, but it's not a factor at all with the simpler approach, since rewrite_filephp_usage gets passed a set of URLs that haven't been decoded and then re-encoded.

        -Paul

        Show
        Paul Nicholls added a comment - - edited Hi David, The urldecode/rawurldecode difference is pretty minor - urldecode is basically the same as rawurldecode except that it also converts raw + signs into spaces. It might be possible (though I'd imagine it would be very uncommon) for some URLs to have spaces encoded as plus signs instead of %20 - for instance, if somebody has been editing raw HTML. If there are plus signs in the actual file names, they should have been encoded as %2B, so we shouldn't have to worry about accidentally mangling filenames containing plus signs by using urldecode - meaning that urldecode might be a slightly safer option. While your patches work, it might be better to take the simpler and slightly more efficient approach I suggested in my previous comment - shifting the decoding into migrate_referenced_files, so that it only happens in the place that it's actually necessary. Decoding it and then going through and re-encoding it chunk-by-chunk seems like a waste of time (and unnecessary complexity) when we can just decode it in the one place that actually needs it decoded - the bit that deals with the actual files. Edited to add: It's also possible that, due to differences in how a URL was originally encoded and how (raw)urlencode works, some links might not get rewritten with your approach. It wouldn't be very likely, but it's not a factor at all with the simpler approach, since rewrite_filephp_usage gets passed a set of URLs that haven't been decoded and then re-encoded. -Paul
        Hide
        David Mudrak added a comment -

        Right. It seems that this requires more work then. As some other issues were detected in this area recently (not with your patch but related to it), it seems like a wise solution to revert this from integration.git now and try your approach. We should definitely have unittests examples more offensive to be sure it all works well - like the one you mentioned above ("some links might not get rewritten with your approach").

        Show
        David Mudrak added a comment - Right. It seems that this requires more work then. As some other issues were detected in this area recently (not with your patch but related to it), it seems like a wise solution to revert this from integration.git now and try your approach. We should definitely have unittests examples more offensive to be sure it all works well - like the one you mentioned above ("some links might not get rewritten with your approach").
        Hide
        David Mudrak added a comment -

        I was thinking a bit more about the approach in my patch compared to the one suggested by Paul. I tend to prefer my one still at the moment. My reasoning is that the real name of the file "foo bar.txt" and not "foo%20bar.txt". So rewrite_filephp_usage() should get this real name of the file as a parameter. The fact that the file's name is somehow encoded in the text is an implementation detail known to that method. The caller should not care about it. It just seems to be more conceptually right to me. From that point of view, moving the decoding to the caller sounds hacky. And I'm not sure about any significant performance aspect here. Surely couple of string operations is not what makes things slower these days.

        Anyway, I should really let someone else to look at this yet. It's late night here and my brain may not be working reliably.

        Show
        David Mudrak added a comment - I was thinking a bit more about the approach in my patch compared to the one suggested by Paul. I tend to prefer my one still at the moment. My reasoning is that the real name of the file "foo bar.txt" and not "foo%20bar.txt". So rewrite_filephp_usage() should get this real name of the file as a parameter. The fact that the file's name is somehow encoded in the text is an implementation detail known to that method. The caller should not care about it. It just seems to be more conceptually right to me. From that point of view, moving the decoding to the caller sounds hacky. And I'm not sure about any significant performance aspect here. Surely couple of string operations is not what makes things slower these days. Anyway, I should really let someone else to look at this yet. It's late night here and my brain may not be working reliably.
        Hide
        Paul Nicholls added a comment -

        I understand where you're coming from, but I think it's down to semantics and function names - the functions deal with references to files, which just so happen to be in the form of URLs (or rather, URL fragments). Since the file names are coming from and going to URLs, I still think it makes the most sense to leave them as URLs and only decode them at the single point that works with actual files.

        I'm sure the extra string (and array) operations wouldn't add a massive amount to the time taken, but it could build up in large courses with hundreds (or even thousands) of references to files. Admittedly, it would still only be a small fraction of the total time taken, but why slow down an already slow process if we don't have to?

        Letting somebody else weigh in on this definitely sounds like a good idea - an impartial observer might well be what we need right now

        Show
        Paul Nicholls added a comment - I understand where you're coming from, but I think it's down to semantics and function names - the functions deal with references to files, which just so happen to be in the form of URLs (or rather, URL fragments). Since the file names are coming from and going to URLs, I still think it makes the most sense to leave them as URLs and only decode them at the single point that works with actual files. I'm sure the extra string (and array) operations wouldn't add a massive amount to the time taken, but it could build up in large courses with hundreds (or even thousands) of references to files. Admittedly, it would still only be a small fraction of the total time taken, but why slow down an already slow process if we don't have to? Letting somebody else weigh in on this definitely sounds like a good idea - an impartial observer might well be what we need right now
        Hide
        David Mudrak added a comment -

        With regarding + (the plus sign) in the file - note that according http://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-and-when-to-20 the <img src="foo+bar.png" /> the file should not be considered as having a space. It is supposed to stay as is. Might be good to have additional unittest for it.

        Show
        David Mudrak added a comment - With regarding + (the plus sign) in the file - note that according http://stackoverflow.com/questions/2678551/when-to-encode-space-to-plus-and-when-to-20 the <img src="foo+bar.png" /> the file should not be considered as having a space. It is supposed to stay as is. Might be good to have additional unittest for it.
        Hide
        Paul Nicholls added a comment -

        Ah - that's a good reference. Based on that, we should use rawurldecode. I've pushed a new set of branches which simply do a rawurldecode inside the foreach in migrate_referenced_files:

        Pull From Repository: git://github.com/pauln/moodle.git
        Pull Branch: MDL-36204_master_2
        Pull Branch: MDL-36204_23_2
        Pull Branch: MDL-36204_22_2

        Show
        Paul Nicholls added a comment - Ah - that's a good reference. Based on that, we should use rawurldecode. I've pushed a new set of branches which simply do a rawurldecode inside the foreach in migrate_referenced_files: Pull From Repository: git://github.com/pauln/moodle.git Pull Branch: MDL-36204 _master_2 Pull Branch: MDL-36204 _23_2 Pull Branch: MDL-36204 _22_2
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        More yet, I've been testing Moodle 1.9 and it performs rawurldecode() @ get_file_argument() so "+" has never worked for sites with PATH_INFO enabled. Only for sites with that disabled it may work.

        So... I feel myself inclined to vote for David's alternative using raw, that is the correct one for URLs and also works in query strings. The "+" only works in query strings.

        Ciao

        Edited: Lol, Paul I commented without seeing your comment in the mean time.

        Show
        Eloy Lafuente (stronk7) added a comment - - edited More yet, I've been testing Moodle 1.9 and it performs rawurldecode() @ get_file_argument() so "+" has never worked for sites with PATH_INFO enabled. Only for sites with that disabled it may work. So... I feel myself inclined to vote for David's alternative using raw, that is the correct one for URLs and also works in query strings. The "+" only works in query strings. Ciao Edited: Lol, Paul I commented without seeing your comment in the mean time.
        Hide
        Paul Nicholls added a comment -

        Hi Eloy,
        No worries - I must've posted my comment while you were typing yours! Since we're in agreement about rawurldecode vs urldecode, it's just down to whether we want to decode only in the place that it's necessary (i.e. the branches I just posted), or if we want find_referenced_files to decode and then have to re-encode in rewrite_filephp_usage (i.e. the branches David posted) - do you have any thoughts on that?

        Show
        Paul Nicholls added a comment - Hi Eloy, No worries - I must've posted my comment while you were typing yours! Since we're in agreement about rawurldecode vs urldecode, it's just down to whether we want to decode only in the place that it's necessary (i.e. the branches I just posted), or if we want find_referenced_files to decode and then have to re-encode in rewrite_filephp_usage (i.e. the branches David posted) - do you have any thoughts on that?
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        I think I like more David's solution, as far as it's clearer in my mind:

        1) Firstly we extract the correct file names (to look for them)
        2) Later we rebuild the links in the original texts with proper encoding.

        Sure your 1-line achieve the same (haven't looked/tried), but IMO David's one is clearer and it shouldn't add too much load to the whole conversion IMO. Also, going to your new alternative means reverting current commits and applying the new ones (or break history but now it's not a good moment for that with QA ongoing).

        So I'd vote for:

        1) Add David's commits on top of current ones.
        2) Add some more tests (David?)

        Up to Dan to decide in some hours. Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - - edited I think I like more David's solution, as far as it's clearer in my mind: 1) Firstly we extract the correct file names (to look for them) 2) Later we rebuild the links in the original texts with proper encoding. Sure your 1-line achieve the same (haven't looked/tried), but IMO David's one is clearer and it shouldn't add too much load to the whole conversion IMO. Also, going to your new alternative means reverting current commits and applying the new ones (or break history but now it's not a good moment for that with QA ongoing). So I'd vote for: 1) Add David's commits on top of current ones. 2) Add some more tests (David?) Up to Dan to decide in some hours. Ciao
        Hide
        Paul Nicholls added a comment -

        If the previous patch having already made it to integration is an issue, I can supply a patch which applies on top of the previous one to shift the decoding to migrate_referenced_files (and switches to rawurldecode) if that makes life easier for integrators. I'll wait until we hear from Dan first, though - no point doing the extra work if he decides to go with David's approach

        Show
        Paul Nicholls added a comment - If the previous patch having already made it to integration is an issue, I can supply a patch which applies on top of the previous one to shift the decoding to migrate_referenced_files (and switches to rawurldecode) if that makes life easier for integrators. I'll wait until we hear from Dan first, though - no point doing the extra work if he decides to go with David's approach
        Hide
        David Mudrak added a comment -

        OK, here goes the patch for integration.git that should be applied on top of Paul's already integrated work. Please see https://github.com/mudrd8mz/moodle/commit/2c9689ed2198c15e130f6354f75c716e9a1cdf67 for a quick overview and my previous comments for more info.

        DEAR INTEGRATORS,

        please pull following branches into integration.git:

        Pull From Repository: git://github.com/mudrd8mz/moodle.git
        2.4 Pull Branch: MDL-36204-files-with-spaces
        2.3 Pull Branch: MDL-36204-files-with-spaces_23
        2.2 Pull Branch: MDL-36204-files-with-spaces_22

        Show
        David Mudrak added a comment - OK, here goes the patch for integration.git that should be applied on top of Paul's already integrated work. Please see https://github.com/mudrd8mz/moodle/commit/2c9689ed2198c15e130f6354f75c716e9a1cdf67 for a quick overview and my previous comments for more info. DEAR INTEGRATORS, please pull following branches into integration.git: Pull From Repository: git://github.com/mudrd8mz/moodle.git 2.4 Pull Branch: MDL-36204 -files-with-spaces 2.3 Pull Branch: MDL-36204 -files-with-spaces_23 2.2 Pull Branch: MDL-36204 -files-with-spaces_22
        Hide
        Dan Poltawski added a comment -

        Integrated these new fixes, thanks David.

        Adrian, could you retest?

        Show
        Dan Poltawski added a comment - Integrated these new fixes, thanks David. Adrian, could you retest?
        Hide
        Adrian Greeve added a comment -

        Tested on the 2.2, 2.3 and master integration branches.
        No problems this time. Both files displayed with no problems.
        Thanks,
        Test passed.

        Show
        Adrian Greeve added a comment - Tested on the 2.2, 2.3 and master integration branches. No problems this time. Both files displayed with no problems. Thanks, Test passed.
        Hide
        Dan Poltawski added a comment -

        Congratulations! Another bug solved.. only another 7330 to go, thanks for contributing to contributing to 0.8% of all bugs being fixed this week!

        ciao
        Dan

        Show
        Dan Poltawski added a comment - Congratulations! Another bug solved.. only another 7330 to go, thanks for contributing to contributing to 0.8% of all bugs being fixed this week! ciao Dan

          People

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

            Dates

            • Created:
              Updated:
              Resolved: