Moodle
  1. Moodle
  2. MDL-20629

Give question type a chance to upgrade it's attempts data upon editing a question

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.9.6
    • Fix Version/s: None
    • Component/s: Questions
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Rank:
      2494

      Description

      Since editing a questions with existing attetmpts should definitely be allowed, a question type should have a possibility to change attempt data to avoid breaks (and even try to save the students answers from corruption in some cases). This could be done by adding to a question type a function like

      upgrade_existing_responses($oldquestion, $newquestion, $responses)

      It is easy to implement in question engine and will add to quiz correctess and stability without restraining the user.

        Activity

        Hide
        Pierre Pichet added a comment -

        Hi Oleg,
        My first comments is that should be part of a more general schema as Tim is working on for HEAD.
        There is no so much bad reports on 1.9 that this suggestion will solve, to work on a 1.9 specific solution.
        There are bugs like MDL-20570 as cited by Tim on the forum, that are off a very different nature.

        Show
        Pierre Pichet added a comment - Hi Oleg, My first comments is that should be part of a more general schema as Tim is working on for HEAD. There is no so much bad reports on 1.9 that this suggestion will solve, to work on a 1.9 specific solution. There are bugs like MDL-20570 as cited by Tim on the forum, that are off a very different nature.
        Hide
        Oleg Sychev added a comment -

        I did agree about not implementing 1.9 specific solution, but sort of know that Tim like to set fix version himself.

        This is another approach to the problems that lead you to MDL-20584. It can ensure that old quiz attempts will never breaks on question editing (thought some data may be lost or corrupted). First of all we should define exact interface of the function.

        The reasons why I would have it implemented rather sooner than later are:
        1) it is able to be used in any question versioning schema or without it, while right now question type could only implement a workaround that should be changed upon question engine editing
        2) particular question types could implement it to a varying degrees (saving more or less data) and a good implementation for multichoice or multianswer is quite hard, this is not sort of thing you'd want to implement fast; so it is good to have a well-established point where such code could be created and improved over time while been safe from a changes of a question engine.
        3) Implementation for the question engine part will be easy, for now I guess it can just call function on question saving (this can be changed later during versioning)

        As of MDL-20570, it could probably be resolved only during Backup 2.0 Working with Moodle some time I come to conclusion that if you can, you should usually start active production using big new features only from the next version of the Moodle (i.e. roles from 1.8, gradebook and question sharing from 2.0 and so on). That way you'll have a good chances to avoid any serious trouble with it.

        Show
        Oleg Sychev added a comment - I did agree about not implementing 1.9 specific solution, but sort of know that Tim like to set fix version himself. This is another approach to the problems that lead you to MDL-20584 . It can ensure that old quiz attempts will never breaks on question editing (thought some data may be lost or corrupted). First of all we should define exact interface of the function. The reasons why I would have it implemented rather sooner than later are: 1) it is able to be used in any question versioning schema or without it, while right now question type could only implement a workaround that should be changed upon question engine editing 2) particular question types could implement it to a varying degrees (saving more or less data) and a good implementation for multichoice or multianswer is quite hard, this is not sort of thing you'd want to implement fast; so it is good to have a well-established point where such code could be created and improved over time while been safe from a changes of a question engine. 3) Implementation for the question engine part will be easy, for now I guess it can just call function on question saving (this can be changed later during versioning) As of MDL-20570 , it could probably be resolved only during Backup 2.0 Working with Moodle some time I come to conclusion that if you can, you should usually start active production using big new features only from the next version of the Moodle (i.e. roles from 1.8, gradebook and question sharing from 2.0 and so on). That way you'll have a good chances to avoid any serious trouble with it.
        Hide
        Tim Hunt added a comment -

        We are not going to do this.

        First, there are now many standard and add-on question types, and they can be edited without problem.

        Second, if this were to be implemented on a large Moodle site, it would be a performance disaster.

        It is true that when designing a question type, it is important to think about how they store attempt data, so that editing the quetsion will not cause problems.

        Show
        Tim Hunt added a comment - We are not going to do this. First, there are now many standard and add-on question types, and they can be edited without problem. Second, if this were to be implemented on a large Moodle site, it would be a performance disaster. It is true that when designing a question type, it is important to think about how they store attempt data, so that editing the quetsion will not cause problems.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: