You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(18) |
Feb
(17) |
Mar
(11) |
Apr
(12) |
May
(21) |
Jun
(76) |
Jul
(8) |
Aug
(156) |
Sep
(117) |
Oct
(67) |
Nov
(122) |
Dec
(134) |
2003 |
Jan
(170) |
Feb
(214) |
Mar
(121) |
Apr
(36) |
May
(25) |
Jun
(10) |
Jul
(13) |
Aug
(69) |
Sep
(3) |
Oct
(17) |
Nov
(2) |
Dec
(40) |
2004 |
Jan
(34) |
Feb
(50) |
Mar
(69) |
Apr
(10) |
May
(76) |
Jun
(126) |
Jul
(180) |
Aug
(32) |
Sep
(43) |
Oct
(31) |
Nov
(25) |
Dec
(21) |
2005 |
Jan
(23) |
Feb
(75) |
Mar
(32) |
Apr
(34) |
May
(23) |
Jun
(34) |
Jul
(25) |
Aug
(21) |
Sep
(31) |
Oct
(34) |
Nov
(6) |
Dec
(16) |
2006 |
Jan
(9) |
Feb
(19) |
Mar
(45) |
Apr
(64) |
May
(33) |
Jun
(29) |
Jul
(11) |
Aug
(24) |
Sep
(55) |
Oct
(24) |
Nov
(38) |
Dec
(40) |
2007 |
Jan
(47) |
Feb
(28) |
Mar
(89) |
Apr
(35) |
May
(58) |
Jun
(30) |
Jul
(103) |
Aug
(80) |
Sep
(57) |
Oct
(108) |
Nov
(45) |
Dec
(38) |
2008 |
Jan
(39) |
Feb
(45) |
Mar
(29) |
Apr
(46) |
May
(39) |
Jun
(20) |
Jul
(19) |
Aug
(38) |
Sep
(40) |
Oct
(49) |
Nov
(64) |
Dec
(31) |
2009 |
Jan
(20) |
Feb
(31) |
Mar
(28) |
Apr
(46) |
May
(45) |
Jun
(45) |
Jul
(32) |
Aug
(11) |
Sep
(34) |
Oct
(33) |
Nov
(40) |
Dec
(17) |
2010 |
Jan
(28) |
Feb
(55) |
Mar
(23) |
Apr
(78) |
May
(33) |
Jun
(11) |
Jul
(10) |
Aug
(12) |
Sep
(70) |
Oct
(89) |
Nov
(55) |
Dec
(33) |
2011 |
Jan
(33) |
Feb
(66) |
Mar
(33) |
Apr
(40) |
May
(20) |
Jun
(29) |
Jul
(199) |
Aug
(42) |
Sep
(76) |
Oct
(10) |
Nov
(29) |
Dec
(38) |
2012 |
Jan
(30) |
Feb
(52) |
Mar
(56) |
Apr
(25) |
May
(17) |
Jun
(93) |
Jul
(15) |
Aug
(19) |
Sep
(23) |
Oct
(78) |
Nov
(59) |
Dec
(2) |
2013 |
Jan
(62) |
Feb
(18) |
Mar
(12) |
Apr
(119) |
May
(47) |
Jun
(34) |
Jul
(34) |
Aug
(12) |
Sep
(69) |
Oct
(128) |
Nov
(14) |
Dec
(11) |
2014 |
Jan
(232) |
Feb
(62) |
Mar
(67) |
Apr
(165) |
May
(82) |
Jun
(54) |
Jul
(26) |
Aug
(70) |
Sep
(56) |
Oct
(59) |
Nov
(3) |
Dec
(16) |
2015 |
Jan
(9) |
Feb
(6) |
Mar
(2) |
Apr
(2) |
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(17) |
Sep
(6) |
Oct
(4) |
Nov
(2) |
Dec
(3) |
2016 |
Jan
(19) |
Feb
(5) |
Mar
(6) |
Apr
(3) |
May
(1) |
Jun
(10) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Guy B. <guy...@ch...> - 2002-09-04 15:33:22
|
Kenzaburo Ito (ke...@30...) on 04/09/2002 at 08:45 wrote: > We're still looking at how complex our implementation of custom fields are > going to be. We will not have a per user setting for the view pages yet. Wouldn't it be useful to add a field holding the "Time Spent" or "Working hours" for a patch/fix/feature/bug handled inside Mantis? This would help when reporting the time spent on a development. -- bug |
From: Kenzaburo I. <ke...@30...> - 2002-09-04 13:45:47
|
We're still looking at how complex our implementation of custom fields are going to be. We will not have a per user setting for the view pages yet. Thanks, -Ken > Looks like we are already on track! > > Can somebody give me a status update for the custom fields, please? I'd > be really appreciated here. > > Today I've also heard feature request that belongs to the custom fields: > Can we make a per user setting on the view_all_bug_page.php to select > which of the custom fields should be shown there? > > Thanks, > Christian > >> -----Original Message----- >> From: ke...@30... [mailto:ke...@30...] >> Sent: Saturday, August 31, 2002 5:25 AM >> To: man...@li... >> Subject: [Mantisbt-dev] Summary of 0.18.0 todo >> >> >> All, >> >> We've decided on serverl items, listed below: >> >> * Reworked the config systems slightly, Eliminating te >> config_inc2.php file. >> * core functions moved ti new dir core/. >> * Remove dependency on register_globals. >> * Proper cleansing of input data. >> * New Manual. >> * Fix logon/redirects. >> * Performance tweaks. >> * Custom Fields. >> * Rework and improve JpGraph support. >> * Move to XHTML compliance >> >> ...And anything else that comes up as we make progress. >> >> Thanks, >> -Ken >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by: OSDN - Tired of that same old >> cell phone? Get a new here for FREE! >> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >> _______________________________________________ >> Mantisbt-dev mailing list >> Man...@li... >> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev >> > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: <Chr...@he...> - 2002-09-04 08:32:13
|
Looks like we are already on track! Can somebody give me a status update for the custom fields, please? I'd be really appreciated here. Today I've also heard feature request that belongs to the custom fields: Can we make a per user setting on the view_all_bug_page.php to select which of the custom fields should be shown there? Thanks, Christian > -----Original Message----- > From: ke...@30... [mailto:ke...@30...] > Sent: Saturday, August 31, 2002 5:25 AM > To: man...@li... > Subject: [Mantisbt-dev] Summary of 0.18.0 todo > > > All, > > We've decided on serverl items, listed below: > > * Reworked the config systems slightly, Eliminating te > config_inc2.php file. > * core functions moved ti new dir core/. > * Remove dependency on register_globals. > * Proper cleansing of input data. > * New Manual. > * Fix logon/redirects. > * Performance tweaks. > * Custom Fields. > * Rework and improve JpGraph support. > * Move to XHTML compliance > > ...And anything else that comes up as we make progress. > > Thanks, > -Ken > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Julian F. <ju...@be...> - 2002-09-03 09:39:44
|
pre...@us... wrote: > Update of /cvsroot/mantisbt/mantisbt/core > In directory usw-pr-cvs1:/tmp/cvs-serv1194/core > > Modified Files: > error_api.php > Log Message: > removed ob_clean call. Clearing the buffer may make for a nicer error message but it totally destroys any debug output. Think of a better way if a pretty error must be displayed. Hrm... What debugging data are you losing exactly? I've occasionaly had problems with non-fatal E_CORE_* or E_COMPILE_* type errors getting erased, but it hasn't seemed to make debugging any more difficult. I would like to figure out a better-solution but the only way I can find to catch *all* errors in PHP is to use some hack that appends code to the end of every page - I don't want to go there. Other options include having a config option to turn the ob_clean() call on or off and only clearing for certain errors. I do think when deployed we want to make the error messages look good and clean, and I particularly think that things like "You are not authorized" should not be showing up half way down a partially rendered page. Anyone have any brilliant thoughts? Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Julian F. <ju...@be...> - 2002-09-03 09:21:05
|
smh...@us... wrote: > Update of /cvsroot/mantisbt/mantisbt > In directory usw-pr-cvs1:/tmp/cvs-serv4619 > > Modified Files: > view_all_inc.php > Log Message: > Restored print_assign_to_option_list to the filter select list (it was commented out by mistake, right?) I thought it was commented out because it was really slow if you had a lot of users. Someone needed to look at optimizing it somehow... But, since we're in active development now, I don't have any objections to uncommenting it so that optimization actually occurs. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Kenzaburo I. <ke...@30...> - 2002-09-03 00:54:09
|
I found the problem, a malformed SQL query which I've fixed. -Ken > I can't use my installation of Mantis right now because the user_prefs are > now > tightly tied to each project. Whenever the user_prefs are not found it > breaks > so I could not login. I created a dummy entry to allow login. This > results > in numerous warnings because the needed user_id/project_id user prefs are > not > in place. > > I see no mention of this on the dev list where all needed db modifications > should be posted. This should be either provided via an upgrade script or > automagically. > > I need an upgrade script. > > Thanks, > -Ken > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Kenzaburo I. <ke...@30...> - 2002-09-02 15:34:39
|
Done, -Ken > Sorry guys, this is an internal ticket which was bounced by error to this > list instead of the right mail alias. Having an email gateway into mantis > isn't necessarily a good thing(TM). > > PS : shouldn't this list be in "post by subscribers only" mode ? |
From: Kenzaburo I. <ke...@30...> - 2002-09-02 15:31:27
|
It's commented out because, for the moment. I'm unable to acutally log into Mantis *cough*. I would liked to verify my changes don't break every browser. -Ken > At 20:43 1-9-2002 -0500, you wrote: >>I've checked in the last of the changes that I am aware of. I will be >>going >>through once more to see if I miseed anything. I've added a doctype >>definition in the html_api.php file (but it is commented out by default). > > Did you add a XML header as well? It is after all an XML file now. > > Why is it commented out? > > Jeroen > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Guy B. <guy...@ch...> - 2002-09-02 12:48:33
|
Christophe Daubry (cd...@ch...) on 02/09/2002 at 10:49 wrote: > ************************************************** > > Demande de suppresion de BAL sur chimie... > > ************************************************** Sorry guys, this is an internal ticket which was bounced by error to this list instead of the right mail alias. Having an email gateway into mantis isn't necessarily a good thing(TM). PS : shouldn't this list be in "post by subscribers only" mode ? -- bug |
From: Jeroen L. <jl...@ca...> - 2002-09-02 05:49:09
|
At 20:43 1-9-2002 -0500, you wrote: >I've checked in the last of the changes that I am aware of. I will be going >through once more to see if I miseed anything. I've added a doctype >definition in the html_api.php file (but it is commented out by default). Did you add a XML header as well? It is after all an XML file now. Why is it commented out? Jeroen |
From: Kenzaburo I. <ke...@30...> - 2002-09-02 01:43:11
|
All, I've checked in the last of the changes that I am aware of. I will be going through once more to see if I miseed anything. I've added a doctype definition in the html_api.php file (but it is commented out by default). If anything looks weird or broken it may be because of a typo while replacing the HTML with XHTML. Let me know or you can fix it yourself. One problem arises: how to validate the pages to be sure. Since we require cookies to access the pages right now the only way is to save a web page manuall and feed it into a validator. Does anyone know of an easy way to accomplish this? Otherwise we'll just verify the major pages and then rely on bug reports. Thanks, -Ken |
From: Colin S. O. <co...@og...> - 2002-09-01 21:54:34
|
Without running the code I would assume that - print '<p>' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '<p>'; + print '<p />' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '<p />'; is not XHTML compliant (<p /> creating an empty tag which has no data between it), despite what the chekin was meant to do, it should be - print '<p>' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '<p>'; + print '<p>' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '</p>'; Unless I am misunderstanding what the $MANTIS_ERROR bit does. --- Colin S. Ogilvie co...@og... -----Original Message----- From: man...@li... [mailto:man...@li...]On Behalf Of pre...@us... Sent: 01 September 2002 22:46 To: man...@li... Subject: [Mantisbt-cvs] mantisbt/core access_api.php,1.3,1.4 database_api.php,1.6,1.7 email_api.php,1.10,1.11 html_api.php,1.8,1.9 print_api.php,1.9,1.10 Update of /cvsroot/mantisbt/mantisbt/core In directory usw-pr-cvs1:/tmp/cvs-serv23010 Modified Files: access_api.php database_api.php email_api.php html_api.php print_api.php Log Message: Changed p tags to be XHTML compliant Index: access_api.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/core/access_api.php,v retrieving revision 1.3 retrieving revision 1.4 diff -u -d -r1.3 -r1.4 --- access_api.php 31 Aug 2002 01:59:34 -0000 1.3 +++ access_api.php 1 Sep 2002 21:45:59 -0000 1.4 @@ -12,13 +12,13 @@ ########################################################################### # Access Control API ########################################################################### - # function to be called when a user is attempting to access a page that + # function to be called when a user is attempting to access a page that # he/she is not authorised to. This outputs an access denied message then # re-directs to the mainpage. function access_denied() { global $MANTIS_ERROR; print '<center>'; - print '<p>' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '<p>'; + print '<p />' . $MANTIS_ERROR[ERROR_ACCESS_DENIED] . '<p />'; print_bracket_link( 'main_page.php', lang_get( 'proceed' ) ); print '</center>'; exit; @@ -45,7 +45,7 @@ } } # -------------------- - # check to see if the current user has access to the specified bug. This assume that the bug exists and + # check to see if the current user has access to the specified bug. This assume that the bug exists and # that the user has access to the project (check_bug_exists() and project_access_check()). function access_bug_check( $p_bug_id, $p_view_state='' ) { global $g_private_bug_threshold; @@ -310,6 +310,6 @@ return user_get_field( $t_user_id, 'access_level' ); } } - + ?> Index: database_api.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/core/database_api.php,v retrieving revision 1.6 retrieving revision 1.7 diff -u -d -r1.6 -r1.7 --- database_api.php 29 Aug 2002 02:56:23 -0000 1.6 +++ database_api.php 1 Sep 2002 21:45:59 -0000 1.7 @@ -16,7 +16,7 @@ # This in the general interface for all database calls. # The actual SQL queries are found in the pages. # Use this as a starting point to port to other databases - + # An array in which all executed queries are stored. This is used for profiling $g_queries_array = array(); @@ -138,7 +138,7 @@ # -------------------- # display both the error num and error msg function db_error() { - return '<p>'.db_error_num().': '.db_error_msg().'<p>'; + return '<p />'.db_error_num().': '.db_error_msg().'<p />'; } # -------------------- # close the connection. Index: email_api.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/core/email_api.php,v retrieving revision 1.10 retrieving revision 1.11 diff -u -d -r1.10 -r1.11 --- email_api.php 31 Aug 2002 02:54:19 -0000 1.10 +++ email_api.php 1 Sep 2002 21:45:59 -0000 1.11 @@ -607,11 +607,11 @@ $result = mail( $t_recipient, $t_subject, $t_message, $t_headers ); if ( TRUE != $result ) { - PRINT "PROBLEMS SENDING MAIL TO: $t_recipient<p>"; + PRINT "PROBLEMS SENDING MAIL TO: $t_recipient<p />"; PRINT htmlspecialchars($t_recipient).'<br />'; - PRINT htmlspecialchars($t_subject).'<p>'; + PRINT htmlspecialchars($t_subject).'<p />'; PRINT nl2br(htmlspecialchars($t_headers)).'<br />'; - PRINT nl2br(htmlspecialchars($t_message)).'<p>'; + PRINT nl2br(htmlspecialchars($t_message)).'<p />'; exit; } } Index: html_api.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/core/html_api.php,v retrieving revision 1.8 retrieving revision 1.9 diff -u -d -r1.8 -r1.9 --- html_api.php 31 Aug 2002 23:31:22 -0000 1.8 +++ html_api.php 1 Sep 2002 21:45:59 -0000 1.9 @@ -174,14 +174,14 @@ # @@@ if (isset($g_string_cookie_val)&&!empty($g_string_cookie_val)) { if ( $g_show_footer_menu ) { - PRINT '<p>'; + PRINT '<p />'; print_menu(); } } print_source_link( $p_file ); - PRINT '<p>'; + PRINT '<p />'; PRINT '<hr size="1" />'; if ( ON == $g_show_version ) { PRINT "<span class=\"timer\"><a href=\"http://mantisbt.sourceforge.net/\">Mantis $g_mantis_version</a></span>"; @@ -279,7 +279,7 @@ if (( ON == $g_show_source )&& ( access_level_check_greater_or_equal( ADMINISTRATOR ) )) { - PRINT '<p>'; + PRINT '<p />'; PRINT '<div align="center">'; PRINT "<a href=\"show_source_page.php?f_url=$p_file\">Show Source</a>"; PRINT '</div>'; @@ -400,7 +400,7 @@ case $t_documentation_page : $t_documentation_page = ''; break; } - PRINT '<p><div align="center">'; + PRINT '<p /><div align="center">'; print_bracket_link( $t_manage_page, lang_get( 'manage_users_link' ) ); print_bracket_link( $t_manage_project_menu_page, lang_get( 'manage_projects_link' ) ); print_bracket_link( $t_manage_user_create_page, lang_get( 'create_new_account_link' ) ); @@ -460,7 +460,7 @@ case $t_documentation_page: $t_documentation_page = ''; break; } - PRINT '<p><div align="center">'; + PRINT '<p /><div align="center">'; print_bracket_link( $t_documentation_page, lang_get( 'system_info_link' ) ); print_bracket_link( $g_path.'ChangeLog', 'ChangeLog' ); print_bracket_link( $g_path.'README', 'README' ); @@ -474,7 +474,7 @@ function print_summary_menu( $p_page='' ) { global $g_use_jpgraph; - PRINT '<p><div align="center">'; + PRINT '<p /><div align="center">'; print_bracket_link( 'print_all_bug_page.php', lang_get( 'print_all_bug_page_link' ) ); if ( $g_use_jpgraph != 0 ) { @@ -497,17 +497,17 @@ global $g_allow_signup; if ( $g_allow_signup != 0 ) { - PRINT '<p><div align="center">'; + PRINT '<p /><div align="center">'; print_bracket_link( 'signup_page.php', lang_get( 'signup_link' ) ); PRINT '</div>'; } } # -------------------- function print_proceed( $p_result, $p_query, $p_link ) { - PRINT '<p>'; + PRINT '<p />'; PRINT '<div align="center">'; if ( $p_result ) { # SUCCESS - PRINT lang_get( 'operation_successful' ) . '<p>'; + PRINT lang_get( 'operation_successful' ) . '<p />'; } else { # FAILURE print_sql_error( $p_query ); } @@ -530,7 +530,7 @@ function print_status_colors() { global $g_status_enum_string; - PRINT '<p>'; + PRINT '<p />'; PRINT '<table class="width100" cellspacing="1">'; PRINT '<tr>'; $t_arr = explode_enum_string( $g_status_enum_string ); Index: print_api.php =================================================================== RCS file: /cvsroot/mantisbt/mantisbt/core/print_api.php,v retrieving revision 1.9 retrieving revision 1.10 diff -u -d -r1.9 -r1.10 --- print_api.php 1 Sep 2002 01:23:24 -0000 1.9 +++ print_api.php 1 Sep 2002 21:45:59 -0000 1.10 @@ -701,7 +701,7 @@ function print_project_user_list_option_list2( $p_user_id ) { global $g_mantis_project_user_list_table, $g_mantis_project_table; - $c_user_id = db_prepare_int( $p_user_id ); + $c_user_id = db_prepare_int( $p_user_id ); $t_prv = PRIVATE; $query = "SELECT DISTINCT p.id, p.name @@ -1048,7 +1048,7 @@ PRINT $MANTIS_ERROR[ERROR_SQL]; print_email_link( $g_administrator_email, lang_get( 'administrator' ) ); - PRINT "<p>$p_query;<p>"; + PRINT "<p />$p_query;<p />"; } # -------------------- ########################################################################### ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Mantisbt-cvs mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-cvs |
From: Jeroen L. <jl...@ca...> - 2002-09-01 10:19:17
|
At 00:41 1-9-2002 -0700, you wrote: >I'm posting this message on two lists because I'm not sure which one is >most appropriate. Here's my question: > >I'd like to run Mantis on my hosted Web site, but they run MySQL version >3.22.27. The requirements posted on sourceforge call for 3.23.2. Is there >any chance of it working? Wow. I got this message 6 times :) As far as I know: no. Part of it will work, but COUNT(DISTINCT value) was introduced in 3.23.2, and there might be other changes since 3.22.27. You could try an old version of Mantis? Of course, you could simply start bugging your ISP to upgrade. 3.22.27 is almost 3 years old. Jeroen P.S. I'm sending this to both lists again, to let everyone know that the mail was answered. From now on, any replies should go to mantisbt-help. |
From: Larry W. A. <al...@co...> - 2002-09-01 07:41:51
|
I'm posting this message on two lists because I'm not sure which one is most appropriate. Here's my question: I'd like to run Mantis on my hosted Web site, but they run MySQL version 3.22.27. The requirements posted on sourceforge call for 3.23.2. Is there any chance of it working? Thank you. Larry W. Allen CodeSlingers al...@co... |
From: Larry W. A. <al...@co...> - 2002-09-01 07:32:33
|
I'm posting this message on two lists because I'm not sure which one is most appropriate. Here's my question: I'd like to run Mantis on my hosted Web site, but they run MySQL version 3.22.27. The requirements posted on sourceforge call for 3.23.2. Is there any chance of it working? Thank you. Larry W. Allen CodeSlingers al...@co... |
From: Larry W. A. <al...@co...> - 2002-09-01 07:31:12
|
I'm posting this message on two lists because I'm not sure which one is most appropriate. Here's my question: I'd like to run Mantis on my hosted Web site, but they run MySQL version 3.22.27. The requirements posted on sourceforge call for 3.23.2. Is there any chance of it working? Thank you. Larry W. Allen CodeSlingers al...@co... |
From: Kenzaburo I. <ke...@30...> - 2002-08-31 22:47:33
|
I can't use my installation of Mantis right now because the user_prefs are now tightly tied to each project. Whenever the user_prefs are not found it breaks so I could not login. I created a dummy entry to allow login. This results in numerous warnings because the needed user_id/project_id user prefs are not in place. I see no mention of this on the dev list where all needed db modifications should be posted. This should be either provided via an upgrade script or automagically. I need an upgrade script. Thanks, -Ken |
From: Kenzaburo I. <ke...@30...> - 2002-08-31 03:25:26
|
All, We've decided on serverl items, listed below: * Reworked the config systems slightly, Eliminating te config_inc2.php file. * core functions moved ti new dir core/. * Remove dependency on register_globals. * Proper cleansing of input data. * New Manual. * Fix logon/redirects. * Performance tweaks. * Custom Fields. * Rework and improve JpGraph support. * Move to XHTML compliance ...And anything else that comes up as we make progress. Thanks, -Ken |
From: Julian F. <ju...@be...> - 2002-08-29 19:21:31
|
vb...@us... wrote: > Update of /cvsroot/mantisbt/mantisbt/core > In directory usw-pr-cvs1:/tmp/cvs-serv24640 > > Modified Files: > user_api.php > Log Message: > Fixed a problem where when a user field was requested for user 0, > a Mantis error was generated. This case occurs when displaying the history > when a defect is assigned and hence the handler name is changed from > 0 to N. Hence, the history code triggers user_get_field for id 0. The code is > changed to return @null@. This needs more thought. Wouldn't it be better to have the history function check if the user was 0 or not before asking for a field for the user? I'm not a big fan of low-level api functions handling special cases like that. We could have a wrapper function somewhere that does the check if necessary, but the lowest level one *should* return an error if you give it 0 because you may want to catch that you are doing that and shouldn't be. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Julian F. <ju...@be...> - 2002-08-29 08:41:31
|
Ross Johnson wrote: > > > Julian Fitzell wrote: > >> Gardner, Chris wrote: >> >>> Here is the exact strings variable we use in the lang/string_english.txt >>> file: >>> >>> $s_severity_enum_string = "10:Not Known >>> Yet,20:Superficial,50:Minor,60:Major,70:Crash,80:System Inoperable"; >>> >>> Then on the report_bug_advanced page the drop down for Severity would >>> read: >>> Not Known Yet >>> Superficial >>> @null@ >>> @null@ >>> Minor >>> Major >>> Crash >>> System Inoperable >>> >>> This would also happen with the reproducibility string. >>> >>> Chris >> >> >> >> Oh, I get it... I'd say you want to override $g_severity_enum_string >> in your custom config file as well, since that defines the possible >> enum values. Now I don't know for sure if there are any negative >> side-effects of doing this because I've never done it and I don't know >> if it was desgined to be changed. But it's in the config file so I'd >> imagine it was. > > > Could this area benefit from some redesigning? Perhaps someone is > already working on it. > > I'm assuming it's historical why these are hardwired in php rather than > kept in a table in the database. > > The main benefit I see of putting these into a db table, apart from then > being configurable via a web browser, is that these descriptions can > then be changed over time without corrupting information in past bug > entries. That is, the enum value is what is recorded in the bug table, > therefore re-associating the value with a new description or removing > that description from the list causes information to be > lost/misrepresented in older bug entries. > > By keeping these descriptions in a table and referenced by their id > rather than enum value, history is preserved (a bug entry with an > original severity of 'Major' will always be shown as 'Major', even if > 'Major' is no longer on the list or it's severity value has been changed). > > In general, this type of information should never be purged but marked > as unused instead. > > The severity value would be a separate column. Having multiple entries > with the same severity value shouldn't be a problem: all that aren't > marked as unused would simply be listed on the same line in the list. > Mostly, only one would be configured as in-use though. > > Another advantage is that, with not a lot more effort, severity levels > and descriptions can be created on a per-project basis. > > A similar problem arises when users are deleted. Rather than purging the > user's table row, it should just be marked as deleted, so that the > original user information is never lost from the historical record. > > Assuming that I were to volunteer to work on this, does this seem like a > reasonable proposal? > > Should this form part of a more general webised configuration feature? > > Is anyone already working on parts of this? I don't know enough about the history to answer most of this in much detail. I can certainly see benefits to not actually deleting db info: victor and I were just talking about how a generic notification system doesn't quite work because you have to send a bug deletion email *before* you delete it (to get the email list - though I do think you could just store the user list). Personally I don't really ever delete users or bugs but I can see why people might want to. So anyway, I don't personally object to the theory necessarily although there certainly are times when you would want to actually clear out your databse a bit. For users, we could just suggest disabling them instead of deleting them (already supported). I don't think we currently ignore disabled users when presenting lists of users, but I think an argument could be made in favour of that and then that would serve basically the same purpose. In terms of a "general webised configuration feature" we are moving towards exploring that and there is interest. We've been removing all references to global configuration variables and replacing them with calls to config_get(). This would allow us to easily move configuration to a db in the future and we are intending to experiment with this. If you're interested on working on this then there would definitely be support behind you. It likely won't happen before 0.18.0 though (except possibly the database changes) Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Ross J. <rp...@is...> - 2002-08-29 04:50:36
|
Julian Fitzell wrote: > Gardner, Chris wrote: > >> Here is the exact strings variable we use in the lang/string_english.txt >> file: >> >> $s_severity_enum_string = "10:Not Known >> Yet,20:Superficial,50:Minor,60:Major,70:Crash,80:System Inoperable"; >> >> Then on the report_bug_advanced page the drop down for Severity would >> read: >> Not Known Yet >> Superficial >> @null@ >> @null@ >> Minor >> Major >> Crash >> System Inoperable >> >> This would also happen with the reproducibility string. >> >> Chris > > > Oh, I get it... I'd say you want to override $g_severity_enum_string in > your custom config file as well, since that defines the possible enum > values. Now I don't know for sure if there are any negative > side-effects of doing this because I've never done it and I don't know > if it was desgined to be changed. But it's in the config file so I'd > imagine it was. Could this area benefit from some redesigning? Perhaps someone is already working on it. I'm assuming it's historical why these are hardwired in php rather than kept in a table in the database. The main benefit I see of putting these into a db table, apart from then being configurable via a web browser, is that these descriptions can then be changed over time without corrupting information in past bug entries. That is, the enum value is what is recorded in the bug table, therefore re-associating the value with a new description or removing that description from the list causes information to be lost/misrepresented in older bug entries. By keeping these descriptions in a table and referenced by their id rather than enum value, history is preserved (a bug entry with an original severity of 'Major' will always be shown as 'Major', even if 'Major' is no longer on the list or it's severity value has been changed). In general, this type of information should never be purged but marked as unused instead. The severity value would be a separate column. Having multiple entries with the same severity value shouldn't be a problem: all that aren't marked as unused would simply be listed on the same line in the list. Mostly, only one would be configured as in-use though. Another advantage is that, with not a lot more effort, severity levels and descriptions can be created on a per-project basis. A similar problem arises when users are deleted. Rather than purging the user's table row, it should just be marked as deleted, so that the original user information is never lost from the historical record. Assuming that I were to volunteer to work on this, does this seem like a reasonable proposal? Should this form part of a more general webised configuration feature? Is anyone already working on parts of this? Thanks. Ross Johnson |
From: Victor B. <vb...@op...> - 2002-08-28 22:40:33
|
> Gardner, Chris wrote: > > Here is the exact strings variable we use in the lang/string_english.txt > > file: > > > > $s_severity_enum_string = "10:Not Known > > Yet,20:Superficial,50:Minor,60:Major,70:Crash,80:System Inoperable"; > > > > Then on the report_bug_advanced page the drop down for Severity > would read: > > Not Known Yet > > Superficial > > @null@ > > @null@ > > Minor > > Major > > Crash > > System Inoperable > > > > This would also happen with the reproducibility string. > > > > Chris > > Oh, I get it... I'd say you want to override $g_severity_enum_string in > your custom config file as well, since that defines the possible enum > values. Now I don't know for sure if there are any negative > side-effects of doing this because I've never done it and I don't know > if it was desgined to be changed. But it's in the config file so I'd > imagine it was. > > Hopefully somone else will jump in if this is incorrect. To override an enumeration list, you need to override it in two places: - custom_strings_inc.php: This allows you to override strings that are defined in the lang/strings_<language>.txt. You can override the strings dependent on the language if you use multiple languages. - custom_config_inc.php: This should be consistent with the enumerations defined in the custom strings, in order not to get a @null@. For the future: - Please use http://mantisbt.sourceforge.net/mantis for reporting bugs. - Use mantisbt-help for requesting help. - Use mantisbt-dev for suggesting new developments like global categories, ...etc. and of course you are always welcome to talk about anything that is related to Mantis on #mantishelp. Regards, Victor |
From: Julian F. <ju...@be...> - 2002-08-28 20:55:59
|
Gardner, Chris wrote: > Here is the exact strings variable we use in the lang/string_english.txt > file: > > $s_severity_enum_string = "10:Not Known > Yet,20:Superficial,50:Minor,60:Major,70:Crash,80:System Inoperable"; > > Then on the report_bug_advanced page the drop down for Severity would read: > Not Known Yet > Superficial > @null@ > @null@ > Minor > Major > Crash > System Inoperable > > This would also happen with the reproducibility string. > > Chris Oh, I get it... I'd say you want to override $g_severity_enum_string in your custom config file as well, since that defines the possible enum values. Now I don't know for sure if there are any negative side-effects of doing this because I've never done it and I don't know if it was desgined to be changed. But it's in the config file so I'd imagine it was. Hopefully somone else will jump in if this is incorrect. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |
From: Gardner, C. <chr...@td...> - 2002-08-28 20:25:30
|
Here is the exact strings variable we use in the lang/string_english.txt file: $s_severity_enum_string = "10:Not Known Yet,20:Superficial,50:Minor,60:Major,70:Crash,80:System Inoperable"; Then on the report_bug_advanced page the drop down for Severity would read: Not Known Yet Superficial @null@ @null@ Minor Major Crash System Inoperable This would also happen with the reproducibility string. Chris -----Original Message----- From: Julian Fitzell [mailto:ju...@be...] Sent: Wednesday, August 28, 2002 2:36 PM To: man...@li... Subject: Re: [Mantisbt-dev] Bug in print_enum_string_option_list Hi Chris, Gardner, Chris wrote: > I have encountered a bug in Mantis. We have added fields to the strings file > for severity, priority, etc... The problem arises when you do not have a > complete sequential order. Our severity variable was something like 10: > value, 20: value, 50: value, 60: value . The print_enum_string_option_list > would then print @null@ for the values for 30 and 40. I have made the minor > addition below to prevent this from happening. > > function print_enum_string_option_list changes: > if ( $t_elem[0] == $p_val ) { > PRINT "<option value=\"$t_elem[0]\" > SELECTED>$t_elem2</option>"; > } else { > - PRINT "<option > value=\"$t_elem[0]\">$t_elem2</option>"; > + if($t_elem2 != "@null@") { > + PRINT "<option > value=\"$t_elem[0]\">$t_elem2</option>"; > + } > } I am unable to reproduce the problem you are describing. I removed one of the elements from the default severity so that it was: $g_severity_enum_string = '10:feature,20:trivial,40:tweak,50:minor,60:major,70:crash,80:block'; And I saw no @null@'s appearing in the bug_update_advanced_page.php. What page were you seeing the problems in? It may be that this has been fixed in CVS, I'm not sure. If you can provide more details I will see if I can track it down. > Since this is my first submission to the list I also have a few feature > requests. The first is the addition of a Development Life Cycle drop down > for reporting bugs. This way we would know if it happened in analysis, > build, testing, design, .. This will be addressed by "custom attributes" which will allow you to define whatever extra fields you want. The intention is to have the database tables set up for it when we release 0.18.0 but the actual code may not be included until after that. If you want to help out on this, drop into IRC or drop Victor (vboctor) an eamil - he's the one who's mostly working on it at the moment. > Another suggestion/request I have is for global > categories. A lot of the different projects we have setup could have used > the same categories for reporting bugs. However, I am too lazy to go in and > add them all for individual projects. The CVS code (and thus 0.18.0 when it released) allows you to copy categories from one project to another. Actually, 0.17.3 looks like it has some of this too. Does this address your concern at all? I know it isn't quite the same as global categories. It might be possible to implement global categories, I'm not sure. If you have a plan in mind, feel free to post details here or drop into IRC to chat about it. As long as the plan works and doesn't make things too complicated you'll probably find support. > I would be willing to work on either of these two things if they are > acceptable to add tot he project. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) ------------------------------------------------------- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim _______________________________________________ Mantisbt-dev mailing list Man...@li... https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Julian F. <ju...@be...> - 2002-08-28 19:40:44
|
Hi Chris, Gardner, Chris wrote: > I have encountered a bug in Mantis. We have added fields to the strings file > for severity, priority, etc... The problem arises when you do not have a > complete sequential order. Our severity variable was something like 10: > value, 20: value, 50: value, 60: value . The print_enum_string_option_list > would then print @null@ for the values for 30 and 40. I have made the minor > addition below to prevent this from happening. > > function print_enum_string_option_list changes: > if ( $t_elem[0] == $p_val ) { > PRINT "<option value=\"$t_elem[0]\" > SELECTED>$t_elem2</option>"; > } else { > - PRINT "<option > value=\"$t_elem[0]\">$t_elem2</option>"; > + if($t_elem2 != "@null@") { > + PRINT "<option > value=\"$t_elem[0]\">$t_elem2</option>"; > + } > } I am unable to reproduce the problem you are describing. I removed one of the elements from the default severity so that it was: $g_severity_enum_string = '10:feature,20:trivial,40:tweak,50:minor,60:major,70:crash,80:block'; And I saw no @null@'s appearing in the bug_update_advanced_page.php. What page were you seeing the problems in? It may be that this has been fixed in CVS, I'm not sure. If you can provide more details I will see if I can track it down. > Since this is my first submission to the list I also have a few feature > requests. The first is the addition of a Development Life Cycle drop down > for reporting bugs. This way we would know if it happened in analysis, > build, testing, design, .. This will be addressed by "custom attributes" which will allow you to define whatever extra fields you want. The intention is to have the database tables set up for it when we release 0.18.0 but the actual code may not be included until after that. If you want to help out on this, drop into IRC or drop Victor (vboctor) an eamil - he's the one who's mostly working on it at the moment. > Another suggestion/request I have is for global > categories. A lot of the different projects we have setup could have used > the same categories for reporting bugs. However, I am too lazy to go in and > add them all for individual projects. The CVS code (and thus 0.18.0 when it released) allows you to copy categories from one project to another. Actually, 0.17.3 looks like it has some of this too. Does this address your concern at all? I know it isn't quite the same as global categories. It might be possible to implement global categories, I'm not sure. If you have a plan in mind, feel free to post details here or drop into IRC to chat about it. As long as the plan works and doesn't make things too complicated you'll probably find support. > I would be willing to work on either of these two things if they are > acceptable to add tot he project. Julian -- ju...@be... Beta4 Productions (http://www.beta4.com) |