| Next revision | Previous revision |
| mantisbt:plugins_feedback [2007/11/07 09:19] – created jreese | mantisbt:plugins_feedback [2014/02/27 03:05] (current) – Bascy |
|---|
| | |
| ====== 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 ===== |
| <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. |
| | |
| |
