User Tools

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

Site Tools


mantisbt:plugins_feedback

Differences

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

Link to this comparison view

Next revision
Previous revision
mantisbt:plugins_feedback [2007/11/07 09:19]
jreese created
mantisbt:plugins_feedback [2014/02/27 03:05] (current)
Bascy
Line 1: Line 1:
 +
 ====== Plugin Feedback and Questions ====== ====== Plugin Feedback and Questions ======
 +
 +===== General Suggestions =====
 +
 +After reading the documentation,​ and the code, I'd suggest that plugins SHOULD actually be utilized for user replacable functionality. ​ A prime example for this would be a login event. ​ Authentication plugins could then react to a login event, and return if a user is authorized for something. ​ This would also potentially allow for multiple authentication mechanisms, such as a Mantis specific administrator,​ but also single signon authentication with, say, an ldap source.
  
 ===== IRC Chats ===== ===== IRC Chats =====
Line 6: Line 11:
 <​code>​ <​code>​
 <​vboctor_>​ nuclear_eclipse,​ some question relating to events: <​vboctor_>​ nuclear_eclipse,​ some question relating to events:
-<​vboctor_>​ 1. A lot of companies replace the Mantis Logo in the header with their own branding, are we going to support this via plugins? + 
-<​vboctor_>​ 2. I think that page header should be the first thing in the page, event before the logo etc.  This is important to allow integrating Mantis into websites and CMS. +<​vboctor_>​ 1. A lot of companies replace the Mantis Logo in the header ​ 
-<​vboctor_>​ 3. In case of integrating Mantis in websites / CMS we want to avoid generating our own HEAD/BODY etc, right?+with their own branding, are we going to support this via plugins? 
 +<​jreese>​ As it is right now, the Mantis Logo is hardcoded to display,  
 +unless the user has set $g_top_include_page in their configuration. ​  
 +As plugins are meant to *add* features and content, rather than modify 
 +the existing functionality,​ I don't feel this applies well in its  
 +current form. 
 + 
 +<​vboctor_>​ 2. I think that page header should be the first thing in the 
 +page, event [even? -jr] before the logo etc.  This is important to allow 
 +integrating Mantis into websites and CMS. 
 +<​jrees>​ Well, if we keep it as it currently is, the user can simply set 
 +up $g_top_include_page and $g_bottom_include_page,​ to handle integration 
 +rather than trying to make this happen in plugins. ​  
 + 
 +<​vboctor_>​ 3. In case of integrating Mantis in websites / CMS we want to 
 +avoid generating our own HEAD/BODY etc, right? ​  
 +<​jreese>​ This depends, there are parts of Mantis that need to output  
 +resource links in the <​head>​ tag, like CSS and Javascript, but to have 
 +Mantis integrated into other applications (not vice versa a la Dokuwiki) 
 +we could have the <​head>​ section only output if $g_top_include_page isn'​t 
 +set. 
 <​vboctor_>​ 4. What about the string display chaining event? <​vboctor_>​ 4. What about the string display chaining event?
 </​code>​ </​code>​
  
 * To be answered shortly. * To be answered shortly.
 +
  
mantisbt/plugins_feedback.1194445188.txt.gz · Last modified: 2008/10/29 04:31 (external edit)