Moodle

Andreas - I am not sure what the logic was behind not allowing users with the ability to edit questions to participate in a feedback. For Colin's site, I have at least temporarily modified the code. For me the lines in question are:

if($feedback->anonymous == FEEDBACK_ANONYMOUS_YES AND !$capabilities->edititems) {

and

if($capabilities->complete AND !$capabilities->edititems) {

Why is the complete capability not sufficient? What is it that we are trying to prevent by having the not editterms? Sorry if I am missing something obvious.

Peace - Anthony

Colin - Just a reminder that it helps if you could email me when you create an issue for the JSEA so that I can watch and vote for it. This one apparently slipped past me. Also, it would be good to add it to the JSEA public task list in Outlook under Documentation - Moodle tracker issues. Let me know if you have any questions. I try to maintain the list by order of the tracker number. Peace - Anthony

Hi Anthony,

oops, I don't know what devil was riding me . I think I have just converted to roles at that time and not verified the new logic.
Can you be so kind and check in the changes for me. I'm absolutely busy until september and will not be able to do this before.
Thank you very much!
Andreas

Andreas - I know the feeling. I have checked in the changes and will go ahead and resolve this as fixed. Best of luck on your current work. Peace - Anthony

Patch applied to CONTRIB 19STABLE and core HEAD. Peace - Anthony

Hi Anthony & Andreas. I think this needs to be revisited. The change here results in everyone being given the 'complete' capability on an anonymous feedback, possibly in conflict with the capabilities set elsewhere. For instance, we are using anonymous feedbacks for end-of-term course evaluations, and do not want teachers to be able to answer the questions. We have the mod/feedback:complete capability for the teacher role set to 'prevent' (the default), but the code overrides that setting. Would it not be better to let the feedback simply use the capabilities as defined via the roles/permissions interfaces, or am I missing something?

We've commented out this bit altogether, which allows admins to set or override the complete capability for different roles as needed:

if($feedback->anonymous == FEEDBACK_ANONYMOUS_YES ) {
$capabilities->complete = true;
}

Ann - thanks for your attention to the behavior. Could you give me a little more thorough explanation of the example and how you envision that it should behave. I am coming back to this issue cold - it has been too long since I've looked at the code. What I think I am hearing is that there is a capability for completing the feedback activity and that by default for a teacher or the owner of the feedback it should be set to true, allow the owner to complete; however, you want to be able to do an override of that functionality so that be default the teacher cannot participate in the feedback. I wonder how this is impacted by a feedback within a teacher's course and one that reports the results back to a public setting (forgive me if I am conflating feedback and questionnaire). But if you could give a few scenarios that I could use to ensure that everything is working properly that would be helpful (of course a patch would be even more helpful . Peace - Anthony

Hi Anthony - I'll try to clarify. Currently, there is a mod/feedback:complete capability. The default setting for a teacher is 'prevent' and the default for a student is 'allow', which is fine. As an admin I should be able to change or override it if I want things to behave differently.

Now, with a non-anonymous feedback, whatever the 'complete' capability is set to is being honored. If I leave the capability to 'prevent' for teachers, teachers cannot answer the questions. If I change it to 'allow', they can. This is just what I would expect.

With an anonymous feedback, however, the code snippet above sets the 'complete' capability to true for everyone - and admin settings for that capability are just ignored. For instance, if I leave the mod/feedback:complete capability for the teacher role set to 'prevent' , teachers can answer the questions anyway.

I may be missing something, but I don't think it should be necessary to set that 'complete' capability to true in the code for anonymous feedbacks.

Thanks,
-Ann

Patch attached.

Ann - Thanks for the clarification and the patch. I think I may have added in the code you suggest removing to allow guests to be able to complete anonymous feedbacks. But this also can be implemented by role overrides so I see no good reason that your patch cannot be applied and removing the those lines which were a bit hacky anyway. I think removing them is better as it will make the role behavior a bit more pure. I agree with and like your line of reasoning. Thanks for your attentiveness to these details and their practical implications. I will let Andreas make the final determination and commits unless he wants to assign this to me. Peace - Anthony

Hi Ann,

the reason for this behave is to offer a possibility to fill out a feedback without any preceding login. The problem is, that before the user is logged in, there are no capabilities which can be checked.
Your suggested patch would avoid this possibility.
Nevertheless you are right. This behavior should be controllable. I think a good way to give or give not the possibility for full anonymous feedbacks could be a property page for this module on the module administration page.

Andreas

Ah, that makes sense. We don't let anyone to do anything without logging in, so I tend to forget about that possibility. ;-o
However, wouldn't overriding the guest role to set 'mod/feedback:complete' to 'allow' be enough to let users complete feedbacks without logging in?

Thanks, -Ann

Hi Ann,

you are right if the feedback is on a course. But if the feedback is located on the main site the user is not a guest.
I have submitted the changes on cvs. I think the feedback should now work as expected.
Now you will find a new global setting for the feedback-module.
The check is now:
if(isset($CFG->feedback_allowfullanonymous)
AND $CFG->feedback_allowfullanonymous
AND $feedback->anonymous == FEEDBACK_ANONYMOUS_YES ) {
$capabilities->complete = true;
}

Andreas

Ok, the feedback now has a new settings page where can be defined whether fullanonymous is possible or not. If fullanonymous is possible all users can fillout a feedback on the frontpage what is defined anonymous.
The feedback-module now will respect the settings for complete-capability for the admin too.
Andreas

just quick notice:
/mod/feedback/settings.php: line 5 : the referenced string is not in the lang pack ('allowfullanonymous')

and also 'configallowfullanonymous'.

Sorry for the thousand edits

Now the string has been integrated.
Thank you!
Andreas