Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

by Valery Fremaux -
Number of replies: 5

Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

These methods were all stored in the deprecatedlib.php because they rely on an old rigid role mapping prior to 1.7. They still work but should be abandonned, so how to get rid off them ?

A solution is to have an adequate use of the capacity model :

I posted an old methodology (in french) for developers that wanted to know the process to use capability model in a new project http://moodle.org/mod/forum/discuss.php?d=83835.

I will have it soon translated in english.

Step 1 : Create capabilities that are characteristical of a particular legacy role.

The only thing to do is creating a capability which semantic clearly discriminates the teacher, non editing teacher or student or even guest.

These capabilities are added to the db/access.php as said in the developer doc on docs.moodle.org or in the above post.

Let setup a very emblematic capability :

'mod/module:isteacher' so defined :

    'mod/module:isteacher' => array(

        'captype' => 'read',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'student' => CAP_INHIBIT,
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'coursemanager' => CAP_INHIBIT,
            'admin' => CAP_INHIBIT
        )
    ),
 
and another one 'mod/module:isstudent' defined as :

    'mod/module:isteacher' => array(

        'captype' => 'read',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'student' => CAP_ALLOW,
            'teacher' => CAP_INHIBIT,
            'editingteacher' => CAP_INHIBIT,
            'coursemanager' => CAP_INHIBIT,
            'admin' => CAP_INHIBIT
        )
    ),

Step 2 : review the code and replace oldway functions

The function isteacher() will be changed in :

$context = get_context_intance(CONTEXT_MODULE, $idmodule);
has_capability('mod/module:isteacher', $context);

for the current context (what copes within a module copes for a block or a course). 

In the same way, function isstudent() should be rewritten as :

$context = get_context_intance(CONTEXT_MODULE, $idmodule);
has_capability('mod/module:isstudent', $context);

also in the current context. 

To replace get_course_teachers() or get_course_students(), you may ask for the users who have this capability in the current context :

$teachers = get_users_by_capability($context, 'mod/module:isteacher', 'u.id,firstname,lastname,picture,email', 'lastname');

This would be done either with the 'mod/module/isstudent' capability. (fields which were asked for are usable for a fullname or a print_user).

There is of course absolutely no need to add role discriminating explicit capabilities, and this selection could be done with capabilities that have more functional signification.

Average of ratings: -
In reply to Valery Fremaux

Re: Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

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 the right approach, because it does not let you do things more flexibly in the future.

A better approach is to ask: What are the things that students can do in this module? What are the things that teachers can do? and so on.

For example, in the quiz, Students can
* View that the quiz exists and read the introduction (mod/quiz:view)
* Attempt the quiz (mod/quiz:attempt)

Teachers can additionally
* Preview the quiz (mod/quiz:preview)
* View the quiz reports (mod/quiz:viewreport)
* Manage which questions are in the quiz (mod/quiz:manage)
* and so on ...

This tells you which capabilities you should create, and for each ifteacher() call in the code, you need to work out what the code inside the if statement, and then replace it with the appropriate has_capability call.

This is harder work as you convert your module to the roles system, but the benefits are:

1. It gives administrators much more flexibility when deciding which users can do which thing with your module.

2. It makes your code much easier to understand, because if you see if (!isteacher()), the all you know is that the code is something to do with what students can do. If you see if (has_capability('mod/quiz:attempt')) then you know that the code is something to do with students (or whoever) attempting the quiz.
In reply to Tim Hunt

Re: Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

by Valery Fremaux -
I agree it was a shortcut for pre 1.7 existing modules. The referenced article in French I mentionned fits more Tim's approach I fully agree with for new module implementation. 
In reply to Valery Fremaux

Re: Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

by Eric Merrill -
Picture of Core developers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
To me this seems like a 2.0 thing. Is this what you guys are thinking?

-eric
In reply to Eric Merrill

Re: Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

by Martín Langhoff -
This is a v1.7 thing, called roles and capabilities wink It'd be great to have a brief 'howto' -- the approach Valery & Tim discuss is good, and matches our practices here, but it wasn't obvious at the beginning.
In reply to Martín Langhoff

Re: Methodology : Replace deprecated functions isteacher(), get_course_teachers(), isstudent(), get_course_students()

by Eric Merrill -
Picture of Core developers Picture of Moodle HQ Picture of Peer reviewers Picture of Plugin developers Picture of Testers
Well, I was more meaning killing the depreciated functions.

To me it seems to make sense for that to be something as a part of 2.0 compatibility for plug-ins and modules. Maybe I'm just confused as to what you guys are referring to, and Ill just shut-up now...

-eric