Moodle
  1. Moodle
  2. MDL-31983

Include Reports Under Settings block -> Course administration

    Details

    • Testing Instructions:
      Hide
      1. Make sure the 'Settings block' is now called 'Administration'
      1. Navigate to a course
      2. Make sure you can find the 'Reports' under Course administration
      1. Navigate to someone's profile
      2. Make sure you can find the 'Activity reports' under Profile Settings
      1. Navigate to a quiz module
      2. Make sure you can find the 'Results' under Quiz administration
      3. Also make sure that you can't expand the quiz in the navigation block
      1. Navigate to the front page
      2. Make sure you can find the 'Activity reports' under Front page settings

      You should have upgraded your instance at some point, make sure you don't encounter any error due to a call to a missing function

      Show
      Make sure the 'Settings block' is now called 'Administration' Navigate to a course Make sure you can find the 'Reports' under Course administration Navigate to someone's profile Make sure you can find the 'Activity reports' under Profile Settings Navigate to a quiz module Make sure you can find the 'Results' under Quiz administration Also make sure that you can't expand the quiz in the navigation block Navigate to the front page Make sure you can find the 'Activity reports' under Front page settings You should have upgraded your instance at some point, make sure you don't encounter any error due to a call to a missing function
    • Affected Branches:
      MOODLE_22_STABLE
    • Fixed Branches:
      MOODLE_25_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-31983-master
    • Rank:
      38651

      Description

      The reporting options (Logs, Live Logs, Activity report, Course participation, Activity completion) are centralized (although buried) in the Navigation block -> My courses -> 'Coursename' -> Reports. This placement is unintuitive when looking for data on a course, activity or for a particular participant. This will be especially troublesome if the Navigation block is not populated by default in the course. Who will think to add a Navigation block to see logs of course activity?

      Is there any dialog which reasons why Reports found in 1.9 in the Administration block was removed from the list in the current 2.2 Settings -> Course administration? This new placement would not only be consistent for users migrating from 1.9 to 2.x, but also a more logical location for dealing with course management.

      1. MDL-31983 block_settings-add reports to course settings.txt
        2 kB
        Tõnis Tartes
      1. after-course-reports.png
        30 kB
      2. after-quiz.png
        19 kB
      3. after-sitewide.png
        31 kB
      4. after-teacher-in-course.png
        21 kB
      5. before-course-reports.png
        20 kB
      6. before-quiz-reports.png
        14 kB
      7. before-sitewide.png
        31 kB
      8. before-teacher-in-course.png
        28 kB
      9. block-report-concept.png
        26 kB

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for suggesting this.

          Show
          Michael de Raadt added a comment - Thanks for suggesting this.
          Hide
          Matt Jenner added a comment -

          I agree with the placement, reporting, for me at least, is more of a 'Settings' thing than 'Navigation' - in terms of the block structure anyway.

          In addition, the Navigation block becomes difficult to view once enrolled on >20 courses. With it's configurable expanding trees reduced to the most basic mode digging into the block to find course reports is still difficult.

          A high level menu in Settings named 'Reports' which expands to all applicable course reports would seem like a logical placement.

          Show
          Matt Jenner added a comment - I agree with the placement, reporting, for me at least, is more of a 'Settings' thing than 'Navigation' - in terms of the block structure anyway. In addition, the Navigation block becomes difficult to view once enrolled on >20 courses. With it's configurable expanding trees reduced to the most basic mode digging into the block to find course reports is still difficult. A high level menu in Settings named 'Reports' which expands to all applicable course reports would seem like a logical placement.
          Hide
          Tõnis Tartes added a comment -

          I would also like to have the Logs option in Course Administration, rather than in the Navigation block. For our school's teachers and students the Navigation block is a bit confusing and they would like to hide that, but it has the Logs option which is neccessary for teachers and therefore hiding is not a good option.

          Show
          Tõnis Tartes added a comment - I would also like to have the Logs option in Course Administration, rather than in the Navigation block. For our school's teachers and students the Navigation block is a bit confusing and they would like to hide that, but it has the Logs option which is neccessary for teachers and therefore hiding is not a good option.
          Hide
          Susana Leitão added a comment -

          We also prefer the course reports on Course Settings. We also disabled most of the navigation block (on our default theme) because it gets confusing... We have already hacked moodle 2 to have some of course reports on settings block and user's activity reports on user's profile view page.

          Show
          Susana Leitão added a comment - We also prefer the course reports on Course Settings. We also disabled most of the navigation block (on our default theme) because it gets confusing... We have already hacked moodle 2 to have some of course reports on settings block and user's activity reports on user's profile view page.
          Hide
          Tõnis Tartes added a comment -

          Made a patch, someone should review this.

          Show
          Tõnis Tartes added a comment - Made a patch, someone should review this.
          Hide
          moodle.com added a comment -

          Assigning this to you, Martin, as this is a behavioural change that will need your consideration/blessing.

          Show
          moodle.com added a comment - Assigning this to you, Martin, as this is a behavioural change that will need your consideration/blessing.
          Hide
          Martin Dougiamas added a comment -

          I'm not sure this is an obvious thing ...

          Reports are simply not settings and I'm sure a whole lot of people would complain if they were moved there ...

          Show
          Martin Dougiamas added a comment - I'm not sure this is an obvious thing ... Reports are simply not settings and I'm sure a whole lot of people would complain if they were moved there ...
          Hide
          Chris Follin added a comment -

          Few items in the Course Administration section of the Settings block are settings. Users aren't settings, backup and restore aren't settings, etc. These are administrative functions; however, the Settings block is where one goes to access the course administrative functions. Reports are also administrative functions so, in my opinion, reports should be located with the other administrative functions that are currently found in the Settings block.

          Show
          Chris Follin added a comment - Few items in the Course Administration section of the Settings block are settings. Users aren't settings, backup and restore aren't settings, etc. These are administrative functions; however, the Settings block is where one goes to access the course administrative functions. Reports are also administrative functions so, in my opinion, reports should be located with the other administrative functions that are currently found in the Settings block.
          Hide
          Martin Dougiamas added a comment -

          Reports are more generally a plugin that shows some sort of overview of the course. Some of them (most of them) may be restricted to teacher (admin) roles by default but they are controlled by capabilities and so don't have to be.

          It's easy to imagine reports that are actually geared to students, for example, showing their progress in the relation to the course, or giving them other analytical feedback about their performance.

          Reports are read-only, while everything under administration involves making changes to the course in some way.

          I guess another option would be a new "Reporting" block, but that seems overkill ... something to discuss in the new Analytics and Reporting forum maybe ...http://moodle.org/mod/forum/view.php?id=8044

          Anyway, if a huge majority of people want this to change we can change it, but I'm not seeing that yet.

          Show
          Martin Dougiamas added a comment - Reports are more generally a plugin that shows some sort of overview of the course. Some of them (most of them) may be restricted to teacher (admin) roles by default but they are controlled by capabilities and so don't have to be. It's easy to imagine reports that are actually geared to students, for example, showing their progress in the relation to the course, or giving them other analytical feedback about their performance. Reports are read-only, while everything under administration involves making changes to the course in some way. I guess another option would be a new "Reporting" block, but that seems overkill ... something to discuss in the new Analytics and Reporting forum maybe ... http://moodle.org/mod/forum/view.php?id=8044 Anyway, if a huge majority of people want this to change we can change it, but I'm not seeing that yet.
          Hide
          Martin Dougiamas added a comment -

          I should also point you to the separation of reports and tools that happened in Moodle 2.2:

          http://docs.moodle.org/dev/Admin_tools

          Previously a lot of people abused "reports" which has led to this confusion ...

          Show
          Martin Dougiamas added a comment - I should also point you to the separation of reports and tools that happened in Moodle 2.2: http://docs.moodle.org/dev/Admin_tools Previously a lot of people abused "reports" which has led to this confusion ...
          Hide
          Chris Follin added a comment -

          I know of the changes in 2.2. Some of our clients became very vocal after our 2.2 upgrade about not liking what happened to reports. That is part of why we're following this ticket.

          Show
          Chris Follin added a comment - I know of the changes in 2.2. Some of our clients became very vocal after our 2.2 upgrade about not liking what happened to reports. That is part of why we're following this ticket.
          Hide
          Eric Strom added a comment -

          Thanks to everyone for the comments on this topic. I see Martin describing Reports as, in essence, a separate function from the configuration of courses and something that could potentially cover a wider territory than what they currently do. I personally very much like the idea of a distinct Reports block if it was integrated with admin and other data analysis features.

          But I would rather not wait on this goal at the expense of keeping reports in the navigation block until then. Reporting tools, even if they don't modify data or settings, still serve an administrator function. This is how those in instructor roles see the Settings block (formerly "Administration").

          From another take, having a single "Reports" link/menu in the Settings is far more streamlined (in terms of screen real-estate) than a separate block. At this point I would keep it this way until enough report options are available to warrant a separate block.

          If students had some options to create reports I would think it would likely coincide with their progress or course activity in some way. And since Grades is located in the Course administration for the Student role, it seems to follow that their reports could be there, too - at least for now.

          Show
          Eric Strom added a comment - Thanks to everyone for the comments on this topic. I see Martin describing Reports as, in essence, a separate function from the configuration of courses and something that could potentially cover a wider territory than what they currently do. I personally very much like the idea of a distinct Reports block if it was integrated with admin and other data analysis features. But I would rather not wait on this goal at the expense of keeping reports in the navigation block until then. Reporting tools, even if they don't modify data or settings, still serve an administrator function. This is how those in instructor roles see the Settings block (formerly "Administration"). From another take, having a single "Reports" link/menu in the Settings is far more streamlined (in terms of screen real-estate) than a separate block. At this point I would keep it this way until enough report options are available to warrant a separate block. If students had some options to create reports I would think it would likely coincide with their progress or course activity in some way. And since Grades is located in the Course administration for the Student role, it seems to follow that their reports could be there, too - at least for now.
          Hide
          Martin Dougiamas added a comment -

          And what about Participants? Does it make sense for those to be in the navigation tree all alone (apart from the course structure/content)? Perhaps Participants should be in Settings too?

          I really think we need to think of this in terms of a proper redesign rather than flipping individual items of the interface around for everyone. The reports moved into the navigation menu three years ago and many people are used to them where they are now.

          One solution may be adding Yet More Options so individual sites can choose where they want various things. I'd obviously prefer we had a consensus-based design approach but there's plenty of precedents for more options (as you can see in the admin menus!).

          Show
          Martin Dougiamas added a comment - And what about Participants? Does it make sense for those to be in the navigation tree all alone (apart from the course structure/content)? Perhaps Participants should be in Settings too? I really think we need to think of this in terms of a proper redesign rather than flipping individual items of the interface around for everyone. The reports moved into the navigation menu three years ago and many people are used to them where they are now. One solution may be adding Yet More Options so individual sites can choose where they want various things. I'd obviously prefer we had a consensus-based design approach but there's plenty of precedents for more options (as you can see in the admin menus!).
          Hide
          Eric Strom added a comment -

          As far as Particiants go, it depends on which role and their perspective.

          From a student view:
          Participants have been and are currently available in the 'People' block. And 'My profile settings' are included in the Settings block. I don't see a compelling reason to keep participants in the Navigation block. It is buried deep in the Navigation block (just like 'Reports' is).

          From the Instructor/Admin role:
          We would look at 'Settings block -> Course administration -> Users'
          or the People block.

          We have actually created a single customized block which includes a link to 'Participants', 'Online users' and a custom picture roster layout for instructors and found this to be useful and more effecient use of the screen space.

          Since we moved to moodle 2 just this Fall, the fact that others have seen Reports in navigation doesn't have much bearing on our reaction to the change. The argument that we could find a more consise navigation structure for these features probably shouldn't be influenced much on how long the current design has been around.

          I understand flip-flopping is not desireable for the user experience. And yes I would feel good about having consensus.
          Configuration options are good for people to have. And with some use, in time people will have expeience behind their opinion for which design approach works better.

          So, yes options are good. Let's move forward however we can.

          Show
          Eric Strom added a comment - As far as Particiants go, it depends on which role and their perspective. From a student view: Participants have been and are currently available in the 'People' block. And 'My profile settings' are included in the Settings block. I don't see a compelling reason to keep participants in the Navigation block. It is buried deep in the Navigation block (just like 'Reports' is). From the Instructor/Admin role: We would look at 'Settings block -> Course administration -> Users' or the People block. We have actually created a single customized block which includes a link to 'Participants', 'Online users' and a custom picture roster layout for instructors and found this to be useful and more effecient use of the screen space. Since we moved to moodle 2 just this Fall, the fact that others have seen Reports in navigation doesn't have much bearing on our reaction to the change. The argument that we could find a more consise navigation structure for these features probably shouldn't be influenced much on how long the current design has been around. I understand flip-flopping is not desireable for the user experience. And yes I would feel good about having consensus. Configuration options are good for people to have. And with some use, in time people will have expeience behind their opinion for which design approach works better. So, yes options are good. Let's move forward however we can.
          Hide
          Eric Strom added a comment -

          Not to muddy the waters here, but to the comment about "...reports are simply not settings". Reports are a function of course administration. However, the majority of the options in the Administration block in 1.9 are now found in the block "Settings". The confusion of having administrative functions scattered between multiple blocks (Settings and Navigation) is the crux of this discussion/issue.

          Show
          Eric Strom added a comment - Not to muddy the waters here, but to the comment about "...reports are simply not settings". Reports are a function of course administration. However, the majority of the options in the Administration block in 1.9 are now found in the block "Settings". The confusion of having administrative functions scattered between multiple blocks (Settings and Navigation) is the crux of this discussion/issue.
          Hide
          Michael de Raadt added a comment -

          There was a proposal at the Hackfest to rename "Settings" to "Administration", which would allow focus Navigation on just navigation and house the rest under Administration.

          Show
          Michael de Raadt added a comment - There was a proposal at the Hackfest to rename "Settings" to "Administration", which would allow focus Navigation on just navigation and house the rest under Administration.
          Hide
          Frédéric Massart added a comment -

          Assigning this to me, noting that this has been approved at the Hackfest. http://docs.moodle.org/dev/Perth_Hackfest_October_2012/Navigation_and_UI

          Show
          Frédéric Massart added a comment - Assigning this to me, noting that this has been approved at the Hackfest. http://docs.moodle.org/dev/Perth_Hackfest_October_2012/Navigation_and_UI
          Hide
          Eric Strom added a comment -

          Curious about the reason (discussions at Hackfest) to go back to the Administration block name vs keeping with Settings.
          It makes sense for admin and teacher roles perhaps, but Students would really have little in terms of Administration for a course. The name 'Settings' seems logical for at least the student role.

          My 2 cents:
          One reason I hesitate about the idea of changing back to "Administration block" is the fact that many support resources (outside of moodle docs) that reference the 'Settings' block of moodle 2 would then be inconsistent and need modification. Time intensive for folks like me who train and support moodle users.

          Explaining to a user to find Course administration under the Settings block seems more elegant (or less confusing) than finding Course administration under the Administration block. Maybe it is just me, but I fear more confusion for some if there are multiple "administration" tiers in the interface.

          Perhaps Settings isn't perfect either, but at the very least it is fewer letters :7)

          Show
          Eric Strom added a comment - Curious about the reason (discussions at Hackfest) to go back to the Administration block name vs keeping with Settings. It makes sense for admin and teacher roles perhaps, but Students would really have little in terms of Administration for a course. The name 'Settings' seems logical for at least the student role. My 2 cents: One reason I hesitate about the idea of changing back to "Administration block" is the fact that many support resources (outside of moodle docs) that reference the 'Settings' block of moodle 2 would then be inconsistent and need modification. Time intensive for folks like me who train and support moodle users. Explaining to a user to find Course administration under the Settings block seems more elegant (or less confusing) than finding Course administration under the Administration block. Maybe it is just me, but I fear more confusion for some if there are multiple "administration" tiers in the interface. Perhaps Settings isn't perfect either, but at the very least it is fewer letters :7)
          Hide
          Frédéric Massart added a comment -

          Thanks for your input Eric. You raised an interesting point, but this issue will not take care of renaming the Settings block, its only purpose is to move the reports under settings instead of navigation where they are now. Unfortunately I can't redirect you to any other issue as none have been raise yet.

          Cheers,
          Fred

          Show
          Frédéric Massart added a comment - Thanks for your input Eric. You raised an interesting point, but this issue will not take care of renaming the Settings block, its only purpose is to move the reports under settings instead of navigation where they are now. Unfortunately I can't redirect you to any other issue as none have been raise yet. Cheers, Fred
          Hide
          Tim Hunt added a comment -

          -1 There are also other report links in Moodle.

          # I suppose where site-level reports are is fine.

          1. Quiz reports certainly need to be moved.
          2. I don't really know about other types of activity module, but you ought to check them all, and report your findings in a comment here.
          3. Are reports (like logs) able to add themselves in course-cateogry or user context? If so, where do the links go?
          Show
          Tim Hunt added a comment - -1 There are also other report links in Moodle. # I suppose where site-level reports are is fine. Quiz reports certainly need to be moved. I don't really know about other types of activity module, but you ought to check them all, and report your findings in a comment here. Are reports (like logs) able to add themselves in course-cateogry or user context? If so, where do the links go?
          Hide
          Frédéric Massart added a comment -

          1/ Quiz reports are not extending the navigation, the quiz itself extends the navigation block to add them. If they need to take place in the settings block, then the quiz reports should define a function extend_navigation_module().
          2/ Same than for Quiz, the report submodules should define a function extend_navigation_module to have their link populated under the settings block.
          3/ There are 4 levels of reports: system, user, course and module. None of them would add reports to a course category.

          • The system reports appear under Site administration
          • The user reports appear under a person's name, typically in "Navigation > Participants". I didn't change this (yet) as this issue does not mention them.
          • The course reports are now supposed to appear in "Course administration"
          • The module reports are displayed within the module settings block
          • The front page reports (which I had forgotten, thanks ) will now be displayed under 'Front page settings'

          I moved the reports under filters because I noticed that it's where they were displayed for module reports.

          Show
          Frédéric Massart added a comment - 1/ Quiz reports are not extending the navigation, the quiz itself extends the navigation block to add them. If they need to take place in the settings block, then the quiz reports should define a function extend_navigation_module(). 2/ Same than for Quiz, the report submodules should define a function extend_navigation_module to have their link populated under the settings block. 3/ There are 4 levels of reports: system, user, course and module. None of them would add reports to a course category. The system reports appear under Site administration The user reports appear under a person's name, typically in "Navigation > Participants". I didn't change this (yet) as this issue does not mention them. The course reports are now supposed to appear in "Course administration" The module reports are displayed within the module settings block The front page reports (which I had forgotten, thanks ) will now be displayed under 'Front page settings' I moved the reports under filters because I noticed that it's where they were displayed for module reports.
          Hide
          Frédéric Massart added a comment -

          Pushing back for peer review to get attention back .

          Show
          Frédéric Massart added a comment - Pushing back for peer review to get attention back .
          Hide
          Tim Hunt added a comment -

          Fred, I though that the purpose of this issue was to make the Moodle UI better and more consistent for users.

          Users do not care that "Quiz reports are not extending the navigation, the quiz itself extends the navigation block to add them. If they need to take place in the settings block, then the quiz reports should define a function extend_navigation_module()." That is an implementation detail that is the kind of thing that developers have to worry about so that users don't have to.

          If you are moving Reports links from settings to navigation, then please do a proper job. Just moving some, but not all, reports links is just going to make things worse for users. I am sure that is not your intention.

          Show
          Tim Hunt added a comment - Fred, I though that the purpose of this issue was to make the Moodle UI better and more consistent for users. Users do not care that "Quiz reports are not extending the navigation, the quiz itself extends the navigation block to add them. If they need to take place in the settings block, then the quiz reports should define a function extend_navigation_module()." That is an implementation detail that is the kind of thing that developers have to worry about so that users don't have to. If you are moving Reports links from settings to navigation, then please do a proper job. Just moving some, but not all, reports links is just going to make things worse for users. I am sure that is not your intention.
          Hide
          Frédéric Massart added a comment -

          As we discussed on Jabber, I have moved the 'Results' reports to the settings block where you liked it the most. I have also moved the users' 'Activity reports' to the profile settings, it's probably better to keep consistency and having all the reports in one place. Also, I removed the previous function quiz_extend_navigation() as it became empty after removing the redundant 'Info' node, and thinking of performances it is probably better not to call it, even if empty. Please also note it is safe to remove it.

          Waiting for your final review to push for integration.

          Show
          Frédéric Massart added a comment - As we discussed on Jabber, I have moved the 'Results' reports to the settings block where you liked it the most. I have also moved the users' 'Activity reports' to the profile settings, it's probably better to keep consistency and having all the reports in one place. Also, I removed the previous function quiz_extend_navigation() as it became empty after removing the redundant 'Info' node, and thinking of performances it is probably better not to call it, even if empty. Please also note it is safe to remove it. Waiting for your final review to push for integration.
          Hide
          Tim Hunt added a comment -

          The code looks good to me now, so from that point of view this is ready for integration.

          I think it would be good if you could catch someone like Martin D or Helen to to look at this more from a user's point of view, to ensure it makes sense to them, before this is integrated.

          Show
          Tim Hunt added a comment - The code looks good to me now, so from that point of view this is ready for integration. I think it would be good if you could catch someone like Martin D or Helen to to look at this more from a user's point of view, to ensure it makes sense to them, before this is integrated.
          Hide
          Frédéric Massart added a comment -

          Thanks Tim, pushing for integration.

          Martin, Helen, could you have a look at the proposal of moving the 'Activity reports' of a participant under the settings block? (screenshots before/after)

          Show
          Frédéric Massart added a comment - Thanks Tim, pushing for integration. Martin, Helen, could you have a look at the proposal of moving the 'Activity reports' of a participant under the settings block? (screenshots before/after)
          Hide
          Martin Dougiamas added a comment - - edited

          I still think this might be a mistake because I don't see reports as being settings or admin.

          It depends on your view of what a report is. Traditionally, sure, it's something for admin people, but these days on the internet everyone is used to seeing reports on everything. You can go to klout.com and get a report on your own twitter account, for example. In Moodle it's just a way to display some aggregate information to you.

          I always thought we'd see more analytics reports being created for all roles to view. I still hold hope.

          The current "Settings" name is going to become confusing. Admin would definitely be better if we're going to start jamming a bunch of non-settings stuff in there again. And we need to think about how all this looks in other languages with imperfect translations of admins/settings and reports. Will it make sense?

          Sorry but the more I think about this I think my preference is to go all the way to a full Reports block for all reports and do this properly.

          So in summary I think we can go three ways:

          1. Include these reports as per current patch and rename Settings -> Administration (ADVANTAGES: easy to do, DISADVANTAGES: muddling the interface, changing key UI for teachers)
          2. Create a new Reports block and use it to display any reports for the current context (ADVANTAGES: clean separation of UI functions, usability, DISADVANTAGES: upgrade could be tricky, block real estate)
          3. Leave things as they are. (ADVANTAGES: very easy, DISADVANTAGES: Navigation more cluttered)

          I think we need a lot more voters on this to find a consensus. There's not enough yet.

          Show
          Martin Dougiamas added a comment - - edited I still think this might be a mistake because I don't see reports as being settings or admin. It depends on your view of what a report is. Traditionally, sure, it's something for admin people, but these days on the internet everyone is used to seeing reports on everything. You can go to klout.com and get a report on your own twitter account, for example. In Moodle it's just a way to display some aggregate information to you. I always thought we'd see more analytics reports being created for all roles to view. I still hold hope. The current "Settings" name is going to become confusing. Admin would definitely be better if we're going to start jamming a bunch of non-settings stuff in there again. And we need to think about how all this looks in other languages with imperfect translations of admins/settings and reports. Will it make sense? Sorry but the more I think about this I think my preference is to go all the way to a full Reports block for all reports and do this properly. So in summary I think we can go three ways: Include these reports as per current patch and rename Settings -> Administration (ADVANTAGES: easy to do, DISADVANTAGES: muddling the interface, changing key UI for teachers) Create a new Reports block and use it to display any reports for the current context (ADVANTAGES: clean separation of UI functions, usability, DISADVANTAGES: upgrade could be tricky, block real estate) Leave things as they are. (ADVANTAGES: very easy, DISADVANTAGES: Navigation more cluttered) I think we need a lot more voters on this to find a consensus. There's not enough yet.
          Hide
          Frédéric Massart added a comment -

          If we don't move the reports down to settings, then we should consider moving the modules reports up to the navigation block, to keep consistency. I don't think we're using sub modules reports (except in quiz), but if any 3rd party uses our API, then the settings will end up there.

          Show
          Frédéric Massart added a comment - If we don't move the reports down to settings, then we should consider moving the modules reports up to the navigation block, to keep consistency. I don't think we're using sub modules reports (except in quiz), but if any 3rd party uses our API, then the settings will end up there.
          Hide
          Tim Hunt added a comment -

          1. is definitely better than 3. - at least judging by the feedback that I have seen in the quiz forum and elsewhere, and also my experience interacting with the UI during testing. Other people seemed to agree and Hacktoberfest.

          If you want to open this discussion, then please go ahead, but I think you need to do that soon so we can get this sorted.

          I think you may be reading too much into the words settings or admin - and we can try to find a better word. The way the distinction works in my mind is this:

          Let us try to define all activity within a module into two types:

          1. doing the activity: reading and posting to a forum, reading and writing wiki pages, attempting a quiz, etc. This stuff belongs in the body of the page, and in the navigation.
          2. meta stuff: this involves creating the and configuring the activity (settings) and settings back and seeing how it is going (reports). And, as you say, this is not necessarily exclusive to teachers/admins.

          So, by that logic, reports happily live in the "meta" block (but I am not seriously suggesting that as a name )

          Show
          Tim Hunt added a comment - 1. is definitely better than 3. - at least judging by the feedback that I have seen in the quiz forum and elsewhere, and also my experience interacting with the UI during testing. Other people seemed to agree and Hacktoberfest. If you want to open this discussion, then please go ahead, but I think you need to do that soon so we can get this sorted. I think you may be reading too much into the words settings or admin - and we can try to find a better word. The way the distinction works in my mind is this: Let us try to define all activity within a module into two types: doing the activity: reading and posting to a forum, reading and writing wiki pages, attempting a quiz, etc. This stuff belongs in the body of the page, and in the navigation. meta stuff: this involves creating the and configuring the activity (settings) and settings back and seeing how it is going (reports). And, as you say, this is not necessarily exclusive to teachers/admins. So, by that logic, reports happily live in the "meta" block (but I am not seriously suggesting that as a name )
          Hide
          Frédéric Massart added a comment -

          Reopening and moving outside of the current sprint as it requires more thoughts (or votes) to be integrated.

          Show
          Frédéric Massart added a comment - Reopening and moving outside of the current sprint as it requires more thoughts (or votes) to be integrated.
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Tim Hunt added a comment -

          Who is going to ensure that more thought happens? Martin? I don't see a forum thread about this yet.

          Show
          Tim Hunt added a comment - Who is going to ensure that more thought happens? Martin? I don't see a forum thread about this yet.
          Hide
          Martin Dougiamas added a comment -

          Fred, I suggest you start a discussion in Using Moodle in the upcoming features forum.

          Show
          Martin Dougiamas added a comment - Fred, I suggest you start a discussion in Using Moodle in the upcoming features forum.
          Hide
          Mary Cooch added a comment -

          As a user I'd personally find it more intuitive to look for reports in "Settings" - so option 1 for me.

          Show
          Mary Cooch added a comment - As a user I'd personally find it more intuitive to look for reports in "Settings" - so option 1 for me.
          Hide
          Frédéric Massart added a comment -

          I have raised the discussion here: https://moodle.org/mod/forum/discuss.php?d=221434

          Show
          Frédéric Massart added a comment - I have raised the discussion here: https://moodle.org/mod/forum/discuss.php?d=221434
          Hide
          Alex Büchner added a comment -

          I like Martin's idea of a separate Report block as it also creates a home once more reporting / analytics features will be added.

          Show
          Alex Büchner added a comment - I like Martin's idea of a separate Report block as it also creates a home once more reporting / analytics features will be added.
          Hide
          Michael Hughes added a comment -

          Vote for option 1 here.

          Just to through my 2c in here. When we moved to 2.2 one of the biggest issues was the "disappearance" of reports from the Settings, as our users associated a report within being related to the activity and reporting on the activity. Also the 1st thing a fair number of our users did was do suppress the Navigation block.

          Adding a new Reports block only adds clutter and another location we have to explain to users where to find it.

          I'd almost rather that student-orientated reports appear under navigation (e.g. drill down course->module->report) but all reports to (also) appear under "Settings/Administration".

          Show
          Michael Hughes added a comment - Vote for option 1 here. Just to through my 2c in here. When we moved to 2.2 one of the biggest issues was the "disappearance" of reports from the Settings, as our users associated a report within being related to the activity and reporting on the activity. Also the 1st thing a fair number of our users did was do suppress the Navigation block. Adding a new Reports block only adds clutter and another location we have to explain to users where to find it. I'd almost rather that student-orientated reports appear under navigation (e.g. drill down course->module->report) but all reports to (also) appear under "Settings/Administration".
          Hide
          Ray Morris added a comment -

          -1 on this. I certainly agree with Martin - reports are not settings. The general idea may be good, but it needs a different
          twist to get to the BEST way we can do it.

          Settings is mostly administrative functions, used by administrators, and are used to make CHANGES to the system. Reports are basically view only, they don't change the system, and are used by teachers and even students. I don't think it makes sense to mix a report that a student might look it in with administrative functions.

          There may be a change which would be good, but this isn't quite it. If there's one thing I've learned in 20 years of programming,
          it that if you're fighting against clear facts like "reports are not administrative settings", you haven't yet found
          the best approach. Pretending a student viewing a report is a "setting" will bite us eventually.

          Show
          Ray Morris added a comment - -1 on this. I certainly agree with Martin - reports are not settings. The general idea may be good, but it needs a different twist to get to the BEST way we can do it. Settings is mostly administrative functions, used by administrators, and are used to make CHANGES to the system. Reports are basically view only, they don't change the system, and are used by teachers and even students. I don't think it makes sense to mix a report that a student might look it in with administrative functions. There may be a change which would be good, but this isn't quite it. If there's one thing I've learned in 20 years of programming, it that if you're fighting against clear facts like "reports are not administrative settings", you haven't yet found the best approach. Pretending a student viewing a report is a "setting" will bite us eventually.
          Hide
          Nathan Lind added a comment -

          @ Martin:
          My vote: #1 (with a modification) - move Reports to the Settings block. It makes as much sense having "Reports" in the Settings block as it does "Grades". People will not get hung up on whether the block itself is called Settings or Administration. Not a big deal. The important thing is moving Reports to the Settings/Administration block where it was located for many versions. It is difficult to find in the Navigation block. Thanks!

          Show
          Nathan Lind added a comment - @ Martin: My vote: #1 (with a modification) - move Reports to the Settings block. It makes as much sense having "Reports" in the Settings block as it does "Grades". People will not get hung up on whether the block itself is called Settings or Administration. Not a big deal. The important thing is moving Reports to the Settings/Administration block where it was located for many versions. It is difficult to find in the Navigation block. Thanks!
          Hide
          Eric Strom added a comment -

          @Ray
          I would argue differently on the perspective of role/functionality of reports. Coming at this from the instructor perspective (the primary beneficiary of the value of reports), I would suggest that MOST users approach their moodle interface with two mindsets:
          1) Course content or "stuff" (activities, modules, resources, blocks, etc.)
          2) Not course content (everything else)

          This lumps course settings, records of activity data and site level customizations together. Even though reports don't change data, they often are manipulating information with filters and such. I don't think the general user differentiates between this and other under the hood settings like an administrator or programmer might. The more I think about it, the more I feel satisfied with option 1.

          Agreeing with Michael's recent comments.

          If the contextual piece in the settings block remains as it has been, the reports options could be contexualized for the current component as Martin suggests in option 2 without the need for a separate Reports block. Following this logic, we would see user activity reports located in the profile settings of the settings block.

          And I suppose activity reports could remain located in the Navigation -> Course -> Participants -> Activity reports if people felt it necessary. I'm not convinced it has to be there.

          Show
          Eric Strom added a comment - @Ray I would argue differently on the perspective of role/functionality of reports. Coming at this from the instructor perspective (the primary beneficiary of the value of reports), I would suggest that MOST users approach their moodle interface with two mindsets: 1) Course content or "stuff" (activities, modules, resources, blocks, etc.) 2) Not course content (everything else) This lumps course settings, records of activity data and site level customizations together. Even though reports don't change data, they often are manipulating information with filters and such. I don't think the general user differentiates between this and other under the hood settings like an administrator or programmer might. The more I think about it, the more I feel satisfied with option 1. Agreeing with Michael's recent comments. If the contextual piece in the settings block remains as it has been, the reports options could be contexualized for the current component as Martin suggests in option 2 without the need for a separate Reports block. Following this logic, we would see user activity reports located in the profile settings of the settings block. And I suppose activity reports could remain located in the Navigation -> Course -> Participants -> Activity reports if people felt it necessary. I'm not convinced it has to be there.
          Hide
          Ray Morris added a comment - - edited

          @Eric
          > Coming at this from the instructor perspective ... approach their moodle interface with two mindsets:
          > 1) Course content or "stuff" (activities, modules, resources, blocks, etc.)

          Understood. From an instructor perspective, I would imagine you're quite conscious of Edit Mode and normal (run) mode. Looking at stuff versus changing stuff. That's an important distinction, and it's precisely the distinction between Settings and Reports.

          Show
          Ray Morris added a comment - - edited @Eric > Coming at this from the instructor perspective ... approach their moodle interface with two mindsets: > 1) Course content or "stuff" (activities, modules, resources, blocks, etc.) Understood. From an instructor perspective, I would imagine you're quite conscious of Edit Mode and normal (run) mode. Looking at stuff versus changing stuff. That's an important distinction, and it's precisely the distinction between Settings and Reports.
          Hide
          Eric Strom added a comment -

          @Ray

          > "Looking at stuff versus changing stuff."
          No, I'm not highlighting that distinction (edit on and view modes). I am framing this as the learning objects and resources of the course (content) vs all other aspects that are used to control, modify or work with the LMS environment (settings). I think this differs from what you suggest.

          To describe another way, I am suggesting that Reports are considered an "Other" - something outside of the actual course material and participants engaging in them. Settings are also an "Other" - not directly active in the course engagement - or at least we would like them to be transparent enough to users that it feels that way.

          Show
          Eric Strom added a comment - @Ray > "Looking at stuff versus changing stuff." No, I'm not highlighting that distinction (edit on and view modes). I am framing this as the learning objects and resources of the course (content) vs all other aspects that are used to control, modify or work with the LMS environment (settings). I think this differs from what you suggest. To describe another way, I am suggesting that Reports are considered an "Other" - something outside of the actual course material and participants engaging in them. Settings are also an "Other" - not directly active in the course engagement - or at least we would like them to be transparent enough to users that it feels that way.
          Hide
          Ray Morris added a comment -

          @Eric

          Both can be true. "Is not course content" doesn't imply "is an administrative setting". If a report is "not a banana" that doesn't mean it's an apricot. You are conscious of whether or not you are in edit mode, correct? Therefore you understand the difference between "see" and "change". So I think we'd agree that there are three types of things: course content, reports about what happened, and administrative settings.

          Show
          Ray Morris added a comment - @Eric Both can be true. "Is not course content" doesn't imply "is an administrative setting". If a report is "not a banana" that doesn't mean it's an apricot. You are conscious of whether or not you are in edit mode, correct? Therefore you understand the difference between "see" and "change". So I think we'd agree that there are three types of things: course content, reports about what happened, and administrative settings.
          Hide
          Martin Dougiamas added a comment -

          My feeling at the moment after reading people's feedback now is that the general consensus is towards #1. Nothing is perfect but this seems to be the best combination of ease of migration and performance.

          If we do this I think it's essential we change the block name back to Administration (I quite liked someone's suggestion of "Management" but this has even more change issues for training, docs etc).

          In any case I'm glad it's been aired more widely and a bunch of you have taken the time to offer your thoughts, thank you.

          So my +10 for the current patch in this bug plus renaming the block, in 2.5 only. And I suspect we could also tweak some of the names/structure within the admin block but that can be separate and later.

          I think you can press on, Fred.

          Show
          Martin Dougiamas added a comment - My feeling at the moment after reading people's feedback now is that the general consensus is towards #1. Nothing is perfect but this seems to be the best combination of ease of migration and performance. If we do this I think it's essential we change the block name back to Administration (I quite liked someone's suggestion of "Management" but this has even more change issues for training, docs etc). In any case I'm glad it's been aired more widely and a bunch of you have taken the time to offer your thoughts, thank you. So my +10 for the current patch in this bug plus renaming the block, in 2.5 only. And I suspect we could also tweak some of the names/structure within the admin block but that can be separate and later. I think you can press on, Fred.
          Hide
          Frédéric Massart added a comment -

          Thanks everyone! I am pushing this issue for integration. Cheers, Fred.

          Show
          Frédéric Massart added a comment - Thanks everyone! I am pushing this issue for integration. Cheers, Fred.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          While code looks ok... I think there are still some inconsistencies to review:

          I01) Front page continues showing "Front page settings".
          I02) Offtopic: Category shows "Category: XXXX"
          I03) Course shows "logs" under reports and activity shows "logs" as an own item (no under reports).
          I04) Quiz shows reports under "results" (instead of "reports"), and not below "filters", like the rest but in an arbitrary position. Again, "logs" has its own item.

          And then, some observation: If the goal is to make "reports" to be shown always there, below "filters", and we want to do consistenly for front page, course cat, course and module pages... shouldn't we "force" modules to have to follow some API to inject their own reports in a standard way instead of current "freedom" ? (See I04). I think now it's the time to do so, not later.

          So reopening... ciao

          Show
          Eloy Lafuente (stronk7) added a comment - While code looks ok... I think there are still some inconsistencies to review: I01) Front page continues showing "Front page settings". I02) Offtopic: Category shows "Category: XXXX" I03) Course shows "logs" under reports and activity shows "logs" as an own item (no under reports). I04) Quiz shows reports under "results" (instead of "reports"), and not below "filters", like the rest but in an arbitrary position. Again, "logs" has its own item. And then, some observation: If the goal is to make "reports" to be shown always there, below "filters", and we want to do consistenly for front page, course cat, course and module pages... shouldn't we "force" modules to have to follow some API to inject their own reports in a standard way instead of current "freedom" ? (See I04). I think now it's the time to do so, not later. So reopening... ciao
          Hide
          CiBoT added a comment -

          Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.

          Show
          CiBoT added a comment - Moving this reopened issue out from current integration. Please, re-submit it for integration once ready.
          Hide
          Frédéric Massart added a comment -

          Hi Eloy, here are my 2c:

          1/ To me 'Front page settings' sounds better than 'Front page administration' even if under the block 'Administration'. A bit like 'Profile settings'.
          3/ The problem here is that the reports node is created whenever a module has reports sub modules. None of the core ones have (see below about quiz), so I am not sure whether we should move the logs to a reports node, knowing that for 100% of the core modules it would only contain logs. Also, note that logs in module settings is just a redirect to the course reports > logs.
          4/ I mentioned to Tim that Quizzes were not using the 'Report API' but he seemed confident that naming them 'Results' and placing them where I've moved them was the best. I'll let him comment on that.

          About the freedom, we're actually not giving it at all. If the module uses the right API to extend the report navigation (report_extend_navigation_module), those links will be displayed under Reports. But, of course, as modules can extend the navigation, they can bypass this and add nodes to the module settings directly (see Quiz).

          Show
          Frédéric Massart added a comment - Hi Eloy, here are my 2c: 1/ To me 'Front page settings' sounds better than 'Front page administration' even if under the block 'Administration'. A bit like 'Profile settings'. 3/ The problem here is that the reports node is created whenever a module has reports sub modules . None of the core ones have (see below about quiz), so I am not sure whether we should move the logs to a reports node, knowing that for 100% of the core modules it would only contain logs . Also, note that logs in module settings is just a redirect to the course reports > logs. 4/ I mentioned to Tim that Quizzes were not using the 'Report API' but he seemed confident that naming them 'Results' and placing them where I've moved them was the best. I'll let him comment on that. About the freedom , we're actually not giving it at all. If the module uses the right API to extend the report navigation (report_extend_navigation_module), those links will be displayed under Reports . But, of course, as modules can extend the navigation, they can bypass this and add nodes to the module settings directly (see Quiz).
          Hide
          Tim Hunt added a comment -

          Note that there are various sorts of plug-in here.
          First there are generic report_ plugins in the top level report/ folder. They can add themselves anywhere in the UI, for any context. That is how log links appear everywhere.

          Then, in particular modules, like quiz, there are types of sub-plugin. In the quiz we have quiz report plugins in mod/quiz/report/. Report is not quite the right word here, because it includes things like the manual grading UI. Certainly, in the context of the quiz, putting these things in the settings nav makes the most sense locally, even if it is inconsistent globally. Someone as to make a judgement call here. My opinion was to have a separate Results item for them:

          • It is the word that users are familiar with looking for.
          • It makes the quiz-specific things separate from the generic reports like logs.

          but I may be wrong. However, you need to come up with a coherent argument why doing something different is better. A one-word answer 'consistency' is not sufficient.

          Show
          Tim Hunt added a comment - Note that there are various sorts of plug-in here. First there are generic report_ plugins in the top level report/ folder. They can add themselves anywhere in the UI, for any context. That is how log links appear everywhere. Then, in particular modules, like quiz, there are types of sub-plugin. In the quiz we have quiz report plugins in mod/quiz/report/. Report is not quite the right word here, because it includes things like the manual grading UI. Certainly, in the context of the quiz, putting these things in the settings nav makes the most sense locally, even if it is inconsistent globally. Someone as to make a judgement call here. My opinion was to have a separate Results item for them: It is the word that users are familiar with looking for. It makes the quiz-specific things separate from the generic reports like logs. but I may be wrong. However, you need to come up with a coherent argument why doing something different is better. A one-word answer 'consistency' is not sufficient.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Well,

          all the (1-4) inconsistencies there were commented from a user POV (visual), not looking to the internals of how each type of plugin injects itself.

          So I was not looking for a technical explanation but for a usability re-considerations, now that we have decided to perform the "move" (finally, yay!).

          And that's the only reason I exposed those inconsistencies (for me, again, as a user), looking forward for some discussion.

          If everybody agrees that the inconsistencies are not inconsistencies and it has 100% sense to show the reports in that way, np here (although my brain continues processing them as "wrong").

          IMO some day we should decide clearly where each report (based on x,y,z criteria) should go. And I don't see those criteria defined and applied (hence, again, the/my inconsistencies).

          Anyway, that's all from my side. Feel free to ignore them. Next week this will be integrated from a technical-pov and done.

          Thanks for the explanations, ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Well, all the (1-4) inconsistencies there were commented from a user POV (visual), not looking to the internals of how each type of plugin injects itself. So I was not looking for a technical explanation but for a usability re-considerations, now that we have decided to perform the "move" (finally, yay!). And that's the only reason I exposed those inconsistencies (for me, again, as a user), looking forward for some discussion. If everybody agrees that the inconsistencies are not inconsistencies and it has 100% sense to show the reports in that way, np here (although my brain continues processing them as "wrong"). IMO some day we should decide clearly where each report (based on x,y,z criteria) should go. And I don't see those criteria defined and applied (hence, again, the/my inconsistencies). Anyway, that's all from my side. Feel free to ignore them. Next week this will be integrated from a technical-pov and done. Thanks for the explanations, ciao
          Hide
          Amy Groshek added a comment - - edited

          It may have already been pointed out that students currently access grades from the Settings block. And grades are by definition a report.

          This is a difficult argument to take a side on, because we have also presented ourselves with a very binary decision. The fact that learner actions and administrator actions cross over in the Settings block muddies the decision quite a bit. Neither "Settings" nor "Administration" feel right for an action taken by a student. Wherever we place these things, all reports available to a student, including grades, should be quickly and easily accessible in the same area of the screen, ideally in the same list. Learners should never have to struggle to get information about their own learning.

          Show
          Amy Groshek added a comment - - edited It may have already been pointed out that students currently access grades from the Settings block. And grades are by definition a report. This is a difficult argument to take a side on, because we have also presented ourselves with a very binary decision. The fact that learner actions and administrator actions cross over in the Settings block muddies the decision quite a bit. Neither "Settings" nor "Administration" feel right for an action taken by a student. Wherever we place these things, all reports available to a student, including grades, should be quickly and easily accessible in the same area of the screen, ideally in the same list. Learners should never have to struggle to get information about their own learning.
          Hide
          Petr Škoda added a comment -

          Hmm, maybe we should look for a new name for this block. How does "Utilities" sound to native English speakers?

          Show
          Petr Škoda added a comment - Hmm, maybe we should look for a new name for this block. How does "Utilities" sound to native English speakers?
          Hide
          Amy Groshek added a comment -

          Petr Škoda I personally like "Utilities" better and think it's a good suggestion. Interested to hear what others think.

          Show
          Amy Groshek added a comment - Petr Škoda I personally like "Utilities" better and think it's a good suggestion. Interested to hear what others think.
          Hide
          Chris Follin added a comment - - edited

          I started a conversation at Moodlerooms about this topic to get company-wide feedback. Everyone was in 100% agreement with Reports being moved to the Settings block. However, no one wants the Settings block to be renamed, at least not in Moodle 2. The name "Settings" does not suddenly become inaccurate if Reports is moved into that block. The name "Settings" has been inaccurate all along as many items currently in that block are not settings (Users, Grades, Backup/Restore). Changing the name in Moodle 2 has a huge impact on all existing user documentation, screenshots, training courses and collateral, support documents, and sales demos. Virtually everything references that block by name and would need to be changed. Especially for us as a Partner, the effort required to update the name of the block in all of the things I mentioned is disproportionate to the actual value of changing the name. We strongly prefer that the name remains "Settings" until Moodle 3, at which point we would need to update all of these things anyway, so the additional effort for a name change is significantly less than the effort for a name change alone.

          That said, if the name must change now (or thinking ahead to Moodle 3) our internal consensus was initially for the name "Utilities" although that raised a point that it makes some people think of public utilities (like electricity and water/sewer) and paying bills. The name "Tools" was then suggested and support swung in favor of "Tools." Many thought "Tools" will translate to other languages better than "Utilities." There were few votes for "Administration" and "Management" as these two do not seem, to most people, to be relevant to students.

          Show
          Chris Follin added a comment - - edited I started a conversation at Moodlerooms about this topic to get company-wide feedback. Everyone was in 100% agreement with Reports being moved to the Settings block. However, no one wants the Settings block to be renamed, at least not in Moodle 2. The name "Settings" does not suddenly become inaccurate if Reports is moved into that block. The name "Settings" has been inaccurate all along as many items currently in that block are not settings (Users, Grades, Backup/Restore). Changing the name in Moodle 2 has a huge impact on all existing user documentation, screenshots, training courses and collateral, support documents, and sales demos. Virtually everything references that block by name and would need to be changed. Especially for us as a Partner, the effort required to update the name of the block in all of the things I mentioned is disproportionate to the actual value of changing the name. We strongly prefer that the name remains "Settings" until Moodle 3, at which point we would need to update all of these things anyway, so the additional effort for a name change is significantly less than the effort for a name change alone. That said, if the name must change now (or thinking ahead to Moodle 3) our internal consensus was initially for the name "Utilities" although that raised a point that it makes some people think of public utilities (like electricity and water/sewer) and paying bills. The name "Tools" was then suggested and support swung in favor of "Tools." Many thought "Tools" will translate to other languages better than "Utilities." There were few votes for "Administration" and "Management" as these two do not seem, to most people, to be relevant to students.
          Hide
          Ray Morris added a comment -

          +1 for "Tools" in Moodle 3.

          Show
          Ray Morris added a comment - +1 for "Tools" in Moodle 3.
          Hide
          Frédéric Massart added a comment -

          Thanks everyone for your feedback on this issue. As discussed on Jabber with Eloy, I am pushing this issue for integration as it has been discussed and approved. Although, as there are still discussion going on about the title of the Settings block, I have included the title change as a separate commit to help the integrators ignoring it if need be.

          Show
          Frédéric Massart added a comment - Thanks everyone for your feedback on this issue. As discussed on Jabber with Eloy, I am pushing this issue for integration as it has been discussed and approved. Although, as there are still discussion going on about the title of the Settings block, I have included the title change as a separate commit to help the integrators ignoring it if need be.
          Hide
          Dan Poltawski added a comment - - edited

          Since Martin has made the call on making the change to administration, I will be integrating it this way. (Nobody ever got fired for integrating MDs directions ) .

          However, I asked Fred to switch from using get_string('administration') to switch the pluginname properly, else we'd end up with an inconsistent interface with some things calling it settings and some things calling it administration.

          Fred, you've missed:

          $string['settings:addinstance'] = 'Add a new settings block';
          $string['settings:myaddinstance'] = 'Add a new settings block to the My Moodle page';
          
          Show
          Dan Poltawski added a comment - - edited Since Martin has made the call on making the change to administration, I will be integrating it this way. ( Nobody ever got fired for integrating MDs directions ) . However, I asked Fred to switch from using get_string('administration') to switch the pluginname properly, else we'd end up with an inconsistent interface with some things calling it settings and some things calling it administration. Fred, you've missed: $string['settings:addinstance'] = 'Add a new settings block'; $string['settings:myaddinstance'] = 'Add a new settings block to the My Moodle page';
          Hide
          Frédéric Massart added a comment -

          Oops. That's fixed now!

          Show
          Frédéric Massart added a comment - Oops. That's fixed now!
          Hide
          Dan Poltawski added a comment -

          Integrated, thanks Fred.

          Show
          Dan Poltawski added a comment - Integrated, thanks Fred.
          Hide
          Helen Foster added a comment -

          Please could we make it 'My home' rather than 'My Moodle'.

          Show
          Helen Foster added a comment - Please could we make it 'My home' rather than 'My Moodle'.
          Hide
          Martin Dougiamas added a comment -

          New bug for that, Helen (I do agree though).

          Show
          Martin Dougiamas added a comment - New bug for that, Helen (I do agree though).
          Hide
          Rossiani Wijaya added a comment -

          This is working as expected.

          Tested only for Master.

          Test passed.

          Show
          Rossiani Wijaya added a comment - This is working as expected. Tested only for Master. Test passed.
          Hide
          Amy Groshek added a comment -

          Note for posterity's sake re: Chris Follin's comment: poll at Remote-Learner had folks heavily favoring "Tools" as well.

          Show
          Amy Groshek added a comment - Note for posterity's sake re: Chris Follin 's comment: poll at Remote-Learner had folks heavily favoring "Tools" as well.
          Hide
          Petr Škoda added a comment -

          "Tools" sounds good!

          Show
          Petr Škoda added a comment - "Tools" sounds good!
          Hide
          Damyon Wiese added a comment -

          Thanks for your hard work - this issue has made it! Moodle is now a little bit better.

          Regards, Damyon

          Show
          Damyon Wiese added a comment - Thanks for your hard work - this issue has made it! Moodle is now a little bit better. Regards, Damyon
          Hide
          Tim Hunt added a comment -

          The final version of this patch set the quiz version number to 2013310100. I am fixing that mess in MDL-38557.

          Show
          Tim Hunt added a comment - The final version of this patch set the quiz version number to 2013310100. I am fixing that mess in MDL-38557 .
          Hide
          Dan Poltawski added a comment -

          Hmm, disappointed I didn't spot that, but also that the CI server didn't.

          Show
          Dan Poltawski added a comment - Hmm, disappointed I didn't spot that, but also that the CI server didn't.
          Hide
          Dan Poltawski added a comment -

          Regarding the CI checking to avoiding regressions like this, i've added comments on MDLSITE-1973.

          Show
          Dan Poltawski added a comment - Regarding the CI checking to avoiding regressions like this, i've added comments on MDLSITE-1973 .
          Hide
          Mary Cooch added a comment -

          Removing the docs_required label as I have been through the 2.5 docs and changed references to reports from their old to their new location with their new name, and Helen has changed the Settings block to Administration.

          Show
          Mary Cooch added a comment - Removing the docs_required label as I have been through the 2.5 docs and changed references to reports from their old to their new location with their new name, and Helen has changed the Settings block to Administration.

            People

            • Votes:
              26 Vote for this issue
              Watchers:
              33 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: