Moodle
  1. Moodle
  2. MDL-21504

Inserting/Deleting new Navigation block

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a bug
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Blocks, Navigation
    • Labels:
      None
    • Affected Branches:
      MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      32184

      Description

      Using Moodle 2.0 dev (Build: 20100203)
      In a course, it is possible for a teacher to Add a Navigation block, in fact to add several Navigation blocks... But it is impossible to Delete them!
      When one navigation block is already displayed in a course, the option to add an extra one should not appear in the Blocks dropdown list. At least it should be possible to delete extra ones...
      Joseph

        Activity

        Hide
        Dan Marsden added a comment -

        looks like only one navigation block can be added now, but the icon to delete an existing block isn't there - assigning to Sam as I think he wrote the navigation block

        Sam - this happens when you set the navigation block as "non-sticky" and then add it to an existing course - the user can't delete the block after adding it as the delete icon isn't shown.

        Show
        Dan Marsden added a comment - looks like only one navigation block can be added now, but the icon to delete an existing block isn't there - assigning to Sam as I think he wrote the navigation block Sam - this happens when you set the navigation block as "non-sticky" and then add it to an existing course - the user can't delete the block after adding it as the delete icon isn't shown.
        Hide
        Sam Hemelryk added a comment - - edited

        Hi guys,

        Good spotting with the nav and settings blocks, you noted that you could originally add several navigation blocks but not delete them, this was infact due to a bug in the block system that has since been resolved.
        In regards to the navigation blocks not being deletable this is in fact intentional, because the navigation and settings blocks are not integral to the operation of Moodle it was deemed necessary to ensure that people could not (well not easily anyway) render there site unusable by deleting those blocks.
        This of course came about after several people complained after they deleted these blocks

        That being said we didn't lock it off completely, there is a method of overriding the non-deletable blocks by adding a config variable to your sites config.php file.
        By default it is as shown below:

        $CFG->undeletableblocktypes = 'navigation,settings';
        

        To make those blocks deletable simple add $CFG->undeletableblocktypes = ''; to your config.php.

        Hope this helps, feel free to re-open this issue if you would like to discuss it more.

        Cheers
        Sam

        Show
        Sam Hemelryk added a comment - - edited Hi guys, Good spotting with the nav and settings blocks, you noted that you could originally add several navigation blocks but not delete them, this was infact due to a bug in the block system that has since been resolved. In regards to the navigation blocks not being deletable this is in fact intentional, because the navigation and settings blocks are not integral to the operation of Moodle it was deemed necessary to ensure that people could not (well not easily anyway) render there site unusable by deleting those blocks. This of course came about after several people complained after they deleted these blocks That being said we didn't lock it off completely, there is a method of overriding the non-deletable blocks by adding a config variable to your sites config.php file. By default it is as shown below: $CFG->undeletableblocktypes = 'navigation,settings'; To make those blocks deletable simple add $CFG->undeletableblocktypes = ''; to your config.php. Hope this helps, feel free to re-open this issue if you would like to discuss it more. Cheers Sam
        Hide
        Dan Marsden added a comment -

        Thanks Sam, I don't think I like this all that much.... wouldn't it be better suited to a capability that allows deleting of undeletable block types given to admin by default?

        The Settings/navigation blocks are added by default as sticky blocks - if a site admin decides they don't want them as sticky blocks there should be some way to delete blocks added to courses without using a hack to config.php - I understand it might be a good idea to prevent teachers from deleting them, but if we give them the ability to add them to a course when not added as a sticky - there should be some way in the standard interface to allow deleting without a hack to config.php

        was there some discussion on this somewhere that I have missed? - using a hard-coded config.php setting instead of a capability?

        Show
        Dan Marsden added a comment - Thanks Sam, I don't think I like this all that much.... wouldn't it be better suited to a capability that allows deleting of undeletable block types given to admin by default? The Settings/navigation blocks are added by default as sticky blocks - if a site admin decides they don't want them as sticky blocks there should be some way to delete blocks added to courses without using a hack to config.php - I understand it might be a good idea to prevent teachers from deleting them, but if we give them the ability to add them to a course when not added as a sticky - there should be some way in the standard interface to allow deleting without a hack to config.php was there some discussion on this somewhere that I have missed? - using a hard-coded config.php setting instead of a capability?
        Hide
        Sam Hemelryk added a comment -

        Hi Dan,

        First up I've added some watchers to get this a some immediate exposure

        The actual issue of un-deletable blocks was raised several months ago shortly after the navigation blocks were first commit in fact. The idea of using a CFG variable was chosen because it was thought unlikely that people would want to start manipulating the blocks once they came to understand how important they are to Moodles navigation now and it was the most sure fire way to ensure that people were 100% aware of what they were doing, having to manually set a config var ensures that admins who are new or unfamiliar with Moodle don't just rampage off and delete all their navigation.

        That being said managing it by capabilities may be a good idea, allowing admins to delete the block or assign the capability out as they desire.

        Personally if we were going to do something about I would myself lean towards adding a userid field to the block instances table to record who added it and then add a capability to the allow deleting blocks you've added.
        Undeletable blocks added by the system would still be undeletable however the admin could set them to just the site pages and then add or allow people to add the blocks to pages they desire. This would ensure that the admin could tinker to their hearts content, and we'd be safe in knowing that there was always an instance of the block even if it were just at the sit level....
        Anyway just more ideas.

        Watchers I'd be keen to hear your thoughts on this?

        Cheers
        Sam

        Show
        Sam Hemelryk added a comment - Hi Dan, First up I've added some watchers to get this a some immediate exposure The actual issue of un-deletable blocks was raised several months ago shortly after the navigation blocks were first commit in fact. The idea of using a CFG variable was chosen because it was thought unlikely that people would want to start manipulating the blocks once they came to understand how important they are to Moodles navigation now and it was the most sure fire way to ensure that people were 100% aware of what they were doing, having to manually set a config var ensures that admins who are new or unfamiliar with Moodle don't just rampage off and delete all their navigation. That being said managing it by capabilities may be a good idea, allowing admins to delete the block or assign the capability out as they desire. Personally if we were going to do something about I would myself lean towards adding a userid field to the block instances table to record who added it and then add a capability to the allow deleting blocks you've added. Undeletable blocks added by the system would still be undeletable however the admin could set them to just the site pages and then add or allow people to add the blocks to pages they desire. This would ensure that the admin could tinker to their hearts content, and we'd be safe in knowing that there was always an instance of the block even if it were just at the sit level.... Anyway just more ideas. Watchers I'd be keen to hear your thoughts on this? Cheers Sam
        Hide
        Dan Marsden added a comment -

        I guess the problem for me is that we allow admins to change the "un-deleteable" blocks on the site homepage from sticky to non-sticky. If we prevented this then it might make more sense?

        By changing to non-sticky they are "deleting" the blocks from appearing on course pages.

        so - short term solution might just be that we prevent "un-deleteable" blocks from changing from sticky/non-sticky when unless the config setting is reset?

        Show
        Dan Marsden added a comment - I guess the problem for me is that we allow admins to change the "un-deleteable" blocks on the site homepage from sticky to non-sticky. If we prevented this then it might make more sense? By changing to non-sticky they are "deleting" the blocks from appearing on course pages. so - short term solution might just be that we prevent "un-deleteable" blocks from changing from sticky/non-sticky when unless the config setting is reset?

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: