Moodle
  1. Moodle
  2. MDL-30340

Block config on some pages result in settings you can't undo, and undesirable pagetype/context settings

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.1.2, 2.2
    • Fix Version/s: 2.2
    • Component/s: Blocks
    • Labels:
    • Rank:
      32700

      Description

      I am trying to customize the blocks that students will see on their user profile page. I go to Settings > Site Administration > Appearance > Default profile page and click the "Customize this page" button. Then, I add a block. If I leave it as-is, it works fine, and appears where it should. But if I can go into its settings to edit its page context, strange things happen. The first time you access it, there are two choices under "Display on page types": "Only user profile pages" and "My home page." The SECOND and all later times that you return to those settings, a third option "All pages," has appeared.

      What is problematic is that, once "All pages" has appeared, the block's "Display on page types" ALWAYS defaults to this, no matter what setting I choose. If I change "Only user profile pages" (see image "beforesaving.png"), and then press "Save," the setting is actually immediately reset to "All pages" (see image "aftersaving.png"). I cannot figure out why the setting that I apply won't "stick."

      I have replicated this problem on both our local Moodle 2.x installation and on demo.moodle.org.

      1. MDL-30340-bui_editingatfrontpage-fix.diff
        4 kB
        Martin Dougiamas
      1. aftersaving.png
        57 kB
      2. beforesaving.png
        58 kB

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting this. A prime example of a solid bug report.

          I wonder if this has to do with the page layout of the profile page.

          I've put it on our backlog.

          In the meantime feel free to help us work on this issue. If you are able to provide a patch, please add a patch label so we will spot it.

          Show
          Michael de Raadt added a comment - Thanks for reporting this. A prime example of a solid bug report. I wonder if this has to do with the page layout of the profile page. I've put it on our backlog. In the meantime feel free to help us work on this issue. If you are able to provide a patch, please add a patch label so we will spot it.
          Hide
          Martin Dougiamas added a comment -

          Here's another example, of trying to get a block set up to display on all user home pages (a very common requirement):

          1) As admin, create a new HTML block at site level (on the front page). Make sure it's set to display on all pages in the site.

          2) Go to your home page (/my). The block should be there.

          3) Edit the settings and change the page type menu to display only on "my-index". Save the form.

          4) Open the same settings for the block again.

          5) The page type has not changed, and it not saveable.

          Show
          Martin Dougiamas added a comment - Here's another example, of trying to get a block set up to display on all user home pages (a very common requirement): 1) As admin, create a new HTML block at site level (on the front page). Make sure it's set to display on all pages in the site. 2) Go to your home page (/my). The block should be there. 3) Edit the settings and change the page type menu to display only on "my-index". Save the form. 4) Open the same settings for the block again. 5) The page type has not changed, and it not saveable.
          Hide
          Martin Dougiamas added a comment -

          Note, this apparently is only a problem on SYSTEM blocks (created on front page or in the default pages as described by OP).

          Show
          Martin Dougiamas added a comment - Note, this apparently is only a problem on SYSTEM blocks (created on front page or in the default pages as described by OP).
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Well,

          I'm sure that the code always resetting to pagetype = '*' is the one @:

          https://github.com/stronk7/moodle/blob/master/lib/blocklib.php#L1236

          So any page having $data->bui_contexts == BUI_CONTEXTS_ENTIRE_SITE (line 1245) gets its page-type reset. I've quick tested it disabling that condition and then the page-type is stored properly.

          Just looking to the referenced MDL-21375 issue now.

          Show
          Eloy Lafuente (stronk7) added a comment - Well, I'm sure that the code always resetting to pagetype = '*' is the one @: https://github.com/stronk7/moodle/blob/master/lib/blocklib.php#L1236 So any page having $data->bui_contexts == BUI_CONTEXTS_ENTIRE_SITE (line 1245) gets its page-type reset. I've quick tested it disabling that condition and then the page-type is stored properly. Just looking to the referenced MDL-21375 issue now.
          Hide
          David Mudrak added a comment -

          I can second Eloy's findings. I just realized the pagetypepattern is reset to '*', probably because the code expects the user actually wants sticky blocks on all page types, not a specific one... Tricky sticky.

          Show
          David Mudrak added a comment - I can second Eloy's findings. I just realized the pagetypepattern is reset to '*', probably because the code expects the user actually wants sticky blocks on all page types, not a specific one... Tricky sticky.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Yeah, it seems that this comment, the "behind the scenes", is the culprit for that:

          http://tracker.moodle.org/browse/MDL-21375?focusedCommentId=80072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-80072

          For front page, the form hides the "page-type" and later calculates it "behind the scenes", doing:

          1) if "entire site" was selected, then apply for pagetype = '*'
          2) else, for any other systemcontext block, apply for pagetype = 'site-index'

          And that, happening "behind the scenes", is clearly against our attempts to specify one pagetype, efectively reseting it behind the scenes, lol.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Yeah, it seems that this comment, the "behind the scenes", is the culprit for that: http://tracker.moodle.org/browse/MDL-21375?focusedCommentId=80072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-80072 For front page, the form hides the "page-type" and later calculates it "behind the scenes", doing: 1) if "entire site" was selected, then apply for pagetype = '*' 2) else, for any other systemcontext block, apply for pagetype = 'site-index' And that, happening "behind the scenes", is clearly against our attempts to specify one pagetype, efectively reseting it behind the scenes, lol. Ciao
          Hide
          David Mudrak added a comment -

          This is a clear regression of MDL-27812

          Show
          David Mudrak added a comment - This is a clear regression of MDL-27812
          Hide
          Eloy Lafuente (stronk7) added a comment -

          So, perhaps, we could try to change the conditions a bit and only apply for those defaults if no pagetype is passed or so.

          Or, alternatively, we could bring back in the UI the page-type and avoid any "behind the scenes". After all, it only applies to the front page.

          Just attempting the first alternative...

          Show
          Eloy Lafuente (stronk7) added a comment - So, perhaps, we could try to change the conditions a bit and only apply for those defaults if no pagetype is passed or so. Or, alternatively, we could bring back in the UI the page-type and avoid any "behind the scenes". After all, it only applies to the front page. Just attempting the first alternative...
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Uhm, no way. The data comes in the form, so it is not possible to detect from where we are editing the block instance.

          We would need something coming in the form like $data->editedfrom, to be able to decide, really hacky.

          My +1 goes to bring back the UI to the front page edition, so any instance edited will look 100% the same if edited in the front page or in the my page or in the profile/my template pages.

          And revert the "behind the scenes" code, of course.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Uhm, no way. The data comes in the form, so it is not possible to detect from where we are editing the block instance. We would need something coming in the form like $data->editedfrom, to be able to decide, really hacky. My +1 goes to bring back the UI to the front page edition, so any instance edited will look 100% the same if edited in the front page or in the my page or in the profile/my template pages. And revert the "behind the scenes" code, of course. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Alternatively... we could try to prevent edition of the instance in places where it does not belong to, so:

          • Instances having * or site-* only will be editable in frontpage
          • Instances having my-index-* only editable in my/indexsys.php
          • Instances having user-* only editable in user/profilesys.php
          • Other instances (blogs, tags...) no bloody idea!

          That way, each one can have its own "behind the scenes" code, and it won't be possible to allow one to mess the other.

          That, or we allow to edit all possible pagetypes everywhere.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Alternatively... we could try to prevent edition of the instance in places where it does not belong to, so: Instances having * or site-* only will be editable in frontpage Instances having my-index-* only editable in my/indexsys.php Instances having user-* only editable in user/profilesys.php Other instances (blogs, tags...) no bloody idea! That way, each one can have its own "behind the scenes" code, and it won't be possible to allow one to mess the other. That, or we allow to edit all possible pagetypes everywhere. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Bah, but it's really inconsistent in every place I'm looking:

          • If you create one block @ course level, setting it to "show in all pages".
          • Then you go to one chat activity and edit it from there and you can set it to "Any chat page" only. But it continues being a "course-context-level" block.
          • Then, the block is not available anymore @ course page (because it's to be shown only in chat pages) and cannot be reverted anymore to "show in all pages" because chat does not allow you to pick pagetype again.
          • 100% locked situation. Only can delete the block and start from scratch!

          So, I think the only way to avoid all this is to completely avoid edition "remotely" (of the instance-related information, np with the position information) and only allow edition if both the context and pagetype match the context and pagetype of the block.

          Anything else can lead to conflicts, like the frontpage vs my, or the course vs chat.

          Ciao, gtg now for 2-3 h

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Bah, but it's really inconsistent in every place I'm looking: If you create one block @ course level, setting it to "show in all pages". Then you go to one chat activity and edit it from there and you can set it to "Any chat page" only. But it continues being a "course-context-level" block. Then, the block is not available anymore @ course page (because it's to be shown only in chat pages) and cannot be reverted anymore to "show in all pages" because chat does not allow you to pick pagetype again. 100% locked situation. Only can delete the block and start from scratch! So, I think the only way to avoid all this is to completely avoid edition "remotely" (of the instance-related information, np with the position information) and only allow edition if both the context and pagetype match the context and pagetype of the block. Anything else can lead to conflicts, like the frontpage vs my, or the course vs chat. Ciao, gtg now for 2-3 h
          Hide
          Tim Hunt added a comment -

          The problem there is the "because chat does not allow you to pick pagetype again."

          Why not? It used to allow you to change the setting back - at least to change pagetype back to *.

          Show
          Tim Hunt added a comment - The problem there is the "because chat does not allow you to pick pagetype again." Why not? It used to allow you to change the setting back - at least to change pagetype back to *.
          Hide
          Martin Dougiamas added a comment - - edited

          tim is correct, of course.

          The workflow for showing a block on all pages of a certain type:

          1. You create the block in the top context (eg a course) that covers the places you want it, and make it "sticky" so it appears on all the sub-contexts.
          2. You then go to the type of place where you want it, eg in chat and edit the block there
          3. You set the pagetype etc to show only on THIS type of page (eg all chat pages in the course)

          To undo this you:

          1. Go to the chat page where the block appears
          2. Edit the settings, and set the pagetypes back to "All" = *
          3. Then the block appears in the "home" (eg course) context again

          This process is exactly the same for a block that was created at the site, category, course, activity.

          The "locked chat" sounds like a bug. And the situation of system blocks is a bug. You NEED to be able to edit the block in all kinds of contexts UNDER the original home location, because that's how you access the pagetypes you need.

          Show
          Martin Dougiamas added a comment - - edited tim is correct, of course. The workflow for showing a block on all pages of a certain type: You create the block in the top context (eg a course) that covers the places you want it, and make it "sticky" so it appears on all the sub-contexts. You then go to the type of place where you want it, eg in chat and edit the block there You set the pagetype etc to show only on THIS type of page (eg all chat pages in the course) To undo this you: Go to the chat page where the block appears Edit the settings, and set the pagetypes back to "All" = * Then the block appears in the "home" (eg course) context again This process is exactly the same for a block that was created at the site, category, course, activity. The "locked chat" sounds like a bug. And the situation of system blocks is a bug. You NEED to be able to edit the block in all kinds of contexts UNDER the original home location, because that's how you access the pagetypes you need.
          Hide
          Martin Dougiamas added a comment -

          I really think we need to solve this before release, even if it's Monday or so.

          It's a pretty fundamental thing in the GUI and could mess up any sites that use blocks in a meaningful way.

          Show
          Martin Dougiamas added a comment - I really think we need to solve this before release, even if it's Monday or so. It's a pretty fundamental thing in the GUI and could mess up any sites that use blocks in a meaningful way.
          Hide
          Martin Dougiamas added a comment -

          Just added some watchers to help

          Show
          Martin Dougiamas added a comment - Just added some watchers to help
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Yes, your definition above would work greatly if:

          1) for parent-child relations (system <==> course <==> module) , all the children can revert the page-type to all the ones available in the parent.
          2) For siblings relations (system <==> system), all the siblings can set all the page-types.

          Nor 1) (the chat lookout) nor 2) (the frontpage able to set my-* and viceversa) are working ok now. And all because of the mutually excluding options.

          Anyway that surely needs to be revisited later (after release). For now it's enough to fix the current issue (the 2 case).

          IMO the problem for 2) is that the frontpage is being used both to define frontpage blocks and also as "another template" for system. And here it's where it collisions with the other 2 templates (the my and the profile ones).

          Said that, if I can help with anything, tell me... ttyl! Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Yes, your definition above would work greatly if: 1) for parent-child relations (system <==> course <==> module) , all the children can revert the page-type to all the ones available in the parent. 2) For siblings relations (system <==> system), all the siblings can set all the page-types. Nor 1) (the chat lookout) nor 2) (the frontpage able to set my-* and viceversa) are working ok now. And all because of the mutually excluding options. Anyway that surely needs to be revisited later (after release). For now it's enough to fix the current issue (the 2 case). IMO the problem for 2) is that the frontpage is being used both to define frontpage blocks and also as "another template" for system. And here it's where it collisions with the other 2 templates (the my and the profile ones). Said that, if I can help with anything, tell me... ttyl! Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          For the records, the "lockout" between course and modules happens with all modules, both under 21_STABLE and master. The original implementation @ 20_STABLE adds properly the last "*" element, so it's possible to "bring back" the block to the course.

          Show
          Eloy Lafuente (stronk7) added a comment - For the records, the "lockout" between course and modules happens with all modules, both under 21_STABLE and master. The original implementation @ 20_STABLE adds properly the last "*" element, so it's possible to "bring back" the block to the course.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          ANOTHER ONE: Category blocks also 100% broken, both 21_STABLE and master. It's not possible anymore to specify * all pages, to get the block shown in all sub-categories/courses. It worked perfectly in 20_STABLE.

          Show
          Eloy Lafuente (stronk7) added a comment - ANOTHER ONE: Category blocks also 100% broken, both 21_STABLE and master. It's not possible anymore to specify * all pages, to get the block shown in all sub-categories/courses. It worked perfectly in 20_STABLE.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          AND THE FINAL: Now trying to see how system (all pages) blocks are edited both at course or module level. And it's another, different, case. In this case, the list of options remains sticky to the system ones and nor the course nor the module page-types are added).

          Show
          Eloy Lafuente (stronk7) added a comment - AND THE FINAL: Now trying to see how system (all pages) blocks are edited both at course or module level. And it's another, different, case. In this case, the list of options remains sticky to the system ones and nor the course nor the module page-types are added).
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          So, apart from the original issue, we have 3 more:

          1. Lock between course blocks page-type editions at module level. (missing "*" to bring back the block to the course).
          2. Category blocks not working anymore, not spread to all children contexts. (missing "*" to pick all pages option). And surely suffering also 1) once fixed.
          3. System blocks not able to be edited with custom page-types at course or module level. And surely suffering also 1) if get fixed. This last is the one I don't know if is a bug of a wanted (sticky) feature, but in that case it does not have any sense to be able to change one system block at module level.

          The THREE problems should have its own issue if you agree they are problems, perhaps they aren't. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited So, apart from the original issue, we have 3 more: Lock between course blocks page-type editions at module level. (missing "*" to bring back the block to the course). Category blocks not working anymore, not spread to all children contexts. (missing "*" to pick all pages option). And surely suffering also 1) once fixed. System blocks not able to be edited with custom page-types at course or module level. And surely suffering also 1) if get fixed. This last is the one I don't know if is a bug of a wanted (sticky) feature, but in that case it does not have any sense to be able to change one system block at module level. The THREE problems should have its own issue if you agree they are problems, perhaps they aren't. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Solution for subproblem1: Not able to 'bring back' one block to its origins when editing @ subcontext. Needs backport to 21_STABLE!

          https://github.com/stronk7/moodle/compare/master...MDL-30340.subcontext_locks

          Show
          Eloy Lafuente (stronk7) added a comment - Solution for subproblem1: Not able to 'bring back' one block to its origins when editing @ subcontext. Needs backport to 21_STABLE! https://github.com/stronk7/moodle/compare/master...MDL-30340.subcontext_locks
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Amazing, trying to fix subproblem 2 of MDL-30340 just realized that we have pages with "dynamic" pagetype, so on edition, the pagetype = 'admin-course-category' and when browsing it is = 'page-course-category'. So setting the former on edition, causes no effect when browsing.

          Going to try if *-course-category works to cover the 2 pagetype approaches...

          That apart of the missing '*' option to spread the block over all the subcategories/courses/modules.

          Show
          Eloy Lafuente (stronk7) added a comment - Amazing, trying to fix subproblem 2 of MDL-30340 just realized that we have pages with "dynamic" pagetype, so on edition, the pagetype = 'admin-course-category' and when browsing it is = 'page-course-category'. So setting the former on edition, causes no effect when browsing. Going to try if *-course-category works to cover the 2 pagetype approaches... That apart of the missing '*' option to spread the block over all the subcategories/courses/modules.
          Hide
          David Mudrak added a comment -

          This is my attempt to fix the My Moodle sticky blocks issue. It already includes Eloy's patch from MDL-30340.subcontext_locks

          https://github.com/mudrd8mz/moodle/compare/master...MDL-30340-sticky-blocks

          Show
          David Mudrak added a comment - This is my attempt to fix the My Moodle sticky blocks issue. It already includes Eloy's patch from MDL-30340 .subcontext_locks https://github.com/mudrd8mz/moodle/compare/master...MDL-30340-sticky-blocks
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Adding link to MDL-30564 about the "varying-pagetype" behavior of the category pages.

          Also, it has been agreed about to, for now, simply add the '* option to the category blocks. Doing...

          Show
          Eloy Lafuente (stronk7) added a comment - Adding link to MDL-30564 about the "varying-pagetype" behavior of the category pages. Also, it has been agreed about to, for now, simply add the '* option to the category blocks. Doing...
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Solution for subproblem2: Not able to spread course-category blocks down to subcontexts. Need backport to 21_STABLE!

          https://github.com/stronk7/moodle/compare/master...MDL-30340.sticky_category_blocks

          Show
          Eloy Lafuente (stronk7) added a comment - Solution for subproblem2: Not able to spread course-category blocks down to subcontexts. Need backport to 21_STABLE! https://github.com/stronk7/moodle/compare/master...MDL-30340.sticky_category_blocks
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Side note, for commodity, no mater all these are going to separate issues, I'm gluing everything @:

          https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus

          git fetch git://github.com/stronk7/moodle.git MDL-30340.totus_tuus

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Side note, for commodity, no mater all these are going to separate issues, I'm gluing everything @: https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus git fetch git://github.com/stronk7/moodle.git MDL-30340 .totus_tuus Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          I've created 2 subtaks for this:

          • MDL-30565: to be able to 'bring back' the edited block to original context.
          • MDL-30566: to be able to 'spread' coursecat blocks to children contexts.

          Both should be integrated before this issue.

          Show
          Eloy Lafuente (stronk7) added a comment - - edited I've created 2 subtaks for this: MDL-30565 : to be able to 'bring back' the edited block to original context. MDL-30566 : to be able to 'spread' coursecat blocks to children contexts. Both should be integrated before this issue.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          I need some feedback about the 3) related issue commented above. Is it a bug? No? Should the "local options" be shown when the block is edited at subcontexts? All the rest of multi-context blocks (course-category, course) allow to change the pagetype on children contexts. System ones do not.

          One simple use case: Create one system-wide HTML block to be shown in all forums, pointing to the forumtiquette rules.

          Show
          Eloy Lafuente (stronk7) added a comment - - edited I need some feedback about the 3) related issue commented above. Is it a bug? No? Should the "local options" be shown when the block is edited at subcontexts? All the rest of multi-context blocks (course-category, course) allow to change the pagetype on children contexts. System ones do not. One simple use case: Create one system-wide HTML block to be shown in all forums, pointing to the forumtiquette rules.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Subproblem 3 has been moved to (non-subtask):

          • MDL-30568: allow subcontexts to play their game editing system-wide contexts

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Subproblem 3 has been moved to (non-subtask): MDL-30568 : allow subcontexts to play their game editing system-wide contexts Ciao
          Hide
          Dan Poltawski added a comment -

          I'm the assignee on this and promised to look at this weekend, but I don't think I have the detailed level of understanding of the situation that Eloy/David now have!

          Show
          Dan Poltawski added a comment - I'm the assignee on this and promised to look at this weekend, but I don't think I have the detailed level of understanding of the situation that Eloy/David now have!
          Hide
          Mary Evans added a comment -

          Eloy,
          I've just been testing this following the test instructions, and not sure if I have this correct, but could it be that some of the cases for the options are actually mutually exclusive?

          Just a thought in passing...

          Mary

          Show
          Mary Evans added a comment - Eloy, I've just been testing this following the test instructions, and not sure if I have this correct, but could it be that some of the cases for the options are actually mutually exclusive? Just a thought in passing... Mary
          Hide
          Martin Dougiamas added a comment -

          I have been testing Eloy's combined branch fairly exhaustively (https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus)

          I think it solves all the major issues and would be good enough to unblock 2.2.

          Problems remaining:

          1) When you edit a block that is on the front page (site-index), you now see two menus that conflict. You can select:

          • "Display throughout the entire site" from contexts, and
          • "site-index" from pagetypes,
            and it will only show on site-index. This is technically correct from a block code point of view, but nonsensical and confusing for users ON THIS PAGE, because there is only one site-index anyway. The solution (as it was before) is to hide the second menu altogether and always set pagetype to '*' behind the scenes (or as a hidden field). But ONLY ONLY when we are editing a block on the front page (site-index). I would like to see this fixed for 2.2 release.

          2) If I create a page on the front page, then go to Tags page and make it show only on Tag pages, it works. But if I try to reverse this process I do not see "All pages" in the Page types menu, so I can't. The block is "locked" in tags. (Note this is a not a problem for Blogs, Notes, Calendar or Reports). Can be fixed after 2.2 as this kind of tag blocks are probably a small use case.

          3) Editing a site-wide block on the Site-level Participants page breaks completely with block not found. Can be fixed after 2.2 though.

          (Mary, the test instructions are badly written, in that the OP used them to indicate the problem. They are not for testing a solution. I'll update them)

          Show
          Martin Dougiamas added a comment - I have been testing Eloy's combined branch fairly exhaustively ( https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus ) I think it solves all the major issues and would be good enough to unblock 2.2. Problems remaining: 1) When you edit a block that is on the front page (site-index), you now see two menus that conflict. You can select: "Display throughout the entire site" from contexts, and "site-index" from pagetypes, and it will only show on site-index. This is technically correct from a block code point of view, but nonsensical and confusing for users ON THIS PAGE, because there is only one site-index anyway. The solution (as it was before) is to hide the second menu altogether and always set pagetype to '*' behind the scenes (or as a hidden field). But ONLY ONLY when we are editing a block on the front page (site-index). I would like to see this fixed for 2.2 release. 2) If I create a page on the front page, then go to Tags page and make it show only on Tag pages, it works. But if I try to reverse this process I do not see "All pages" in the Page types menu, so I can't. The block is "locked" in tags. (Note this is a not a problem for Blogs, Notes, Calendar or Reports). Can be fixed after 2.2 as this kind of tag blocks are probably a small use case. 3) Editing a site-wide block on the Site-level Participants page breaks completely with block not found. Can be fixed after 2.2 though. (Mary, the test instructions are badly written, in that the OP used them to indicate the problem. They are not for testing a solution. I'll update them)
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          I continue thinking that the roots of all (big, big %) of this mess is caused by the mix of system-wide/frontpage blocks that we are trying to achieve in the frontpage UI.

          Life would be really easier and clearer for everybody if we could move the system-wide part to one new, isolated template, like the ones we have already for /my and /user/profile.

          I agree that, for system context there is only one possibility, and * could be assumed, but the 3 available for frontpage are the ones causing the UI problem, and requiring us to show them. Hence, separating would simplify a lot.

          If that is not done... I would recommend to change the UI @ frontpage to something really easier to understand and interact with. After all there are no many combinations possible there. Why not one simple drop-down menu with these combinations available:

          • Front-page only (site-index) (COURSE_CTX)
          • Any front page (site-index-*) (COURSE_CTX)
          • Any top level page (site-*) (COURSE_CTX)
          • System-wide (SYSTEM_CTX)

          That is an easy picker, that prevents any forbidden combination, and it does not require JS, nor nested pickers, not hiding anything.

          Ciao

          PS: In fact, hehe, the menu above is exactly the "Display on page types" one, so basically we can hide the "Page contexts" one, because any page-type belongs to one and only one context (i.e. the inverse automatism - page type defines context - may work).

          PS2: I'm going to take a look to the tags problem.

          Show
          Eloy Lafuente (stronk7) added a comment - - edited I continue thinking that the roots of all (big, big %) of this mess is caused by the mix of system-wide/frontpage blocks that we are trying to achieve in the frontpage UI. Life would be really easier and clearer for everybody if we could move the system-wide part to one new, isolated template, like the ones we have already for /my and /user/profile. I agree that, for system context there is only one possibility, and * could be assumed, but the 3 available for frontpage are the ones causing the UI problem, and requiring us to show them. Hence, separating would simplify a lot. If that is not done... I would recommend to change the UI @ frontpage to something really easier to understand and interact with. After all there are no many combinations possible there. Why not one simple drop-down menu with these combinations available: Front-page only (site-index) (COURSE_CTX) Any front page (site-index-*) (COURSE_CTX) Any top level page (site-*) (COURSE_CTX) System-wide (SYSTEM_CTX) That is an easy picker, that prevents any forbidden combination, and it does not require JS, nor nested pickers, not hiding anything. Ciao PS: In fact, hehe, the menu above is exactly the "Display on page types" one, so basically we can hide the "Page contexts" one, because any page-type belongs to one and only one context (i.e. the inverse automatism - page type defines context - may work). PS2: I'm going to take a look to the tags problem.
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Re: about all the blog/notes/tags... blocks:

          1. ALL them are system context.
          2. Do we really want to be able to send back one block from those pages to the "system template"? I really don't get the point about at. If somebody wants to create one block for all the blog pages or tag pages... why not, simply create it there? Creating it in the front-page as a system-wide block, just to "take/capture it" in the blog or tags page seems unnatural. More yet, I'm not sure if all the blocks available for those pages are suitable to be used out from those pages.
          3. The "bring-back" feature was thought to effectively return the block to its original (parent) context, hence it only applies for system => coursecat => course => module, but not for system => system.
          4. Blogs, for example, are able to shown the "bring back" because the * option is explicitly defined in blog_page_type_list(), but others, like note|tags_page_type_list()... don't have that option. IMO the laters are the correct ones, i.e. I'd take rid of the option in blog ASAP if the rationally in 1..3 has sense for you.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Re: about all the blog/notes/tags... blocks: ALL them are system context. Do we really want to be able to send back one block from those pages to the "system template"? I really don't get the point about at. If somebody wants to create one block for all the blog pages or tag pages... why not, simply create it there? Creating it in the front-page as a system-wide block, just to "take/capture it" in the blog or tags page seems unnatural. More yet, I'm not sure if all the blocks available for those pages are suitable to be used out from those pages. The "bring-back" feature was thought to effectively return the block to its original (parent) context, hence it only applies for system => coursecat => course => module, but not for system => system. Blogs, for example, are able to shown the "bring back" because the * option is explicitly defined in blog_page_type_list(), but others, like note|tags_page_type_list()... don't have that option. IMO the laters are the correct ones, i.e. I'd take rid of the option in blog ASAP if the rationally in 1..3 has sense for you. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Simple grep:

          grep -r "get_string('page-x', 'pagetype" *
          
          admin/lib.php: '*' => get_string('page-x', 'pagetype')
          blog/lib.php: '*'=>get_string('page-x', 'pagetype'),
          course/lib.php: return array('*'=>get_string('page-x', 'pagetype'));
          course/lib.php: return array('*'=>get_string('page-x', 'pagetype'),
          course/report/lib.php: '*' => get_string('page-x', 'pagetype'),
          lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype');
          lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype');
          report/completion/lib.php: => get_string('page-x', 'pagetype'),
          report/log/lib.php: '*'                => get_string('page-x', 'pagetype'),
          report/outline/lib.php: '*'                    => get_string('page-x', 'pagetype'),
          report/participation/lib.php: '*'                          => get_string('page-x', 'pagetype'),
          report/progress/lib.php: '*'                     => get_string('page-x', 'pagetype'),
          report/stats/lib.php: '*'                  => get_string('page-x', 'pagetype'),
          
          • admin/lib.php: correct Is the one introduced conditionally by MDL-30566 to be able to 'bring back' blocks from subcontexts to coursecat.
          • blog/lib.php: wrong As commented right above, it's a system => system situation. We should not allow to send it back to "system-template".
          • course/lib.php: wrong It only should be shown if currencontext is course. If is one block being edited @ subcontext, the 'bring-back' (MDL-30565) will add it at the end.
          • course/report: wrong It's exactly the same thing that the blog/notes/tags... so no way to have the '*' defined on them. Only if the block is being edited on subcontext the 'bring-back' will be shown.
          • lib/blocklib.php: wrong One of the uses is ok (the 'bring-back feature itself'), the other is incorrect (see default_page_type_list()). Same logic than course. The "any-page" should be shown only if editing at currentcontext (and show it on top). Else the 'bring-back' feature will show it the last.
          • report/: *wrong. Only the 'bring-back' (@ last position) should show the "any-page". No sense if not.

          Summary:

          #) Take rid of the harcoded 'page-x' options @ blog and reports. It only should be shown when the 'bring-back' feature inserts it at the end.
          #) At course/lib and default_page_type_list(), modify the use, so 'page-x' is only added (on top) if editing @ currentcontext = parentcontext. Else, the 'bring-back' feature will insert it (bottom).

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Simple grep: grep -r "get_string('page-x', 'pagetype" * admin/lib.php: '*' => get_string('page-x', 'pagetype') blog/lib.php: '*'=>get_string('page-x', 'pagetype'), course/lib.php: return array('*'=>get_string('page-x', 'pagetype')); course/lib.php: return array('*'=>get_string('page-x', 'pagetype'), course/report/lib.php: '*' => get_string('page-x', 'pagetype'), lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype'); lib/blocklib.php: $patterns['*'] = get_string('page-x', 'pagetype'); report/completion/lib.php: => get_string('page-x', 'pagetype'), report/log/lib.php: '*' => get_string('page-x', 'pagetype'), report/outline/lib.php: '*' => get_string('page-x', 'pagetype'), report/participation/lib.php: '*' => get_string('page-x', 'pagetype'), report/progress/lib.php: '*' => get_string('page-x', 'pagetype'), report/stats/lib.php: '*' => get_string('page-x', 'pagetype'), admin/lib.php: correct Is the one introduced conditionally by MDL-30566 to be able to 'bring back' blocks from subcontexts to coursecat. blog/lib.php: wrong As commented right above, it's a system => system situation. We should not allow to send it back to "system-template". course/lib.php: wrong It only should be shown if currencontext is course. If is one block being edited @ subcontext, the 'bring-back' ( MDL-30565 ) will add it at the end. course/report: wrong It's exactly the same thing that the blog/notes/tags... so no way to have the '*' defined on them. Only if the block is being edited on subcontext the 'bring-back' will be shown. lib/blocklib.php: wrong One of the uses is ok (the 'bring-back feature itself'), the other is incorrect (see default_page_type_list()). Same logic than course. The "any-page" should be shown only if editing at currentcontext (and show it on top). Else the 'bring-back' feature will show it the last. report/ : *wrong . Only the 'bring-back' (@ last position) should show the "any-page". No sense if not. Summary: #) Take rid of the harcoded 'page-x' options @ blog and reports. It only should be shown when the 'bring-back' feature inserts it at the end. #) At course/lib and default_page_type_list(), modify the use, so 'page-x' is only added (on top) if editing @ currentcontext = parentcontext. Else, the 'bring-back' feature will insert it (bottom). Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Note: I've created MDL-30574 about to discuss how system => system "bring-backs" should work and where the "any-page" option should be available. For after release.

          Show
          Eloy Lafuente (stronk7) added a comment - Note: I've created MDL-30574 about to discuss how system => system "bring-backs" should work and where the "any-page" option should be available. For after release.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Oki, back to this issue, recent chat copy/paste (slightly edited):

          [16:26:30] <stronk7> there are 3 contexts to pick:
                                 * system
                                 * frontpage only
                                 * frontpage all added
          [16:26:31] <stronk7> tell me which hidden page-types go for each one
          [16:26:39] <Martin Dougiamas (HQ)> *, site-index, *
          [16:26:54] <stronk7> that and only that, 100%
          [16:27:02] <stronk7> forever
          [16:27:15] <Martin Dougiamas (HQ)> but for the middle one, note that "*" === "site-index" because it's the only pagetype in that context
          [16:27:24] <stronk7> for now, yes
          [16:27:28] <Martin Dougiamas (HQ)> for now, yes 
          [16:27:41] <stronk7> okidoki... I'll try
          

          So I'm assuming that:

          1. picking system sets the context to system, recursively and with page-type set to "*"
          2. frontpage only sets the context to site-course, non-recursively and with page-type set to "site-index"
          3. frontpage all added sets the context to site-course, recursively and with paget-type set to "*"
          4. The wording for 3) is incorrect, should be something like "All activities in front-page" or so.
          5. all this is only valid when editing one block in frontpage and must not apply anything extra when one block is edited in any other page.

          Trying it on top of David's patch. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - Oki, back to this issue, recent chat copy/paste (slightly edited): [16:26:30] <stronk7> there are 3 contexts to pick: * system * frontpage only * frontpage all added [16:26:31] <stronk7> tell me which hidden page-types go for each one [16:26:39] <Martin Dougiamas (HQ)> *, site-index, * [16:26:54] <stronk7> that and only that, 100% [16:27:02] <stronk7> forever [16:27:15] <Martin Dougiamas (HQ)> but for the middle one, note that "*" === "site-index" because it's the only pagetype in that context [16:27:24] <stronk7> for now, yes [16:27:28] <Martin Dougiamas (HQ)> for now, yes [16:27:41] <stronk7> okidoki... I'll try So I'm assuming that: picking system sets the context to system, recursively and with page-type set to "*" frontpage only sets the context to site-course, non-recursively and with page-type set to "site-index" frontpage all added sets the context to site-course, recursively and with paget-type set to "*" The wording for 3) is incorrect, should be something like "All activities in front-page" or so. all this is only valid when editing one block in frontpage and must not apply anything extra when one block is edited in any other page. Trying it on top of David's patch. Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          Oki, here it is the patch reducing options as much as possible, following the points above:

          https://github.com/stronk7/moodle/compare/master...MDL-30340-sticky-blocks_simplify_frontpage_ui

          And the super-complete patch, including both the one above and the 2 subtasks is:

          https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus

          That continues applying clean to 21_STABLE:

          https://github.com/stronk7/moodle/compare/MOODLE_21_STABLE...MDL-30340.totus_tuus_21

          Please read the complete commit messages and the comments in code, they try to explain and reference all the important points.

          Note that the only missing thing to consider and to add es the 4) above: think about a better wording for the "frontpage-all" (with subcontexts) page-contexts setting. Current "Display on the front page and any pages added to the front page" is not intuitive at all!

          Testing should include:

          • Create block @ frontpage, playing with the 3 possible page contexts (system, frontpage only and frontpage-all).
          • Review all the rest of system-wide pages (my template, userprofile template, blogs, tags, notes), both with own defined blocks and inherited from frontpage's system-wide.
          • Review all the rest of contexts (course category, course, module), both with own defined blocks and inherited from all parent contexts.

          The only annoyances detected should be:

          • MDL-30564 - Separate course-categories admin interface and normal usage (varying pagetypes problem). It shows, when editing, "admin-xxx", and should be "coursecat xxxx", but it's not fixable until we solve the duality and apply correctly on each page-type.
          • MDL-30574 - Delete some incorrect "any page" options that should not exist (or add some missing ones, to decide in that issue). This is leading to some small inconsistencies in system => system inheritance (that IMO should be 100% forbidden, with each page showing its own pagetypes, but others may think the opposite and enable the "bring back" feature to all them).

          And that's all. Please, review, review, review and test, test, test... ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited Oki, here it is the patch reducing options as much as possible, following the points above: https://github.com/stronk7/moodle/compare/master...MDL-30340-sticky-blocks_simplify_frontpage_ui And the super-complete patch, including both the one above and the 2 subtasks is: https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus That continues applying clean to 21_STABLE: https://github.com/stronk7/moodle/compare/MOODLE_21_STABLE...MDL-30340.totus_tuus_21 Please read the complete commit messages and the comments in code, they try to explain and reference all the important points. Note that the only missing thing to consider and to add es the 4) above: think about a better wording for the "frontpage-all" (with subcontexts) page-contexts setting. Current "Display on the front page and any pages added to the front page" is not intuitive at all! Testing should include: Create block @ frontpage, playing with the 3 possible page contexts (system, frontpage only and frontpage-all). Review all the rest of system-wide pages (my template, userprofile template, blogs, tags, notes), both with own defined blocks and inherited from frontpage's system-wide. Review all the rest of contexts (course category, course, module), both with own defined blocks and inherited from all parent contexts. The only annoyances detected should be: MDL-30564 - Separate course-categories admin interface and normal usage (varying pagetypes problem). It shows, when editing, "admin-xxx", and should be "coursecat xxxx", but it's not fixable until we solve the duality and apply correctly on each page-type. MDL-30574 - Delete some incorrect "any page" options that should not exist (or add some missing ones, to decide in that issue). This is leading to some small inconsistencies in system => system inheritance (that IMO should be 100% forbidden, with each page showing its own pagetypes, but others may think the opposite and enable the "bring back" feature to all them). And that's all. Please, review, review, review and test, test, test... ciao
          Hide
          Sam Hemelryk added a comment -

          Hi Eloy,

          Things look good to me.
          I've been playing with this for the past hour and can't really fault it.
          The only thing that I did note was that if you added a user added a block to their profile page, and then moved it to their my moodle page there was no way to get it back.
          I've just had a look at the code as well, everything looks good there.

          Cheers
          Sam

          Show
          Sam Hemelryk added a comment - Hi Eloy, Things look good to me. I've been playing with this for the past hour and can't really fault it. The only thing that I did note was that if you added a user added a block to their profile page, and then moved it to their my moodle page there was no way to get it back. I've just had a look at the code as well, everything looks good there. Cheers Sam
          Hide
          Martin Dougiamas added a comment -

          Regression: page contexts for blocks are being set to front page course after any edit, even if the block is being added to another course or an activity.

          Show
          Martin Dougiamas added a comment - Regression: page contexts for blocks are being set to front page course after any edit, even if the block is being added to another course or an activity.
          Hide
          Sam Hemelryk added a comment -

          Good spotting thanks Martin!

          Show
          Sam Hemelryk added a comment - Good spotting thanks Martin!
          Hide
          Martin Dougiamas added a comment -

          OK, I've created a patch for this last regression and attached it as a diff for you, Eloy. Can you please add this to your branch?

          Show
          Martin Dougiamas added a comment - OK, I've created a patch for this last regression and attached it as a diff for you, Eloy. Can you please add this to your branch?
          Hide
          Martin Dougiamas added a comment -

          I've tested everything quite thoroughly and I'm confident this is good to integrate now.

          You just need to add my diff (attached) on top of your totus branch, Eloy.

          Show
          Martin Dougiamas added a comment - I've tested everything quite thoroughly and I'm confident this is good to integrate now. You just need to add my diff (attached) on top of your totus branch, Eloy.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Good spotting, guys. Some day we'll discuss about constant overlapping, but not today.

          Adding the diff on top...

          Show
          Eloy Lafuente (stronk7) added a comment - Good spotting, guys. Some day we'll discuss about constant overlapping, but not today. Adding the diff on top...
          Show
          Eloy Lafuente (stronk7) added a comment - Done: Final patch for this issue: https://github.com/stronk7/moodle/compare/master...MDL-30340-sticky-blocks_simplify_frontpage_ui Complete patch including both this issue & 2 subtasks: https://github.com/stronk7/moodle/compare/master...MDL-30340.totus_tuus Backport to 21_STABLE: https://github.com/stronk7/moodle/compare/MOODLE_21_STABLE...MDL-30340.totus_tuus_21 Ciao
          Hide
          Eloy Lafuente (stronk7) added a comment - - edited

          So should I self-integrate and auto-pass (MD as tester) and begin rolling 2.2 ?

          Or do you want anybody else to follow the standard complete steps?

          And 21_STABLE ? new issue for it or integrate too?

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - - edited So should I self-integrate and auto-pass (MD as tester) and begin rolling 2.2 ? Or do you want anybody else to follow the standard complete steps? And 21_STABLE ? new issue for it or integrate too? Ciao
          Hide
          Martin Dougiamas added a comment -

          Integrate it, and I'll do one last test.

          Show
          Martin Dougiamas added a comment - Integrate it, and I'll do one last test.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated (master only). New issue will be created to backport this to 21_STABLE.

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated (master only). New issue will be created to backport this to 21_STABLE.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Integrated.

          Show
          Eloy Lafuente (stronk7) added a comment - Integrated.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Note: MDL-30585 has been created about to backport this to 21_STABLE

          Show
          Eloy Lafuente (stronk7) added a comment - Note: MDL-30585 has been created about to backport this to 21_STABLE
          Hide
          Martin Dougiamas added a comment -

          Updating description to cover the more general bug that we addressed.

          Show
          Martin Dougiamas added a comment - Updating description to cover the more general bug that we addressed.
          Hide
          Martin Dougiamas added a comment -

          Working great now! Still a few issues where you can't 'undo' the settings like on course categories and tags, otherwise perfect!

          Show
          Martin Dougiamas added a comment - Working great now! Still a few issues where you can't 'undo' the settings like on course categories and tags, otherwise perfect!
          Hide
          Eloy Lafuente (stronk7) added a comment -

          And this is now part of the new, just created 22_STABLE and v2.2.0 release, yay! Thanks!

          Closing

          Show
          Eloy Lafuente (stronk7) added a comment - And this is now part of the new, just created 22_STABLE and v2.2.0 release, yay! Thanks! Closing
          Hide
          Eloy Lafuente (stronk7) added a comment -

          (adding the qa_test_required)

          Surely we should have 1/n QA tests covering the "bring back" feature expected behavior | all levels, the frontpage edition and so on.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - (adding the qa_test_required) Surely we should have 1/n QA tests covering the "bring back" feature expected behavior | all levels, the frontpage edition and so on. Ciao
          Hide
          John Lynch added a comment -

          Perhaps I misunderstood the way that this patch works, but I am experiencing the following problem, both on my local installation and on demo.moodle.org:

          If I place a block on Site Administration > Appearance > Default My Moodle page, that block never appears on the My home page of any users on the site. This behavior, at least, seemed to work semi-correctly before the patch. So how does the Default My Moodle page now work? Does it do anything?

          Show
          John Lynch added a comment - Perhaps I misunderstood the way that this patch works, but I am experiencing the following problem, both on my local installation and on demo.moodle.org: If I place a block on Site Administration > Appearance > Default My Moodle page, that block never appears on the My home page of any users on the site. This behavior, at least, seemed to work semi-correctly before the patch. So how does the Default My Moodle page now work? Does it do anything?
          Hide
          Yvonne Hamilton added a comment -

          Will 2.2 upgrade fix this specific issue? ..We have Moodle 2.1.3 and when I add the 'People' block to the Front page and select 'Display throughout the entire site' then go to a course page and edit the block and change page types to be 'Any type of course main page' it jumps back to 'Any Page' after I save it. We want to have the 'People' block on all course main pages only (not site pages as well). We want this without having to add it manually to all courses as this block got wiped out completely from all courses during our upgrade from 1.9.13
          If this issue fixes the problem then can we add a patch to our 2.1.3 instance or do we have to upgrade to 2.2? Some advice would be appreciated.
          Regards,
          Yvonne

          Show
          Yvonne Hamilton added a comment - Will 2.2 upgrade fix this specific issue? ..We have Moodle 2.1.3 and when I add the 'People' block to the Front page and select 'Display throughout the entire site' then go to a course page and edit the block and change page types to be 'Any type of course main page' it jumps back to 'Any Page' after I save it. We want to have the 'People' block on all course main pages only (not site pages as well). We want this without having to add it manually to all courses as this block got wiped out completely from all courses during our upgrade from 1.9.13 If this issue fixes the problem then can we add a patch to our 2.1.3 instance or do we have to upgrade to 2.2? Some advice would be appreciated. Regards, Yvonne
          Hide
          Tim Barker added a comment - - edited

          Hi, I just encountered an error when I tried to edit settings on a courses block that I had set to appear on any page. The error was: Either course id or category must be specified This block (id=24) does not exist on this page (http://tim.moodle.local/moodle/).

          I accessed the course block settings via the edit course settings page.

          Test steps:
          1. Add a courses block to the course page.
          2. Navigate to a sub page and set the block to appear on any page.
          3. Navigate to edit course settings page and click the edit icon on the courses block.

          Expected result:
          Edit course settings, changes cancelled and system displays edit block settings.

          Actual result:
          Exception is thrown. "Either course id or category must be specified This block (id=24) does not exist on this page (http://tim.moodle.local/moodle/)."

          I'm on integration/master

          Show
          Tim Barker added a comment - - edited Hi, I just encountered an error when I tried to edit settings on a courses block that I had set to appear on any page. The error was: Either course id or category must be specified This block (id=24) does not exist on this page ( http://tim.moodle.local/moodle/ ). I accessed the course block settings via the edit course settings page. Test steps: 1. Add a courses block to the course page. 2. Navigate to a sub page and set the block to appear on any page. 3. Navigate to edit course settings page and click the edit icon on the courses block. Expected result: Edit course settings, changes cancelled and system displays edit block settings. Actual result: Exception is thrown. "Either course id or category must be specified This block (id=24) does not exist on this page ( http://tim.moodle.local/moodle/ )." I'm on integration/master
          Hide
          Tim Barker added a comment - - edited

          It appears that this exception is thrown on this page regardless of what type of block it is. I also noticed that the block, I am currently using an HTML block, doesn't appear on "any page". It's still stuck under the course context even though it's set to appear on "any page"!

          Show
          Tim Barker added a comment - - edited It appears that this exception is thrown on this page regardless of what type of block it is. I also noticed that the block, I am currently using an HTML block, doesn't appear on "any page". It's still stuck under the course context even though it's set to appear on "any page"!
          Hide
          Tim Barker added a comment -

          Created 3 new QA tests for this MDLQA-1545, MDLQA-1546 and MDLQA-1547 as subs of MDLQA-1 master copy. If anyone has the chance to review these for me then please let me know if more are required.

          Show
          Tim Barker added a comment - Created 3 new QA tests for this MDLQA-1545 , MDLQA-1546 and MDLQA-1547 as subs of MDLQA-1 master copy. If anyone has the chance to review these for me then please let me know if more are required.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: