|
I've just checked with Tim, who says:
Guests can never attempt quizzes, because quiz responses and scores are stored in the database associated with a userid, and it would be confusing if all guests saw all other guests attempts. Also, there can only be one open attempt per userid at one time. It turns out that you can allow guests to preview a quiz, and that works up to a point. Since grades for previews are not stored long-term, that problem does not arise. However, you still have the problem that at most one preview attempt per userid can be active at any one time. So basically, this only works if you can be sure that so few guests will preview your quiz, that you will never get two of them trying to preview it at the same time. As I understand it, the Guest ROLE is assigned to the guest USER when someone logs in as guest. What this user can or cannot do should therefore be controlled by the role. But you are saying this is only half true: Although the Guest role has a capability for attempting quizzes, its value is ignored (and so-on for many other Guest capabilities).
My biggest problem with this is that it makes the Guest role impossible to explain. People have to read the code to find out which Guest capabilities work and which ones don't. My other problem is there doesn't seem to be any sound technical reason for it. If guest (small g) is really and truly an account, then guest should be able to do everything that a normal user could do, including posting to forums (I have posted to forums outside Moodle as guest). They could even attempt quizzes. The documentation would simply have to explain that the quiz results are meaningless, since you may be attempting the quiz at the same time as hundreds of other guest users. Again, I have experience with systems that allow guests to take quizzes. I think we have three options: (1) make the behavior of Guest role fully controlled by its capabilities (2) remove Guest capabilities that are ignored to prevent confusion (3) remove the Guest role and go back to legacy guest behavior, which is pretty much what we have anyway. Option (1) would be my choice. Re: Tim's comments: I did not want us to get fixated on the details of specific activities. Let's please focus on the broad issue of why we have Guest capabilities that are ignored.
If allowing something causes confusion (which is the worst case scenario for allowing quiz attempts or previews), then the solution is simple: don't set the capability to Allow. But control should rest in the hands of Moodle Admins and Teachers through roles and capabilities. If I had known this was not a simple case of legacy code needing to be updated, I would have classified it as a Major Bug.
Duh! It turns out that Guests CAN post to Forums.
Forum puts up a double wall for Guests. The outer wall tests for the legacy capability and the inner wall tests the normal forum capabilities. So to let Guests participate in a forum, you need to – open the outer wall by setting Guest's Legacy role type to None I don't understand the purpose of the outer wall. It can be breached by anyone who knows how Legacy capabilities work. Quiz is a different story. It also has an outer wall and an inner wall, but the outer wall cannot be breached. The outer wallcalls isguestuser(), which tests user's account, not his capabilities. So anyone logged as userid guest will never be able to attempt quizzes. Different modules ought to implement consistent policies with respect to Guests. The current state of affairs is confusing, to say the least. Unless I'm missing something, modules have no need to test for the legacy capability. The normal capabilites are sufficient. Modules should certainly never test isguestuser(). Without much time to examine this in depth, I just wanted to comment that some of the motivation here behind some of the code was about always being able to identify who wrote what. Accounts are cheap, there's no limit to them. If you need a guest account where people can construct artifacts (which is unusual) then you can make a new real account for that and set it up exactly how you like.
That said, the way guest behaves could certainly use a big review and cleanup across the whole system. Various people have worked on it at different times and implementing it under roles brought a whole new set of complications. Though this issue is about the forum module, it also applies to the chat module. A guest user, despite being properly permissioned, cannot participate in a chat activity. Even working through the "double wall" as John referred to it does not give a user access to participate in a chat module.
I created a chat activity, changed the guest user to Legacy role None and with the permission to talk in a chat and read chat logs. When a guest goes into the chat activity it says, "The chat is not open to guests Would you like to log in now with a full user account?" And the guest user thus cannot participate. Interestingly enough, performing those exact same steps in a Moodle 1.7 install will allow the guest user to participate. We had a client who was using this feature in Moodle 1.7 and, when they requested an upgrade to 1.9, found they could no longer do this. I think Martin's last comment about a review of guest behavior would be terrific and I agree with John's preference for having the guest role behave as indicated in his #1 scenario. Hello,
this is our security policy - guest user account can not submit any information that is stored permanently, sorry. We might add some special configuration option in 2.0 which would allow you remove this important restriction. Please note that it would be still strongly discouraged. In any case all guest related code needs to be reviewed & improved & rewritten. Petr |
|||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Open
Minor
"Sorry, guests are not allowed to post" is legacy behavior
 |
|
Thanks for your comments. I was under the impression that guests could never attempt quizzes though, no matter how the permissions are set.
If this is no longer the case then http://docs.moodle.org/en/Guest
needs updating.