phpbt-dev — Developer's mailing list and cvs commits

[phpBT-dev] Re: htmlentities

[Jirka P. <fi...@us...>]

Wow, I did clean install and sumbitted a bug from another machine and it
works fine, except it is translating quotes into &" what it not
good. But special characters are now displaying OK. It's crazy. I'll try
some another tricks on thursday, because I'll be in off-line for next two
days.

Jirka

[phpBT-dev] htmlentities

[Jirka P. <fi...@us...>]

Mhmm ... I've tried some tricks, but there are two ways and both are wrong.
In both, no change in bug.php is done.

1) If I've made clean install and no change, czech special characters are
not formatted correctly. They are unreadable.
2) If I've made change on line 108 in templates/default/bugdisplay.html like
on figure (1) or figure (2), special characters are well formatted, but
quotes are not slashed.

My idea, that it's all in use of htmlspecialchars function was wrong, I'm
sorry. I'll try some better tricks and I'll send reports.

Jirka

figure (1):
... name="title" value="{$title|stripslashes}"> ...

figure (2):
... name="title" value="{$title}"> ...

Re: [phpBT-dev] Problem with htmlspecialchars and htmlentities

[Jirka P. <fi...@us...>]

> Of course that third argument is only in PHP >=3D 4.1.0, so if it does
> work, we just made a new requirement. :(

We have to make new requirement only for users using non ascii charsets. No=
 one is using PHP 3.x seriously now and 4.1.x is a bit buggy one. I think e=
veryone is waiting for 4.2 and everyone, who is taking it seriously will us=
e it.

> On Mon, Apr 15, 2002 at 04:48:30AM -0700, Ben Curtis wrote:
>> These two functions replace certain html characters with their character
>> code equivalents.  They are especially necessary when printing out a
>> value that may contain a " into the value attribute of a text input box.

This could be done by addslashes() function. I think there is still no need=
 for htmlspecialchars, because it's doing the same thing but it's formattin=
g special chars badly in PHP < 4.1.0. Maybe it will work in PHP >=3D 4.1 wi=
th using the third parameter.

I'm using PHP vs. MySQL for a really long time and I've never needed using =
htmlspecialchars for this reason before, I'm using addslashes/stripslashes =
combo.

>> Though I don't have much experience with other charsets, it looks like
>> the functions take a charset as an optional third option.  Jirka, will
>> you try putting them back in using the charset from cz.php and see if it
>> works?

I'll try using third parameter later today and I'll report to dev list.

If it will work and we decide to use it, we have to rewrite all occurences =
of htmlspecialchars function. But this is only one part of problem. Second =
part is templates htmlentities attribute. Is it necessary to use it? Maybe =
we are using too much conversion from and back to htmlspecialchars, htmlent=
ities, slashes and we are losing the goal. Maybe. I'm not sure, it's on you=
r decision.

Jirka

Re: [phpBT-dev] Problem with htmlspecialchars and htmlentities

[Ben C. <php...@be...>]

Of course that third argument is only in PHP >= 4.1.0, so if it does
work, we just made a new requirement. :(

On Mon, Apr 15, 2002 at 04:48:30AM -0700, Ben Curtis wrote:
> These two functions replace certain html characters with their character
> code equivalents.  They are especially necessary when printing out a
> value that may contain a " into the value attribute of a text input box.
> Though I don't have much experience with other charsets, it looks like
> the functions take a charset as an optional third option.  Jirka, will
> you try putting them back in using the charset from cz.php and see if it
> works?
> 
> On Mon, Apr 15, 2002 at 10:24:29AM -0000, Jirka Pech wrote:
> > I've found possible localisation problem. I don't know exactly, why htmlspecialchars function is used in /bug.php (and other scripts of course, but I've focused on this one), but this function causes a problem with encoding of Czech Language special characters. For example ve have special 'hooked e' character, which is converted to something else by this function and displayed incorrectly with 'htmlentities' attribute in template bugdisplay.html.
> > 
> > I'm not sure if these may be removed (e.g. for security reasons), but everything works ok for me, if I've removed htmlspecialchars function from /bug.php (in function do_form) and htmlentities attribute from /templates/default/bugdisplay.html (on line 108).
> > 
> > Jirka
> > 

Re: [phpBT-dev] Problem with htmlspecialchars and htmlentities

[Ben C. <php...@be...>]

These two functions replace certain html characters with their character
code equivalents.  They are especially necessary when printing out a
value that may contain a " into the value attribute of a text input box.
Though I don't have much experience with other charsets, it looks like
the functions take a charset as an optional third option.  Jirka, will
you try putting them back in using the charset from cz.php and see if it
works?

On Mon, Apr 15, 2002 at 10:24:29AM -0000, Jirka Pech wrote:
> I've found possible localisation problem. I don't know exactly, why htmlspecialchars function is used in /bug.php (and other scripts of course, but I've focused on this one), but this function causes a problem with encoding of Czech Language special characters. For example ve have special 'hooked e' character, which is converted to something else by this function and displayed incorrectly with 'htmlentities' attribute in template bugdisplay.html.
> 
> I'm not sure if these may be removed (e.g. for security reasons), but everything works ok for me, if I've removed htmlspecialchars function from /bug.php (in function do_form) and htmlentities attribute from /templates/default/bugdisplay.html (on line 108).
> 
> Jirka
> 
> _______________________________________________
> phpbt-dev mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpbt-dev

[phpBT-dev] Problem with htmlspecialchars and htmlentities

[Jirka P. <fi...@us...>]

I've found possible localisation problem. I don't know exactly, why htmlspe=
cialchars function is used in /bug.php (and other scripts of course, but I'=
ve focused on this one), but this function causes a problem with encoding o=
f Czech Language special characters. For example ve have special 'hooked e'=
 character, which is converted to something else by this function and displ=
ayed incorrectly with 'htmlentities' attribute in template bugdisplay.html.

I'm not sure if these may be removed (e.g. for security reasons), but every=
thing works ok for me, if I've removed htmlspecialchars function from /bug.=
php (in function do_form) and htmlentities attribute from /templates/defaul=
t/bugdisplay.html (on line 108).

Jirka

[phpBT-dev] CVS: phpbt include.php,1.114,1.115

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv18837

Modified Files:
	include.php 
Log Message:
Add a little more info

Index: include.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/include.php,v
retrieving revision 1.114
retrieving revision 1.115
diff -u -r1.114 -r1.115
--- include.php	14 Apr 2002 23:47:37 -0000	1.114
+++ include.php	14 Apr 2002 23:51:26 -0000	1.115
@@ -47,7 +47,7 @@
 	);
 $db = DB::Connect($dsn);
 if (DB::isError($db)) {
-	die($db->message);
+	die($db->message.'<br>'.$db->userinfo);
 }
 $db->setOption('optimize', 'portability');
 $db->setFetchMode(DB_FETCHMODE_ASSOC);

[phpBT-dev] CVS: phpbt include.php,1.113,1.114

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv18194

Modified Files:
	include.php 
Log Message:
Die with the error message when failing to connect to the database

Index: include.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/include.php,v
retrieving revision 1.113
retrieving revision 1.114
diff -u -r1.113 -r1.114
--- include.php	11 Apr 2002 20:16:11 -0000	1.113
+++ include.php	14 Apr 2002 23:47:37 -0000	1.114
@@ -46,6 +46,9 @@
 	'password' => DB_PASSWORD
 	);
 $db = DB::Connect($dsn);
+if (DB::isError($db)) {
+	die($db->message);
+}
 $db->setOption('optimize', 'portability');
 $db->setFetchMode(DB_FETCHMODE_ASSOC);
 $db->setErrorHandling(PEAR_ERROR_CALLBACK, "handle_db_error");
@@ -105,6 +108,7 @@
 		error_reporting(E_ALL ^ E_NOTICE); // Clobber Smarty warnings
 		return Smarty::fetch($_smarty_tpl_file, $_smarty_cache_id, $_smarty_compile_id, $_smarty_display);
 	}
+
 }
 
 $t = new extSmarty;

[phpBT-dev] CVS: phpbt/templates/default/base removetemplates.html,NONE,1.1

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt/templates/default/base
In directory usw-pr-cvs1:/tmp/cvs-serv27952/templates/default/base

Added Files:
	removetemplates.html 
Log Message:
Allow the admin to clear out compiled templates.  This makes it possible to remove the c_templates dir w/out having root access.

--- NEW FILE: removetemplates.html ---
<div align="center">
	The compiled templates have been removed, so you can now uninstall
	phpBugTracker by closing this browser window and removing the installation
	directory.  If you don't wish to uninstall phpBugTracker, then simply browse
	through the site and the templates will be recompiled.
</div>

[phpBT-dev] CVS: phpbt/admin removetemplates.php,NONE,1.1

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt/admin
In directory usw-pr-cvs1:/tmp/cvs-serv27952/admin

Added Files:
	removetemplates.php 
Log Message:
Allow the admin to clear out compiled templates.  This makes it possible to remove the c_templates dir w/out having root access.

--- NEW FILE: removetemplates.php ---
<?php

// removetemplates.php - Clean out the template directories
// ------------------------------------------------------------------------
// Copyright (c) 2001, 2002 The phpBugTracker Group
// ------------------------------------------------------------------------
// This file is part of phpBugTracker
//
// phpBugTracker is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// phpBugTracker is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with phpBugTracker; if not, write to the Free Software Foundation,
// Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
// ------------------------------------------------------------------------
// $Id: removetemplates.php,v 1.1 2002/04/13 19:40:25 bcurtis Exp $

chdir('..');
define('TEMPLATE_PATH', 'admin');
include 'include.php';

$perm->check('Admin');

$t->clear_all_cache();
$t->clear_compiled_tpl();
include 'templates/default/base/removetemplates.html';

?>

Re: [phpBT-dev] New optional features (request for comments)

[Jirka P. <fi...@us...>]

> This does sound good, but I want to have a discussion on how we can add
> other lookups like this and the database version of the phpBB guys in a
> modular fashion.  How can we make it so that anyone who has something
> extra they want to track in the database can just add a new table with
> values (let's say phases of the moon for example) and then tie the bug
> table to the phases_of_moon table?  I'm thinking of something like the
> skeleton script that helps you get started writing a php extension.  It
> generates the header, c, and test files that you can use as a jumping
> off point for writing an extension.  Perhaps we could write a skeleton
> script that creates a db-changes file (alter the bug table, create the
> new lookup table, etc.).   I guess the first thing to do is have a
> detailed outline of all the changes that need to be made to the code
> base and database to have a new lookup, such as Environment, added and
> trackable.  Let's try and do this in a modular fashion rather than just
> adding more and more lookups.

And what if we do not want to abuse user with a skeleton script or something
(not everyone is capable to run skeleton scripts), but if we will create new
part of administration interface integrated into phpBugTracker's
administration?

Let's follow the user on his way to add new field:
1) User (Admin in this step) wants to track the phase of the Moon.
2) Admin opens administration and clicks on New field.
3) Admin fills if the field will be only the variable value or foreign key.
4) If it will be the variable, tables and scripts (config.php,
cofig-dist.php and other) are self modified.
5) If it will be foreign key, user is forced to fill at least one value,
which will be available for selection. New table is created, rows (with
values sumbitted by user) are inserted into it and scripts are self
modified.

Rather than modifying scripts, this fields may be configured in the database
table or .ini file.  I understand, it needs more coding than creating a
skeleton script, but it will be more user friendly.

So, we can create new table TBL_EXTRAS, which will contain extra fields and
foreign keys. We also need modify TBL_BUG and TBL_PROJECT, because some
extra fields will stay per project and other extra fileds will stay per bug.
For example version_to_be_closed will be property (or attribute) of a Bug
and database_version will be property of a Project. I don't actually know if
we will ever have extra fields for e.g. Component or not.

Jirka

Re: [phpBT-dev] New optional features (request for comments)

[Ben C. <php...@be...>]

On Sat, Apr 13, 2002 at 04:01:36PM +0200, Jirka Pech wrote:
> I want to start adding new features before all the translations. Features
> needed by me, are (1) Environemnt tracking, (2) Bug closing version
> tracking, (3) External bug id tracking. I think now it's right time to
> discuss these features, I'll explain it:
> 
> (1) Environment tracking means that users will be able to track the
> environment (e.g. Beta testing, Limited production etc.) application is
> running in. I know that we have Version, but it's insufficient. Here is an
> example: Let's have one application, which is running on Testing site. The
> same application is running in separated Limited production (usually called
> 'pilot') environment. Some bugs may appear in version 1.5 only in Limited
> production environment, but these bugs will never appear on Testing site
> which has the same version, but something may be set up differently. The bug
> may appear due to stricter user rights settings or something similar, for
> example. When developers will be able to track that the bug appeared only in
> Limited production, they will have less work to track it. I hope this will
> be usefull per project option.

This does sound good, but I want to have a discussion on how we can add
other lookups like this and the database version of the phpBB guys in a
modular fashion.  How can we make it so that anyone who has something
extra they want to track in the database can just add a new table with
values (let's say phases of the moon for example) and then tie the bug
table to the phases_of_moon table?  I'm thinking of something like the
skeleton script that helps you get started writing a php extension.  It
generates the header, c, and test files that you can use as a jumping
off point for writing an extension.  Perhaps we could write a skeleton
script that creates a db-changes file (alter the bug table, create the
new lookup table, etc.).   I guess the first thing to do is have a
detailed outline of all the changes that need to be made to the code
base and database to have a new lookup, such as Environment, added and
trackable.  Let's try and do this in a modular fashion rather than just
adding more and more lookups.

> 
> (2) Bug closing version is planned to be the Version number, where the bug
> is fixed or where it will be fixed. Bug closing version may be submitted
> when the bug status is changing to Closed or Verified, I'm not sure yet. We
> will put one of next planned versions number into this field. It's similar
> to External bug id, but the Bug closing version will be selected from
> version_name field in TBL_VERSION. This is already planned into release
> 0.9.0.

The version_to_be_closed and the version_closed fields (should those be
the actual names of the new fields?) should act just like the current
version_id field.  They should be foreign keys referencing the version
table.

> 
> (3) External bug id tracking means that we will have one more varchar field
> in TBL_BUG. This (same as previous two) can be per project confuguration
> option. It's needed when you have too many people contributing and some of
> them using other bug tracking system. They need to add their bug tracking
> system's bug id to phpBugTracker and they usually want to be able to search
> by it or filter the search by it.

John put his request in the RoadMap (thanks for using it, guys!) for an 
additional project field that would store a project number or contract number.
His request is very similar to this one -- basically a free-form field that 
can store anything.  I propose we create an extra_info field that is a varchar 
or text that can be labeled anything you like in the UI.

> 
> I'll do all of these in 3 weeks and I want to start as soon as possible, so
> tell me if I'm thinking about it somehow wrong.
> Jirka Pech

[phpBT-dev] CVS: phpbt CHANGELOG,1.55,1.56

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv12114

Modified Files:
	CHANGELOG 
Log Message:


Index: CHANGELOG
===================================================================
RCS file: /cvsroot/phpbt/phpbt/CHANGELOG,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- CHANGELOG	11 Apr 2002 18:43:17 -0000	1.55
+++ CHANGELOG	13 Apr 2002 15:04:12 -0000	1.56
@@ -1,3 +1,8 @@
+-- 0.8.1 -- 13 Apr 2002
+: Fixed bugs with version and component creation.
+: Bug fixed with displaying both created date and last modified date in the bug
+  list.
+
 -- 0.8.0 -- 11 Apr 2002
 : Switched database abstraction layer to PEAR::DB.
 : Added bug dependencies.

[phpBT-dev] CVS: phpbt/templates/default/admin project-edit.html,1.6,1.7

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt/templates/default/admin
In directory usw-pr-cvs1:/tmp/cvs-serv8456/templates/default/admin

Modified Files:
	project-edit.html 
Log Message:
Let's re-fix that component creation and fix the same problem with version creation

Index: project-edit.html
===================================================================
RCS file: /cvsroot/phpbt/phpbt/templates/default/admin/project-edit.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- project-edit.html	12 Apr 2002 21:32:37 -0000	1.6
+++ project-edit.html	13 Apr 2002 14:51:57 -0000	1.7
@@ -3,16 +3,17 @@
 <script language="JavaScript">
 <!--
 	var me = '{$SCRIPT_NAME}';
+	var projectId = '{$project_id}';
 	{literal}
 		
 	function popupComponent(id) {
-		window.open(me + '?op=edit_component&use_js=1&id='+id, 'ewin', 'dependent=yes, width=450, height=300, scrollbars=auto');
-	}
-	function popupNewComponent(id) {
-		window.open(me + '?op=edit_component&use_js=1&project_id='+id+'&id=0', 'ewin', 'dependent=yes, width=450, height=300, scrollbars=auto');
+		window.open(me + '?op=edit_component&project_id='+projectId+'&use_js=1&id='+id, 'ewin', 'dependent=yes, width=450, height=300, scrollbars=auto');
+		return false;
 	}
+
 	function popupVersion(id) {
-		window.open(me + '?op=edit_version&use_js=1&id='+id, 'ewin', 'dependent=yes, width=250, height=150, scrollbars=auto');
+		window.open(me + '?op=edit_version&project_id='+projectId+'&use_js=1&id='+id, 'ewin', 'dependent=yes, width=250, height=150, scrollbars=auto');
+		return false;
 	}
 	{/literal}
 // -->
@@ -63,7 +64,7 @@
 	<tr>
 		<td width="50%" valign="top">
 			<br>
-			&nbsp;<b>Versions</b> - <a href="{$SCRIPT_NAME}?op=edit_version&id=0" onClick="popupVersion(0); return false;">{$STRING.addnew} Version</a>
+			&nbsp;<b>Versions</b> - <a href="{$SCRIPT_NAME}?op=edit_version&project_id={$project_id}&id=0" onClick="return popupVersion(0);">{$STRING.addnew} Version</a>
 			<hr size="1">
 			<table border="0" cellpadding="2" width="100%">
 				<tr>
@@ -88,7 +89,7 @@
 		</td>
 		<td width="50%" valign="top">
 			<br>
-			&nbsp;<b>Components</b> - <a href="{$SCRIPT_NAME}?op=edit_component&project_id={$project_id}&id=0" onClick="popupNewComponent({$project_id}); return false;">{$STRING.addnew} Component</a>
+			&nbsp;<b>Components</b> - <a href="{$SCRIPT_NAME}?op=edit_component&project_id={$project_id}&id=0" onClick="return popupComponent(0);">{$STRING.addnew} Component</a>
 			<hr size="1">
 			<table border="0" cellpadding="2" width="100%">
 				<tr>

[phpBT-dev] CVS: phpbt/admin project.php,1.40,1.41

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt/admin
In directory usw-pr-cvs1:/tmp/cvs-serv8456/admin

Modified Files:
	project.php 
Log Message:
Let's re-fix that component creation and fix the same problem with version creation

Index: project.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/admin/project.php,v
retrieving revision 1.40
retrieving revision 1.41
diff -u -r1.40 -r1.41
--- project.php	12 Apr 2002 21:39:19 -0000	1.40
+++ project.php	13 Apr 2002 14:51:57 -0000	1.41
@@ -65,7 +65,7 @@
 }
 
 function show_version($versionid = 0, $error = '') {
-  global $db, $t, $_pv, $STRING, $QUERY;
+  global $db, $t, $_pv, $STRING, $QUERY, $_gv;
 
 	foreach ($_pv as $k => $v) $$k = $v;
 	
@@ -75,7 +75,10 @@
 		if (!empty($_pv)) {
 		    $t->assign($_pv);
 		} else {
-		    $t->assign('active', 1);
+		    $t->assign(array(
+					'active' => 1,
+					'project_id' => $_gv['project_id']
+					));
 		}
 	}
 	$t->assign('error', $error);
@@ -128,7 +131,7 @@
 }	
 
 function show_component($componentid = 0, $error = '') {
-	global $db, $t, $_pv, $STRING, $QUERY;
+	global $db, $t, $_pv, $STRING, $QUERY, $_gv;
 	
 	if ($componentid) {
 		$t->assign($db->getRow(sprintf($QUERY['admin-show-component'], $componentid)));
@@ -136,7 +139,10 @@
 		if (!empty($_pv)) {
 		    $t->assign($_pv);
 		} else {
-		    $t->assign('active', 1);
+		    $t->assign(array(
+					'active' => 1,
+					'project_id' => $_gv['project_id']
+					));
 		}
 	}
 	$t->assign('error', $error);
@@ -295,12 +301,7 @@
 	switch($_gv['op']) {
   	case 'add' : show_project(); break;
   	case 'edit' : show_project($_gv['id']); break;
-  	case 'edit_component' :
-	    if (!$_gv['id']) {
-		$t->assign('project_id',$_gv['project_id']);
-	    }
-	    show_component($_gv['id']);
-	break;
+  	case 'edit_component' : show_component($_gv['id']);	break;
   	case 'edit_version' : show_version($_gv['id']); break;
   	case 'del_component' : del_component($_gv['id'], $_gv['project_id']); break;
   	case 'del_version' : del_version($_gv['id'], $_gv['project_id']); break;

[phpBT-dev] New optional features (request for comments)

[Jirka P. <fi...@us...>]

I want to start adding new features before all the translations. Features
needed by me, are (1) Environemnt tracking, (2) Bug closing version
tracking, (3) External bug id tracking. I think now it's right time to
discuss these features, I'll explain it:

(1) Environment tracking means that users will be able to track the
environment (e.g. Beta testing, Limited production etc.) application is
running in. I know that we have Version, but it's insufficient. Here is an
example: Let's have one application, which is running on Testing site. The
same application is running in separated Limited production (usually called
'pilot') environment. Some bugs may appear in version 1.5 only in Limited
production environment, but these bugs will never appear on Testing site
which has the same version, but something may be set up differently. The bug
may appear due to stricter user rights settings or something similar, for
example. When developers will be able to track that the bug appeared only in
Limited production, they will have less work to track it. I hope this will
be usefull per project option.

(2) Bug closing version is planned to be the Version number, where the bug
is fixed or where it will be fixed. Bug closing version may be submitted
when the bug status is changing to Closed or Verified, I'm not sure yet. We
will put one of next planned versions number into this field. It's similar
to External bug id, but the Bug closing version will be selected from
version_name field in TBL_VERSION. This is already planned into release
0.9.0.

(3) External bug id tracking means that we will have one more varchar field
in TBL_BUG. This (same as previous two) can be per project confuguration
option. It's needed when you have too many people contributing and some of
them using other bug tracking system. They need to add their bug tracking
system's bug id to phpBugTracker and they usually want to be able to search
by it or filter the search by it.

I'll do all of these in 3 weeks and I want to start as soon as possible, so
tell me if I'm thinking about it somehow wrong.
Jirka Pech

[phpBT-dev] CVS: phpbt query.php,1.70,1.71

[Jirka P. <fi...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv8480/phpbt

Modified Files:
	query.php 
Log Message:
Fixed error when enabling date fields (bug 543243). There were created_date and last_modified_date columns in two tables in the same select query and there were not uniquely identied.


Index: query.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/query.php,v
retrieving revision 1.70
retrieving revision 1.71
diff -u -r1.70 -r1.71
--- query.php	12 Apr 2002 00:32:12 -0000	1.70
+++ query.php	13 Apr 2002 12:32:17 -0000	1.71
@@ -178,9 +178,9 @@
   	'resolution_name' => 'resolution_name',
   	'reporter' => 'reporter.login as reporter',
   	'owner' => 'owner.login as owner',
-  	'created_date' => 'created_date Date',
+  	'created_date' => 'b.created_date',
   	'lastmodifier' => 'lastmodifier.login as lastmodifier',
-  	'last_modified_date' => 'last_modified_date',
+  	'last_modified_date' => 'b.last_modified_date',
   	'project_name' => 'project.project_name',
   	'version_name' => 'version.version_name',
   	'component_name' => 'component.component_name',

[phpBT-dev] CVS: phpbt/admin project.php,1.39,1.40

[Jirka P. <fi...@us...>]

Update of /cvsroot/phpbt/phpbt/admin
In directory usw-pr-cvs1:/tmp/cvs-serv7828/phpbt/admin

Modified Files:
	project.php 
Log Message:
Added one 'if branch' for project_id missing in show_component for create new component and did some code cleanup. This repairs the bug 542938.


Index: project.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/admin/project.php,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- project.php	9 Apr 2002 20:44:52 -0000	1.39
+++ project.php	12 Apr 2002 21:39:19 -0000	1.40
@@ -72,8 +72,11 @@
 	if ($versionid) {
 		$t->assign($db->getRow(sprintf($QUERY['admin-show-version'], $versionid)));
 	} else {
-		if (!empty($_pv)) $t->assign($_pv);
-		else $t->assign('active', 1);
+		if (!empty($_pv)) {
+		    $t->assign($_pv);
+		} else {
+		    $t->assign('active', 1);
+		}
 	}
 	$t->assign('error', $error);
 	$t->display('admin/version-edit.html');
@@ -130,8 +133,11 @@
 	if ($componentid) {
 		$t->assign($db->getRow(sprintf($QUERY['admin-show-component'], $componentid)));
 	} else {
-		if (!empty($_pv)) $t->assign($_pv);
-		else $t->assign('active', 1);
+		if (!empty($_pv)) {
+		    $t->assign($_pv);
+		} else {
+		    $t->assign('active', 1);
+		}
 	}
 	$t->assign('error', $error);
 	$t->display('admin/component-edit.html');
@@ -245,9 +251,11 @@
 
 		$t->display('admin/project-edit.html');
   } else {
-		if (!empty($_pv)) $t->assign($_pv);
-		else $t->assign('active', 1);
-
+		if (!empty($_pv)) {
+		    $t->assign($_pv);
+		} else {
+		    $t->assign('active', 1);
+		}
 		$t->display('admin/project-add.html');
   }
 	
@@ -287,7 +295,12 @@
 	switch($_gv['op']) {
   	case 'add' : show_project(); break;
   	case 'edit' : show_project($_gv['id']); break;
-  	case 'edit_component' : show_component($_gv['id']); break;
+  	case 'edit_component' :
+	    if (!$_gv['id']) {
+		$t->assign('project_id',$_gv['project_id']);
+	    }
+	    show_component($_gv['id']);
+	break;
   	case 'edit_version' : show_version($_gv['id']); break;
   	case 'del_component' : del_component($_gv['id'], $_gv['project_id']); break;
   	case 'del_version' : del_version($_gv['id'], $_gv['project_id']); break;

[phpBT-dev] CVS: phpbt/templates/default/admin project-edit.html,1.5,1.6

[Jirka P. <fi...@us...>]

Update of /cvsroot/phpbt/phpbt/templates/default/admin
In directory usw-pr-cvs1:/tmp/cvs-serv5404/phpbt/templates/default/admin

Modified Files:
	project-edit.html 
Log Message:
New function for empty component added. Project_id was missing in previous version and it's needed for add component to the project. This caused the buggy behaviour reported in bug 542938.


Index: project-edit.html
===================================================================
RCS file: /cvsroot/phpbt/phpbt/templates/default/admin/project-edit.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- project-edit.html	11 Apr 2002 16:08:05 -0000	1.5
+++ project-edit.html	12 Apr 2002 21:32:37 -0000	1.6
@@ -1,4 +1,4 @@
-{include file="admin/header.html" page_title="$TITLE[editproject]"}
+{include file="admin/header.html" page_title="Edit Project"}
 
 <script language="JavaScript">
 <!--
@@ -8,6 +8,9 @@
 	function popupComponent(id) {
 		window.open(me + '?op=edit_component&use_js=1&id='+id, 'ewin', 'dependent=yes, width=450, height=300, scrollbars=auto');
 	}
+	function popupNewComponent(id) {
+		window.open(me + '?op=edit_component&use_js=1&project_id='+id+'&id=0', 'ewin', 'dependent=yes, width=450, height=300, scrollbars=auto');
+	}
 	function popupVersion(id) {
 		window.open(me + '?op=edit_version&use_js=1&id='+id, 'ewin', 'dependent=yes, width=250, height=150, scrollbars=auto');
 	}
@@ -85,7 +88,7 @@
 		</td>
 		<td width="50%" valign="top">
 			<br>
-			&nbsp;<b>Components</b> - <a href="{$SCRIPT_NAME}?op=edit_component&id=0" onClick="popupComponent(0); return false;">{$STRING.addnew} Component</a>
+			&nbsp;<b>Components</b> - <a href="{$SCRIPT_NAME}?op=edit_component&project_id={$project_id}&id=0" onClick="popupNewComponent({$project_id}); return false;">{$STRING.addnew} Component</a>
 			<hr size="1">
 			<table border="0" cellpadding="2" width="100%">
 				<tr>

[phpBT-dev] CVS: phpbt TODO,1.13,1.14

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv27879

Modified Files:
	TODO 
Log Message:


Index: TODO
===================================================================
RCS file: /cvsroot/phpbt/phpbt/TODO,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- TODO	15 Dec 2001 19:17:44 -0000	1.13
+++ TODO	12 Apr 2002 15:51:17 -0000	1.14
@@ -6,4 +6,4 @@
 - Be able to color by priority instead of severity
 - Conversion script from a bugzilla database
 - Be able to change bug comments sort order (i.e., to most recent first) and be able to save a default for this setting in the config
-- Move db abstraction to adodb (?)
+- Full i18n/l10n

Re: [phpBT-dev] Road Map

[Ben C. <php...@be...>]

Oops, that url is http://phpbt.sourceforge.net/wiki/index.php?RoadMap

On Fri, Apr 12, 2002 at 06:47:33AM -0700, Ben Curtis wrote:
> As promised, I've jotted down some things I want to accomplish in the
> next version.  I tried to remember things suggested by others on the
> list, but I may have forgotten some.  If I forgot your idea, I apologize
> -- it wasn't intentional. :)  You can see my ideas at
> http://phpbt.sourceforge.net/wiki/index.php?full=RoadMap.  Since this is
> a wiki, you are more than welcome to add your comments to the page.
> Please be considerate, though, when editing ... don't clobber someone
> else's work. :)
> 
> _______________________________________________
> phpbt-dev mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpbt-dev

[phpBT-dev] Road Map

[Ben C. <php...@be...>]

As promised, I've jotted down some things I want to accomplish in the
next version.  I tried to remember things suggested by others on the
list, but I may have forgotten some.  If I forgot your idea, I apologize
-- it wasn't intentional. :)  You can see my ideas at
http://phpbt.sourceforge.net/wiki/index.php?full=RoadMap.  Since this is
a wiki, you are more than welcome to add your comments to the page.
Please be considerate, though, when editing ... don't clobber someone
else's work. :)

[phpBT-dev] CVS: phpbt/languages cz.php,1.4,1.5

[Jirka P. <fi...@us...>]

Update of /cvsroot/phpbt/phpbt/languages
In directory usw-pr-cvs1:/tmp/cvs-serv19476/phpbt/languages

Modified Files:
	cz.php 
Log Message:
Modified charset. My previous information, that it's iso was wrong. It will be better to be iso for the future, but it's now Windows-1250 encoding. Maybe I'll modify whole file to iso-8859-2 later.


Index: cz.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/languages/cz.php,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- cz.php	11 Apr 2002 17:37:24 -0000	1.4
+++ cz.php	12 Apr 2002 13:48:17 -0000	1.5
@@ -23,7 +23,7 @@
 // $Id$
 
 $STRING = array(
-	'lang_charset' => 'iso-8859-2',
+	'lang_charset' => 'Windows-1250',
 	'nouser' => 'Tento uživatel neexistuje',
 	'dupeofself' => 'BUG nemùže být shodný se sám se sebou',
 	'nobug' => 'Tento BUG neexistuje',

[phpBT-dev] CVS: phpbt/admin user.php,1.47,1.48

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt/admin
In directory usw-pr-cvs1:/tmp/cvs-serv20229/admin

Modified Files:
	user.php 
Log Message:
Fixes bug 542937 - not quoting email address on user create

Index: user.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/admin/user.php,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -r1.47 -r1.48
--- user.php	9 Apr 2002 20:44:52 -0000	1.47
+++ user.php	12 Apr 2002 12:01:22 -0000	1.48
@@ -61,7 +61,7 @@
 			values (".join(', ', array($new_user_id, 
 				$db->quote(stripslashes($_pv['first_name'])), 
 				$db->quote(stripslashes($_pv['last_name'])),
-				$db->quote(stripslashes($login)), $_pv['email'], $mpassword, 
+				$db->quote(stripslashes($login)), $db->quote($_pv['email']), $mpassword, 
 				$_pv['active'], $u, $now, $u, $now)).')');
 		// Add to the selected groups
 		if (isset($_pv['fusergroup']) and is_array($_pv['fusergroup']) and

[phpBT-dev] CVS: phpbt bug.php,1.97,1.98

[Benjamin C. <bc...@us...>]

Update of /cvsroot/phpbt/phpbt
In directory usw-pr-cvs1:/tmp/cvs-serv19345

Modified Files:
	bug.php 
Log Message:
Fix a bug with stickiness of limit query

Index: bug.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/bug.php,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- bug.php	10 Apr 2002 15:26:35 -0000	1.97
+++ bug.php	12 Apr 2002 00:32:48 -0000	1.98
@@ -493,8 +493,12 @@
 ///
 /// Grab the links for the previous and next bugs in the list
 function prev_next_links($bugid, $pos) {
-	global $db, $_sv, $QUERY, $t;
+	global $dsn, $_sv, $QUERY, $t;
 	
+	// Create a new db connection because of the limit query affecting later queries
+	$db = DB::Connect($dsn); 
+	$db->setOption('optimize', 'portability');
+
 	if (!isset($_sv['queryinfo']['query']) || !$_sv['queryinfo']['query']) {
 		return array('', '');
 	}
@@ -510,8 +514,8 @@
 		$_sv['queryinfo']['query'], $bugid, $_sv['queryinfo']['order'], 
 		$_sv['queryinfo']['sort']), $offset, $limit);
 		
-	list($firstid, $chunks) = $rs->fetchRow(DB_FETCHMODE_ORDERED);
-	list($secondid, $chunks) = $rs->fetchRow(DB_FETCHMODE_ORDERED);
+	list($firstid, $chunks) = $rs->fetchRow();
+	list($secondid, $chunks) = $rs->fetchRow();
 	
 	if ($pos) {
 		if ($firstid) {