If anyone can explain why this works, I'd love to hear the explanation. How can I use my Teacher role in a User context when the Teacher role is assigned in a Course context? User and Course contexts are disjoint. They do not have a parent-child relationship. So how can a role assigned in one affect what the user can do in another?
Create three students, three teachers, and three courses. Assign roles as given in the following table:
||1 & 2
||2 & 3
||1 & 3
Once you have done that, log in as Teacher 1 and then use Login As with Student 1. Go to the front page and look at the course listing - what courses do you see? Teacher 1 should only be able to access Course 1 logged in as Student 1, and is not be able to access Course 3. And while you are able to do some things at the site level (such as send messages), you are not able to do others (such as change passwords).
Another example would be trying to do Login As with an Administrator account. Once again logged in as Teacher 1, add the administrator as a student to your course. Can you Login As the administrator?
Both these examples are against Moodle 1.9. If you take a look at /course/loginas.php, you'll see that Moodle keeps the original user's id as part of the context, thus preventing them from doing just anything as that user. I would probably advise keeping the
This is a huge wormhole in the capabilities system. If I am a Teacher in a course context and Teacher has been edited or overridden to have moodle/user:loginas permission, then I can login as any participant in my course. Then I can go to "my" user context and do all those evil things listed under Risks.
The fact that loginas has four Risk triangles isn't the solution. The underlying model is wrong. To login as another user should require loginas permission in that user's personal User context.
I understand from Petr that the security of the moodle/user:loginas capability has been greatly improved since Moodle 1.7 by allowing a user to log in as any other user, except users with the moodle/site:doanything capability.
The capability moodle/role:switchroles may be used as an alternative to moodle/user:loginas.
(2) switchroles is no substitute for loginas unless you are using roles in an extremely primitive way.
Why (2)? Because switchroles only lets you see what one of the other predefined role can see. If you're using roles in a sophisticated way, users have multiple role assignments in different contexts. Ultimately, the only way to see what these users see is to login as them.
Now I may seem to be arguing against myself. But I am not! There's nothing wrong with moodle/user:loginas per se. All I am saying is that it should be required in the user context, like other user-related capabilities.
A role with loginas is analogous to Parent. Parent is assigned in the user context, not the course context.
the security of the moodle/user:loginas capability has been greatly improved since Moodle 1.7 by allowing a user to log in as any other user, except users with the moodle/site:doanything capability.
OK, then I can login as anyone on the site except for admins. I choose a victim, manually enroll them in my course (they'll never know I did it), login as them, do something as them, log out as them, and unenroll them in my course. I don't even think it leaves a trace in the logs. For example, I just logged in as Teacher on demo.moodle.org, enrolled Martin D in my course, and sent you a message as him.
It is not even necessary for an admin to grant the teacher loginas. The teacher can grant it to himself! All he needs is the ability to override permissions for Student. With that ability, he can give Student loginas, then assign himself the Student role. Then proceed as above.
None of this would be possible if loginas were required in the user context, like all the other user-related capabilities.
IMO anybody that does not see this as a problem is wearing blinders.
You are the developing expert on this, but in practice we find this to be quite useful and there does seem to be reasonable limits on what a teacher can do when they use loginas. I would hate to increase the administrative burden of setting up this ability (like needing to go in by hand and add each teacher to each student at the course level to this role, etc.)
For example of the use, as a teacher I can log in as a student, see their view of the gradebook in my course, upload an assignment for them that I might have received by email, go in an close a quiz that they neglected to close (and hence which is not yet scored), see their view of the course (rather than a generic student view which in our environment with custom blocks and other features is different) etc.
Note, however, I can not then go from my course and enter another course as that student for which I am not a teacher, look at grades or change assignments in that course, etc. So it seems as if a teacher can affect the types of things that happen only in their course context.
True, there are some questionable things that a teacher can do, like make changes in the student's profile. But as a practical matter, historical hierarchy suggests that a teacher is higher up in the chain of command and that this ability probably prevents more problems and abuse than what it allows. But it is an inconsistency.
So, I guess I would be interested in your idea of a solution given the important uses above that would also not be a tremendous burden on the computer administration and that would minimize the possibility of opening security holes more than are already present.
You have articulated the use cases for loginas very well. I agree it is an essential feature, especially as "switch roles" becomes less and less useful to those of us who use roles in a sophisticated way.
Incidentally, I think that 99.9% of all "abuse" is the result of incompetence, not malice. Look at the top of the chain today (admins) and tell me how many of them have accidentally locked themselves out of Moodle because they fiddled with a user policy they didn't understand.
Let's say there's a role called CanLoginAs with a single permission, moodle/user:loginas = Allow. As Admin, I want to be able to selectively decide (a) who gets to have this role (b) who they can login as. The solution is to assign the role to (a) my trained and trusted users in (b) selected user contexts. Right now, I can do (a) but not (b) because loginas is tested in the course context.
I don't claim to have an efficient solution. The problem is identical to the problem of assigning Parents in the mentee's user context. Do we have an efficient solution for Parent? Does bulk upload work for Parent?
Bottom line is that convenience should never trump security.
First: I was inspired by your profile picture and ordered the Moodle license plate for Washington State for my car today
I guess if I were defining the capability policies, I would certainly not allow messages to be sent by a person with loginas authority. And if I did, It would certainly need to be clear who is was sent by (From Gary on the behalf of John, etc.)
As for changing profiles, I have less of a problem with this being part of the bundle of rights of one with this ability. Usually it is a teacher changing back the name of a student who has decided that they want to go by "Batman". I'm not sure if I would want the Moodle Master to be bothered by this
Of course, giving such ability at the site level where a role could log in as every teacher, change grades, see all user transactions, would be a big deal. That is where I see the risk.
While I might agree with you that convenience should never trump security in principal, practice is different. If you make things too difficult, people will open the flood gates, and that is where problems start happening. And I think that needing to manually go in and assign every teacher to every student and to restrict is so that they can only do so in the context of their own courses would be so burdensome, that I think we would lose the benefit you are hoping to gain because admins would shortcut the process by giving users too much authority.
I think we should reopen your bug report as a "new feature" so that it can remain as something that should be decided by consensus. I would be happy to continue the discussion until we come to the right solution.
As I pointed out earlier, it's not even necessary to give teachers loginas because they can give it to themselves as long as they have the ability to override at least one other role.
I hope we do continue this discussion .
Good luck with the license plate! I got mine almost 2 years ago. Moodle isn't that big in NJ, or I'm sure it would have been taken. Did you see this discussion?
It would probably be hard to implement, but if you use loginas to log in as Joe Smith in Course Security101, then you should only be treated as Joe smith in contexts inside course Security101, if you go outside there, you should revert to being just yourself.
However, that might be a hard change to implement.
I think you're describing how loginas works now. If you loginas Joe Smith in Security101, then you are restricted to the course context and Joe Smith's user context. If you venture outside either of those contexts, you don't revert to being yourself, but you are blocked with a variety of error messages. Moodle clearly understands that you're Tim Hunt logged in as Joe Smith. But in the course and Joe Smith's user context, you are not restricted in what you can do.
loginas in course context strikes me as a hack on what is otherwise a fairly clean model of roles and capabilities. You get a permission (loginas) in context A (course) which magically gives you the ability to do things in another context B (user); yet A and B are disjoint contexts! It is problematic to understand, let alone explain.
Re the tracker: I originally opened MDL-13854 "To login as another user should require loginas permission in that user's personal User context" but after a lot of discussion, both here and in the tracker, Petr changed it from a bug to a new feature request: "To login as another user could be assignable in User context too." IMO that does not really solve the problem because users can always assign themselves permissions for themselves behind the admin's back, and the things they can currently do with loginas in a user context are truly amazing. I would prefer to see loginas become a capability that could only be used in the user context.
To see whether this had worked, I logged in as the teacher and then I went to 'participants' to try to log in as one of the students in the course. I didn't see any 'login as' button as I can see when I access as administrator.
I'm wondering whether a solution for this problem (assuming that it cannot be solved in the way John has suggested) would be to assign this grad student the role of administrator. If I assign her the role of administrator in the context of that course, she won't have administrator permissions outside the course, right? Or will she?
What version of Moodle are you using? Allowing moodle/user:loginas works fine in Moodle 1.9.
I don't recommend that you assign the grad student the role of administrator in the course context, since this role should only be assigned as a system role.
I used to be very daring and use beta versions even on our production server. But now too many users are involved as more and more courses in our department are hosted in our Moodle installation and my headaches have increased. So I decided to play it safe. As I understand 1.9 is still beta.
So, the question is, can what John suggests be done in 1.8.4? I tried exactly the same steps John mentions but did not see the 'login as' button. Since Helen says that the administrator role, even if it is assigned within a course context, would give permissions to the assignee that would go beyond the course, this doesn't seem to be a good option. [edit, I had answered before reading all the messages] Although now I'm a bit confused because reading John's message after Helen's I see that he seems to think that any extra permissions my grad student would have by being administrator within the course would cease to be functional immediately after she leaves the context of the course.
So the question is is upgrading to 1.9 the only way to do what I want? Or would a simpler solution be to assign the 'administrator' role to this 'teacher' within her course?
Thanks a lot again for your help. I'm glad my problem has also been useful to think a bit more about the structuring of roles .
Allowing moodle/user:loginas works just the same in Moodle 1.8.4 as in 1.9. (However, Moodle 1.9 has now been released as a stable version. )
I suggest you create a test teacher account for trying out the moodle/user:loginas capability.
That's good to know. It comes at a good time because we have the Easter break to do the upgrade.
> Allowing moodle/user:loginas works just the same in Moodle 1.8.4 as in 1.9.
But now I'm confused again . I thought what I wanted to do was possible in 1.9 but not in 1.8.4. At least this is what I concluded from the discussion in this thread. You mean I won't be able to give permissions to teachers so that they can 'log in' as the students in their courses? Because this is what I was saying I cannot do in 1.8.4. I had understood from John's answer that he could do that in 1.9.
Just to clarify, you can enable a teacher to login as a student in 1.8.4 and in 1.9. However, as Matt C pointed out, you can't test the functionality by using the "Login as" button for a teacher then the "Login as" button for a student. Instead you should create a test teacher account and login via the login page.
Thanks to everybody that helped and, as I said, I'm glad my question triggered a discussion about roles which can only serve to make this functionality better and more secure.
It is possible in 1.9...it's just not set by default. Do the following:
1. Login as admin
2. At the site, click on Users/Permissions/Define Roles
3. Click to edit the Teacher role
4. Scroll down past about 9,000 settings until you get to "moodle/user:loginas" and change it to "Allow". Of course, you will see just about every security warning possible to the right of this setting...be sure you understand those risks as John has pointed out in this thread.
5. Scroll on past the remaining 6,000 settings and press "Save changes"
Then, just for future reference be sure to write down what you did because if you forget, you (nor anyone else) will ever see anything indicating you have made this change.
Then your teachers will be able to loginas students by simply clicking on their profile and clicking the loginas button and they can make changes to the feedback submissions as long as the feedback is not anonymous and is set to allow resubmitting.
5. Just go to the end of the page and press "Save changes"
True...I was making a point which I'm sure won't be lost on most people reading this thread
I'm sorry to resurrect this issue, but this is exactly the problem I'm having at the moment.
We're on v1.9+.
I login as admin, and edit the Teacher role, adding Allow to "loginas".
I logout as admin and login as Test Teacher. I go into Test Course, select Test Student from the list of participants and... still don't see the "Login As" button.
When I do exactly the same thing on our v1.8.3 instance, it works fine.
What am I missing on the v1.9 instance?
I hope you end up seeing this.
I have a test server running a moodle installation. We do this mainly because we've added some unusual customizations - mainly to the front page and it's it's something we are always developing.
I've looked in the rest of the docs and the forums and can't find an answer.
I have given another member of staff the loginas capability but when he opens a profile he sees no 'login as' button.
How does 'login as' actually work?
By the way I use it all the time but if giving the permission doesn't make the facility available, then what does?
ps: Moodle 1.9.5 (Build: 20090515)
Just wondering in what context you're allowing the login as capability? If applied in the course context, it allows a user to login as another course participant and browse within that course only. (Source: Capabilities/moodle/user:loginas)
To give another example we met:
- By accident a student got the role parent
- in the role parent we block the option to enrole in a course
- having the role student AND parent blocks the option to enrole.
(we find such problem quick with the script that shows all users roles (in context)
You didn't mention your version of Moodle. Which one are you using?
I tested this on 1.9 and it works. Here is exactly what I did:
- override Teacher in the course context, allowing moodle/user:loginas
- go to the course
- click Participants
- click on the name of any participant
- on the user's page, you should see a login as button
Let's figure out why the override isn't working for you.
I posted my last message before reading this one. Thanks Matt. This is exactly what I did. So you think this is the reason why I'm not seeing the 'login as' button? Or is this something I should expect anyway because I'm using 1.8.4 rather than 1.9. I cannot log in with the teachers credentials unless I change her password. That would not be a problem because after all I'm trying to help her but I'm a bit reluctant to do this without knowing for sure that this is really what the problem is. I guess on Monday I can ask her to access her account and see whether she can see the 'log in as' button.
by allowing "login as other users" - an instructor can login as other instructors in the course - and could essentially post to discussions as that other instructor.
Just wondering if there's a way around that - so that they could login as students but not other instructors?
Suppose teacher A has loginas = Allow in her course. This allows her to loginas any course participant. To prevent her from logging in as teacher B, who is also a course participant, you might try giving A loginas = Prevent or even Prohibit in B's User context (you would probably do this by creating a new role CannotLoginAs and assigning it to A in B's User context). But surprise! It doesn't work. The way the loginas calculation is done (see paragraph 1), since A has loginas permission in the course, her permission in User is simply ignored.
The only solution I can think of is to consistently assign loginas permission in User contexts. This would not involve the Teacher role, since the Teacher role is only assigned within courses. Instead, you would define a new role CanLoginAs with moodle/site:loginas = Allow and all other permissions Not set, and assign it to all teachers in their students' User contexts. This is similar to the problem we currently have assigning the Parent role, except the average "parent" in this use case has 150 children Needless to say this is NOT something you want to do unless you can automate it. Enhancements like MDL-14298 could help a lot here.
Why not have the student just download the feeback into Excel and make the changes there. If she is going do any analysis on the results she will need to download them anyway...she could just as easily make the changes after downloading instead of needing to log in as the students and make them before downloading.
Just a thought.
Thanks. That is indeed a good idea and eventually this is what we are going to have to do. I was resisting doing this at this point, though, because my student is not very experienced (in fact, she's never used it before) with Excel and I thought that it would be simpler for her, at this initial stage, to view the charts generated by Feedback directly in Moodle. The survey she has conducted contains an enormous amount of text and questions of different kinds (for 158 respondents) and managing it in Excel can get a bit unwieldy for somebody who is not familiar with spreadsheets (why a grad student at this day and age is not familiar with the basic functioning of a spreadsheet is another matter ). A lot of restructuring and cleaning up will be necessary to be able to extract the relevant graphic charts from the Excel spreadsheet. So I thought entering the data directly in Feedback and using the charts generated by Feedback for a first cursory look at how the data is shaping up would be simpler at this point.
Actually, in spite of what I'm saying and with all the difficulties I'm experiencing with the assignment of roles, the Excel solution you propose might turn out to be the only solution because we are experiencing problems accessing the surveys (even with my administrator role) once they have been completed. Andreas, the developer of this third party module, suggested this could be done if the feedback was nonanonymous by switching multiple submit to 'on' directly on the database. After that one can supposedly open the feedback as user again and edit the answers.
We did that in the following way:
ALTER TABLE `mdl_feedback` CHANGE `multiple_submit` `multiple_submit` INT( 1 ) NULL DEFAULT '1'
However, even after doing this I still cannot access the survey logging in as the student to add the answers that were missing . I still get the message saying that the survey is closed because it has been completed. So, when you imagine the time I've spent writing the messages in this forum, in the Feedback forum, my private messages to Andreas and the fiddling with the data base, I guess the solution you suggest would have been simpler and less time consuming after all . The thing is, this is something I wanted my student to be able to do.
I understand...and I can do what you are trying to do in version 1.6. Of course, I don't have "benefit" of the powerful roles and capabilities system to deal with
Good luck...the feedback block is one of the best, if not the best, 3rd party block out there, so I hope it can continue to work at least as well as it did before the roles "enhancements".
Your answer has left me a bit puzzled. I thought the problem we were having with Feedback was not directly related to the roles. The problem with the roles was indirectly related in that I wanted my grad student to be able to 'log in as' the different participants in the survey so that she could add the data they had forgotten to add. But, as I said, even with the role of administrator, I cannot access a survey that has already been completed even though I'm able to log in as the different users.
However, you say that in version 1.6 you are able to do that. How do you do it? This is something that shouldn't have changed from versions 1.6 to 1.8 of Feedback.
Everything is impacted by roles...and I haven't seen anything beneficial from a teacher's standpoint yet...only a lot of headache and unnecessary complexity.
In 1.6 it works exactly as Andreas said. If the survey is not anonymous and multiple submit is allowed (which can be enabled in the database for existing surveys that don't allow multiple submit) then the admin or teacher can loginas the student and edit the responses.
EDIT: In fact, if you like, just backup the course with the feedback in it and send it to me or give me a download link and I'll restore it to a 1.6 install and give you a teacher account so you can get your survey fixed.
After the problems we had with the migration to 1.8.4, we installed instances of all versions from 1.5.3 to 1.9 so that we can restore back up copies of courses as many times as needed to get them "clean". Usually all the way up to 1.9 and then back to 1.8.4.
So, we have a 1.6 installation as well. I'll do what you suggest in our own server since it is not me but the student who will have to do the work of going through the different surveys and completing the answers . Thanks again for your offer, though.
No problem...good luck.
OK, I tried to do as you suggested and attempted to restore a backup copy of this course in a 1.6 installation. I got the following error message:
- Creating temporary structures
- Deleting old data
|An error has ocurred|
And I cannot go on from there.
At this point I don't really know what else I can do. Changing the parameters in the data base as Andreas Grabs (the creator of Feedback) suggested doesn't allow me to access the survey (provided I made the right changes in the DB) and I cannot go back to 1.6 either.
Did you try going up to 1.9 with it...I've verified on my 1.9 test site that it does work like you want on a 1.9 install.
It will stay greyed out as long as there are completed surveys. But, if you change the multiple submit value in the database to 1 then it should read "Yes" when you look at it in Moodle. You should do this:
1. Login to your database with phpmyadmin
2. Select the mdl_feedback table (click on that table)
3. Click on Browse at the top
4. You will now see all of your feedbacks in that table. Find the one you are interested in and click the pencil
5. Change the multiple submit value from 0 to 1
6. Scroll down and press Go.
Now if you go to Moodle and click on update in the feedback you should see that the multiple submit field is still greyed out, but it should read "Yes". Now a teacher should be able to loginas any student and update their choices.
Thanks Josep...glad you got it fixed.