Talk:Modules and plugins replacement proposal

Some minor suggestions from Tim (so much for the request not to comment yet):

• This may be a version 2.0 feature, but simple links from the database entries to the place on AMOS where people need to go to translate this plugin, and back again.
• In terms of which version of core Moodle the plugins works with, there are big advantages if this information can remain in version.php, where it is readable by the Moodle install code. The MnP database could automatically read the data out of there to display on the web, like AMOS gets strings out of version control.

In the database schema:

• Rather than separate local_contrib_plugin_contributor.creator/active columns, would it be better to have a single contributortype column? Easier to extend in future.
• Should userid be in local_contrib_review or local_contrib_review_outcome?
• If there a good reason for using 'softwareversion' in names? moodleversion would make it clearer. Of course, that is less generic.
• should local_contrib_review_outcomes have a machine-readable column that holds a status like pass/fail, as well as the text in review?
• Do you really need hierarchical categories. They are a pain in SQL, and they add UI complexity. I think one-level categories may be fine, particularly if you have tags as well.

In terms of display, it would be nice if you could use group icons from using Moodle (like core-developer, Partner, PHM) when displaying users. It would be useful if people could see that a review was by a core developer.

I had not realised that the file API did not support local plugins. See https://github.com/moodle/moodle/blob/master/pluginfile.php#L738

Would a capability like "new entries from this user approved automatically" and "new versions from this user approved automatically" be worthwhile? I believe the current system overloads the approve capability for this, which causes pain.

--Tim Hunt 09:17, 12 January 2011 (UTC)