project: Moodle
summary: Review which blocks can be added by users
description: Weve done a lot of work for 4.0, but many old blocks are still available by default for users to add. For example, the navigation block. However, given the amount of work weve done on navigation we dont want every teacher being able to add this block. So we could disable it in the admin settings. This issue is to review each block, whether it should show up in the list or not. And if not, to consider deprecating it. Edited to add: Dev docs page - Add a block cleanup| Forum discussion - Add a block cleanup for Moodle 4.0|

1.summary: Dont display blocks in the "Add a block" list if their main feature is disabled
description: Currently, some blocks related to advanced features can be added, even if this feature is disabled (for instance, blogs). A mechanism should be added to hide the block from the "Add a block" list if the main feature they are using is disabled. This is the list of blocks that could take advantage of this: - Accessibility review ($CFG->enableaccessibilitytools) - Blog menu (CFG->enableblogs) - Blog tags (CFG->enableblogs + $CFG->usetags) - Recent blog entries (CFG->enableblogs) - Comments ($CFG->usecomments) - Course completion status ($CFG->enablecompletion) - -Flickr ($CFG>usetags)- --> No change is required because it can be only added in tag pages (which can be accessed only when tags are enabled). - Global search ($CFG->enableglobalsearch) - Latest badges ($CFG->enablebadges) - Learning plans ($CFG->core_competency | enabled) - Tags ($CFG->usetags) - Random glossary entry (mod_glossary) - Network servers (auth_mnet)
2.summary: Disable by default some blocks, such as feedback, RSS or self-completion
description: The following blocks should be disabled by default in new installations. When upgrading the Moodle version, these blocks should be disabled too, unless they have any existing instance (in that case, they will stay enabled). The blocks to disable by default because they are super-specific or not as used as they were in the past are: - Course summary. It only displays the course summary. - Feedback. Its only useful when mod_feedback is created in the site course (so it would be better to ask admins using site feedbacks to enable it, instead of having it all the time in the list). - Remote RSS feeds. Nowadays, RSS is not as widely used as it was in the past. - Self completion. It makes sense only when "Self-completion" has been marked in the course completion settings. The current string "Note: The self completion block should be added to the course if manual self-completion is enabled" might be reviewed to add a reference to ask to enable it if its disabled.
3.summary: Let themes define un-addable blocks
description: After the UX improvements in Moodle 4.0, some of the blocks make no sense in boost (for instance, Navigation). However, they are still required when using classic. A new theme setting should be added to let themes mark blocks as un-addable (to avoid them being displayed in the "Add a block" list). That will allow boost to define the following blocks in the default value (that admins will be able to change): - Navigation (navigation). Navigation in Moodle 4.0 has been improved in boost so this block shouldnt be required anymore. - Administration (settings). Same reason as Navigation. - Courses (course_list). The "My courses" new page have been created, which replaces most of the content displayed on this block. - Section links (section_links). The course index should help to quickly identify and access sections in a course. This issue is about: Creating the method get_unaddable_by_theme_block_types() method (or similar). Calling this method from get_addable_blocks() in lib/blocklib.php Adding the theme setting, to let themes define their un-addable blocks. Adding the previous blocks to the boost theme.

Below is an instruction that describes a task, paired with an input that provides an epic with this format: 
"project": "Name of the project" 
"summary": "Summary of the epic user story" 
"description": "Description of the epic user story". Write a response that appropriately completes the request.### Instruction:
Break this epic user story into smaller tasks to help the developers understand the epic better, you can divide this epic into as much as you want depending on the complexity of the epic.
### Input:
project: Moodle
summary: Review which blocks can be added by users
description: Weve done a lot of work for 4.0, but many old blocks are still available by default for users to add. For example, the navigation block. However, given the amount of work weve done on navigation we dont want every teacher being able to add this block. So we could disable it in the admin settings. This issue is to review each block, whether it should show up in the list or not. And if not, to consider deprecating it. Edited to add: Dev docs page - Add a block cleanup| Forum discussion - Add a block cleanup for Moodle 4.0|

### Response:
1.summary: Dont display blocks in the "Add a block" list if their main feature is disabled
description: Currently, some blocks related to advanced features can be added, even if this feature is disabled (for instance, blogs). A mechanism should be added to hide the block from the "Add a block" list if the main feature they are using is disabled. This is the list of blocks that could take advantage of this: - Accessibility review ($CFG->enableaccessibilitytools) - Blog menu (CFG->enableblogs) - Blog tags (CFG->enableblogs + $CFG->usetags) - Recent blog entries (CFG->enableblogs) - Comments ($CFG->usecomments) - Course completion status ($CFG->enablecompletion) - -Flickr ($CFG>usetags)- --> No change is required because it can be only added in tag pages (which can be accessed only when tags are enabled). - Global search ($CFG->enableglobalsearch) - Latest badges ($CFG->enablebadges) - Learning plans ($CFG->core_competency | enabled) - Tags ($CFG->usetags) - Random glossary entry (mod_glossary) - Network servers (auth_mnet)
2.summary: Disable by default some blocks, such as feedback, RSS or self-completion
description: The following blocks should be disabled by default in new installations. When upgrading the Moodle version, these blocks should be disabled too, unless they have any existing instance (in that case, they will stay enabled). The blocks to disable by default because they are super-specific or not as used as they were in the past are: - Course summary. It only displays the course summary. - Feedback. Its only useful when mod_feedback is created in the site course (so it would be better to ask admins using site feedbacks to enable it, instead of having it all the time in the list). - Remote RSS feeds. Nowadays, RSS is not as widely used as it was in the past. - Self completion. It makes sense only when "Self-completion" has been marked in the course completion settings. The current string "Note: The self completion block should be added to the course if manual self-completion is enabled" might be reviewed to add a reference to ask to enable it if its disabled.
3.summary: Let themes define un-addable blocks
description: After the UX improvements in Moodle 4.0, some of the blocks make no sense in boost (for instance, Navigation). However, they are still required when using classic. A new theme setting should be added to let themes mark blocks as un-addable (to avoid them being displayed in the "Add a block" list). That will allow boost to define the following blocks in the default value (that admins will be able to change): - Navigation (navigation). Navigation in Moodle 4.0 has been improved in boost so this block shouldnt be required anymore. - Administration (settings). Same reason as Navigation. - Courses (course_list). The "My courses" new page have been created, which replaces most of the content displayed on this block. - Section links (section_links). The course index should help to quickly identify and access sections in a course. This issue is about: Creating the method get_unaddable_by_theme_block_types() method (or similar). Calling this method from get_addable_blocks() in lib/blocklib.php Adding the theme setting, to let themes define their un-addable blocks. Adding the previous blocks to the boost theme.
