User Tools

  • Logged in as: anonymous (anonymous)
  • Log Out

Site Tools


mantisbt:addson_requirements

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
mantisbt:addson_requirements [2007/09/06 10:40] DGtlRiftmantisbt:addson_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1
Line 205: Line 205:
   * Detail the parameters sent to each of the events.   * Detail the parameters sent to each of the events.
   * How are the plug-ins going to be distributed.   * How are the plug-ins going to be distributed.
 +
 +
 +
 +
 +
 +
  
  
Line 217: Line 223:
       * 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       * 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       * 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 ==== ==== First implementation ====
mantisbt/addson_requirements.1189089623.txt.gz · Last modified: 2008/10/29 04:31 (external edit)

Driven by DokuWiki