Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-33823

The "My Courses" listing is inconsistent (Authenticated user see all courses as his courses), as there is no capability to control course listing for users, and all courses are always public if available to students.

    Details

    • Database:
      Any
    • Testing Instructions:
      Hide

      How to reproduce this error:
      Create one or more Moodle courses.
      Try to make some courses visible to everyone (public) and others not (non-public) from the courses lists.
      Try to enrol someone as a student (normal capabilities) to one non-public course. Then access Moodle as that student to see if he can now see that non-public course. Then enter that course as that student.
      Try to create a role based on Autheticateh users that would see those non-public courses, but with extra courses listing visibility.

      Show
      How to reproduce this error: Create one or more Moodle courses. Try to make some courses visible to everyone (public) and others not (non-public) from the courses lists. Try to enrol someone as a student (normal capabilities) to one non-public course. Then access Moodle as that student to see if he can now see that non-public course. Then enter that course as that student. Try to create a role based on Autheticateh users that would see those non-public courses, but with extra courses listing visibility.
    • Workaround:
      Hide

      Patch included.

      Show
      Patch included.
    • Affected Branches:
      MOODLE_20_STABLE, MOODLE_21_STABLE, MOODLE_22_STABLE

      Description

      I could reproduce this problem under every Moodle 2.x until now.

      PROBLEM:
      There is no way to hide courses from users' courses listing that would not remove their possibility to enter them if they are enrolled there.
      It would be great to enable setting the courses as public/non-public from the course listing perspective. Also, creating a system-wide capability to provide or not the users to view only public courses, or all of them would be a great advance on access control. This could change the courses list and the courses search, returning only 'listable' courses for users, regarding the course setting and the user capability.

      There is also the problem that a user should not be able to search courses in the platform, if he is not strictly able to do so. The print_course_search() method @ '<MOODLE_URL>/course/lib.php' should only return the course search field is the user has the capability to see them.

      I set this as a possible security issue, as there are several Moodle sites where the users must see only the courses which he is enrolled to, or only the courses that as public for listing.

        Gliffy Diagrams

        1. course_visibility.patch
          9 kB
          Luis Gustavo Mueller de Alcantara
        1. default_authenticated_user.png
          49 kB
        2. default_authenticated_user-student_in_one_course.png
          36 kB
        3. default_not_logged_in.png
          30 kB

          Issue Links

            Activity

            Hide
            skodak Petr Skoda added a comment -

            Hello,

            course:view is used only for access into courses, it is not supposed to block listing of courses. If you want to prevent course listing the only way at the moment is to hide categories. I am proposing to close this as "not a bug" because it works as expected.

            Petr

            Show
            skodak Petr Skoda added a comment - Hello, course:view is used only for access into courses, it is not supposed to block listing of courses. If you want to prevent course listing the only way at the moment is to hide categories. I am proposing to close this as "not a bug" because it works as expected. Petr
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi Petr,

            I see your point, but there are some usage that would be incorrect if that is taken as the "correct" way. We do not want to prohibit the students from seeing these courses, we want that 'only enrolled users' could see them. I understand it is quiet close one from another, but let me explain it better:

            • If you get one or more course enrollments, the mycourses screen will show only these courses, else, it would show all of them (my courses? I have none...);
            • If the course category is hidden, any student (by default without the capability 'moodle/course:viewhiddencourses') would not be able to see those courses anymore, but we want those students enrolled to that course still able to use it;
            • We do not want to hide the courses from every students (the approach you suggested), we must hide the courses from those students who are not allowed to see the courses because they are not enrolled to them (if they do not have the 'moodle/course:view' capability);
            • There is also an overriding for this, at the navigation block, that would still show all the courses if set up to be used in that way (support included in the patch).

            Please be pacient and take a close look at this. I believe You will agree with me.

            Thanks for your patience and support,
            Luis Alcantara

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi Petr, I see your point, but there are some usage that would be incorrect if that is taken as the "correct" way. We do not want to prohibit the students from seeing these courses, we want that 'only enrolled users' could see them. I understand it is quiet close one from another, but let me explain it better: If you get one or more course enrollments, the mycourses screen will show only these courses, else, it would show all of them (my courses? I have none...); If the course category is hidden, any student (by default without the capability 'moodle/course:viewhiddencourses') would not be able to see those courses anymore, but we want those students enrolled to that course still able to use it; We do not want to hide the courses from every students (the approach you suggested), we must hide the courses from those students who are not allowed to see the courses because they are not enrolled to them (if they do not have the 'moodle/course:view' capability); There is also an overriding for this, at the navigation block, that would still show all the courses if set up to be used in that way (support included in the patch). Please be pacient and take a close look at this. I believe You will agree with me. Thanks for your patience and support, Luis Alcantara
            Hide
            skodak Petr Skoda added a comment -

            1/ course:view is for managers only and is supposed to allow access to course without enrolment - nothing else, this will not be changed
            2/ list of "My courses" contains all courses I am enrolled in, category visibility is completely ignored - this was optional in 1.9, it will not change in 2.x

            I have renamed the issue because it was mentioning course:view capability which was not correct, feel free to rename it again. I agree that course listing based on one tree of contexts is not flexible enough. Thanks a lot for the report, hopefully other developers will join the discussion. It might be better to post in moodle.org forums too to get more attention from developers, admins and teachers.

            Petr

            Show
            skodak Petr Skoda added a comment - 1/ course:view is for managers only and is supposed to allow access to course without enrolment - nothing else, this will not be changed 2/ list of "My courses" contains all courses I am enrolled in, category visibility is completely ignored - this was optional in 1.9, it will not change in 2.x I have renamed the issue because it was mentioning course:view capability which was not correct, feel free to rename it again. I agree that course listing based on one tree of contexts is not flexible enough. Thanks a lot for the report, hopefully other developers will join the discussion. It might be better to post in moodle.org forums too to get more attention from developers, admins and teachers. Petr
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Ok Petr, we are almost there.

            Please, have one last reading about this.

            1- I do agree with you that the 'moodle/course:view' capability is for meant for admninistrative usage only, and that is the main problem I reported there. The issue I pointed, is that if I am a 'Authenticated user' I do not have the 'moodle/course:view' capability, and so, I could not see all the courses in the platform, but I DO!!! And as Moodle is such a great platform, with all those contexts, roles and capabilities possibilities, why don't we use them? The patch I included there just makes things built under that flexibility work as they should.

            2- The list of "My courses" must show only 'My courses', of course. But this is not happening as I am only an 'Authenticated user', and so, I have NO COURSE yet. Sadly, I could see all courses under that situation, and this is getting us many troubles. We must create a dummy course to every new Moodle user (like a welcome course), to make things work as they should.

            Please help us on this. And thanks for pointing the Forum post, I will make one post about it.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Ok Petr, we are almost there. Please, have one last reading about this. 1- I do agree with you that the 'moodle/course:view' capability is for meant for admninistrative usage only, and that is the main problem I reported there. The issue I pointed, is that if I am a 'Authenticated user' I do not have the 'moodle/course:view' capability, and so, I could not see all the courses in the platform, but I DO!!! And as Moodle is such a great platform, with all those contexts, roles and capabilities possibilities, why don't we use them? The patch I included there just makes things built under that flexibility work as they should. 2- The list of "My courses" must show only 'My courses', of course. But this is not happening as I am only an 'Authenticated user', and so, I have NO COURSE yet. Sadly, I could see all courses under that situation, and this is getting us many troubles. We must create a dummy course to every new Moodle user (like a welcome course), to make things work as they should. Please help us on this. And thanks for pointing the Forum post, I will make one post about it.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi Petr,

            I found a better way to explain myself.

            Regarding roles, Authenticated users is less permissive than Students.
            Every Student is also an Authenticated user.

            How come, in a Moodle site with 1000 courses, an Authenticated user sees all those 1000 courses, and as he gets enrolled to one of them, he can see only that one? He loses all those other courses?

            Let me remind you that Authenticated users and Students do not have the 'moodle/course:view' capability.

            As you said earlier, all courses should be shown to administrators only (by default). We might still show all courses under the Navigation block if (and only if) the user has that permission, or the navigation block is configured to force that approach.

            Thank again,
            Luis Alcantara

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi Petr, I found a better way to explain myself. Regarding roles, Authenticated users is less permissive than Students. Every Student is also an Authenticated user. How come, in a Moodle site with 1000 courses, an Authenticated user sees all those 1000 courses, and as he gets enrolled to one of them, he can see only that one? He loses all those other courses? Let me remind you that Authenticated users and Students do not have the 'moodle/course:view' capability. As you said earlier, all courses should be shown to administrators only (by default). We might still show all courses under the Navigation block if (and only if) the user has that permission, or the navigation block is configured to force that approach. Thank again, Luis Alcantara
            Hide
            salvetore Michael de Raadt added a comment -

            Hi, Luis.

            It is still possible for a student to get to the list of all courses (/course/index.php), but we don't link to it in navigation, we only show a button on the home page.

            I suggest you start a new issue that reflects the desired functionality you would like to see.

            Show
            salvetore Michael de Raadt added a comment - Hi, Luis. It is still possible for a student to get to the list of all courses (/course/index.php), but we don't link to it in navigation, we only show a button on the home page. I suggest you start a new issue that reflects the desired functionality you would like to see.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi Michael,

            That's exactly my point. The '/course/index.php' page (and all other ones) must show the courses, ONLY FOR THOSE TO WHOM THE RIGHTS TO VIEW THEM ARE GRANTED. It you have somehow an option (even hidden to a normal user) that overrides the capabilities, it is a clear security issue. The same odd behavior can be achieved from '/course/category.php?id=<INT_CATEGORY_ID>', and from the profile editing at the navigation block, and so on.

            This patch I included is able to make those capabilities match their purpose. Even if you have 5 courses into a category, and you have the capability to see only two of them, this is what you will be able to see. And even more, it also supports the alternative way (already implemented in that block configuration before) that an administrator could use to force always showing all the courses in the navigation block, if he desires that behaviour apart from the course viewing capabilities, as it was meant to be.

            Let's take a step even further, and talk about cohorts. Moodle enables to split users creating contextualized groups, system wide or category/sub-category wide. We are clearlly able to create courses for different age groups, and the behavour you described is clearly capable to show adult restricted content to a six years child, if it is in the course list.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi Michael, That's exactly my point. The '/course/index.php' page (and all other ones) must show the courses, ONLY FOR THOSE TO WHOM THE RIGHTS TO VIEW THEM ARE GRANTED. It you have somehow an option (even hidden to a normal user) that overrides the capabilities, it is a clear security issue. The same odd behavior can be achieved from '/course/category.php?id=<INT_CATEGORY_ID>', and from the profile editing at the navigation block, and so on. This patch I included is able to make those capabilities match their purpose. Even if you have 5 courses into a category, and you have the capability to see only two of them, this is what you will be able to see. And even more, it also supports the alternative way (already implemented in that block configuration before) that an administrator could use to force always showing all the courses in the navigation block, if he desires that behaviour apart from the course viewing capabilities, as it was meant to be. Let's take a step even further, and talk about cohorts. Moodle enables to split users creating contextualized groups, system wide or category/sub-category wide. We are clearlly able to create courses for different age groups, and the behavour you described is clearly capable to show adult restricted content to a six years child, if it is in the course list.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi guys,

            I'm not saying that the user must have the 'moodle/course:view' capability assigned to him, as a necessary prerequisite to see the Course. It would be a mess...

            There are many other usages that would enable the user to see a Course, like being a site Manager, or a Course Creator, or a Teacher/Non-Editing Teacher/Student enrolled to the course, or a Guest if Guest access granted to the Course, or has the capability to view the course (Back to the Manager). If I have one of those conditions, then I should be able to see the related courses, otherwise I would not. We are not talking about granting 'moodle/course:view' capability to students and so on (it makes no sense), but that users that do not have any of those conditions should not be able to see the courses, nor even listed to them, unless the administrator grants access to those throught the Navigation Block checking the 'navshowallcourses', that garantees the listing of all the courses in the platform, independently if the user has access to that course or not.

            If that is not the point, I do not see why all those contexts/roles/capabilities/permissions/enrolments/participations stuff implemented, if their behavior are not consistent. Once I am an Authenticated user, I see all Moodle courses in the "My Courses" page (my courses?), once I get enrolled to one course, I am still an Authenticaded user, but the "My Courses" page shows me only the Courses I am enrolled to (great), and I loose the ability to list de other courses, unless I click the 'All courses' Button (if enabled), or I know the target link (security issue).

            But that is not the worst part. The problem is that I can not restrict access to Users from Courses even if I want to do that, having all those rules implemented. It is a waste of effort. We are pretty close on achieving that, Moodle is 99% ready, and that is what this post is about.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi guys, I'm not saying that the user must have the 'moodle/course:view' capability assigned to him, as a necessary prerequisite to see the Course. It would be a mess... There are many other usages that would enable the user to see a Course, like being a site Manager, or a Course Creator, or a Teacher/Non-Editing Teacher/Student enrolled to the course, or a Guest if Guest access granted to the Course, or has the capability to view the course (Back to the Manager). If I have one of those conditions, then I should be able to see the related courses, otherwise I would not. We are not talking about granting 'moodle/course:view' capability to students and so on (it makes no sense), but that users that do not have any of those conditions should not be able to see the courses, nor even listed to them, unless the administrator grants access to those throught the Navigation Block checking the 'navshowallcourses', that garantees the listing of all the courses in the platform, independently if the user has access to that course or not. If that is not the point, I do not see why all those contexts/roles/capabilities/permissions/enrolments/participations stuff implemented, if their behavior are not consistent. Once I am an Authenticated user, I see all Moodle courses in the "My Courses" page (my courses?), once I get enrolled to one course, I am still an Authenticaded user, but the "My Courses" page shows me only the Courses I am enrolled to (great), and I loose the ability to list de other courses, unless I click the 'All courses' Button (if enabled), or I know the target link (security issue). But that is not the worst part. The problem is that I can not restrict access to Users from Courses even if I want to do that, having all those rules implemented. It is a waste of effort. We are pretty close on achieving that, Moodle is 99% ready, and that is what this post is about.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Maybe this title represents better the reported problem.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Maybe this title represents better the reported problem.
            Hide
            salvetore Michael de Raadt added a comment -

            Thanks for working on this issue, Luis.

            Perhaps a new capability is needed to control this, so that in less open sites, unenrolled but authenticated students cannot see the available courses.

            Petr, I've assigned this to you as you seemed interested. Feel free to reassign if you wish.

            Show
            salvetore Michael de Raadt added a comment - Thanks for working on this issue, Luis. Perhaps a new capability is needed to control this, so that in less open sites, unenrolled but authenticated students cannot see the available courses. Petr, I've assigned this to you as you seemed interested. Feel free to reassign if you wish.
            Hide
            skodak Petr Skoda added a comment -

            Reassigning to Sam because this is a navigation issue. I personally do not see any problem in this and it seems to work as expected - but maybe I do not understand this. I believe this is not a security issue because all visible courses in visible categories should be visible at the moment, I am going to clear the security flag because it restricts access to this issue.

            Show
            skodak Petr Skoda added a comment - Reassigning to Sam because this is a navigation issue. I personally do not see any problem in this and it seems to work as expected - but maybe I do not understand this. I believe this is not a security issue because all visible courses in visible categories should be visible at the moment, I am going to clear the security flag because it restricts access to this issue.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Thank you guys for helping me on this.

            Michael, I believe you see what I am facing, now. We are talking about a Learning Management System that is not able to seamless define course visibility regarding user contexts. At the course settings, we have the Avaliability @link(http://docs.moodle.org/22/en/Course_settings#Availability) that sets mdl_course->visibility = 0/1. As the setting says for itself, the options are: "This course is available to students" or "This course is not available to students" (maybe only "Hidden" would be enough). That is logical, because the courses are meant to be the learning objects that helps the students on the learning process. The target is clearly the students here.

            What I have argued is that this rule must be respected so we could have a more consistent accessibility control. The new capability you have pointed out was meant to be my next step. I would call it "Visibility levels", and that would require new capabilities to be set up properly at course level. Later, I will create a new feature request talking about that idea, and link to this bug. Resuming, we could set "Hidden", "Visible to Students", "Visible to Authenticated users", "Visible to Authenticated users if local auto-enrolment enabled", "Always visible". Maybe we could see some other visibility possibilities, but those would take care of a really flexible visibility management.

            Petr, I believe this is not just a navigation problem (but also a navigation problem indeed), because it would require also a minor change at the course library '/course/lib.php', as you can see at the patch I included. I also believe that we should be carefull on correcting this issue, as many many Moodle out there may take advantage of this bug as a feature, and they are not wrong on doing that. The visibility levels I think about, would help things keep working as they are now, but enabling the flexibility administrators ever dreamed about, restrictive or permissive depending on the user context. I just could not push that hard, before I proved my theory.

            Once again, thank you guys.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Thank you guys for helping me on this. Michael, I believe you see what I am facing, now. We are talking about a Learning Management System that is not able to seamless define course visibility regarding user contexts. At the course settings, we have the Avaliability @link( http://docs.moodle.org/22/en/Course_settings#Availability ) that sets mdl_course->visibility = 0/1. As the setting says for itself, the options are: "This course is available to students" or "This course is not available to students" (maybe only "Hidden" would be enough). That is logical, because the courses are meant to be the learning objects that helps the students on the learning process. The target is clearly the students here. What I have argued is that this rule must be respected so we could have a more consistent accessibility control. The new capability you have pointed out was meant to be my next step. I would call it "Visibility levels", and that would require new capabilities to be set up properly at course level. Later, I will create a new feature request talking about that idea, and link to this bug. Resuming, we could set "Hidden", "Visible to Students", "Visible to Authenticated users", "Visible to Authenticated users if local auto-enrolment enabled", "Always visible". Maybe we could see some other visibility possibilities, but those would take care of a really flexible visibility management. Petr, I believe this is not just a navigation problem (but also a navigation problem indeed), because it would require also a minor change at the course library '/course/lib.php', as you can see at the patch I included. I also believe that we should be carefull on correcting this issue, as many many Moodle out there may take advantage of this bug as a feature, and they are not wrong on doing that. The visibility levels I think about, would help things keep working as they are now, but enabling the flexibility administrators ever dreamed about, restrictive or permissive depending on the user context. I just could not push that hard, before I proved my theory. Once again, thank you guys.
            Hide
            samhemelryk Sam Hemelryk added a comment -

            Hi guys,

            I've just been reading through all of the comments here. It's quite an long winded issue already but looks like things may be headed in the right direction.
            To begin with I'm going to cover a few things off:

            1. moodle/course:view This capability is used to control visibility of course contents not the course existence. I think this has already been established in the comments above but just to be sure everyone is clear on it we have always allowed everyone to see the title of a course (its existence). This definition and understanding of this capability won't be changed, again I think we are all clear on this so moving on.
            2. My Courses Authenticated users enrolled in courses vs. those who are not. Users who are enrolled in one or more courses see a "My courses" branch containing the courses they are enrolled in. Users not enrolled in any courses will see the "Courses" branch (not My Courses) which will contain all of the courses on the site (or a limited selection if there are many). That is how the navigation was designed to function. Authenticated users without any enrolments and guests both see that courses branch. This was done because it is reflects the information available to those users through other areas of Moodle such as front page display of courses/combolist, and the course/index.php page which has already been mentioned. Did you know there is a setting "navshowallcourses" which will generate the "Courses" branch in the navigation for those users who are enrolled in one or more courses. The opposite of what you want though I imagine. There is no way to tell the navigation not to generate that information, it was not envisaged as being needed as the information is available elsewhere.

            So looking at those two points I don't think this has anything to do with course:view, and I don't consider it a navigation issue a that information is available everywhere by design.
            By the looks everyone recognises that.

            This issue appears now appears to have evolved to be purely about controlling knowledge about the existence of a course. i.e. control access to the currently public course name. I think Luis you already have this in mind as you've mentioned you mean to open a new issue to discuss it and look for a solution.

            To me guys it looks like this issue can be closed as not a bug. It appears everything discussed here as a potential issue is in fact by design and things are operating as they were intended.
            I do think opening a new bug to investigate controlling knowledge about the existence of a course is a good idea. Although I don't know that a practical solution could be found... either way that can be discussed on the new issue.
            About this issue, are there any complaints if it gets closed?
            Luis are you happy with our explanation of things?

            Cheers
            Sam

            Show
            samhemelryk Sam Hemelryk added a comment - Hi guys, I've just been reading through all of the comments here. It's quite an long winded issue already but looks like things may be headed in the right direction. To begin with I'm going to cover a few things off: moodle/course:view This capability is used to control visibility of course contents not the course existence. I think this has already been established in the comments above but just to be sure everyone is clear on it we have always allowed everyone to see the title of a course (its existence). This definition and understanding of this capability won't be changed, again I think we are all clear on this so moving on. My Courses Authenticated users enrolled in courses vs. those who are not. Users who are enrolled in one or more courses see a "My courses" branch containing the courses they are enrolled in. Users not enrolled in any courses will see the "Courses" branch (not My Courses) which will contain all of the courses on the site (or a limited selection if there are many). That is how the navigation was designed to function. Authenticated users without any enrolments and guests both see that courses branch. This was done because it is reflects the information available to those users through other areas of Moodle such as front page display of courses/combolist, and the course/index.php page which has already been mentioned. Did you know there is a setting "navshowallcourses" which will generate the "Courses" branch in the navigation for those users who are enrolled in one or more courses. The opposite of what you want though I imagine. There is no way to tell the navigation not to generate that information, it was not envisaged as being needed as the information is available elsewhere. So looking at those two points I don't think this has anything to do with course:view, and I don't consider it a navigation issue a that information is available everywhere by design. By the looks everyone recognises that. This issue appears now appears to have evolved to be purely about controlling knowledge about the existence of a course. i.e. control access to the currently public course name. I think Luis you already have this in mind as you've mentioned you mean to open a new issue to discuss it and look for a solution. To me guys it looks like this issue can be closed as not a bug. It appears everything discussed here as a potential issue is in fact by design and things are operating as they were intended. I do think opening a new bug to investigate controlling knowledge about the existence of a course is a good idea. Although I don't know that a practical solution could be found... either way that can be discussed on the new issue. About this issue, are there any complaints if it gets closed? Luis are you happy with our explanation of things? Cheers Sam
            Hide
            skodak Petr Skoda added a comment -

            Thanks Sam, I agree with you 100%.

            Show
            skodak Petr Skoda added a comment - Thanks Sam, I agree with you 100%.
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - - edited

            Hi guys,

            Thank you Sam for you precise explanation.
            I agree with you that not been able to hide the "Courses" branch is not a Navigation block issue, as the Navigation block could only reflect the way Moodle was built to show courses. I have mentioned that on the comment sent '20/Jun/12 9:17 AM'. It is a management issue, as the administrator is not able to manage how users navigate throught the courses, and which courses would be shown to whom. This problem reflects in the Navigation block behaviour, and this is why I see Petr came up assigning you this issue.

            I think the screenshots supposed to help, in fact made things a little blurred. The focus here is about the users courses visibitity not reflecting the ability (capabilities assigned / enrolments) to view courses. For example, the main page as an Authenticated user, without any courses enrolled. He sees a "My courses" entitled page with the "Available courses" content, and in fact he has no course yet. He should be sent to the "Available courses" page.

            And back again to where we came from. Users should have access to things they are capable of doing under Moodle. That is what this post is about. I see this is a confusing theme, as it is all around Moodle, and involves many things like capabilities, visibility levels, course library, course settings, navigation block, and even enrolment library.

            Now I see my approach was too deep, and I should not consider it as a security bug, as the sollution is too wide and things always worked that way.

            So guys, how should I treat this? Maybe a 'new feature' or an 'improvement' request here in Tracker? Any other suggestions?

            Could we at least avail this ticket to solve the Authenticated user home screen, as not been the "My courses" page but the "Available courses" one?

            If you guys agree, I will rename that way.

            Thank you Petr, Michael and Sam for your points of view, help and patience.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - - edited Hi guys, Thank you Sam for you precise explanation. I agree with you that not been able to hide the "Courses" branch is not a Navigation block issue, as the Navigation block could only reflect the way Moodle was built to show courses. I have mentioned that on the comment sent '20/Jun/12 9:17 AM'. It is a management issue, as the administrator is not able to manage how users navigate throught the courses, and which courses would be shown to whom. This problem reflects in the Navigation block behaviour, and this is why I see Petr came up assigning you this issue. I think the screenshots supposed to help, in fact made things a little blurred. The focus here is about the users courses visibitity not reflecting the ability (capabilities assigned / enrolments) to view courses. For example, the main page as an Authenticated user, without any courses enrolled. He sees a "My courses" entitled page with the "Available courses" content, and in fact he has no course yet. He should be sent to the "Available courses" page. And back again to where we came from. Users should have access to things they are capable of doing under Moodle. That is what this post is about. I see this is a confusing theme, as it is all around Moodle, and involves many things like capabilities, visibility levels, course library, course settings, navigation block, and even enrolment library. Now I see my approach was too deep, and I should not consider it as a security bug, as the sollution is too wide and things always worked that way. So guys, how should I treat this? Maybe a 'new feature' or an 'improvement' request here in Tracker? Any other suggestions? Could we at least avail this ticket to solve the Authenticated user home screen, as not been the "My courses" page but the "Available courses" one? If you guys agree, I will rename that way. Thank you Petr, Michael and Sam for your points of view, help and patience.
            Hide
            link4swords Joe Dubois added a comment -

            Luis,
            I have been looking at the same issue. Meaning, if I have two customers, I do not want customer A to see the listing of customer B and vice versa. Searching Moodle, I came across the public/private course plugin: http://docs.moodle.org/dev/PublicPrivate . This was developed in April 2010 and I wish it had been incorporated into later versions of Moodle. Can this be installed into Moodle 2.x? And if so, how would I go about doing that.

            Joe

            Show
            link4swords Joe Dubois added a comment - Luis, I have been looking at the same issue. Meaning, if I have two customers, I do not want customer A to see the listing of customer B and vice versa. Searching Moodle, I came across the public/private course plugin: http://docs.moodle.org/dev/PublicPrivate . This was developed in April 2010 and I wish it had been incorporated into later versions of Moodle. Can this be installed into Moodle 2.x? And if so, how would I go about doing that. Joe
            Hide
            marina Marina Glancy added a comment -

            Hi,
            everybody agrees that 'moodle/course:view' is an unrealted capability.
            Would we agree to close this issue as a duplicate of MDL-10965 ?

            Show
            marina Marina Glancy added a comment - Hi, everybody agrees that 'moodle/course:view' is an unrealted capability. Would we agree to close this issue as a duplicate of MDL-10965 ?
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi Marina,

            I agree in part, but I'm not convinced that https://tracker.moodle.org/browse/MDL-10965 issue covers all the problem. It has a partial perspective of what we have talked about here.

            Let me explain this in another format. We could achieve a partial desired functionality by creating a new role from Student. Let's call that 'Student who sees only own courses'. Then we enables that kind of student to see hidden courses. Every course in this Moodle instance must be hidden. From that point on, For those students the course listing would work as expected, but all the navigation links and course listing are shown as dimmed (as expected from CSS), and we can not hide courses from those students anymore without removing that role from them. So we resolve from one side and remove other nice features from the other. It work almos like the courses like Joe Dubois' sollution whithout any core changes...

            I believe that Joe Dubois' sollution is a closer option, as we can control the visibility from each course, which would behave as expected from the course control perspective. But I say closer, because the course listing visibility could be set from the course (or parent contexts), from the user enrolment, or even from the role assignment. That is the tricky part, and that is way we need some core changes.
            One course could the hidden in the listing from everyone, but could be visible to the authenticaded users, once/while a self enrolment is enabled there, or could be visible if the user is enrolled but has no role there anymore, or has any role there but is not enrolled there... Of course, course access would still be required and controlled, but the visibility from listing should have some extra considerations to take care.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi Marina, I agree in part, but I'm not convinced that https://tracker.moodle.org/browse/MDL-10965 issue covers all the problem. It has a partial perspective of what we have talked about here. Let me explain this in another format. We could achieve a partial desired functionality by creating a new role from Student. Let's call that 'Student who sees only own courses'. Then we enables that kind of student to see hidden courses. Every course in this Moodle instance must be hidden. From that point on, For those students the course listing would work as expected, but all the navigation links and course listing are shown as dimmed (as expected from CSS), and we can not hide courses from those students anymore without removing that role from them. So we resolve from one side and remove other nice features from the other. It work almos like the courses like Joe Dubois' sollution whithout any core changes... I believe that Joe Dubois' sollution is a closer option, as we can control the visibility from each course, which would behave as expected from the course control perspective. But I say closer, because the course listing visibility could be set from the course (or parent contexts), from the user enrolment, or even from the role assignment. That is the tricky part, and that is way we need some core changes. One course could the hidden in the listing from everyone, but could be visible to the authenticaded users, once/while a self enrolment is enabled there, or could be visible if the user is enrolled but has no role there anymore, or has any role there but is not enrolled there... Of course, course access would still be required and controlled, but the visibility from listing should have some extra considerations to take care.
            Hide
            marina Marina Glancy added a comment -

            Luis, would you mind changing the description and testing instructions of your issue be applicable to the current version and also exclude mentioning of moodle:course/view. While doing that please keep in mind the issue MDL-10965 and describe your point of view as complementing solution.

            Show
            marina Marina Glancy added a comment - Luis, would you mind changing the description and testing instructions of your issue be applicable to the current version and also exclude mentioning of moodle:course/view. While doing that please keep in mind the issue MDL-10965 and describe your point of view as complementing solution.
            Hide
            marina Marina Glancy added a comment -

            Luis, do you agree to close this issue to defer the resolution to MDL-10965 ? This issue description does not reflect the actual problem

            Show
            marina Marina Glancy added a comment - Luis, do you agree to close this issue to defer the resolution to MDL-10965 ? This issue description does not reflect the actual problem
            Hide
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment -

            Hi Marina. I tried to update this issue removing the moodle/course:view capability, and taking the "big picture" of the problem. I was trying to point one problem from one functionallity from the site enter point, but I see there must be some extra work to achieve that.

            I believe that the new description would help on understanding the hole problem, and how it would be possible to solve it without that much of changes inside Moodle core.
            The changes should be applied to whenever the courses are listed inside Moodle, mainly on system context. Inside a course, the control is done pretty well.

            Show
            luis.alcantara Luis Gustavo Mueller de Alcantara added a comment - Hi Marina. I tried to update this issue removing the moodle/course:view capability, and taking the "big picture" of the problem. I was trying to point one problem from one functionallity from the site enter point, but I see there must be some extra work to achieve that. I believe that the new description would help on understanding the hole problem, and how it would be possible to solve it without that much of changes inside Moodle core. The changes should be applied to whenever the courses are listed inside Moodle, mainly on system context. Inside a course, the control is done pretty well.
            Hide
            marina Marina Glancy added a comment -

            Thanks Luis. Just noting here (again) that MDL-10965 and MDL-46401 suggest detailed solutions for the same problem. I will leave this issue open for now, maybe new suggestions arise.

            Show
            marina Marina Glancy added a comment - Thanks Luis. Just noting here (again) that MDL-10965 and MDL-46401 suggest detailed solutions for the same problem. I will leave this issue open for now, maybe new suggestions arise.

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated: