0004227: Roadmap 1.0 - Templates

Notes
(0007619) jotarp (reporter) 2004-09-16 03:51	template_example. I like MantisBT. It is planned to use it in my company (public organization, 40 users), but I need some customization in the look'n'feel. I think that to use a template engine, smarty or other, is an error ( please, read: http://www.sitepoint.com/article/beyond-template-engine [^] ). I have uploaded an example of how it would be possible to be done (with the just-php-template-engine from that article). Test it and comment. Thank you.

(0008270) philippg (reporter) 2004-11-07 15:57	In case you have not started on it yet, please do not use smarty. The prior poster is - in his article - correct in saying, that smartys approach is good. However, having used Smarty before, I'd like to say that Smarty - is too big (especially for the job) - has too much funcionality that makes it become "PHP light-edition" - has far too many inconsistencies in terms of style and usage - is not very efficient Apart from that, I somehow refuse to use a template engine, which talks about itself having a "Kernel".

(0008284) fman (reporter) 2004-11-08 09:53	I'm a bit scared about the effort involving a major re-write an testing of Mantis. I think that to get rid of redundant code , it's enough to start developing php functions to manage in a simple way the User Interface, instead of using the pattern: CTRL-C , CTRL-V . Anyway you have done a great work with this product !!!.

(0008597) Thox (reporter) 2004-12-13 09:24	I'd also like to recommend not using Smarty. It is far too bloated and is mostly wasted. More information very similar to what jotarp posted can be found here: http://www.massassi.com/php/articles/template_engines/ [^]

(0008692) bloodrath (reporter) 2004-12-17 07:45	i've personnaly rewrite some mantis page with smarty template engine. Why will you say ? because i need a cleaner view of php code. Sorry but i could'nt be agree with this (extract from the link posted) "In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code". mixed php+html+css+javascript cause a web page becoming ugly to maintain, this is the reason why i love smarty (and other template engine) : keeping html page cleaner. I think the reason why i prefer smarty is the ability to create plugin. So to close this note i say Wonderful !

(0008694) Thox (reporter) 2004-12-17 07:58	A smarty plugin is basically just a function for doing something with a templates. All of the plugins could be reproduced with Brian Lozier's template code by plain old PHP functions. Using smarty adds an extra layer of slow code. It's so bloated that there is a Smarty Light sourceforge project. I'd much prefer to avoid using any template syntax.

(0008736) bloodrath (reporter) 2004-12-20 04:01	excuse me but as smarty is basically php, i think it's obvious that "plain old PHP functions" could reproduce smarty plugin process. sure it was slower than coding function directly but not slower than any other wrapper please have a look http://www.phpinsider.com/smarty-forum/viewtopic.php?t=102&postdays=0&postorder=asc&start=0 [^] (brian himself taking part of the thread).

(0008993) DamienMcKenna (reporter) 2005-01-12 23:57	I would strongly suggest a cleanup of the codebase as a step towards this to separate presentation from business logic (similar to PHP-vs-HTML but a different view point). Right now to change e.g. the top menu you have to delve deep into the PHP code, rather than editing "templates/top_menu.php" or some-such.

(0009026) jferraz (reporter) 2005-01-14 22:06	Using templates is a very important step for Mantis, but I don't know if smarty is the right solution (given the expectations). Have you ever considered using XSL Transformations? XSLT is much more powerfull than Smarty, and much more "solid", although it will require a much bigger rewrite of the user interface (well... we will REMOVE the user interface and let everything to be produced by a XSL file). If you don't know XSL yet, an example: The bug view page will be reduced to something like this (parenthesis are disguised xml tags): (bug-view-page mode="simple") (bug bugid="4227") (summary)Roadmap 1.0 - Templates(/summary) (description)...(/description) ... (relationships) (relationship role="related" bugid="798") (status)closed(/status) (resolution)duplicate(/resolution) ... (/relationship) ... (/relationships) ... (/bug) (/bug-view-page) Also, this solution couples much better with i18n, we need just a entity file for each language that will be linked against the XSL stylesheet, everything else will be handled by the XSL processor. XSLT can also be used to produce output in other formats like plain text from the same input data, very useful to produce e-mail messages.

(0009027) Thox (reporter) 2005-01-15 03:20	I wasn't aware that XSLT was available in all installations of PHP. I know that it's in PHP 5 but I think it's an optional (and often left out) extension of previous versions. I don't see any reason to add new languages or syntaxes to Mantis. It's written in PHP so what's wrong with using PHP for the templates? There's no need for any middle-language to interpret templates from.

(0009030) jferraz (reporter) 2005-01-15 10:49	PHP has (at least some) support for DOM and XSLT since 4.0, but the currently supported implementation is since 4.1. Yes, it is an optional extension just like mysql is. PHP5 implementation is much better, indeed. Also, take into account that most users already use a web browser cappable of xslt processing (IE 6, Opera 7, Mozilla, Firefox and other gecko browsers), we will have to process on server only a few requests. Smarty is always processed on the server side. Of course, for a solution like this we'll have to raise Mantis requirements a bit, but see bug 0005102.

(0009031) gtomlin (reporter) 2005-01-15 11:13	Here's a little article that shows how easily XSLT separates logic and presentation: http://www.quepublishing.com/articles/article.asp?p=27861 [^]

(0010880) vwegert (developer) 2005-07-19 16:25	I like the XSLT idea - we could easily generate a bug view page, an email notification or even some kind of pager text from the same XML output using different translations. I've had the opportunity to use XSLT (see http://xorph.sourceforge.net [^]), and in my opinion it's not that complex - can't say anything about it's speed though.

(0011422) fman (reporter) 2005-09-22 02:20	Template Wars: I would to understand the big advantages adn difference between developing the presentation layer /user interface logic using: 1. XSLT 2. Smarty 3. PHP functions. I dare to say no real difference at all ( I'm saying nothing about performance), regarding code cleaness. All you have done (the template engine force you to do this) is take your code and organize it better trying to draw a clear separation between business logic (bl) and presentation logic (pl). Now you have a nice PHP page (call it BL.PHP) that is reponsible for getting the data, prepare it and send to the presentation logic, call it PL.PHP, PL.XSTL or PL.tpl (smarty). But If I'm not wrong if your user want to add a NEW info at user interface level, and BL.PHP has not getting it, then the user NEED TO modifiy: a. BL.PHP b. PL.(what you want). And what if you want to change the position on screen of one existen value ? You need to modify PL.XSTL, or PL.tpl, or PL.PHP, then I see no difference. The secret IMHO it's not using template engine, but developing not mixing presentation logic and bussiness logic in the same page, then the anwser if better code organization and modularization. The effort need to convert an application like Mantis to use a template engine will be enormous, and you will need a lot of regression testing. OK, this statement is valid if you reorganize the code using PHP. The difference (not to say no to new things) is that you need to gain confidence with new languages (XSTL, smarty) instead of usign you PHP knowledge. I hope I've made my point clear Regards Francisco

(0012509) vboctor (administrator) 2006-04-16 09:44	<vboctor> thraxisp, relating to templates. <vboctor> the obvious options are: <vboctor> - Smarty <vboctor> - PHP templates, i.e. use PHP as the template engine and use decipline to make sure that in the template code we are not doing coding that is not relating to presentation. <vboctor> for both options we need to restructure our code. <vboctor> for example, smarty uses the concepts of functions and modifiers. These are used from templates <vboctor> For example, a bug_id modifier formats 23 as 000023 <vboctor> I believe if we use PHP templates, we can easliy port to any template engine later on if we find the need. <vboctor> we should implement a template class in core that we use as our mini template engine. <vboctor> takes an associate array with all the variables + a template file name. <thraxisp> 'evening, vb123. I had originally thought of writng the templates in php with calls to format any of the data required. <thraxisp> Smarty seemes to have dome a lot of that already, but interfacing to it does require a lot of rework. <vb123> I am not sure what is the best option. <vb123> smarty vs php custom template class <vb123> smarty introduced a dependency on another package + requires setting up write access to a templates_c folder. <vb123> which complicates the installation process. <vb123> I'm not sure if Smarty compiled templates will be faster than php custom templates. <thraxisp> The only way to pass information to it is via variables, or objects. Our current code uses a lot of function calls. I've prototypeed some of this using objects. <vb123> it = smarty? <thraxisp> Yes, Installation is harder, particularly if you don't have shell access. <thraxisp> yes. it = smarty <vb123> usually template engines allows the script to register some variables that are accessible from the templates. <vb123> The templates can also use (in case of Smarty for example) modifiers which are functions taking one parameter and functions. <vb123> For Mantis, we need to separate the calculation of data from the formatting. <vb123> For example, print_blah_options() typically puts the combo-box options and calculates them. <vb123> we need to separate the calculation of the entries, from the code that formats them for a combobox. <vb123> I think we should start by refactoring the code to allow for the use of templates. <vb123> during this period we should php templates. <vb123> if we find a reason, we can easily port our templates to Smarty. <thraxisp> That's fairly straightforward. I was looking at things like the config_get() calls. <vb123> I think we should create a themes folder, and classic folder under it. This folder should have the same UI as now but using templates. <vb123> templates should be called xxxx.tpl.php <vb123> we should use a templates class to make sure that the templates only access variables registered with them, rather than access to global variables. <thraxisp> I was also thinking of using the templates to implement simple and advanced views. <vb123> we can have the list of supported views as a configuration variable. For example: <thraxisp> The problem with the assignment is that there are possibly hundreds to assign given the amount of configuration we do. <vb123> simple, moderate, advanced. <vb123> Then we open issue_view_<mode> <vb123> from the templates. <vb123> This shows how we can allow users to use configuration to make mantis use extra templates. <vb123> I also think we should use fallback themes. <vb123> For example, use theme "Victor" and if template is not found, use theme "classic". <thraxisp> I was thinking that we would have view.php open templates/x/view.advanced.tpl.php for advanced. <thraxisp> I agree on fallback. <vb123> This way I can define a new theme that only overrides a couple of templates or add a couple of new ones. <vb123> yes, that's what I meant relating to view advanced stuff. <vb123> we should also support project specific themes <vb123> project x use theme a, project y use them b, a and b may use classic as their fallback theme. <thraxisp> Do we want to make it simpler to hide a field? I can't see someone copying templates and editing for a single field. <vb123> this requires some thought, since doing so in the templates will also compicate them, since the hidding of a field may affect the page layout. <vb123> initially creating an overriding theme shouldn't be too hard. <vb123> I also don't think that we should implement themes/templates on a branch. <vb123> if we use the approach we are discussing here, then it can be done as a gradual thing. <vb123> the steps will be: <vb123> 1. build the infrastructure. <vb123> 2. Change one page at a time to support templates. <vb123> The main pages are: <vb123> 1. view/update/report - advanced/simple <vb123> 2. view issues (e.g. ability to define the columns) <vb123> although this may be defined via configuration. <vb123> rather than templates <vb123> the columns is not really part of formatting and hence it should be part of the configs. <thraxisp> Handling visibility (and editability) of fields in the template would be useful in handling updates and reporting from the same view. <vb123> the templates should be as smart as needed, but no more. <vb123> ideally they should be stupid, but in some scenarios we will need some if structures in there. The decisions should ideally all be made by the calling script. <thraxisp> The current bug_change_status_page is a smarter template. It tries to show fields that need to be changed with the change in status. I was thinking that it should really look like the update page with the changeable fields enabled. <thraxisp> What's the best way to document the plan? <vb123> It is ok that the template does some checks and accordingly changes it's output. <vb123> However, the template should look as follows: <vb123> if ( a ) { <vb123> } <vb123> rather than <vb123> if ( a && b \|\| c ) { <vb123> } <vb123> where a, b, c are either variables passed to the template or functions that are called by the template. <vb123> e.g. can_edit_blah() <thraxisp> That's what I was thinking. Like: <thraxisp> if ( visible['field'] ) { <thraxisp> echo content; <thraxisp> } <vb123> the template should be able to call functions that are defined in the core APIs or in the script that called it. <vb123> yep, the case you mentioned is where the output is controlled by the variables registered with the template when running it. <vb123> we should also support the case where a template internally refers to other templates. <vb123> e.g. template for view issue page may use header, menu, then the bulk of the view, then footer. <vb123> the main template should be able to pass data to the templates it is calling internally. <thraxisp> The other big problem with Smarty is the language handling. I've seen plugins for that. <vb123> yep, we need to provide an easy way to handle this. Perhaps we can consider using the gettext vb123> I'll post the script of our discussion in the templates issue in the bugtracker.

(0012741) fman (reporter) 2006-04-27 10:38	Regarding : "The other big problem with Smarty is the language handling. I've seen plugins for that. yep, we need to provide an easy way to handle this. Perhaps we can consider using the gettext" I'm part of the development team of Testlink, and we are using Smarty (also dtoproject is using Smarty), and to do language handling I have took YOUR lang_get function, simplify it and register it as new function on Smarty. Everything is working OK. Obviously using gettext is on option, but anyway you need a smarty plugin to handle it, and have one problem for mantis (IMHO) the strings.txt files can not be used. Just my 5 cents, and my compliments for you great product !!

(0012747) thraxisp (manager) 2006-04-27 22:14 edited on: 2006-04-29 13:13	I've started implementing this feature using Smarty as the template manager, and smartyML for localization. This add-on can be found on the smarty wiki. I'm looking at the following directory structure: \|- mantis + core \| +- smarty (smarty engine and support) + languages \| +- eng \| +- etc.... + themes \| +- theme1 \| +- header.tpl \| +- footer.tpl \| +- page.tpl \| +- theme2 \| +- page.tpl + themes_c (compiled templates) \| +- theme1 \| +- theme2 Parameters for the pages are passed to the page template through arrays or objects. I've started with the view pages. In this case, an array ($show) is used to pass information that may be used to control the display. Another array ($display) is used to pass configuration information from the config system to the template. Bug information is passed through an object that already existed in bug_api.php. This development is being done on a branch labelled EXP_TEMPLATE, in CVS so that progress can be reviewed.

(0012748) vboctor (administrator) 2006-04-27 22:56 edited on: 2006-04-27 23:23	I have some questions relating to the template fallback that we discussed before. This means that if template xyz is not found in the current theme, then we retrieve it from a fallback or default theme. This way users can create themes that only override the the templates they need to override. 1. Once the templates are resolved, do the compiled version get added to the themes_c/my_current_theme independent from where the template was fetched? This way in future references we just use the compiled version from the current theme and hence no need for further resolutions. 2. If the user overrides header.tpl, will this be picked up from view_issue.tpl that is sourced from the fallback theme? I assume that in the directory structure that you are proposing the tpl files should be indented one level to be within the theme1 and theme2 folders. My preference relating to localisation are: 1. Implement a smarty plug-in that uses our current language files without changes. Consider using fman's work (see previous note). 2. In the future, consider replacing this plug-in and our language files with gettext. This will allow us to re-use the standard infrastructure that are used to manage and update such standard format. An example tool is http://www.poedit.org/ [^] , but I'm sure there are others.

(0012755) thraxisp (manager) 2006-04-29 13:21	1. Yes,the compiled versions get added to the themes_c/ directory corresponding to the theme directory the template came from. They are also stored separately based on language. This does imply that the theme is compiled once, but it does get resolved each time the page is loaded. 2. Yes. Smarty uses a search order to find templates. I've set it up to use the user selected theme first, the, 'classic' This could be extended to do user/project/classic. All templates, including 'included' ones follow this path. I am currently using smartyML for languages. The files are almost identical to the current ones. I'll modify it to use the current ones for simplicity. The gettext based engines use a similar process as they define text to be translated as a block and then operate on the strings as part of the compile.

(0013103) DGtlRift (developer) 2006-07-17 10:26	Is there a change set that can be used with this for testing or is it looking like it will be some time before a prototype can be used?

(0013184) BenBE (reporter) 2006-08-02 20:53	Regarding this issue I'd like to throw The Templating System of phpBB into the round, or better the eXtreme Styles MOD as both provide a quite powerful, but easy-to-use interface to create templates with probably only little stuff to change with mantisbt internals. The drawback of this solution would be, that the templater would need to know all language string at one or them being assigned at runtime by hand as needed for the template. But with the templater looking stuff up itself should do fine in most cases. Also I think XSLT can be a nice solution it often lacks browser support and webmaster's understanding.

(0013582) djnz (reporter) 2006-10-04 19:27	I have spent a little time on a proof of concept for using Smarty with Mantis, and have reached a point where the main layout of the site is now generated with a single Smarty template rather than calls to html_blah(). I have attached an archive of the files http://www.mantisbugtracker.com/bugs/file_download.php?file_id=1139&type=bug [^] to be added to achieve this; instructions follow for trying it out. This proof of concept was developed against v.1.0.5, but should work with other versions. Unpack the archive and copy the 'tpl' directory to core (ie core/tpl). Make sure that the web server can write to the directory core/tpl/templates_c. In core.php, comment out the line require_once( $t_core_path.'html_api.php' ); Add the line require_once( $t_core_path.'tpl' .DIRECTORY_SEPARATOR. 'template_api.php' ); Try it out - you shouldn't notice any difference apart from the Smarty logo in the bottom right. You can revert back by simply reversing the changes in core.php and deleting core/tpl. This is only a proof of concept, so please don't expect it to do anything exciting, but if you look at the code and the page.tpl template you should be able to see the potential.

(0015460) dino (reporter) 2007-08-20 02:25	A lot of discussion around templates...and a great improvement for the next release...By the way, when is this likely to be and will templates or the capability to modify forms i.e remove/update fields be part of the next release?

(0017063) lbertin (reporter) 2008-02-16 14:27	Hello there, Any news on templates ? It seems a long time since any bug related was updated. Thanks

(0021299) milliams (reporter) 2009-03-30 13:39	I've looked in the latest Git revision and I can find no mention of a template system or Smarty at all, not even in a branch. Did the work being carried out by thraxisp disappear? I thought this was a "Roadmap 1.0" issue?

(0021352) scorpe51 (reporter) 2009-04-01 07:34	Hey there! Haven't thought about something else than Smarty yet? Seems to me that this kind of template engine is superfluous nowadays. I mean, I don't have anything against this template engine particularly, but I kinda notice now that people are not using complex template engines. For example, using MVC framework such as Symfony or Zend Framework will demonstrate that you could have efficient templates mainly written in (x)html but using small portions of PHP code, which isn't too hard to learn and implement for designers! See Zend_View library if you're not convinced, but seems to me that it's quite an efficient way to implement templates. Just a few thoughts to help setting up the template system. Mainly I've heard people complaining a bit about the global design of mantisbt, compared to Flyspray for example. In my opinion, once you get used to it, this tracker is quite effective, and have a great community (and frequent updates, keep the good job up!). It just misses optional choice for a design. Thanks! Scorpe51

(0021374) milliams (reporter) 2009-04-02 18:53	Just an update for anyone who's listening in: I've started work on this. I began using Smarty but given the design of Mantis it's neater to implement it using pure PHP. If anyone wants to try it out, you can find it in the 'phpt' branch of my mantisforge fork at http://git.mantisforge.org/w/mantisbt/milliams.git?a=shortlog;h=refs/heads/phpt [^] Since it's a gradual integration process, it should be possible to have a completely working version at all times so feel free to try it out. Note that it is possible that once the pure PHP template system is complete it will pave the way for a Smarty/whatever based implementation but TBH if pure PHP works, then there's no need to change it.

(0023776) klkl (reporter) 2009-11-20 11:32 edited on: 2010-01-12 10:47	If you're going to add templating engine, please consider PHPTAL: http://phptal.org [^] or at least don't tie Mantis to any particular template engine. Smarty is definitely waste of time. However PHPTAL guarantees XHTML well-formedness and protects against XSS, which is a major advantage over "find'n'replace" engines. I've noticed e-mail-related bugs are marked as dependent on it. Please don't mix templates for e-mails with templates for HTML. e-mail and HTML need different, incompatible escaping, which 90% of the time seems unimportant... until you get entities messing up your e-mails or XSS exploits in HTML.

(0024127) blueberry (reporter) 2010-01-11 08:25	Just want to "vote" for this issue. This should have a high priority. The lack of a nice set of templates is one of the major disadvantages of mantis, e.g. when you want to give customers access to Mantis.

(0031642) istvanb (reporter) 2012-04-11 10:19	I am wondering if this approach is feasible: Define ALL the fields on the issue reporting page as custom variables, where some of them would be mandatory in a way that the user must use them for each issue (like Summary). If all the fields would be "custom fields" then rearranging the fields would be very easy. Also each project could be configured independently. (so lets say now I either display the "additional info" field at every issue, or disable it for every issue. If it would be a custom field, then I can select if a certain project should or should not use it).

Issue History
Date Modified	Username	Field	Change
2004-07-30 17:58	grangeway	New Issue
2004-07-30 17:58	grangeway	Relationship added	child of 0004181
2004-07-30 17:59	grangeway	Relationship added	related to 0003681
2004-07-31 19:15	vboctor	Relationship added	related to 0001872
2004-07-31 19:52	vboctor	Relationship added	related to 0000798
2004-08-07 11:09	jlatour	Status	new => acknowledged
2004-08-27 12:45	grangeway	Relationship added	has duplicate 0002240
2004-09-16 03:51	jotarp	File Added: template_example.tar.gz
2004-09-16 03:51	jotarp	Note Added: 0007619
2004-10-13 17:13	thraxisp	Relationship added	parent of 0004708
2004-11-07 15:57	philippg	Note Added: 0008270
2004-11-08 09:53	fman	Note Added: 0008284
2004-12-13 09:24	Thox	Note Added: 0008597
2004-12-17 07:45	bloodrath	Note Added: 0008692
2004-12-17 07:58	Thox	Note Added: 0008694
2004-12-20 04:01	bloodrath	Note Added: 0008736
2005-01-12 23:57	DamienMcKenna	Note Added: 0008993
2005-01-14 22:06	jferraz	Note Added: 0009026
2005-01-15 03:20	Thox	Note Added: 0009027
2005-01-15 10:49	jferraz	Note Added: 0009030
2005-01-15 11:13	gtomlin	Note Added: 0009031
2005-07-19 16:25	vwegert	Note Added: 0010880
2005-09-22 02:20	fman	Note Added: 0011422
2006-01-25 10:30	ryandesign	Relationship added	related to 0006628
2006-01-25 19:30	ryandesign	Relationship deleted	related to 0006628
2006-01-25 19:36	ryandesign	Relationship added	parent of 0006628
2006-02-06 07:24	ryandesign	Relationship added	related to 0003736
2006-02-06 07:24	ryandesign	Relationship added	related to 0006671
2006-03-03 08:34	ryandesign	Relationship added	related to 0006768
2006-03-09 08:06	ryandesign	Relationship added	related to 0006220
2006-03-09 08:16	ryandesign	Relationship added	related to 0006785
2006-03-09 13:16	ryandesign	Relationship added	related to 0006829
2006-04-16 09:44	vboctor	Note Added: 0012509
2006-04-17 12:06	grangeway	Relationship added	has duplicate 0002464
2006-04-17 12:19	grangeway	Relationship added	related to 0002814
2006-04-27 10:38	fman	Note Added: 0012741
2006-04-27 22:14	thraxisp	Note Added: 0012747
2006-04-27 22:14	thraxisp	Assigned To	=> thraxisp
2006-04-27 22:14	thraxisp	Status	acknowledged => assigned
2006-04-27 22:56	vboctor	Note Added: 0012748
2006-04-27 23:23	vboctor	Note Edited: 0012748
2006-04-29 13:13	thraxisp	Note Edited: 0012747
2006-04-29 13:21	thraxisp	Note Added: 0012755
2006-07-17 10:26	DGtlRift	Note Added: 0013103
2006-07-17 10:34	DGtlRift	Relationship added	related to 0003468
2006-07-26 08:24	ryandesign	Relationship added	related to 0007206
2006-08-02 20:53	BenBE	Note Added: 0013184
2006-08-02 21:26	ryandesign	Relationship added	has duplicate 0007326
2006-10-04 19:22	djnz	File Added: Smarty_for_mantis_PoC.zip
2006-10-04 19:27	djnz	Note Added: 0013582
2006-11-18 01:10	ryandesign	Relationship added	has duplicate 0007607
2007-08-20 02:25	dino	Note Added: 0015460
2008-02-16 14:27	lbertin	Note Added: 0017063
2008-09-04 00:06	vboctor	Relationship added	has duplicate 0009597
2008-11-14 09:50	DGtlRift	Relationship added	related to 0009818
2009-03-30 13:39	milliams	Note Added: 0021299
2009-04-01 07:34	scorpe51	Note Added: 0021352
2009-04-02 18:53	milliams	Note Added: 0021374
2009-05-19 19:27	thraxisp	Assigned To	thraxisp =>
2009-05-19 19:27	thraxisp	Status	assigned => acknowledged
2009-10-24 01:11	vboctor	Relationship added	related to 0011070
2009-11-20 11:32	klkl	Note Added: 0023776
2010-01-11 08:25	blueberry	Note Added: 0024127
2010-01-12 10:47	klkl	Note Edited: 0023776	View Revisions
2010-08-02 15:12	atrol	Relationship added	related to 0006713
2010-09-12 15:16	atrol	Relationship added	related to 0012000
2010-09-28 02:36	atrol	Relationship added	related to 0012339
2010-09-28 20:13	daryn	Tag Attached: redesign
2011-01-14 13:54	atrol	Relationship added	related to 0012685
2012-04-11 10:19	istvanb	Note Added: 0031642
2012-06-22 03:54	atrol	Relationship added	related to 0011385