Wiki

User Tools

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

Site Tools

Trace:
mantisbt:plugins_feedback

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:plugins_feedback [2007/11/07 10:13] – jreesemantisbt: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 10: Line 14:
 <vboctor_> 1. A lot of companies replace the Mantis Logo in the header  <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? 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 <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 +page, event [even? -jr] before the logo etc.  This is important to allow 
-Mantis into websites and CMS.+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 <vboctor_> 3. In case of integrating Mantis in websites / CMS we want to
-avoid generating our own HEAD/BODY etc, right?+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?
Line 22: Line 39:
  
 * To be answered shortly. * To be answered shortly.
 +
  
mantisbt/plugins_feedback.1194448396.txt.gz · Last modified: (external edit)
CC Attribution-Noncommercial-Share Alike 4.0 International Driven by DokuWiki