Note:

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

Modules and plugins replacement proposal: Difference between revisions

From MoodleDocs
Line 771: Line 771:


==RSS feeds==
==RSS feeds==
There will be several publishable feed that
 
If you enable RSS feeds for this new system the following feed will be published:
 
* '''New plugins''' This RSS feed will contain just the new plugins within the system.
* '''Recent updates''' This RSS feed will contain new plugins, new versions, and updated versions.
* '''List of categories''' This RSS feed will contain a summary of each category in the system.
* '''Category plugins list''' This RSS feed will contain the more recently updated plugins in the category.
* '''Collection list''' This RSS feed will contain the most recently updated plugins in the collection.


==Screen descriptions and mockups==
==Screen descriptions and mockups==

Revision as of 07:03, 13 January 2011

Hi all before you get to excited this document is still under construction. Please bear with me while I create it and refrain from editing it. Also note there is a high chance things will change regually.

Creation of an alternative Modules and plugins database system. This is a design proposal for the system that will be created to replace the Modules and plugins database. Development of this system will be undertaken by Moodle HQ after this proposal has reached maturity.

The initial direction

The new system is to completely replace the current modules and plugins database, as well as the themes database. It has been decided that the new system will be a local plugin within Moodle. This gives us the advantage that we can both make use of the Moodle backend, as well as benefit from already having all of the user accounts, capabailities/permissions, and setup of Moodle.org for when this new system gets implemented. Because of this decision the new system will be making use of the Moodle API's whereever possible, this includes, comments, tags, if possible ratings (some improvements required) and of course the Moodle file API. Integration and reliance on these Moodle components will be documented within this proposal along with the database stucture, and screens that the system will consist of.

The following are the major design focuses for this new system:

Categorise contributed code Categorisation of code based upon the type of the code, and perhaps for unspecific areas such as hacks categorisation based upon the nature of the code as well.
Track versions of contributed code This will allow contributors to maintain multiple versions of thier code, hopefully better supporting the diversity of code between Moodle versions.
A trusted review system A trusted review system consisting of both a general review and criteria based review for versions of contributed code.
Complete supported version tracking Tracking of both major and minor release support by version of contributed code.
Full support for all types of contributed code All native Moodle plugin types including theme's as well as core patches/hacks.
Improved user interaction We hope to get users interacting more with contributors. Providing ratings, commenting, reiviewing, perhaps even contributing themselves.
Better search The ability to easily search for plugins, and plugin versions, comments, and reviews.
More comprehensive reporting Sortable, customisable reports for the an array of things within the new system.
Notification services and systems Choose to be notified when there are new plugins, new versions, new reviews, and changes or any combination of.
Support for popular version control systems Be able to link in to you projects git, cvs, or svn repository.
Statistics Downloads, views, reviews, ratings, activity etc.
Awards There will be awards for plugins that can be used for things such as showing the level of the plugin (gold, silver, bronze), or marking it was a status (featured).

Categorisation

Obvioulsy one of the big things that we want to achieve with this new system is proper categorisation of contributed code.

It would be great to be able to browse plugins by their category, search within a category, and view information organised/limited by category.

On top of this is tagging, the new system will support tagging pluggins so that we can further compartmentalise and then organise, limit, and view based upon this axis as well.

Plugins, plugin versions, and supported versions of Moodle

This new system will track not only plugins, but versions of plugins. Contributors will be able to create, or register a plugin with us and then as they continue to develope and maintain it release further versions as they desire.

When a new version for a plugin is created the contributor is able to enter detailed information at the version such as release notes, details about the VCS system used to manage the code, the previous version this version builds upon, and importantly the different versions of Moodle this plugin is designed to work with.

This is of course much more comrehensible than the information gathered by the current system where contributors update a plugin for each release and previous release information is lost.

Reviews and awards

Many people have asked for this functionality and we have listened, one of the major new features for this system will be reviews.

Reviewes will be completed by trusted people who are known to be knowledgable in Moodle development.

The reviewes themselves will consist of both a general review or the plugin as well as the review of specific criteria/ideals such as security, coding standard, usability, and documenation. The reviewer will then be able to rate each criteria, and of course the plugin as a whole.

In conjunction to this there will also be an awards system whereby when a plugin achieves notable goals it will be given awards to recognise this. This will in the initial release of the new system be a manual undertaking by an administrator.

Through the process of getting trusted reviews and awards we are again able to provide better recommendations and direction to our users.

Version controll systems and downloads

With this new system we will start collecting information about the version control system that the contributor is using. We gather this information for each version of a plugin that is created and are able to collect some or all of the following: the new of the vcs system, the url to the repository, the name of the branch, and the name of the tag.

With this information we can provide useful information and links to the end user, and whilst presently we not not attempt any intergration of monitoring perhaps in the future.

In regards to downloads we will still require users to upload thier plugin as a package, this allows us to ensure we will always ahve a valid download to historical versions. Contributors will be able to specify an optional alternative download location as well if they choose, however in order to record accurate statistics we will mediate the download link.

Reporting and nofitications

With all the new functionality and information that is going to be put into this new system we are going to need better methods of monitoring what is going on and notify certain parties when things change or are introduced.

For just this purpose the new system will be created with several reports and a notifications subsystem to keep people up to date with what is happening in the system.

Database structure

The following is the puposed database structure for this new system.

Entity relationship diagram
local_contrib_plugin
Contributed plugins and/or code
id int (10) unsigned not null
categoryid int (10) unsigned not null Maps to local_contrib_category.id
name varchar (255) not null The name of the plugin
shortdescription smalltext A short plain text description of the module
description mediumtext A complete description of the plugin
descriptionformat int(2) unsigned default 0 not null
websiteurl varchar (255) default NULL A url to a site/page about this plugin
sourcecontrolurl varchar (255) default NULL A url to a system being used to manage the source for this plugin
faqs mediumtext Frequently asked questions for/about this plugin
faqsformat int(2) unsigned default 0 not null
documentation mediumtext Documenation for/about this plugin
documentationformat int(2) unsigned default 0 not null
documentationurl varchar (255) default NULL A url to further documentation about this plugin
timecreated int (10) unsigned Time the plugin was created within out system
timelastmodified int (10) unsigned Last time the plugin or any of its versions were modified
approved int(1) unsigned default 0 not null Flag to track when this module was approved
available int(1) unsigned default 0 not null Toggle availablility of this module easily.


local_contrib_version
Tracks a version of a plugin
id int (10) unsigned not null
pluginid int (10) unsigned not null Maps to local_contrib_plugin.id
previousversionid int (10) unsigned default NULL Id of the version this version supersedes, maps to local_contrib_version.id
nextversionid int (10) unsigned default NULL Id of the version this version is superseded by, maps to local_contrib_version.id
version varchar(255) The version as a string
name varchar(255) default NULL The name of the version
status varchar(255) default NULL The status of the version, e.g. stable, development
releasenotes mediumtext Notes about this version of the plugin
releasenotesformat int(2) unsigned default 0 not null
websiteurl varchar (255) default NULL A url to a site/page about this plugin version
altdownloadurl varchar (255) default NULL An alternative download location for this plugin version
vcssystem varchar (255) default NULL The version control system used to manage this version (git, cvs, svn)
vcsrepositoryurl varchar (255) default NULL The url to the VCS used to manage this plugin version
vcsbranch varchar (255) default NULL The branch for this version within the VCS
vcstag varchar (255) default NULL The tag for this version within the VCS
timecreated int (10) unsigned Timestamp when this version was created
timelastmodified int (10) unsigned Timestamp when this version was last updated in some way
approved int(1) unsigned default 0 not null Set to 1 when the version has been approved and is available to the public
available int(1) unsigned default 1 not null When on this version is visible to the public


local_contrib_category
Plugin categories
id int (10) unsigned not null
parentid int (10) unsigned not null Maps to local_contrib_category.id
name varchar (255) not null The name of this category
shortdescription smalltext A short plain text description of this category
description mediumtext A full description of this category.
descriptionformat int(2) unsigned default 0 not null


local_contrib_contributor
Tracks the contributors to a project so that no one gets forgotten.
id int (10) unsigned not null
userid int (10) unsigned not null Maps to user.id
pluginid int (10) unsigned not null Maps to local_contrib_plugin.id
creator int(1) unsigned default 0 If true the user is the creator of the plugin
type varchar (125) unsigned default 'active' Enum active, inactive, primary
timecreated int (10) unsigned not null Timestamp when this user became a contribtor
Unqiue key userid + pluginid


local_contrib_collection
A collection that plugins can belong to
id int (10) unsigned not null
name varchar(255) The name of the collection
shortdescription smalltext A short description of the collection


local_contrib_collection_plugin
A collection that plugins can belong to
id int (10) unsigned not null
collectionid int (10) unsigned not null
pluginid int (10) unsigned not null
userid int (10) unsigned not null The id of the user who added this plugin to the collection
timeadded int (10) unsigned not null Timestamp when this plugin was added to the collection
Unqiue key collectionid + pluginid


local_contrib_software_versions
Contains the different Moodle versions that a plugin version can support
id int (10) unsigned not null
name varchar(255) Name of the software plus version
version decimal (12,5) not null Version number for sorting
timecreated int (10) unsigned not null Timestamp when this version was made available to support


local_contrib_supported_versions
Maps a supported Moodle version to a plugin
id int (10) unsigned not null
versionid int (10) unsigned not null Maps to local_contrib_version.id
softwareversionid int (10) unsigned not null Maps to local_contrib_software_version.id


local_contrib_review
Used to record plugin version reviews
id int (10) unsigned not null
userid int (10) unsigned not null The user who published the review, maps to user.id
versionid int (10) unsigned not null The version of the plugin reviewed, maps to local_contrib_version.id
softwareid int (10) unsigned not null The version of software used in this review, maps to local_contrib_software_version.id
generalreview mediumtext A general review about this plugin version
generalreviewformat int(2) unsigned default 0 not null
timereviewed int (10) unsigned not null The time the plugin version was reviewed


local_contrib_review_criteria
Contains the criteria a plugins versions should be reviewed on.
id int (10) unsigned not null
name varchar (255) The name of the review criteria
description mediumtext A description of the review criteria
descriptionformat int(2) unsigned default 0 not null
scaleid int (10) unsigned not null The scale to rate on, maps to scale.id


local_contrib_review_outcome
Contains the outcome and comments of a reviewed criteria
id int (10) unsigned not null
reviewid int (10) unsigned not null Maps to local_contrib_review.id
criteriaid int (10) unsigned not null Maps to local_contrib_review_criteria.id
review mediumtext The review of this criteria
reviewformat int(2) unsigned default 0 not null


local_contrib_awards
Contains the different awards that can be granted to a plugin and/or plugin version
id int (10) unsigned not null
name varchar (255) The name of the award
description mediumtext A description about this award
descriptionformat int(2) unsigned default 0 not null
timecreated int (10) unsigned not null Timestamp from when this award was created


local_contrib_plugin_awards
Tracks the awards a plugin, or plugin version have been awarded
id int (10) unsigned not null
awardid int (10) unsigned not null Maps to local_contrib_award.id
pluginid int (10) unsigned not null Maps to local_contrib_plugin.id
versionid int (10) unsigned default NULL Maps to local_contrib_version.id
timeawarded int (10) unsigned not null Timestamp from when this was awarded
userid int (10) unsigned not null The user who awarded this award

File areas

There are several file areas that will be used within this new system.

Please not this relies on changes to the core system in order to be possible, presently the file API doesn't support local plugins.

Type Contextid Component Filearea Itemid
Plugin badge Image [200x200] CONTEXT_SYSTEM local_contrib plugin_badge Plugin id
Plugin icon Image [16x16] CONTEXT_SYSTEM local_contrib plugin_icon Plugin id
Plugin screenshots Images 0..n CONTEXT_SYSTEM local_contrib plugin_screenshots Plugin version id
Review images Images 0..n CONTEXT_SYSTEM local_contrib review_images Review id
Award image Image [200x200] CONTEXT_SYSTEM local_contrib award_image Award id
Award icon Image [16x16] CONTEXT_SYSTEM local_contrib award_icon Award id
Collection icon Image [64x64] CONTEXT_SYSTEM local_contrib collection_icon Collection id

Capabilities

The following are the capabilities that this new local plugin will introduce and utilise.

Capability Type Description
local/contrib:view read View the system
local/contrib:viewunapproved read View unapproved plugins
local/contrib:createplugins write Create new plugins within the system
local/contrib:editownplugins write Edit plugins the user previously created
local/contrib:editanyplugin write Edit any plugins within the system
local/contrib:deleteownplugin write Delete a plugin you created
local/contrib:deleteanyplugin write Delete a plugin
local/contrib:deleteownpluginversion write Delete a plugin version you created
local/contrib:deleteanypluginversion write Delete a plugin version
local/contrib:approveplugin write Approve a plugin
local/contrib:approvepluginversion write Approve a plugin version
local/contrib:autoapproveplugins write New plugins created by this user are automatically approved
local/contrib:autoapprovepluginversions write New plugin versions created by this user are automatically approved
local/contrib:publishreviews write Create and publish a review
local/contrib:editownreview write Edit a review you created
local/contrib:editanyreview write Edit a review written by anyone
local/contrib:comment write Add a comment on a plugin, plugin version, or review
local/contrib:rate write Rate a plugin or plugin version
local/contrib:editowntags write A user can edit the tags associated with a plugin they manage.
local/contrib:editanytags write A user can edit the tags associated with any plugin.
local/contrib:managesupportableversions write Manage supportable

Ratings

There are three rateable areas within this new system:

Plugin versions
Any user with the rate capability will be able to rate a plug-in version.
Review - general
Reviewers will be able to give a plugin version a rating for the general section of the review.
Review - criteria
Reviewers will be able to give each criteria reviewed for a plugin version its own rating.

The plugin versions ratings will be averaged to form an average rating for the plugin version.

The two review ratings will be averaged to form an average rating for the review as a whole.

Finally people have asked for plugins to be rateable, however this will not be so. Instead a plugins rating will come from it most recent version.

Comments

The are several areas within this new system where users with the comment capability will be able to comment, they are as follows:

Plugin
Users will be able to comment on a plugins home page
Plugin version
Users will be able to comment on specific plugin version.
Plugin faqs
Users will be able to comment on the plugins FAQ page.
Plugin documentation
Users will be able to comment on the plugins Docs page.
Reviews
Users will be able to comment on specific reviews.

Of course the core comments API will be used to manage all comment areas.

Tags

There is only one area within this new system that users will be able to tag and that is plugins.

Any user with either the editowntags or editanytags capabality will be able to manage the tags associated with a plugin.

Of course like ratings and comments the core tag API will be used for this.

Settings

The following are the settings that I anticipate the new system will have.

Setting Purpose
courseidforgroups Set to a courseid and user group pictures will be used from that course for users throughout the new system.
publishtorss If enabled then RSS feeds will be generated for a matrix of things including category listings, and plugin collections.

RSS feeds

If you enable RSS feeds for this new system the following feed will be published:

  • New plugins This RSS feed will contain just the new plugins within the system.
  • Recent updates This RSS feed will contain new plugins, new versions, and updated versions.
  • List of categories This RSS feed will contain a summary of each category in the system.
  • Category plugins list This RSS feed will contain the more recently updated plugins in the category.
  • Collection list This RSS feed will contain the most recently updated plugins in the collection.

Screen descriptions and mockups

Navigation screens

The following are the navigation screens for the system, these are screens that will be readily accessible to those who are not logged in or have little or no permissions other than view.

The frontpage of the contrib plugin
Viewing a plugin
Viewing a version of a plugin


  • Reading a review
  • Downloading a version of a plugin

Plugin administration screens

  • Creating a plugin
  • Creating a plugin version
  • Adding plugin information

System administration screens

  • General settings
  • Managing categories
  • Managing Moodle versions
  • Managing awards
  • Managing supportable versions

Reports

  • Plugin report
  • Plugin approval report
  • Plugin version approval report
  • Recent activity
  • Requiring attention
  • Review report

Required core changes

One of the goals for this new system was to get it using the core Moodle systems where possible and practical. Presently this proposal relies of several changes been made to core systems in order to get them into a usable state by this plugin. While I understand it is not desirable to have to make core changes I do think that in all cases making these changes would be of general benefit anyway. In all cases I am happy to be responsible to for making the required changes.

Changes to the ratings API

Presently the ratings system is VERY limited. When a rating is stored is associated by a context and an item id. The problem with this of course is that it immediatly limits ratings to be applied to only one structure per context. In the case of this new system which is currently planned as a local plugin it is running under the system context which immediatly makes the rating system unusable. As part of the development of this new system I would like to purpose the following changes at the same time:

  1. Add two new columns to the rating table in the database that are similar to fields found in the file table
    • component (string 255) This is the frankenstyle name of the component the rating relates to e.g. mod_forum, local_contrib
    • ratingarea (string 255) This is a unique name that the utilisine component can use to allow several areas within a component to be rated e.g. for the forum you may have post, and discussion.
  2. Extend the API to require the two new fields but provide backwards compatability to working without them.
  3. Review all locations using the rating system presently and refactor to make use of these two new fields.


More information