Differences

This shows you the differences between two versions of the page.

--- mantisbt:addson_requirements [2007/09/06 02:03] – Much more detailed requirements vboctor
+++ mantisbt:addson_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Mantis Add-Ons Requirements ======
+====== Mantis Plug-ins Requirements ======
   * **Author:** Victor Boctor
@@ Line 6: / Line 6: @@
 ===== Introduction =====
-Mantis currently supports some extensibility features like custom fields, custom functions, custom constants, and custom strings.  These has proven to be useful features that allowed Mantis users to tweak their own installations without having to change Mantis code base and hence making the upgrade experience much easier.  The aim of Mantis Add-ons support is to take this to the next level and enable users to do more powerful additions to Mantis and be able to make these publicly available to other users.  Some of the add-ons will be distributed with Mantis and others will be available through Mantis website / bugtracker.
+Mantis currently supports some extensibility features like custom fields, custom functions, custom constants, and custom strings.  These has proven to be useful features that allowed Mantis users to tweak their own installations without having to change Mantis code base and hence making the upgrade experience much easier.  The aim of Mantis Plug-ins support is to take this to the next level and enable users to do more powerful additions to Mantis and be able to make these publicly available to other users.  Some of the Plug-ins will be distributed with Mantis and others will be available through Mantis website / bugtracker.
 ===== Types of Plug-in =====
@@ Line 19: / Line 19: @@
   * Ability to detect all plug-ins in the Mantis directory structure.
-  * From the manage plug-ins page, allow administrators (configurable threshold) to install / un-install an add-on.
+  * From the manage plug-ins page, allow administrators (configurable threshold) to install / un-install a plug-in.
-  * Keep track of the installed add-ons and make sure to provide them with the needed integration points.
+  * Keep track of the installed plug-ins and make sure to provide them with the needed integration points.
   * Extend the database scheme upgrade script to support modules.
   * Detailed documentation about how to implement Mantis plug-ins.
@@ Line 47: / Line 47: @@
   lang/
   modules/
-    css/
+    #modulename#/
-      *.css
+      css/
-    images/
+        *.css
-      logo.jpg (some plugins may have logos, file name is configurable)
+      images/
-    core/
+        logo.jpg (some plugins may have logos, file name is configurable)
-      functions_inc.php
+      core/
-    javascript/
+      javascript/
-      *.js
+        *.js
-    doc/
+      doc/
-      readme.html
+        readme.html
-    lang/
+      lang/
-      strings_english.txt
+        strings_english.txt
-    pages/
+      pages/
-      (new pages - included from module_page.php based on module name and action)
+        (new pages - included from module_page.php based on module name and action)
-    #modulename#_constants_inc.php
+      #modulename#_constants_inc.php
-    #modulename#_defaults_inc.php
+      #modulename#_defaults_inc.php
-    #modulename#_inc.php
+      #modulename#_inc.php
 </code>
@@ Line 88: / Line 88: @@
 The following pages will allow management of plug-ins and all their related details:
-- manage_modules_page.php: This pages lists all the available modules, their minimum requirements, dependencies, etc.  It also allows administrators to the install / uninstall the available plugins.
+  * manage_modules_page.php: This pages lists all the available modules, their minimum requirements, dependencies, etc.  It also allows administrators to the install / uninstall the available plugins.
-- manage_modules_add.php: The action page for installing modules.
+  * manage_modules_add.php: The action page for installing modules.
-- manage_modules_remove.php: The action page for uninstalling modules.
+  * manage_modules_remove.php: The action page for uninstalling modules.
-- module_page.php: This page takes in the plugin name, action as mandatory parameters.  Depending on the "action" there can be other parameters.  For example, module_page.php?module=last_visited&action=readme will view the readme of the plugin.  The modules folder will have a .htaccess file that blocks direct access to files in the modules tree.
+  * module_page.php: This page takes in the plugin name, action as mandatory parameters.  Depending on the "action" there can be other parameters.  For example, module_page.php?module=last_visited&action=readme will view the readme of the plugin.  The modules folder will have a .htaccess file that blocks direct access to files in the modules tree.
 ===== Plug-ins APIs =====
@@ Line 97: / Line 97: @@
 This is the standard APIs that are used in managing modules and allowing modules to interact with some standard Mantis functionality.  In addition to these APIs, the plug-in implementation can use the rest of the APIs like strings_api, etc.
-- module_event - trigger an event with the appropriate parameters.
+  * module_event - trigger an event with the appropriate parameters.
-- module_event_is_subscribed() - check before doing extra work for the event.
+  * module_event_is_subscribed() - check before doing extra work for the event.
-- module_include_all()
+  * module_include_all()
-- module_include_lang()
+  * module_include_lang()
-- module_include_css()
+  * module_include_css()
-- module_include_javascript()
+  * module_include_javascript()
-- module_get_info( $p_module_name );
+  * module_get_info( $p_module_name );
-- module_install( $p_module_name );
+  * module_install( $p_module_name );
-- module_get_dependencies( $p_module_name )
+  * module_get_dependencies( $p_module_name )
-- module_can_install( $p_module_name )
+  * module_can_install( $p_module_name )
-- module_get_depedents( $p_module )
+  * module_get_depedents( $p_module )
-- module_can_uninstall( $p_module )
+  * module_can_uninstall( $p_module )
 ===== Events =====
@@ Line 200: / Line 200: @@
     * max access level
     * for each project?
+===== To be Spec'd =====
+  * Detail the parameters sent to each of the events.
+  * How are the plug-ins going to be distributed.
 ===== Feedback =====
 This is still in progress, but you are free to contribute ideas.
+   * (DGtlRift) I would say that in "Information about a plugin" there should also be:
+      * plugin version - could be used by a plugin manager to query if there is an updated plugin available from the plugin's website.
+      * minimum mantis compatibility version - verify that this plugin will actually work with this version of mantis.  I could picture as time goes on the new events, apis, etc could be introduced to mantis, which newer plugins would start using, but would be incompatible with legacy versions of mantis.
+   * (DGtlRift) I would also suggest that the "Information about a plugin" should be either in well known variables within #modulename#_constants_inc.php and if there are missing a mandatory constant, do not "load/register" the plugin.
+      * I'm also thinking that it may be easier to use a hash table to store the constants in #modulename#_constants_inc.php plugins["#modulename#"]->ver etc
+      * Perhaps XML would be better for having this info
+   * (deboutv) In my plugin manager, I have chosen to provide Mantis plugin in pkg format. This file is the result of a zip and a serialize of an array => gzcompress( serialize( array ), 9 ); The array contains the following fields:
+<code=PHP>
+$t_pkg['plugin'] = 'string'; // The plugin name
+$t_pkg['check'] = array(); // The array of requirements to be checked, eg: array( 'mantis' => array( 'min' => '1.0.5' ),
+                           //    'php' => array( 'min' => '4.0.0' ), 'plugins' => array( 'pluginmanager' => array( 'min' => '0.1.2' ) ) );
+$t_pkg['files'] = array(); // The files of the plugin (base64 encoded), eg: array( 'plugins/bbcode/core.php' => base64_string, ... )
+$t_pkg['remove'] = array(); // The list of files to remove.
+$t_pkg['info'] = array(); // The plugin info (version, name, id...)
+$t_pkg['info_pm'] = array(); // The plugin manager info
+</code>
+   * (deboutv) Hacking Mantis with a plugin. We need to think about the security of the Mantis application and its data. Allowing plugins is dangerous because of the content of the plugin (it could pretend to be a BBCode interpreter but in reality it could be a BBCode interpreter and a spy). With a plugin (ie: code of third parties), you can read/write the SQL database, grant priviledges to the users...
+   * (DGtlRift) There should also be a description of how plugins themselves should generate events.  This would allow additional optional functionality //between// plugins.  EI: plugin ''doesSomething'' generates event ''pe_doesSomething_special'' so that plugin ''somethingElse'' which doesn't require plugin ''doesSomething'', can optionally do something additional if that plugin is installed.
+   * (DGtlRift) Re: Distribution.
+      * The most simple way is to just have a list of tar.gz compressed archives of each plugin.  The admin would have to download them and uncompress them into the plugins directory. After that, they would be available for activation from with Admin for Managing plugins.
+      * The next option would be to offer the ability to install via the admin interface, where Mantis would check against a web list of available plugins and download (to the server) and install the plugin (requiring Mantis to have write privileges) to the plugins directory.  There are some serious security issues involved with this method, but it gives one unified interface for the admin.
+      * Another option is to have all the plgins in RPM form - which would automate installation for the sysadmin.
+   * (DGtlRift) Should the plugins be globally "turned on" by the Mantis Admin or should each project have the ability to enable/disable installed plugins?
 ==== First implementation ====