Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Talk:Filter enable/disable by context

From MoodleDocs

Tim - Nice work! Overall, I really like the proposal and think that it would give the much needed flexibility to folks. Ultimately, admin still controls whether it is all on or all off (with enable). Here are some notes that I made as I reviewed the proposal.

  1. With respect to active, you were asking for another term which I couldn't think of but I do think it should indicate that it is active site wide.
  2. On the filter admin screen, I think it might be nice for the admin to see a list of contexts which are explicitly enabled with an option for deleting an individual context.
  3. A small detail, when deleting a filter I would want to make sure that we remember to display the notice reminding the admin to remove the code from the server to prevent it from being re-installed like we do for blocks and mods - as much consistency we can develop between how modules, blocks, and filters (i.e. plugins) are handled the more intuitive I believe Moodle is for the users.
  4. Along the lines of consistency, do the proposed navigation changes for Moodle 2.0 include providing this type of customization for blocks and modules as well? If not, I think it would be good to be able to make a block only available for Math courses, or a particular modules like WebWorks only available in Math courses. I'm not sure what other issues this might raise but it seemed like some of these ideas might also be applied in a similar way to blocks/plugins. As part of this, I envision the page have a single settings button that could display multiple tabs for filters, blocks, mods, etc. Only the tabs that make sense at the particular context would be shown. For example, it does not make sense to provide a module with block or module options so just the filter tab would appear.
  5. You mention selecting the active, inactive, inherit would be from a drop down and then question if it would be better with radio buttons. I think for consistency it would be better to use radio buttons and make it look like the capabilities page. We may be at a point where we start to develop a particular look and feel for administrative options.
  6. For "problem pages" like the user profile page that may pull in information from various places or the My Moodle page, might it be possible to get a list of the used contexts on that page and use and concat together the list of active filters? As I understand it, these would be the exception cases where you want the text to be filtered based on context it belongs to rather than the particular page. Page could be the default but perhaps you could right the function to occasionally use the context.

These were the thoughts that came to mind when I read it this morning. I'm pretty tired now so I'm not sure how coherent this is but I did want to get you some feedback. Peace - Anthony