Moodle

I expect that students find the inability to copy and paste during the attempt equally irritating

Oh, I sort of expect they are finding that much more irritating

But anyway I see no reason to keep a person with ability to preview questions from copying them on review.

Actually I expect student review securing to be not very effective since it isn't IP protected. As result, since protection don't work no all browser, it is obviously easy to workaround - we can't control what browser is used on an arbitrary computer...

Also student's review security could be better by starting it in popup too to block menu access (and so an ability to see the source of the pages).

Well, previewing a quiz with a secure window is a complete mess now.

1. When previewing a quiz you are not restricted from context menu, using clipboard and so on - but when reviewing you own preview you are restricted from that (while still been able to edit questions).
2. If you start (or continue) preview with a button you get a preview in popup window while if you start preview using tab you get it in the same browser window.

Something should probably be done there, especially in case 1.

The hard part would be finding a correct capability to check for applying restrictions (such as inability to copy text). I could imagine a use case of untrusted previewer (i.e. a parent or boss, who should be allowed to preview but not copy questions), in which case restrictions should apply for both review and preview.

But any person that could look at question bank will be able to copy questions anyway, especially if he/she could export questions, so there is no point in restricting them (except annoyance). Or, alternatively, there could be a new capability, like mod:quiz/insecurequizwindow.

After chat with Tim it was decided that for now system should work as follow:
0. All secure windows are popups (otherwise access to HTML code is possible)
1. Preview started by button always opens in secure window for secure quizzes
2. Preview started by tab always opens in non-secure window
3. Review of attempts in secure quizzes would open in a secure window if a user doesn't have mod/quiz:preview capability

Patch was reviewed. The only unusual effect is that when teacher trying to preview quiz as it will work for a student, using a button, he won't have button "start again" on preview screen. But then, student didn't have this button.

Your patch generally looks good, but there were a couple of minor issues that needed to be fixed. Please see the new patch

previewasstudent.patch.txt

Are you able to review and test this at all?

Also, this can't get committed until there is an equivalent patch for Moodle 2.0, and I am not sure when I might get time to make one, so if you can do it, that would help.

Tim, could you commit MDL-20956 first? There are 2.0 version of patch there (thought it is already slightly obsolete, at least because help strings are moved somewhere) and it too deals with quiz/accessrules.php file (as will need this one), which make debugging and generating patches somewhat inconvenient (I'm not sure could I just delete sections of patches).

Is it OK to change interface of the functions in accessrules.php to pass additional arguments to make this change?

TIm, I somewhat perplexed about 2.0 patch for this. Our convention defined above (see my comment from26 Nov 09) meant there are two ways to access quiz preview (button and tab) and they will work different ways. But I can't find another ways of starting preview except button in 2.0.

The other way of starting a preview is the link in the Settings block. That is the equivalent of the tab.

I will look at MDL-20956 today.

What do you think more appropriate: get previewasstudent by optional_param on the attempt page script (or security manager class) and add an arguments to pass it down to the securewindow_access_rule (it needed to generate review link) or get it in securewindow_access_rule::make_review_link directly using optional_param?

P.S. The comment on the line 734 of accessrules.php (before class securewindow_access_rule extends quiz_access_rule_base {) seems like you are copied it from somewhere else and forget to edit.

I think $previewasstudent should be an argument to securewindow_access_rule::make_review_link() - and so also to quiz_access_manager::make_review_link().

Thanks for pointing out the wrong comment. Fixed now.

During writing the patch discovered a bug in quiz_access_manager::print_start_attempt_button, breaking secure preview/attemps using button. Going to fix it in the patch.

As all previews using button should be secure if the quiz are secure, quiz_access_manager::print_start_attempt_button doesn't need it's first argument ($canpreview) any more. Tim, should I delete it and correct all calls to this function?

Yes, please clean-up the print_start_attempt_button API if possible.

Hmm ... the only script using make_review_link is view.php. Other scripts directly use reviewurl function from the quiz object (attemptlib). Is this OK or all scripts should receive review link throught accessmanager class?

Well, once you are looking at the quiz in a secure window, we don't want links that pop-up a new window, we just want ordinary links inside the pop-up.

The other consideration is that there is no $attemptobj on the view.php page - it would not really make sense.

So, I think attempt.php, summary.php, review.php and reviewquestion.php should use attemptobj.

Other scripts - which is probably only view.php - should use make_review_link.

I think this patch will do the job for 2.0

You may not appreciate using optional_param in the class constructor, but that was the only way to give previewasstudent transparency it needed with so many attempt pages and so many places where links to them are generated (i tried many ways before finding this solution).

I was tested it except testing student doing review of his attempt (i was unable to do so due to MDL-23713), but i don't expect anything changing there since is_preview_student will give false for the student as before.

I'm going to test you patch for 1.9 this Monday but think that changing '&' to '&' in url generating you done was error.

Sorry, I can't work out which patch for 1.9 you mean. Please could you tell me which of http://github.com/moodle/moodle/commits/MOODLE_19_STABLE you mean. Thanks.

And, sorry again, but you latest patch does not apply to 2.0 any more. Is there any chance you could do a CVS update, and then make a new patch.

Attaching a fixed patch for 2.0

About patch - you downloaded a modified version of my patch for 1.9 (previewasstudent.patch.txt) and ask me to review it. You changed in url there & to the & - this is error, as & was used as get argument separator.

Tim, I hope you'll look on the 2.0 patch before it won't apply again....

I hope so. I am on holiday next week, so you won't hear from me until I get back.