During the upgrade, only the lists of present activity modules, text filters and blocks are displayed. But this plugins check screen does not provide full information about the plugins status (which of them are going to be installed or upgraded). Also, we have much more plugin types in Moodle and we should provide a complete overview of them all. For some plugin types (typically activity modules' subplugins), we do not have admin interface at all.
1. During the upgrade, the administrator can see the list of all present plugins categorized by type
2. During the upgrade, the following information should be available for every single plugin: the source of the plugin (standard part of Moodle vs non-standard exension), currently installed version, source code version and location, status (new, needs upgrade, ...)
3. Display a list of all currently installed plugins, their availability (enabled / disabled) and with links to plugin-specific actions (setting, uninstall)
4. Display a unique identifier for each plugin so that admins can use it when reporting issues without the need to know what is the English name of the plugin
Most of the necasary underlying logic has already been implemented for 2.0. We just have to provide user interface for this. To implement this user interface, the following is needed:
- Have a library providing unified access to the meta-information about all plugin types. Such library must abstract from minor differences among various plugin types
- Have the names of all plugin types (activity modules, filters, blocks, assignment types etc) as strings, ideally with computable identifiers. Some of these are already defined in various strings and we can re-use them thanks to AMOS and its CPY instruction