Posts made by Tim Hunt

Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The other bit is part of a quiz instance and cannot be exported.

But what you can do is use the course backup and restore feature. When you do a backup, you can chose what to include, and so you can make a backup file that just contains a single quiz, and then you can restore that into an existing course to make a copy.

Moodle in English -> Quiz -> Graphics in Alternative -> Re: Graphics in Alternative

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes, you can type arbitrary HTML into the options boxes. The only reason for not showing the HTML editor there is to stop the editing form becoming even more insanely long than it already is.

One way to get the content in there is to type all the options into the question stem box, then switch that editor to source view - the <> button - and then cut and past the HTML for the options into the other boxes.

In due course, I would like to add a preference to that editing form - a bit like the 'show advanced' button on some forms, so the user can choose whether to show the HTML editor for the options.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
This is good. It is essentially the same as something that I have proposed informally in chats with Eloy in the past, so I am in favour.

One think you can consider is changing the upgrade procedure, so instead of udpating core first, then each module, then each block, ... etc. Instead you can first go round everywhere getting a list of all the upgrades that need to apply, then you sort them all by name - which effectively sorts them by date order, then apply them in that order. This probably reduces problems with major upgrades, e.g. 1.6->1.9, because when you are writing an update of, say, core tables, you can then be pretty confident of the state of the other tables that you might need to touch in some way.

I would even go one further and not bother with consolidating the separate upgrade files. What is the benefit of that?

Also, I do not see the need for the two-argument form has_dbupdate("2008021700-webdavblocks", "MOODLE_20_STABLE"). That second argument must be tehre to solve some problem, but I can't think what.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
No, I know enough to say that you are incorrect.


The only complete and correct description of all the rules is in accesslib.php, in particular in the function has_capability_in_accessdata. I accept that that is not at all readable.


I think that something even more useful than a textual description of the algorithm would be a set of worked examples the demonstrate first some normally situations, and then most of the interesting edge cases. That would probably take about 20 examples. Compiling the examples would be a great way of learning the algorithm.


But I am not going to bother, because although I could not explain the general algorithm to someone else, I do know enough to set up courses and activities in real situations, and to explain to people how to solve particular roles configuration problems.


So instead of trying to describe the general rules, and alternative approach is write a document that says "If you only do these few things, then it will work like this" and have it that the subset described is enough to do 99.99% of what teachers want.


Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The point (state or level) is what we call the context. It is where you currently are in the site - where the web page you are currently looking at is. The way to think of this is like a file path. If you are thinking about a word document on your hard disc, it might be in folder "VLE docs", but that is acutally
C:\Documents and Settings\timhunt\My Documents\VLE docs\spec.doc 
Similarly, this forum is Forum: Roles and Capabilities, but actually, that is

Site: moodle.org/Category: Community Discussion (in English)/Course: Using Moodle/Forum: Roles and Capabilities


You don't just have a single role. The most normal situation is that you have two. At the moment (assuming you are logged in) you are assigned the role "Logged in user" in context Site: moodle.org. Since this forum is inside the site, that role applies here. Second, you have been assigned the role "Moodler" in context Course: Using Moodle (this happened when you first came here, were asked if wanted to enrol, and clicked yet). Since this forum is inside that course, that role applies here too. So (as I said was normal) in this forum you have two roles. If, however, you go and look at the list of courses in category Community Discussion (in English), then you will only have one role (Logged in user) there, because that category is outside the course. If you were not logged in when looking at this forum (or anywhere else), you would just have one role "Guest", assigned in context Site: moodle.org, and so applying here too.


What a role actually gives you is a defined permission for each capability. A capability is a specific thing that you might, or might not, be allowed to do. For example mod/forum:viewdiscussion, or mod/forum:replypost. A permission on that capability is basically either Allow or Prevent (I am simplifying slightly here).


What actually determines whether you can do a particular thing in a particular context is the computed permission you have for that capability. This is a combination of the permissions you have from each role that applies in this context. The precise rules here are complicated but roughly it is "Count +1 foreach allow, -1 for each prevent. If the total is > 0, the computed permission is allow; if the
total is < 0, it is prevent; in the case of a tie, apply some tie-breaking rules."


There is one more concept to understand, and that is overrides. Above I talked about the defined permissions for a role. Normally, roles are just defined in the site context (for example saying that Moodlers are allowed to
mod/forum:replypost), and that definition applies everywhere. But suppose in one particular forum (e.g. the news forum) you want to change the definition, so Moodlers can't reply there. Well, you can do that by overriding the Moodler role in the context of that forum to change the permission.

Overrides just make the "complicated rules for working out the computed permission" more complicated. Fortunately, you don't really need to understand these rules. They normally do what you expect (and the reason they are very hard to write down precisely is that human common sense is very hard to describe and explain to a computer).


P.S. the terms I have put into bold are a combination of existing ones (context, role, assign, permission, capability, override) that are currently used in the code and user interface and explained on MoodleDocs; and some I made up just now because I thought they made this explanation clearer (applies, defined/computed permission).
Average of ratings: Useful (7)
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The way we solve potential conflicts is to keep our own copy of the code - let's call it OU Moodle - separate from the official Moodle code.

We can do whatever we like with OU Moodle. We can only do things in official Moodle that the community agree with.

Now, it is much easier for us if OU Moodle and official Moodle are as similar as possible. The main reason is so that when there is a new Moodle release, it is easy for us to combine those changes into OU Moodle.

And it is good for the community if, when the OU have done something generally useful, that goes into core Moodle.

So really, not much conflict, but quite a lot of pain for us every 3-6 months doing code merges, followed by testing and bug-fixing.

However, it is not as painful as it might be, because of Moodle's architecture. I lot of things can be done as plugins (ouwiki, resourcepage, studycal course format, workflow block, many admin reports, ...) without changing the Moodle core.

Yes, there are sometimes technical arguments about how things should be done in official Moodle, or whether or not they should be done at all. But my experience is that the Moodle community is a great place to have these debates, because there are a lot of knowledgeable people here, the arguments tend to focus on the issues, and everyone had a common goal of making Moodle as good as possible. Sometimes, the decision is not what is most convenient for the OU, but there is normally a sound reason, so you accept it, and often, during the debate, you learn something.

Moodle in English -> Wiki -> Voting on NWiki vs OUWiki -> Re: Voting on NWiki vs OUWiki

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That should be quite cheap. Sam mostly drinks water. Maybe the occasional orange juice.

Also, the equation is more complex than that. You need to take into account a combination of features, ease use and performance.

Actually I was reading something interesting the other week that was making the distinction between "easy to use" and "easy to learn".

An ATM (hole-in-the-wall machine, thing you use to get money out of the bank) needs to be easy to learn. Lots of people just walk up to it, and need to be able to work out how to use it without instructions.

A powerful tool like Photoshop, or Eclipse, needs to be easy to use. Expert users will use it in their work to perform complex tasks. It should provide powerful features to let them do those tasks efficiently, once they have gone through the days of training required to use it efficiently. Because they will use it a lot, they can afford to invest the training time to achieve optimum performance in the long term.

I think that for most moodle tools, easy to learn is the more important. Teachers needs to be able to introduce technology into their courses to support the learning without the technology being a big deal. It should just work intuitively.

Of course, the two concepts are not mutually exclusive. Firefox is a reasonably good example. It is easy to learn to use for basic web browsing, but there are more advanced options you can turn on if you are a power-user. But then those extra components like firebug are often in the form of third-party modules that have to be downloaded and installed.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I place a huge amount of attention on what developers are keen to work on.

I think this is a very important point (but then I would, I am a developer), and I want to provide some feedback on what it is like working on sam's code.

Looking back, it sometimes seems that most of my career at the OU has consisted of taking over responsibility for sam's code, and maintaining and enhancing it. And I don't have any problem with that at all. sam writes good, well structured code that is easy to maintain and enhance. As a foundation for the future, I would happily start with sam's code, both in general, and in this case.

Note that sam wrote OU wiki after having spent over a year making lots of different customisations and bug-fixes to lots of different areas of Moodle. Therefore, it closely follows moodle coding standards and common practices. The nWiki team have been less involved in the wider Moodle community (as far as I have seen) but then this is probably mostly a result of native language, and so is an unfair basis for comparison.

In another post, Ludo says:
in the case of nwiki there are 3 developers [...] 3 Years working and giving suport has to count for something.
When I read this, it scares me. It means that nWiki took more than 5 developer-years to get where it is today, while OU wiki has taken less than 0.5. And we are thinking about what we want in Moodle 2.0, which is probably of the order of at most another 0.5 developer-years away, in terms of what Moodle HQ can afford to invest in incorporating whatever is chosen into core.

However, 3 years work and support is worth something. It has, presumably generated a lot of knowledge about what features work for teachers and students, and what doesn't. That knowledge is far more reusable than the current nWiki code.

Finally, I don't think that the current beauty contest approach to this decision in particularly helpful. It might have been better to start with a survey asking people what features they want in a wiki for use as a learning tool in courses, rather than leaping in and comparing two solutions. But then I am currently studying a course on requirements gathering, so perhaps I currently have an over-idealised view of processes should work.
Average of ratings: Useful (2)
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I would love to know why you need this. Why shouldn't teachers see each others quizzes when they are all teaching the same course?

If the different teachers are really that separate, why don't you just create a separate course for each teacher? Then each teacher can only access their own course.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
What you are proposing is almost certainly possible, but it sounds to me like it might be unnecessarily complicated.

The following might be a simpler way to achieve most of what you want:

1. Install the Code Syntax Highlighting filter: http://docs.moodle.org/en/Code_Syntax_Highlighting. This supports syntax highlighting of Java (and other languages) code. That lets you have one or more fragments of nicely syntax highlighted Java code in ordinary descriptions, as well as everywhere else in Moodle.

2. Change the quiz module slightly, so it is possible to have more than one copy of a description item in a quiz. This is the easiest way to reuse the same code sample several times in a quiz, just by putting the description item just before each question item it belongs to.


How well this meets your requirements:

1. and 2. Multiple editors and source code arrangement are not really necessary if you are embedding the bits of java code inside a larger bit of content authored using the HTML editor. You can do the layout in HTML, and have as many bits of code as you like inside the one editor.

3. and 4. I don't see much point in being able to upload .java files. If I was making questions like this, I would write the Java code in Eclipse (or whatever you favouring IDE is) - so the easiest way to get it into Moodle would be copy-and-paste. Similarly, copy and paste should be sufficient for getting code out.

Of course, you would have to manually add page-breaks before each description, so the description appears on a page with the correct following questions. If you wanted, you could change the repaginate option on the quiz to add a new option: 'page break before each description', but that is a refinement.


This is just a suggestion. I am sure you have thought about this much more than me, so I may be overlooking something.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
A single activity can have multiple columns in the gradebook. The code that needs changing is in mod/quiz/lib.php, where it calls quiz_grade_item_update and grade_update.

I am not sure exactly what you need to do to get multiple columns. Try looking at the other modules (particularly assignment) and asking in the general developer forum.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
There have been changes to how moodle core communicates with modules in Moodle 1.8 (and in other releases since 1.5, but to a lesser extent).

This should all be documented in Moodle docs - try starting from the release notes pages - but the information may be a bit sketchy.

The change you have to deal with here is the new formslib.php library. Instead of modedit.php, you need a mod_form.php.

Actually, in 1.8, things were backwards compatible, so modedit should go on working, but if you want your module to work on 1.9 in the furture, you should switch now.

Also, you should really start to look in to Roles and Capabilities, which were introduced in 1.7.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I have read this thread. If your are reporting a bug, or suggesting a new feature that other people in the discussion agree with, then you should

1) Search the tracker to see if it is already recorded.
2) If not, add it.

That is the best way to ensure things are not forgotten about.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The main problem is that the Moodle gradebook likes to know a maximum possible score for each activity, and with the sum of attempts score, that is unknown.

Apart from that, it would be relatively easy to implement, just extend a few functions in mod/quiz/locallib.php like quiz_get_grading_option_name, quiz_calculate_best_attempt, quiz_calculate_best_grade

Moodle in English -> Quiz -> Quiz view in Topic Order -> Re: Quiz view in Topic Order

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Actually, the quiz index page just uses the method get_all_instances_in_course from datalib.php. If that is wrong, then the same problem should affect all types of activities.

The order is actually coming from the $modinfo field of the course record, which is a cryptic cache of lots of information that is use to speed up rendering the course page. Perhaps that has not been updated for some reason. There must be a way to trigger it being rebuilt. Try adding a label the the course then deleting it, to see if that fixes things.

Moodle in English -> Comparisons and advocacy -> Free as in beer

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Last weekend I was in London, and went to Tate Modern to see a large crack in the floor:

salcedo_shibboleth.gif

Is that art? I don't know, it was surprisingly impressive, but not as good as the slides. However, what I really wanted to tell you about was what we found in the restaurant.

I assume most people here are familiar with the free-as-in-speech / free-as-in-beer distinction used to explain Free Software. Well, these people: http://freebeer.org/blog/, seem to want to confuse the issue by producing FreeBeer, which is free-as-in-speech. That is, the recipe and all the branding is released under a Creative Commons licence. However, it is not, at least in the Tate cafe, free-as-in-beer. Still, the version I drank (version 3.2), brewed by St Austell's brewery, was delicious.

2238960402_8236033ac1.jpg?v=0
Average of ratings: -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
A more interesting place for the kind of distribution that Artur Zacniewski is talking about is as follows:

Suppose you work for a big university with thousands of students and courses, and are responsible for their Moodle server. Obviously that is an important server, and you will be very paranoid about what code is deployed there. Every change will have to be thoroughly tested, and you will be reluctant to deploy any old third part Module.

However, suppose that one particular teacher (who happens to play golf with the Vice Chancellor) happens to see the SuperWizzyWonderful module in the Module and Plugins database, and decides that they cannot possibly run their course without it. Well, you take one look at the code and decide you aren't going to let it anywhere near your live server.

Now in this situation, it would be really good if you could deploy the dodgy SuperWizzyWonderful module on some other server. Then have your super-stable main Moodle server continue working as before, but be able to connect to other server to provide the SuperWizzyWonderful functionality.

I wonder how close you could get to implementing that using MNet?
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
At the moment, there is a single capability mod/quiz:viewreports, and if you have that, you can see any of the quiz reports, and without it, you can't see any. Perhaps we should change it so that each report has a separate capability, the you can choose to let students see some, but not all reports.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The reason lang strings are defined with single quotes is that you don't want the strings interpreted when they are loaded (that is, when the lang file is included) because they are loaded once and cached in memory.

The $a->whatever strings are replaced in a later step, when the string if eval-ed.

Anyway, in Moodle, the third argument is the way to do it, because you want your code to follow the same idioms as other Moodle code.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You probably don't want to be using sprintf like this.

The problem with sprintf is that it does not translate well into languages with different word orders, because the order of the arguments in the function calls has to be the same as the order of the things in the final string.

What is wrong with the standard Moodle method that looks like this:

$a = new stdClass();
$a->course = $course->shortname;
$a->username = fullname($user);
$a->score = sprintf("%5.2f", $quiz->score); // Use sprintf like this if you need to.
echo get_string('mystring', 'mymod', $a);

and in the lang file

$string['mystring'] = 'On course $a->course, user $a->username scored $a->score.';

That is, it is OK to use sprintf to format individual values, but not the whole string. And actually, IIRC, where the quiz does this sort of thing, it actually uses round(), instead of sprintf().

Moodle in English -> Quiz -> Exam not e-mailing.... -> Re: Exam not e-mailing....

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That is not one of the pieces of data that is currently available.

However, if you wanted to make it available, it would be a simple tweak to the code in the function quiz_send_notification_emails in mod/quiz/locallib.php. Around line 880, there is currently code
 // attempt info
 $a->submissiontime = userdate($attempt->timefinish);
 $a->timetaken = format_time($attempt->timefinish - $attempt->timestart);
You could add
 $a->attemptscore = quiz_rescale_grade($attempt->sumgrades, $quiz);
I think the reason that we did not do this when implementing this feature is that this ignores the settings of "Student may review" on the quiz settings page.

Moodle in English -> Wiki -> OU Wiki for 1.8? -> Re: OU Wiki for 1.8?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
There was a 1.8 version, but it was only released as a zip file, and it did not work on MySQL - only Postgres.

Plus, there have been improvements and enhancements made since then. Anyway, the OU is now using Moodle 1.9, so that is what recent version of OU wiki are compatible with - and it now supports MySQL apart from one problem with the search that sam is aware of, but I don't know if it is fixed yet.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You may find some of these references worth reading: http://docs.moodle.org/en/Documents_useful_for_decision_makers

I think (2006) Jon Dron: Any color you like, as long as it’s Blackboard (r) is a particularly thoughtful article.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Looks like you are hitting the problem that this commit fixed:

http://cvs.moodle.org/moodle/lib/weblib.php?r1=1.812.2.71&r2=1.812.2.72

(Oh, cool that's a bug I fixed!)

From which I deduce that you have not upgraded to 1.8.3 or 1.8.4. You should really consider doing that. There have been loads of bug fixes and performance improvements on the 1.8 branch.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You have not supplied the other vital bit of information, which is the version of Moodle you are using. And without that information, the line numbers in the error messages are pretty meaningless. The problem is probably not in weblib, but higher up the call stack. mod/quiz/view.php, or pagelib seem more likely.

Moodle in English -> Quiz -> quiz category reporting -> Re: quiz category reporting

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
This is not currently possible in Moodle. It has been asked for several times, and I think it is a good idea, but implementing it would require some changes to the database structure, and big changes to the code, so it has not been done yet.

In the mean-time, the only option may to do analyse the results manually, outside Moodle. If you go to Quiz -> Results -> Overview and turn on "Show mark details", then you can download all the scores as an excel spreadsheet. Then you can do whatever you like with them. (And if you had Moodle 1.9, you could then re-import the processed scores into the gradebook.)
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I think we can separate out two separate questions:

1. Should there be separate code for the journal module and assignment module, that has to be maintained separately? The developers answer No, with sound reasons.

2. In the user interface, should a learning Journal appear as just another type of assignment. The teachers answer No, with sound reasons.

However, these two answers are not necessarily incompatible. We developers just need to find a way to clean up the code behind the scenes, while giving teachers a Journal with the features they want.
Average of ratings: Useful (1)
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well, I sort of agree with you. Well, there is no overlap between this and conditional activities and repositories. What I am proposing is a bit of metadata, but it is one very specific sort that is fairly generally applicable. It is not like arbitrary configurable metadata fields, which is what some people want.

The thing is, I have this on my todo list for the next few months. So while while it would be interesting to wait for a more general solution, I don't have that option.

I think if I did this the way I suggest, and later a more general metadata system comes along, then actually, it would be pretty easy to move my proposed change into that general framework - just a simple database upgrade script to copy the data from one place to another.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I was thinking of this as the actual amount of time students would spend working on this, not the total elapsed time from start to the finish. So an forum might be open for a week, but we only expect students to spend 30 minutes during the week contributing.

Social format - ah we don't use that. I'll have to look at it. If there seems like a good way to support it, I will, otherwise I won't.

Index page, well, we don't want it there, so I won't implement it, we can do that later. Activity page. I am not sure you always want it there. Instead I would rather leave it to the teacher to decide what they want to type in the introductory text.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I've got a feature request here from within the OU, and it seems quite sensible, but it will require hacking around with core tables to do it properly. So I was wondering what people here thought. Does this sound sufficiently useful that we can develop it straight in to Moodle 2.0 dev?


What they want is a new field on the module settings form, where you can enter an estimated time required to complete that activity/read that resource. This would be an extra setting in the 'Common module settings' section of the form. It would, of course, be perfectly acceptable to leave that blank.

Then on the course home page, for any activity that has time required set, this is listed by the corresponding activity. The idea is that this makes it easier for students to plan their work.


To implement this, I think I need to
  1. add an int timerequired column to the mdl_course_modules table that stores the time in seconds.
  2. add another form field to the 'Common module settings' to let people set this. I am thinking of a dropdown with the options Not set, 5 mins, 10 mins, 15 mins, 30 mins, 45 mins, 1 hr, 1 1/2 hrs, 2 hrs, 3 hrs, ... 10 hrs.
  3. Display this next to activities on the course home page in all course formats. I think that just means editing print_section from course/lib.php. Obviously this information needs to be displayed surrounded by an appropriate <span> tag so themers can style it as they wish - and I need to make it look nice in the standard theme.

Comments?
Average of ratings: -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
OK, so this is not a great example, and Joseph has immediately spotted the problems with it.

First, for reasons best known to themselves, the person who made this quiz decided to do the whole thing as a single Cloze questions. That is not good quiz design.

Second, Moodle only knows whether there is some data stored for a student relating to a particular question. There is no easy way to know of that is a complete answer. This also affects matching questions. And, indeed, a multiple-response question that asks 'select three ...'.

However, for sensibly designed quizzes, I hope you can see that the new interface is a big step forwards. I hope there will be a better example I can share with you soon.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I'm afraid the only answer is to wait for Moodle 2.0, when some improvements that the OU have made to the quiz module will finally make it in to the official Moodle release.

At least we finally have an example of one of our quizzes on our publicly accessible OpenLearn site: http://openlearn.open.ac.uk/mod/quiz/view.php?id=217180, and it is not a great example, because it only has a single question. However, still worth looking at. Obviously, you will need to sign up for an account so you can attempt the quiz in order to see how it stops you submitting an incomplete quiz by mistake.


Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You would do better discussing this in the quiz forum.

But this is a relatively frequent topic of conversation, so it would be good if you could dig out some of the previous discussion threads and read them.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
This is an Internet Explorer bug.

You will find that once the editor has gone, no Javascript anywhere will run until you restart your browser.

I once tracked this problem down to other JavaScript on the page (in our theme header) interacting badly with the HTML editor. Search through previous posts by me in this forum for a detailed analysis.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The bit before the colon is a context path, so /1 is the system context, and /1/123/1234 is probably the course with contextid 1234 in the category with contextid 123. One bit of data is the role_capabilites, which are the original definitions (role_capabilities in the system context) and role overrides (role capabilities in any other context).

The bit after the colon is the role id.

The role assignments are then the role assignments in different contexts for the current user.

When you first log in, the data is loaded for the site context and all course-categories. When you first visit a course, the data is loaded for that course, and all contexts inside that course.

There is quite a lot of work to do to unpick the debug output and work out what it means.


By the way, have you seen my User's roles report? It does not do what you want, but it does show you all the role assignments for a particular user, which is sometimes useful. It complements the work Martin Langhoff did on the extended participants list.

And I quite like your suggestion for an explanatory interface. If only I had the time to play around trying to implement it. Sadly, I am busy with an immense list of work the OU wants finished by July, and it is already looking unlikely.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
A debug display of of the relevant information is a good idea.

And actually, although there is not a nice moodle interface to display this, in Moodle 1.9 it is readily available because of the work Martin Langhoff did optimising the roles system. Now, relevant roles information is stored in the session, so doing

print_object($USER->access);

will display everything in a not very readable format.

You could even make a simple PHP script (call is something like moodle/rolesdebug.php) like:

require_once('config.php');
require_login();
print_header_simple();
print_object($USER->access);
print_footer();

With more effort, you could do better, of course.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
You are right, there is the role:unassignself capability (http://docs.moodle.org/en/Capabilities/moodle/role:unassignself) but no corresponding assignself capability.

Of course, before you are enrolled in a course, you are unlikely to have a role, but for some situations (Course-creator or Inspector-like roles) it would be useful. Perhaps you should file a feature request in the tracker.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I'm afraid that any reason you can give for using roles basically reduces to 'Achieve greater flexibility'. But really that is a million reasons.

In the past, it was fixed: Only a teacher can do these things. Students should only be allowed to do those things. The only way you could change that was to change the code - with the exception of a few places like forums where options had been added manually. Of course, the pre-programmed roles were well designed, so most of the time, this inflexibility did not get in the way.

Now, teachers and administrators have the flexibility to decide what things whey want particular categories of users to be able to do. Of course, you still have the same tried and tested defaults, but when you want to step beyond them, you just have to twiddle some configuration settings. Don't want students to see their grades on this course? Tick. Want a few trusted students to moderate that forum? Tick. The possibilities are limited only by the teachers imagination. As I said above, there is only one reason for roles, but it is really a million reasons.

I've just finished reading the 2nd Edition of Helen and Jason's book (http://docs.moodle.org/en/Using_Moodle_book). In every chapter, they talk about the relevant capabilities, and ways you might want to override them. (John, I know you are an expert Moodle user, but I would recommend you get hold of this book - you probably want copies to leant to the teachers you are training - and then read it yourself first. It will tell you lots of things you already know, but the 'Effective Moodle Practices' section in each chapter has a lot of good ideas that it is worth reminding yourself of.)

Above, I say 'limited only by the teachers imagination'. I have to admit that that is not totally true. I think we are still slightly hampered by the user interface for managing roles. It keeps getting better, and it is certainly much better in 1.9 than it was in 1.7, but I think everyone agrees that there is more work to do.

Moodle in English -> Quiz -> quiz notification email -> Re: quiz notification email

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
MacOSX should not make a difference.

I assume you have followed the instructions on http://docs.moodle.org/en/Quiz_submission_email_notification

Have you checked that emails of forum posts are sent out for people subscribed to the forums? That would let you test that email is working in general for your Moodle.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I disagree, really powerful tools tend to be simple. Think XML (before they added the namespace complications!)

And any bunch of clown can publish something and call it a standard. It does not mean that Moodle should implement it, unless it brings some benefit to Moodle users.

I have yet to be given a single example where QTI support would be any use to anyone - but I am happy to listed to any you have.

But even it QTI support is useful, then like anything else, you have to balance "how useful is this" with "how much time would it take to implement" and decide whether it is worth the effort. And QTI support is a major project. Several developer months at the very least. (I think other projects to implement a QTI question engines have taken developer-years. e.g. http://www.jisc.ac.uk/whatwedo/programmes/programme_elearning_capital/eassessment/asdl.aspx)

If you had that much development resource there are much more immediately worthwhile new features you could implement - just search the tracker.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That is not a generic QTI importer. It is called "Respondus QTI Importer" importer for a reason - that is, because it imports the files created by the Respondus question authoring system. It just happens that these files are use a subset of QTI format, but that is about as useful as saying that Moodle XML import imports XML files, or GIFT imports text files. In fact, Moodle XML format imports a tiny subset of all possible XML files and the Respondus importer imports a small subset of QTI.

(This is not to criticise the Respondus importer. It is a very useful tool in it's own right.)


There are no plans I know of to make Moodle support QTI. It is just not a priority to people who want to create quizzes and share questions. It is sometimes a priority for people who have check-list of features they want their LMS/CML/VLE to meet. However, no-one has given me a convincing argument why QTI support is a worthwhile feature to have on the list. I do not know of any significant question banks in QTI format, and when people have wanted to transfer questions from another assessment system, it has always been easier to write specific importers, like the Respondus/Blackboard/WebCT/Examview/... ones.

The one thing that might drive adoption of QTI is the IMS Common Cartridge standard, which includes a subset of QTI. When there is useful content, including questions, in CC format, then we will want to support it.


I don't know if you have ever studied the QTI specification, but I have - or at least I have tried. It is an incredibly complex specification and as far as I can see, the only way to implement it is to adopt their data-model and processing model for question. In other words, it would take a major rewrite of the Moodle quiz to support it.

A more promising approach is to take one of the existing stand-alone QTI question engines that are being developed, and integrate it with Moodle in the same way that OpenMark and STACK questions have been integrated with Moodle. That uses a simple protocol that I invented (and named in tribute to the QTI specification) in order to do the OpenMark integration, and then the STACK developers were able to use the same protocol for their integration.

This is my preferred approach, because a QTI question engine is, necessarily, a large and complex piece of software in its own right. So it is not a sensible investment of resources for the Moodle project to write one of its own. It is more sensible for use to use the work of another open source project, in the same way that we did not write our own HTML editor, we used an existing one.

However, I don't think anyone is planning to make this happen because, as I have said, no-one seems to have any real need of QTI support in Moodle.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
As you may know, moodle stores an 'idnumber' for each user. This is often some sort of student identifier that means something to other systems outside Moodle. (Of course, not everyone uses this feature, but it is there.)

I have been asked by my masters at the OU to show this idnumber as an extra column in the grader report. It occurred to me that this might be useful for other people too, providing it is optional. So, would anyone else find this useful. If you would, please vote for MDL-13238.

I am assuming I can implement this by copying the grade_report_showuserimage setting that already exists.


Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
For transferring questions from one Moodle site to another, you definitely want to be using Moodle XML format. It is the only format that lets you export and re-import losslessly. But that only deals with the mechanics of transferring data.

Moodle itself should be capable of handling a huge question bank, particularly in 1.9. You can create as many hierarchical categories as you need. It is probably best to keep a large question bank in the Moodle database, rather than trying to manage it as a set of export files.

Tools for selectively exploring one Moodle site and deciding which questions to export, and then automating the export and import to your master site don't exist yet. But they could be written. It is relatively easy for another bit of code to use the qformat_xml class from /question/format/xml/format.php to selectively export whichever questions it wants to export. So you could write, for example, and admin report plugin for Moodle that lets you type in a course name, and the returns a Moodle XML file containing appropriate questions found in the database.

Then you could build some further levels of scripting on top of that, to automate things further.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Well, see chris collman's recent post in another thread which gives two not terribly satisfactory way to do this.

There is nothing build in to Moodle yet to achieve this. As Pierre says, because there could be many different question type plugins that we don't know about, this could only be done by adding to each question type a "print yourself out in a format suitable for proof-reading."

Actually, we could do this using the question import and export facility. Make a format called something like "XHTML (for proof reading)". We already have the facility for 3rd party question types to export themselves in certain formats.

There is also an existing feature request to be able to export all the questions used by a quiz, rather than all the questions in a particular category.

Both of those would take a bit of time, so are not likely to happen any time soon, but they are all sensible feature requests that it would be nice to get eventually.


Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The best way to follow everything that is changing in CVS is to subscribe to the CVS commits email list at http://lists.moodle.org/.

You certainly want to set up your email system to filter those messages into a separate mail folder - and possibly to only keep commits in /moodle, and discard those in /lang and /contrib.

The other good way is the use the git import of the Moodle tree provided by CatalystIT, one of the Moodle partners: http://git.catalyst.net.nz/gitweb?p=moodle-r2.git;a=summary
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I have never really understood how browsers turn the size="" attribute into an actual size. As long as there is enough space, I would not worry if it was slightly too big.

P.S. Forum search: You have go to advanced search to specify a forum.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Doh! of course, I should have realised this before. The major change is that between Moodle 1.5 and 1.6, the question types and the question bank code was moved out of the quiz module in into Moodle core. So the quiz in 1.6 and beyond is very different from 1.5.

Of course, that does not necessarily mean that your self-contained 1.5-based module cannot be made to work with 1.8.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Turns out that this problem was already fixed in 1.9.

I have now fixed it in 1.8 and 1.7. The fix is just to add:

require_capability('moodle/question:manage', $context);

after

require_login($course->id, false);

near the top of question/edit.php.

 
                    
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
That looks like about the right solution, only a better place to do 1. is in the random_qtype->print_question method.

I have filed this as MDL-13110. I have been busy with other things since Christmas, and so am falling behind on bugs reported to the tracker. However, rest assured I will make time to work on them as soon as possible. Hopefully next week.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
"So I decided different functionality for index.php and view.php."

This is almost certainly a very bad idea. You may make something work now, but there is no guarantee what it will go on working when you grade to Moodle 1.9, 2.0, 2.1, ...

A better idea is to make it a normal module, and add a single instance to the site front page, and then add code that stops you creating more than one instance in a course, or from adding it to any course other than the site front page.

Except do you really want a singleton. You only want one real instance, but what about for training courses, they may be an advantage to being able to create a second instance.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
My colleague Mahmoud is working on a new multiple choice with multiple answers question type with various scoring rules. Once it is finished, we will probably put it in contrib, but it may not be finished for a month or so.
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes, so in the user profile code, you know that that $USER is the global variable for the currently logged in user, and $user is a local variable that you can probably assume is the user whose profile is being displayed (well, that should be your first guess) so the if statement you mention above must be to do with some functionality that is different depending on whether you are looking at your own profile, or someone else's.