Here is that table (grade_history):
http://docs.moodle.org/en/Development:Grades#grade_history
Martin Dougiamas
Posts made by Martin Dougiamas
The main issue with having a textual "teacher-to-teacher change note" (because we already have a "teacher-to-student comment" note) for each change (forced or not forced) is that the interface needs have a popup window come up every time you change a grade, asking if you want to add a note about this.
Otherwise we need a separate icon in every cell that allows that note to be added (as well as the icon already there for notes to the student). Two notes icons.
My gut feel is that this might be too much for most teachers, but if we have a user preference for this (defaulting to off) then it should be OK.
The other (automatic) information we'll have from the log is:
- the grade item
- the user the grade belongs to
- the grade value before
- the grade value after
- the person who changed the grade
- the exact time it was changed
- how it was changed (manually, via module etc)
1. Ger, what do you mean by three levels instead of two?
2. Yes, an overview of "all my courses" is really easy to do now. It's just another report plugin acting on the same data. It would have a different appearance I would think, because it's more of a summary. Does anyone want to try a visualisation of how that should look?
2. Yes, an overview of "all my courses" is really easy to do now. It's just another report plugin acting on the same data. It would have a different appearance I would think, because it's more of a summary. Does anyone want to try a visualisation of how that should look?
I don't see a problem here. It's not really a cross-module call. 
The event is flagged with data attached and Moodle says: "who wants it"! It's completely passive. Only modules that ask for it will be sent the data.
The standard old pattern we use is to load ALL the lib files and search for a function, which is effectively the same thing but less efficient.
The coupling will actually be looser than it was because we are passing everything in one object parameter, and because module functions NEVER call each other directly.
Once the requested data is passed to the handler function it examines the object and if it can't find all the info it needs or wants then it just terminates immediately.
The event is flagged with data attached and Moodle says: "who wants it"! It's completely passive. Only modules that ask for it will be sent the data.
The standard old pattern we use is to load ALL the lib files and search for a function, which is effectively the same thing but less efficient.
The coupling will actually be looser than it was because we are passing everything in one object parameter, and because module functions NEVER call each other directly.
Once the requested data is passed to the handler function it examines the object and if it can't find all the info it needs or wants then it just terminates immediately.
We can't change 1.6, but have you tried this yet against 1.9 / HEAD?
How are you finding the speed of TinyMCE? A year ago it was really slow to load in Moodle ... is that better now?
How are you finding the speed of TinyMCE? A year ago it was really slow to load in Moodle ... is that better now?