From: Kenzaburo I. <ke...@30...> - 2003-08-26 15:54:18
|
All, Firstly, a great big thanks to Victor, Julian, Jeroen and the rest who basically did all the work on 0.18.0 while I was more or less AWOL. The code has been cleaned up dramatically and sped up considerably. We should have a final release after we bake RC1 for a bit longer. Secondly, it's time to start planning on 0.18.1 and 0.19.0. We'll be using the development Wiki to track this and then probably post a roadmap update after we finalize the plans. 0.18.1 additions must _not_ change the database. Database changes will have to wait for 0.19.0. We need to bring back anything that has been shelved or put off and we'll be going back through Mantis to see what enhancements need to be ironed out. Anything new can also be discussed. We will discuss revising our minimum requirements as MySQL and PHP have progressed. Other big things that will probably popup: ADODB, XML-RPC/SOAP, XML export, integration with frameworks (XOOPS, PHPNuke, etc), bundling with other software. Please feel free to start previsouly halted discussion as this is the best time for any design changes or big features. Thanks, -Ken |
From: <c.d...@se...> - 2003-08-29 08:53:31
|
Some suggestions for future releases: Filters: Addition of version and resolution state for selection Allow category selection for 'all projects' i.e. select from all distinct categories Filter by value of custom field View: Show resolution for resolved/closed instead(or as well as) of assignee E-mail: Allow per project e-mail preferences Add status to the subject line of e-mails [project 0002321]NEW: summary.... Add version to body of e-mails Project: Have a project status of closed that does not allow new bugs to be raised against it Actions: Select a number of bugs and mark them as fixed in a particular release version Audit: Audit administration actions Main: Link to show all bugs assigned to me (across all projects) Link to show all resolved bugs raised by me (across all projects) Export: Template documents for export to word/html to allow projects to generate custom reports for clients CSV export should export all fields including custom fields Admin: Copy of custom fields from one project to another. Ability to define a 'template project' that all categories/custom fields are inherited from. Periodic: cron type job that allows e-mail to be picked up to add bugnotes/files mailed from registered users. job to mail reports about unassigned bugs left for longer than a certain time job to mail reports about assigned bugs older than defined time per priority Colin Draper T3 Support Manager Searchspace Limited Prospect House 80-110 New Oxford Street London, WC1A 1HB UK Direct: +44 (0)20 7255 0123 Tel: +44 (0)20 7255 1065 www.searchspace.com <http://www.searchspace.com/> *************************************************************** WARNING: For your own safety all email attachments should be virus scanned prior to opening. This communication contains information which is confidential and may be privileged. Please note that the opinions expressed in this communication are not necessarily those of Searchspace Limited. *************************************************************** |
From: Robert F. <rf...@mo...> - 2003-08-29 11:47:02
|
My $0.02... I have been asked at work for custom Bug Views... Including the ability = to create views with custom fields. And on custom fields: It makes sense to be able to render a field as a = drop down if a list of values is specified. Also, the ability to be able to re-order the fields displayed in the add bug simple and advanced forms, = so that a custom field can be displayed near the top. All of these have popped up in the last few weeks, and if I ever get = time, I'll implement these features for the installation at work, then submit = the patches for v19.0 :) At least, that's the plan. Robert Foster Mountain Visions P/L Australia. rf...@mo... http://mountainvisions.com.au -----Original Message----- From: man...@li... [mailto:man...@li...] On Behalf Of c.d...@se... Sent: Friday, 29 August 2003 6:53 PM To: man...@li... Subject: [Mantisbt-dev] Moving forward Some suggestions for future releases: Filters: Addition of version and resolution state for selection Allow category selection for 'all projects' i.e. select from all distinct categories Filter by value of custom field View: Show resolution for resolved/closed instead(or as well as) of assignee E-mail: Allow per project e-mail preferences Add status to the subject line of e-mails [project 0002321]NEW: summary.... Add version to body of e-mails Project: Have a project status of closed that does not allow new bugs to = be raised against it Actions: Select a number of bugs and mark them as fixed in a particular release version Audit: Audit administration actions Main: Link to show all bugs assigned to me (across all projects) Link to show all resolved bugs raised by me (across all projects) Export: Template documents for export to word/html to allow projects to generate custom reports for clients CSV export should export all fields including custom fields Admin: Copy of custom fields from one project to another. =20 Ability to define a 'template project' that all categories/custom fields are inherited from. Periodic: cron type job that allows e-mail to be picked up to add bugnotes/files mailed from registered users. job to mail reports about unassigned bugs left for longer than a certain time job to mail reports about assigned bugs older than defined time per priority Colin Draper T3 Support Manager =09 Searchspace Limited =09 Prospect House =09 80-110 New Oxford Street =09 London, WC1A 1HB UK Direct: +44 (0)20 7255 0123 Tel: +44 (0)20 7255 1065 www.searchspace.com <http://www.searchspace.com/> *************************************************************** WARNING: For your own safety all email attachments should be virus scanned prior to opening. This communication contains = information which is confidential and may be privileged. Please note that the = opinions expressed in this communication are not necessarily those of Searchspace Limited. *************************************************************** ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Rodney H. <rh...@es...> - 2003-08-26 16:27:30
|
Apologies if this has been brought up before, Ive not been on this list very long. Id like to propose an architectural change that would make mantis easier to customize: o Move all field enumerations out of config files and into db tables. o Create interface for managing the field enumerations. Status, Severity and Priority are some of the 'field enumerations' that should be moved from config files into db tables. In fact, all config information could/should be moved into db tables. Mantis would be much easier to configure and use if one does not have to edit configuration files. One issue that we have found in our customization of mantis is the requirement that the language files also be modified to correspond to the changes made to the field enumerations. It would be nice if a mantis admin could make the changes through an interface and have the language strings 'automagically' updated. Maybe store the lang strings in db tables ? thanks rodney Kenzaburo Ito wrote: > All, > > Firstly, a great big thanks to Victor, Julian, Jeroen and the rest who > basically did all the work on 0.18.0 while I was more or less AWOL. The > code has been cleaned up dramatically and sped up considerably. We should > have a final release after we bake RC1 for a bit longer. > > Secondly, it's time to start planning on 0.18.1 and 0.19.0. We'll be > using the development Wiki to track this and then probably post a roadmap > update after we finalize the plans. 0.18.1 additions must _not_ change > the database. Database changes will have to wait for 0.19.0. > > We need to bring back anything that has been shelved or put off and we'll > be going back through Mantis to see what enhancements need to be ironed > out. Anything new can also be discussed. > > We will discuss revising our minimum requirements as MySQL and PHP have > progressed. Other big things that will probably popup: ADODB, > XML-RPC/SOAP, XML export, integration with frameworks (XOOPS, PHPNuke, > etc), bundling with other software. > > Please feel free to start previsouly halted discussion as this is the best > time for any design changes or big features. > > Thanks, > -Ken > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines > at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: Kenzaburo I. <ke...@30...> - 2003-08-26 16:50:22
|
Rodney, We've discussed this a bit a long while ago. The two big issues against were/are potential slowdowns from database access and localization headaches (primarily with enums, but also with translator updates). In the end, inertia won out and we stayed with what was in place. I completely agree that moving the configurations into the DB would be excellent from an administrative (and upgrade) viewpoint. Likewise for localization. For me it boils down to doing some performance testing and seeing if the results are acceptable. I'd like to put this as an official 'try it out' unless there are sound reasons to the contrary. Thanks, -Ken > Apologies if this has been brought up before, Ive not been on this > list very long. > > > Id like to propose an architectural change that would make mantis > easier to customize: > > o Move all field enumerations out of config files and into db tables. > o Create interface for managing the field enumerations. > > Status, Severity and Priority are some of the 'field enumerations' that > should be moved from config files into db tables. > > In fact, all config information could/should be moved into db tables. > Mantis would be much easier to configure and use if one does not have > to edit configuration files. > > One issue that we have found in our customization of mantis is the > requirement that the language files also be modified to correspond > to the changes made to the field enumerations. It would be nice if > a mantis admin could make the changes through an interface and have > the language strings 'automagically' updated. Maybe store the lang > strings in db tables ? > > > thanks > rodney |
From: Julian F. <ju...@be...> - 2003-08-26 17:10:22
|
And, I should point out the one of the main motivators for moving all config variable access to go through the config_* api instead of using global variables was so this sort of change could be made easily. The one main thing we need to do is figure out how to store the config options that are arrays, etc. We either need to add additional APIs that know how to deal with them, or we just need to serialize the values into the database. This should actually work fine as long as users are using a Mantis interface to modify the data rather than wanting to mess with it directly. <shrug> It doesn't seem likely that I'll have huge chunks of free time in the immediate future but I'll certainly try to keep commenting on the mailing list anyway. Julian Kenzaburo Ito wrote: > Rodney, > > We've discussed this a bit a long while ago. The two big issues against > were/are potential slowdowns from database access and localization > headaches (primarily with enums, but also with translator updates). In > the end, inertia won out and we stayed with what was in place. > > I completely agree that moving the configurations into the DB would be > excellent from an administrative (and upgrade) viewpoint. Likewise for > localization. > > For me it boils down to doing some performance testing and seeing if the > results are acceptable. I'd like to put this as an official 'try it out' > unless there are sound reasons to the contrary. > > Thanks, > -Ken > > >>Apologies if this has been brought up before, Ive not been on this >>list very long. >> >> >>Id like to propose an architectural change that would make mantis >>easier to customize: >> >>o Move all field enumerations out of config files and into db tables. >>o Create interface for managing the field enumerations. >> >>Status, Severity and Priority are some of the 'field enumerations' that >>should be moved from config files into db tables. >> >>In fact, all config information could/should be moved into db tables. >>Mantis would be much easier to configure and use if one does not have >>to edit configuration files. >> >>One issue that we have found in our customization of mantis is the >>requirement that the language files also be modified to correspond >>to the changes made to the field enumerations. It would be nice if >>a mantis admin could make the changes through an interface and have >>the language strings 'automagically' updated. Maybe store the lang >>strings in db tables ? >> >> >>thanks >>rodney |
From: Christopher S. <che...@ya...> - 2003-08-26 22:07:03
|
--- Julian Fitzell <ju...@be...> wrote: > The one main thing we need to do is figure out how to store the config > options that are arrays, etc. We either need to add additional APIs > that know how to deal with them, or we just need to serialize the values > into the database. What do you mean by serialize? Do you mean taking a config var like this: $g_default_notify_flags = array('reporter' => ON, 'handler' => ON, 'monitor' => ON, 'bugnotes' => ON, 'threshold_min' => NOBODY, 'threshold_max' => NOBODY); And turning it into a db value like this: reporter|ON,handler|ON,monito|ON,bugnotes|ON,threshold_min|NOBODY,threshold_max|NOBODY Or something like that? > This should actually work fine as long as users are > using a Mantis interface to modify the data rather than wanting to mess > with it directly. <shrug> I think you can assume anyone who is messing directly with the DB knows-what-they-are-doing(TM), either that, or they deserve what they get ;). Chris Shaffer __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: Julian F. <ju...@be...> - 2003-08-26 22:18:22
|
Christopher Shaffer wrote: > --- Julian Fitzell <ju...@be...> wrote: > >>The one main thing we need to do is figure out how to store the config >>options that are arrays, etc. We either need to add additional APIs >>that know how to deal with them, or we just need to serialize the values >>into the database. > > > What do you mean by serialize? Do you mean taking a config var like this: > > $g_default_notify_flags = array('reporter' => ON, > 'handler' => ON, > 'monitor' => ON, > 'bugnotes' => ON, > 'threshold_min' => NOBODY, > 'threshold_max' => NOBODY); > > And turning it into a db value like this: > > reporter|ON,handler|ON,monito|ON,bugnotes|ON,threshold_min|NOBODY,threshold_max|NOBODY > > Or something like that? Well, I meant more like: serialize($g_default_notify_flags); See http://www.php.net/serialize It will serialize any php object or value to a string. Julian |
From: Rodney H. <rh...@es...> - 2003-08-26 22:53:13
|
I was thinking of one relation ( table ) per enumeration, and then another relation for global configuration items. for example: relation 'severity' { id, description } relation 'config_inc' { hostname, username, password, db_name, etc... } Just add a new relation for each enumeration. It may be useful to specify a field that refers to the relative level within the enumeration. The level would be a unique identifier within the relation so it could be used in place of the id field in the above example. This would give you something to sort on when presenting the information to the user. This is similar to how it is laid out in the current enum variables. eg. relation 'severity' { level, description } The most challenging aspect of this design is maintaining support for language strings. It would be nice if the description field could be stored in a language portable format. Maybe the browser can do the work of showing the characters correctly based on the browsers locale setting. Is this possible??? rodney Christopher Shaffer wrote: > --- Julian Fitzell <ju...@be...> wrote: > >>The one main thing we need to do is figure out how to store the config >>options that are arrays, etc. We either need to add additional APIs >>that know how to deal with them, or we just need to serialize the values >>into the database. > > > What do you mean by serialize? Do you mean taking a config var like this: > > $g_default_notify_flags = array('reporter' => ON, > 'handler' => ON, > 'monitor' => ON, > 'bugnotes' => ON, > 'threshold_min' => NOBODY, > 'threshold_max' => NOBODY); > > And turning it into a db value like this: > > reporter|ON,handler|ON,monito|ON,bugnotes|ON,threshold_min|NOBODY,threshold_max|NOBODY > > Or something like that? > > >>This should actually work fine as long as users are >>using a Mantis interface to modify the data rather than wanting to mess >>with it directly. <shrug> > > > I think you can assume anyone who is messing directly with the DB knows-what-they-are-doing(TM), > either that, or they deserve what they get ;). > > Chris Shaffer > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: Julian F. <ju...@be...> - 2003-08-26 23:35:28
|
Rodney Holm wrote: > I was thinking of one relation ( table ) per enumeration, and then > another relation for global configuration items. > > for example: > > relation 'severity' { > id, > description > } > > relation 'config_inc' { > hostname, > username, > password, > db_name, > etc... > } > > Just add a new relation for each enumeration. I was thinking more in terms of config options like the notification levels that are array-based data as opposed to those which are just lists. But in either case, how would you see the API looking for a page to get at these config options though? Do you have a special function for each one that know where to look stuff up, etc? The nice thing about serializing it is that you can still ask for the value of the config option and get back the array you always used to get. The config interface can still get that array out, display it, let you modify it, and serialize the modified array back in for the new value. I realize it's pretty unclean from a DB point of view and I'm not suggesting it's necessarily the right way to go - it just seems like the simplest way to maintain our nice simple config_api while letting us move the data into a declarative storage format. Julian |
From: Christopher S. <che...@ya...> - 2003-08-27 00:03:12
|
--- Julian Fitzell <ju...@be...> wrote: > The nice thing about serializing it is that you can still ask for the > value of the config option and get back the array you always used to > get. The config interface can still get that array out, display it, let > you modify it, and serialize the modified array back in for the new value. > > I realize it's pretty unclean from a DB point of view and I'm not > suggesting it's necessarily the right way to go - it just seems like the > simplest way to maintain our nice simple config_api while letting us > move the data into a declarative storage format. I guess this poses a question: Does the Mantis team want to take the path of least resistance for now, and comeback to this later? What I mean is, fix the current config system to be more db friendly (revamping it), or patch it for now. Julian's right, serialize() would be a quick solution. But as he's already pointed out, its not very DB-friendly. Perhaps a target version should be set for a revamp of the config system (say, 0.2, or 0.3), and serialize() could be used for now... Chris Shaffer __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: Robert F. <rf...@mo...> - 2003-08-27 01:06:26
|
Radical thought.... How about an XML structure? Which could easily be inserted into the = db... Just a thought. Robert Foster Mountain Visions P/L Australia. rf...@mo... http://mountainvisions.com.au -----Original Message----- From: man...@li... [mailto:man...@li...] On Behalf Of = Christopher Shaffer Sent: Wednesday, 27 August 2003 10:03 AM To: man...@li... Subject: Re: [Mantisbt-dev] Moving forward --- Julian Fitzell <ju...@be...> wrote: > The nice thing about serializing it is that you can still ask for the > value of the config option and get back the array you always used to=20 > get. The config interface can still get that array out, display it, = let=20 > you modify it, and serialize the modified array back in for the new = value. >=20 > I realize it's pretty unclean from a DB point of view and I'm not > suggesting it's necessarily the right way to go - it just seems like = the=20 > simplest way to maintain our nice simple config_api while letting us=20 > move the data into a declarative storage format. I guess this poses a question: Does the Mantis team want to take the = path of least resistance for now, and comeback to this later? What I mean = is, fix the current config system to be more db friendly (revamping it), or patch it for now. Julian's right, serialize() would be a quick solution. But as he's = already pointed out, its not very DB-friendly. Perhaps a target version should = be set for a revamp of the config system (say, 0.2, or 0.3), and = serialize() could be used for now... Chris Shaffer __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Jeroen L. <jl...@ca...> - 2003-08-27 07:12:12
|
On Wed, 27 Aug 2003 11:06:54 +1000, Robert Foster <rf...@mo...> wrote: > Radical thought.... > How about an XML structure? Which could easily be inserted into the db... Sounds good. At least it's an established standard. Still, all the ideas I'm hearing make it impossible to put PHP code in the config and dynamically generate it. That's a bit of a shame. Another thought: perhaps we should convert all language files into Unicode? The problem with that is that we have to find a way to convert old data. Jeroen |
From: Rodney H. <rh...@es...> - 2003-08-27 22:16:06
|
Julian Fitzell wrote: > > I was thinking more in terms of config options like the notification > levels that are array-based data as opposed to those which are just lists. > > But in either case, how would you see the API looking for a page to get > at these config options though? Do you have a special function for each > one that know where to look stuff up, etc? > Im not familiar with the array-based data you are referring to, so it is possible I am missing something important here. As for the API... If you know the name of the relation, you can get all of the values by passing the relation name to a function. You could use the same function for all enumeration relations. You could even keep the names of the enumeration relations in a seperate relation, that way the names of the enum relations would not have to be 'hardcoded' in the software. > The nice thing about serializing it is that you can still ask for the > value of the config option and get back the array you always used to > get. The config interface can still get that array out, display it, let > you modify it, and serialize the modified array back in for the new value. > > I realize it's pretty unclean from a DB point of view and I'm not > suggesting it's necessarily the right way to go - it just seems like the > simplest way to maintain our nice simple config_api while letting us > move the data into a declarative storage format. > Im not the one maintaining or modifying the existing code, and being new to this list, I do not have a lot of historical data to draw upon when presenting ideas. If making these changes because of upgrade issues, or localization issues is cumbersome, then maybe now is not the right time. I just do not know enough about the system right now to make a real good judgements about maintenance/development schedule or the product roadmap. It does seem that most folks here agree that using a database to store the config info is a good long term goal. Keeping the long term goal in mind when developing in the short term should help make it easier when it comes time to implement. rodney > Julian > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: Christopher S. <che...@ya...> - 2003-08-26 22:00:14
|
--- Rodney Holm <rh...@es...> wrote: > In fact, all config information could/should be moved into db tables. > Mantis would be much easier to configure and use if one does not have > to edit configuration files. For what its worth, this is number one on my list, followed by db abstraction (Pear, ADODB). My list looks something like this: 1.) Config overhaul (moving config vars into db and full web-based config interface) 2.) DB Abstraction through ADODB and Pear 3.) Installer 4.) Employ use of templates (Smarty...) 5.) Have the Docs section perform more 'document manager' functions (check in, check out, version checking). 6.) (this ones pie in the sky) Perform code/release management tasks. Just some thoughts, Chris __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
From: Tarjei K. <ta...@ch...> - 2003-08-29 12:48:07
|
Well, I've got a few minors which I've reported earlier really, but I guess it won't hurt to repeat them :) 1. Add the action taken on any bug to the email topic, i.e. instead of getting emails like this: [MyProj 0000001]: severe bug [MyProj 0000001]: severe bug [MyProj 0000001]: severe bug you get something a little more informative: [MyProj 0000132 NEW]: severe bug [MyProj 0000132 ASSIGNED]: severe bug [MyProj 0000132 RESOLVED]: severe bug <partly ranting> 2. Those horrible "Operation successful. Click here to continue" dialogs just have to go. They are absolutely useless. The only thing that's needed are dialogs when things go _wrong_, not when they do as you expect. Analogous, if you click "Send" when writing email, there's no point in the email client popping up a "Mail sent successfully. Click OK to continue" dialog. You will get all the feedback you need, which is when the email could not be delivered. Useless dialogs are a real disease, there's just far too many of them. Let's not make matters worse by including them in Mantis ;) </partly ranting> Cheers, -- Tarjei |
From: Kenzaburo I. <ke...@30...> - 2003-08-29 20:31:53
|
1. Noted. I've wanted this myself. 2. Also noted. There's a quick proceeed option to bypass the messages in common places but I agree it's aggravating after you've used the app for more than 5 minutes. I think, besides errors, the only time you really need to post this type of message is if the resulting page might make it unclear that what you did actually occurred. > 1. Add the action taken on any bug to the email topic, i.e. instead of > getting emails like this: > > [MyProj 0000001]: severe bug > [MyProj 0000001]: severe bug > [MyProj 0000001]: severe bug > > you get something a little more informative: > > [MyProj 0000132 NEW]: severe bug > [MyProj 0000132 ASSIGNED]: severe bug > [MyProj 0000132 RESOLVED]: severe bug > <partly ranting> > 2. Those horrible "Operation successful. Click here to continue" dialogs > just have to go. They are absolutely useless. The only thing that's > needed are dialogs when things go _wrong_, not when they do as you > expect. > > Analogous, if you click "Send" when writing email, there's no point in > the email client popping up a "Mail sent successfully. Click OK to > continue" dialog. You will get all the feedback you need, which is when > the email could not be delivered. > > Useless dialogs are a real disease, there's just far too many of them. > Let's not make matters worse by including them in Mantis ;) > </partly> > > Cheers, > -- > Tarjei |