Restricted Student Role ?

Restricted Student Role ?

by Duncan Walker -
Number of replies: 9
Now that the Roles system seems to have taken over Moodle, for better or for worse, I'm trying my best to use it in the way that I think it should be used.

As an example, we allow our students to initially log on and create their profiles. However, even after imposing a policy document on them, there are some that still enter incorrect or unsuitable names in the name fields.

In the past I've had to hack the code to prevent viewing of the edit tab etc ... But with the Roles option I saw a perfect opening for a new Restricted Student role, where editing of profiles was prohibited / prevented.

I've tried numerous combinations of this and triple checked all possible parameters that would allow editing, yet I can still not get this role to actualy do what it should do. I've set up a dummy student and each time I log in I still have access to editing my profile !!

I'm running on the latest version of Moodle and would have thought by now that the whole Roles thing would have been resolved and be functioning as it suggests, but it seems not.

Does anyone have an alternative to hacking code, that will allow initial entry of details in a profile, but then give an option to prevent further editing for individuals ?
Average of ratings: -
In reply to Duncan Walker

Re: Restricted Student Role ?

by Petr Kalis -
Hi
Try go to Administration Users Authentication and for your used authentication (email I suppose) try Settings. There you have list of profile fields, by default set all to Unlocked, you may find useful (and wanted) menu option Unlocked when empty. Set this to firstname, lastname, and new users can create their profiles and when you will find some bad word, you can change them and users cannot change them back when editting.
Hope this helps.
PK

In reply to Petr Kalis

Re: Restricted Student Role ?

by Duncan Walker -
Hi, Thanks for your reply. Authnetication we use is through LDAP (windows Active Directory). I've looked at these settings before to Lock and Unlock fields, but this is a global change and not something I can assign to individual users. I appreciate your input though and hope that someone admits that Roles actually doesn't do what it says on the tin. I don't know anyone who has actually got Roles working as it should and with the mixture of Legacy roles as well, it just gets more and more complicated. I'd be more than happy to go back to no Roles at all and just have fixed users who can do something or can't.
In reply to Duncan Walker

Re: Restricted Student Role ?

by John Isner -
I tried disabling profile editing using roles and was also unsuccessful. For the record, here's what I did:

As admin:
  • Create a new role UserWhoCannotUpdateProfile, with capabilitiy "Update user profile" set to Prevent
  • On a particular user's profile page, click the Roles tab and assign the new role to the user
As the user in question:
  • Go to my profile page and click the Edit tab. I can edit my profile
I tried these variations:
  • Setting the value to Prohibit
  • Assign the role to the user Globally (site Administration -> Users -> Permissions -> Assign global roles)
  • Preventing "View user profiles"
  • Preventing "Edit user profiles" (edit vs. update -- what's the diff?)
As you noted, nothing works. The code (user/view.php) doesn't even check moodle/user:update capability. It checks Moodle/user:editprofile, but only to prevent someone OTHER THAN the user (such as teacher or a parent) from editing the profile.

There was an issue in the tracker (now closed!) MDL-8820. It doesn't seem to address the issue of a user updating (or editing, or whatever) his own profile. Only allowing or preventing others from doing so.

I created issue MDL-10775 "A user cannot be prevented from editing his own profile"

It is impossible, using the roles system, to prevent a user from updating (or editing, or even viewing) his own profile. For example, see discussion http://moodle.org/mod/forum/discuss.php?d=77540 where users describe various combinations of capabilities and contexts in which they have been applied.

A possibly-related issue, MDL-8820 "moodle/user:editprofile not working in user contexts," was closed. It seems to address only the ability of users to update/edit/view OTHER users profiles, not their own.

Rather than "going back to no roles," I would prefer to see roles fixed.
In reply to John Isner

Re: Restricted Student Role ?

by John Isner -
You can read the developers' comments on MDL-10775. This turns out to be a much tricker issue than we thought, and is probably not solvable using roles.
In reply to Duncan Walker

Re: Restricted Student Role ?

by Petr Kalis -
Hi
Well, whole roles idea is making my head spinning all the time, but as a classic said "Never give up, never surrender" big grin and tried to find a solution.

First: Create global role Restricted user or somethin like that, set his Legacy role to Authenticated user, and set him moodle/user:editprofile to Prohibit. You will use this role for "sinned" users who "tanteid" theirs profile and you dont want them to edit theirs profile ever again. (You will assign them this role in Administration > Users > Permission > Assign global roles)

Second: I looked throught file user/edit.php
and check part with lines

// check access control
if ($user->id != $USER->id) {
// teachers, parents, etc.
$personalcontext = get_context_instance(CONTEXT_USER, $user->id);
require_capability('moodle/user:editprofile', $personalcontext);
....

As i understood, this checks (require_capability part) if user can/cannot edit his profile by the capability "moodle/user:editprofile" .

But i think, that this check is called only on special occassion, when admin/teacher edit another user profile. For user himself it is never called(or i missed something obvious and will have butter on my head, nevermind, not for first time wink ).

So if you expand this section to :

// check access control
 if ($user->id != $USER->id) {
 // teachers, parents, etc.
 $personalcontext = get_context_instance(CONTEXT_USER, $user->id);
 require_capability('moodle/user:editprofile', $personalcontext);
 // no editing of guest user account
 if (isguestuser($user->id)) {
 print_error('guestnoeditprofileother');
 }
 // no editing of primary admin!
 $mainadmin = get_admin();
 if ($user->id == $mainadmin->id) {
 print_error('adminprimarynoedit');
 }
 }else{
 $personalcontext = get_context_instance(CONTEXT_USER, $user->id);
 require_capability('moodle/user:editprofile', $personalcontext);
 }

Or put the check call outside, i really dont know, why its only there, as i said, maybe i missed something really obvious and more experienced developer will correct me, but for me it is this place, where the problem lies.

I tried it, and it worked for me, just after you sent a user to "restricted bin", they cannot edit theirs profile any more.
So if you want to try it, let me know, how it went(dont forget to backup existing file ).
HTH.
PK
In reply to Petr Kalis

Re: Restricted Student Role ?

by John Isner -
Hi Petr,
I tried the same steps as in your paragraph "First" (note that the only difference between your experiment and mine is that you had Authenticated user as a legacy capability in your role, while I had None). I get the same result as before: the user is still able to edit his profile.

Do I also have to make the code changes for it to work?
In reply to John Isner

Re: Restricted Student Role ?

by Petr Kalis -
I think yes, you need to. I think that this is a bug, i cannot think a way, how would it be working without code change. But as i said, maybe i missed something and my change has some undesirable side-effect, or it is not needed.
I added attachment with modified file you can replace your file, if you dont want to digg into a code.(look for tag -dfa-)
PK
In reply to Petr Kalis

Re: Restricted Student Role ?

by Olu Bicoy -
Thanks for this info, I've been trying to figure out how to keep those wiseguys who simply land on the site just because or those kids who are just looking for trouble from self-registering under explicit usernames, etc.