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

[phpBT-dev] Re: Unable to get 1.0RC5 to work

[Ulf E. <ulf...@fa...>]

 From the "Open Discussion":
http://sourceforge.net/forum/forum.php?thread_id=1217828&forum_id=47357

	"Fatal error: Call to a member function on a non-object in
	/local/www/html/phpbt-1.0rc5/inc/functions.php on line 40"


Ben,

Look at include.php: You first set handle_db_error() to handle any 
database errors, then you query for the configuration variables, and 
finally create the $t object. Clearly show_text() can be called before 
$t exists in this case. I'd suggest the attached patch to at least get a 
meaningful error message.

-- 
Ulf

Re: [phpBT-dev] PHP5 and MySQL 4.1

[Ulf E. <ulf...@fa...>]

* Benjamin Curtis [2005-02-24 16:21]:
> 
> Ulf Erikson wrote:

>>Do you mind if I suggest more blockers? ;-) The earlier security issue
>>should probably be revisited once more, and considering the speed of
>>development it would probably be a very good idea to make sure that both
>>php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0.
>>
> 
> 
> Heh, sure, more blockers are always fun.  Yes, the security issues need
> to be reviewed again, and I can vote for PHP5 support.  I'm not sure
> about MySQL 4.1, though, as I had some problems with it combined with
> transaction support while trying to use adodb.  Of course, I probably
> just didn't spend enough time on it to nail down the exact problem. :)

This is the only issue I have had with PHP5:
http://sourceforge.net/mailarchive/forum.php?thread_id=6535282&forum_id=4570

Basically get_class() no longer returns a string with only lowercase 
characters. Simply use DB::isError in your own code, and make sure to 
update PEAR to have a functional isError. (the one i tried used is_a(), 
but that function still couldn't handle it) If nothing else helps, how 
about renaming all "DB_Error" to "db_error" such that all old tests 
still work?

What problems do you think phpBugTracker will have with MySQL 4.1? (and 
how is ADOdb related?) I assumed that using myqsli.php instead of 
mysql.php would take care of all API changes. The big bulk of old 
queries must still be valid. or.. ?

-- 
Ulf

Re: [phpBT-dev] User Permission Levels

[Ulf E. <ulf...@fa...>]

* Benjamin Curtis [2005-02-24 16:21]:
> 
> Ulf Erikson wrote:
> 
>>* Benjamin Curtis [2005-02-15 15:06]:
>>
>>
>>>basically, users could change roles per bug, but they could have a
>>>different set of permissions by virtue of their group memberships on a
>>>more general basis (users in the QA group would always have CloseBug
>>>permission, regardless of reporter/owner/witness role).
>>
>>
>>Hmm.. I must have missed this earlier. Do you mean that you would like
>>to difference EditStatus in permission to close a bug or not?
>>
>>How about other enforcements on what Statuses and Resolutions one can
>>chose depending on the current status? That would finally lead to
>>something similar to the WorkFlow:
>>http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939
>>
>>
> 
> 
> You know, I'm not sure that I realized the full meaning of what I was
> typing until your reply, but yeah, we certainly could do a permission
> per status.  That would go quite a bit of the way towards workflow
> customization.

This quickly grows beyond what I have done.. any chance that you one day 
can help with sketching on what tables and fields to use and how it all 
ought to be connected? (i assume this will be hard to squeeze into the 
current structure, but maybe i am wrong)

-- 
Ulf

Re: [phpBT-dev] User Permission Levels

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

Ulf Erikson wrote:
> * Benjamin Curtis [2005-02-15 15:06]:
> 
>> basically, users could change roles per bug, but they could have a
>> different set of permissions by virtue of their group memberships on a
>> more general basis (users in the QA group would always have CloseBug
>> permission, regardless of reporter/owner/witness role).
> 
> 
> Hmm.. I must have missed this earlier. Do you mean that you would like
> to difference EditStatus in permission to close a bug or not?
> 
> How about other enforcements on what Statuses and Resolutions one can
> chose depending on the current status? That would finally lead to
> something similar to the WorkFlow:
> http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939
> 
> 

You know, I'm not sure that I realized the full meaning of what I was
typing until your reply, but yeah, we certainly could do a permission
per status.  That would go quite a bit of the way towards workflow
customization.

> There are also requests on keeping comments and/or whole bugs restricted
> to people with the right permissions:
> http://sourceforge.net/tracker/index.php?func=detail&aid=626884&group_id=14939&atid=364939
> 
> 
>>> New user can set another reporter for bug
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939
>>
>>
>>
>> This set another reporter bug is one that I'd really like to fix
>> before 1.0, but I haven't put enough thought yet into what is the best
>> approach.
> 
> 
> Do you mind if I suggest more blockers? ;-) The earlier security issue
> should probably be revisited once more, and considering the speed of
> development it would probably be a very good idea to make sure that both
> php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0.
> 

Heh, sure, more blockers are always fun.  Yes, the security issues need
to be reviewed again, and I can vote for PHP5 support.  I'm not sure
about MySQL 4.1, though, as I had some problems with it combined with
transaction support while trying to use adodb.  Of course, I probably
just didn't spend enough time on it to nail down the exact problem. :)

Re: [phpBT-dev] Bug reports via script

[Ulf E. <ulf...@fa...>]

* Ulf Erikson [2005-02-20 19:47]:
> Are the security issues mentioned earlier really fixed?
> http://sourceforge.net/mailarchive/forum.php?thread_id=4376593&forum_id=3188 
> 
> The patch I find that adresses this is:
> http://cvs.sourceforge.net/viewcvs.py/phpbt/phpbt/bug.php?view=log#rev1.134.2.3 
> 
> It seems to checks that bugid is an integer and it quotes a few SQL 
> queries. Still everything in inc/db/*.php are unquoted queries. My 
> feeling is that one can still issue SQL queries from remote by sending 
> faked forms. (simply adding commands to the URL by hand or using scripts 
> like these instead of using the intended web-form)

Sorry. The inc/db/*.php thing is probably not that bad. There are some 
quotes and you do quote strings by db->quote() and cast text that should 
be numbers to int when using queries out the $QUERY array. If nothing is 
missed that should be good enough (as far as i understand it)

Re: [phpBT-dev] Bug reports via script

[Ulf E. <ulf...@fa...>]

* Ulf Erikson [2005-02-17 23:26]:
> The easiest way I know to access web-sites from the command line is by 
> using cURL. There should be bindings to cURL-lib from languages such as 
> python and perl. Attached is a small bash script to show how easy it is 
> to report and comment on bugs this way.

Here is a similar script using Perl::LWP. Making this script insert bugs 
from a CSV should be pretty easy. (only real problem will be that so 
much has to be integers..)

> I've got another question: When I post changes this way, not using the 
> web-forms, do all restrictions still apply? What about safe-guarding 
> against bad data? Some invalid values seem to make a bug invisible..

Are the security issues mentioned earlier really fixed?
http://sourceforge.net/mailarchive/forum.php?thread_id=4376593&forum_id=3188

The patch I find that adresses this is:
http://cvs.sourceforge.net/viewcvs.py/phpbt/phpbt/bug.php?view=log#rev1.134.2.3

It seems to checks that bugid is an integer and it quotes a few SQL 
queries. Still everything in inc/db/*.php are unquoted queries. My 
feeling is that one can still issue SQL queries from remote by sending 
faked forms. (simply adding commands to the URL by hand or using scripts 
like these instead of using the intended web-form)

-- 
Ulf

Re: [phpBT-dev] User Permission Levels

[Ulf E. <ulf...@fa...>]

* Benjamin Curtis [2005-02-15 15:06]:
> basically, users could change roles per bug, but they could have a 
> different set of permissions by virtue of their group memberships on a 
> more general basis (users in the QA group would always have CloseBug 
> permission, regardless of reporter/owner/witness role).

Hmm.. I must have missed this earlier. Do you mean that you would like 
to difference EditStatus in permission to close a bug or not?

How about other enforcements on what Statuses and Resolutions one can 
chose depending on the current status? That would finally lead to 
something similar to the WorkFlow:
http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939

There are also requests on keeping comments and/or whole bugs restricted 
to people with the right permissions:
http://sourceforge.net/tracker/index.php?func=detail&aid=626884&group_id=14939&atid=364939

>> New user can set another reporter for bug
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 
> 
> This set another reporter bug is one that I'd really like to fix before 
> 1.0, but I haven't put enough thought yet into what is the best approach.

Do you mind if I suggest more blockers? ;-) The earlier security issue 
should probably be revisited once more, and considering the speed of 
development it would probably be a very good idea to make sure that both 
php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0.

-- 
Ulf

[phpBT-dev] Bug reports via script

[Ulf E. <ulf...@fa...>]

Hoi,

The project TODO mentions both Create bugs via email and Conversion 
script from a bugzilla database. I think these two tasks can share a 
common back-end. Write different front-ends to receive data via 
procmail, SQL queries, or a user created CSV file, and have them all 
insert the data into phpBugTracker using the same back-end.

There is already a tool in the contrib directory that can insert GNATS 
reports into phpBugTracker, but unfortunately it is hardcoded to use 
MySQL only. Will it be rewritten in a database independent manner one 
day? and at the same time split in two: a gnats front-end and a phpbt 
back-end.

When accessing the database directly you will have to duplicate the 
logics to send out bug mails. At least, I would expect to receive a mail 
telling me the new state of a bug after it has been altered via e-mail.

The easiest way I know to access web-sites from the command line is by 
using cURL. There should be bindings to cURL-lib from languages such as 
python and perl. Attached is a small bash script to show how easy it is 
to report and comment on bugs this way.

What's needed is being able to accept all parameters on the command 
line, URL encoding of summary and comments, and so on, and so on.. Lots 
of parts are missing still to make it useful.

An observation is how you change most of the field names from one form 
to the other. It would be less troubles writing a script if the same 
name was used for the same field all the time..

I've got another question: When I post changes this way, not using the 
web-forms, do all restrictions still apply? What about safe-guarding 
against bad data? Some invalid values seem to make a bug invisible..

-- 
Ulf

Re: [phpBT-dev] User Permission Levels

[Ulf E. <ulf...@fa...>]

* Benjamin Curtis [2005-02-15 15:06]:
> Ulf Erikson wrote:
>> I have implemented different permissions for users and developers when 
>> they are the reporter/owner of a bug and not. For instance, ...

> This works for me, except the priority part.  Very often a reporter 
> might want to change the priority of a bug (in organizations where the 
> developer doesn't have as much determination about which bugs get 
> addressed first).

True. I doubt there is a single set of rules that will satisfy everyone. 
That's why editable permission would be a nice inclusion ;-)

> Perhaps we could have a list of permissions assigned 
> to roles (in addition to -- or maybe in replacement of -- groups).  That 
> way you could have a reporter role, and an owner role, and a 
> "third-party" role, and each of these could be assigned particular 
> permissions (like EditAssignemt, EditPriority, etc.) as desired.  So, 

I would prefer "in addition to" and not "in replacement of" the current 
group permission scheme. The third-party permissions should be more 
strict for users than for project leaders, for instance. (or it should 
at least be possible to set them so)

> basically, users could change roles per bug, but they could have a 
> different set of permissions by virtue of their group memberships on a 
> more general basis (users in the QA group would always have CloseBug 
> permission, regardless of reporter/owner/witness role).  We'd have to 
> decide how to handle conflicts between group permissions and role 
> permissions. :)

How about this thought: Your current group permissions determine what 
you may or not may as a third-part. Being the reporter or bug-owner you 
can only be granted more rights. A few extra bits might be needed to 
specify the roles..

There is also the TBL_USER_PERM. It's not used at all? Have about adding 
an add/remove bit and let that table add or remove a single permission 
to a single user regardless of role? (now we are probably down to too 
low-level fine tuning)

>> What kind of user levels would you like to have? By what granularity? 
>> How would you like to be able to configure this (I'm thinking of my 
>> earlier group permission editor, but that wouldn't scale too well with 
>> an increasing number of permission flags..)? The more ideas the 
>> better. The more detailed descriptions on how to operate this the more 
>> likely that it might happen..
> 
> I haven't had a chance to apply your permission editor patch, so I don't 
> know what the UI is, but I could see a page with each Role or Group 
> listed, beneath each being a grid of checkboxes with the permission 
> names as labels.

Yes. That's what I thought of as non-scalable. But maybe the number of 
roles and fields low enough to not be a problem..

Talking about granularity in permission you have also reports in the 
tracker that talk about disallow users to change the password of guest 
accounts, or to even visit the personal page. And how about an Anonymous 
user to tell the permission for not logged-in visitors?

>> Here are some of the reports I have found that seem related.

>> Non-editable fields when not logged in
> 
> The "Non-editable fields" one is fixed with JavaScript warning a user 
> about not making changes when not logged in.  I don't know that this one 
> is very permission related.

Oops. Sorry. I didn't mean to include closed bugs.

What I do, and hope to convince you to, is use real non-editable fields. 
Like what you do for the EditAssignment. That's why I added some extra 
parameters for 'lookup'. ;-)

A similar idea is to give extra fields such as assigned-to, to people 
with the right permissions (EditAssignment), already when the bug is 
reported. Let the forms be a bit dynamic met the role.

>> New user can set another reporter for bug
> 
> This set another reporter bug is one that I'd really like to fix before 
> 1.0, but I haven't put enough thought yet into what is the best approach.

How about an "EditReporter" bit that only project managers have set?

-- 
Ulf

Re: [phpBT-dev] Comments and thoughts

[Ulf E. <ulf...@fa...>]

* Benjamin Curtis [2005-02-15 14:51]:
> Heh, consistency on the permission stuff would be nice, wouldn't it?  :) 
> It's been such a long time since I looked at the permission stuff -- 
> your email made me go a look at it, and there is some code rot in there 
> indeed.  I think the intent was (and the implementation should be 
> something like) to have have_* functions return a boolean so the calling 
> code can decide what to (presumably non-fatal) and have the check_* 
> functions display the error and stop execution.  I believe the others 
> were intended to be private functions, but again, that was a long time 
> ago now.  I'll be happy to review the permission stuff to try to make it 
> more logical.

That sounds like a good plan. All have_* returns a boolean, all check_* 
stop execution with an error, and everything else is kept internal. 
Another thing, the have_* and the check_* should come in pairs such that 
the same * is used for the same sort of permission. That would make it 
clear enough.

> I had intended the Admin bit to override all others, so that Admins 
> would be able to do anything regardless of whether they had the specific 
> permissions.

Yes. The "Admin" bit works. You check for other bits at a few places: 
Administrator, Manager and Users. None of them exists, but the Admin bit 
grants, of course, permission.

> I think I made a commit recently that reduces the significance of the 
> User group.  I'll poke at that as well and take a look at the admin 
> error template.

The name 'User' is also used in one or another SQL query. I think the 
user editor had some troubles there when I didn't force all to be 
members of the User group.

-- 
Ulf

[phpBT-dev] CVS: phpbt/styles default.css,1.5,1.6

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

Update of /cvsroot/phpbt/phpbt/styles
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29532/styles

Modified Files:
	default.css 
Log Message:
Modified patch from Ulf Erikson - Highlight bug rows on hover (clickable too).  Fails to work in non-standards-compliant browsers (IE)

Index: default.css
===================================================================
RCS file: /cvsroot/phpbt/phpbt/styles/default.css,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- default.css	25 Oct 2004 12:07:02 -0000	1.5
+++ default.css	16 Feb 2005 13:53:40 -0000	1.6
@@ -21,6 +21,11 @@
 	background: #dddddd;
 	}
 	
+tr.bugrow:hover {
+	background: #ccffcc;
+	cursor: pointer;
+}	
+	
 th { 
 	font-family: "Arial","Helvetica","MS Sans Serif","Sans-Serif"; 
 	font-size: 12px;

[phpBT-dev] CVS: phpbt/templates/default buglist.html,1.9,1.10

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

Update of /cvsroot/phpbt/phpbt/templates/default
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv29532/templates/default

Modified Files:
	buglist.html 
Log Message:
Modified patch from Ulf Erikson - Highlight bug rows on hover (clickable too).  Fails to work in non-standards-compliant browsers (IE)

Index: buglist.html
===================================================================
RCS file: /cvsroot/phpbt/phpbt/templates/default/buglist.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- buglist.html	25 Oct 2004 12:07:04 -0000	1.9
+++ buglist.html	16 Feb 2005 13:53:40 -0000	1.10
@@ -1,3 +1,8 @@
+<script language='javascript'>
+   function viewbug(a,b) {
+	  self.location.href='bug.php?op=show&bugid='+a+'&pos='+b;
+   }
+</script>
 <table class="bordertable" align="center" style="width: 100%">
 	<tr>
 		<?php for ($i = 0, $colcount = count($db_fields); $i < $colcount; $i++) { 
@@ -10,12 +15,11 @@
 		</td>
 	<?php } else { ?>
 		<?php for ($i = 0; $i < $bugcount; $i++) { ?>
-			<tr<?php if ($i % 2 != 0) echo ' class="alt" bgcolor="#dddddd"'; ?>>
+			<tr class="bugrow<?php echo ($i % 2 != 0) ? ' alt' : ''; ?>"<?php echo  USE_SEVERITY_COLOR ? ' bgcolor="'.$bugs[$i]['severity_color'].'"' : ''; ?> onclick="<?php echo "viewbug({$bugs[$i]['bug_link_id']}, $i)"; ?>">
 				<?php 
 					foreach ($bugs[$i] as $var => $val) {
 						if ($var == 'bug_link_id') $bugid = $val;
-						elseif ($var == 'severity_color') $bgcolor = $val;
-						else echo '<td '.(USE_SEVERITY_COLOR ? "bgcolor='$bgcolor'" : '').'>'.format_bug_col($val, $var, $bugid, $i).'</td>';
+						elseif ($var != 'severity_color') echo '<td>'.format_bug_col($val, $var, $bugid, $i).'</td>';
 					}
 				?>
 			</tr>

[phpBT-dev] Re: [Phpbt-users] RFE 759250: Table Driven Priorities.

[Ulf E. <ulf...@fa...>]

Hoi,

Hmm.. I had forgotten to include an update for bugform.html. The name of 
the priority field, and the variable, must be changed to priority_id. 
Without that all new bugs get a priority of 0 (zero).

This patch includes the missing hunk and extends the earlier patch to 
also allow colouring on priority instead of severity (as suggested in 
the TODO file).

Maybe two single bit entries (USE_SEVERITY_COLOR and USE_PRIORITY_COLOR) 
is not the cleanest way to do this. Suggestions? How about making this a 
user option instead of a system configuration?

/Ulf

* Ulf Erikson [2005-02-07 20:11]:
> Feature Request 759250 (Table Driven Priorities.) points out one of the 
> few odd design flaws of phpBT.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=759250&group_id=14939&atid=364939 

[phpBT-dev] Re: [Phpbt-users] RFE 784058: shown number of posts in bug lists

[Ulf E. <ulf...@fa...>]

Hoi,

This update of the earlier patch can (optionally) show the number of 
attachments in the bug list as well.

/Ulf

* Ulf Erikson [2005-02-07 20:08]:
> I found Feature Request 784058 (shown number of posts in bug lists) in 
> the SourceForge trackers.
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=784058&group_id=14939&atid=364939 
> 
> 
> I had a wish to see the number of votes in the list myself, and since 
> number of comments is almost the same.. Attached is a patch to add 
> number of comments or number of votes to the query list (from your 
> personal page). The patch, in its current state, only works for MySQL

Re: [phpBT-dev] User Permission Levels

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

Ulf Erikson wrote:
> Hoi,
> 
> I have implemented different permissions for users and developers when 
> they are the reporter/owner of a bug and not. For instance, I allow 
> comments from anyone who is logged in. Managers and project leaders may 
> change almost everything at any time, users and developers only when 
> they are reporter or owner of a bug. The severity is for the reporter 
> only and the priority is for the owner only. (BTW, I have split your 
> severity into report type and severity)

This works for me, except the priority part.  Very often a reporter 
might want to change the priority of a bug (in organizations where the 
developer doesn't have as much determination about which bugs get 
addressed first).  Perhaps we could have a list of permissions assigned 
to roles (in addition to -- or maybe in replacement of -- groups).  That 
way you could have a reporter role, and an owner role, and a 
"third-party" role, and each of these could be assigned particular 
permissions (like EditAssignemt, EditPriority, etc.) as desired.  So, 
basically, users could change roles per bug, but they could have a 
different set of permissions by virtue of their group memberships on a 
more general basis (users in the QA group would always have CloseBug 
permission, regardless of reporter/owner/witness role).  We'd have to 
decide how to handle conflicts between group permissions and role 
permissions. :)

> 
> Now, there is a huge number of requests for all sorts of permission 
> levels in the trackers. My implementation is good enough for me, but the 
> way the new rules are enforced wouldn't attract everyone. I would be 
> willing to try make my implementation general enough to satisfy other 
> peoples needs as well, *if* there can be some discussion on what people 
> actually want and how this can be achieved. The current silence isn't 
> very encouraging..
> 
> What kind of user levels would you like to have? By what granularity? 
> How would you like to be able to configure this (I'm thinking of my 
> earlier group permission editor, but that wouldn't scale too well with 
> an increasing number of permission flags..)? The more ideas the better. 
> The more detailed descriptions on how to operate this the more likely 
> that it might happen..

I haven't had a chance to apply your permission editor patch, so I don't 
know what the UI is, but I could see a page with each Role or Group 
listed, beneath each being a grid of checkboxes with the permission 
names as labels.

> 
> Here are some of the reports I have found that seem related. If you know 
> more please post those links as well. It should be possible to find a 
> solution general enough to be applied to all/most of these issues. 
> Anyone willing to help find it?
> 
> 
> User Permission Levels
> http://sourceforge.net/tracker/index.php?func=detail&aid=829858&group_id=14939&atid=364939 
> 
> 
> Project Admin cannot change assignments
> http://sourceforge.net/tracker/index.php?func=detail&aid=1060247&group_id=14939&atid=114939 
> 
> 
> Managers Cannot Change Bug Details
> http://sourceforge.net/tracker/index.php?func=detail&aid=1017788&group_id=14939&atid=114939 
> 
> 
> Stricter editing ?
> http://sourceforge.net/tracker/index.php?func=detail&aid=618641&group_id=14939&atid=364939 
> 
> 
> Guest login
> http://sourceforge.net/tracker/index.php?func=detail&aid=579407&group_id=14939&atid=364939 
> 
> 
> Non-editable fields when not logged in
> http://sourceforge.net/tracker/index.php?func=detail&aid=579849&group_id=14939&atid=364939 
> 

The "Non-editable fields" one is fixed with JavaScript warning a user 
about not making changes when not logged in.  I don't know that this one 
is very permission related.

> 
> New user can set another reporter for bug
> http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 
> 

This set another reporter bug is one that I'd really like to fix before 
1.0, but I haven't put enough thought yet into what is the best approach.

> 
> How to restrain task assignment only to users at admin group
> http://sourceforge.net/tracker/index.php?func=detail&aid=782962&group_id=14939&atid=114939 
> 
> 

Re: [phpBT-dev] Comments and thoughts

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

Heh, consistency on the permission stuff would be nice, wouldn't it?  :) 
It's been such a long time since I looked at the permission stuff -- 
your email made me go a look at it, and there is some code rot in there 
indeed.  I think the intent was (and the implementation should be 
something like) to have have_* functions return a boolean so the calling 
code can decide what to (presumably non-fatal) and have the check_* 
functions display the error and stop execution.  I believe the others 
were intended to be private functions, but again, that was a long time 
ago now.  I'll be happy to review the permission stuff to try to make it 
more logical.

I had intended the Admin bit to override all others, so that Admins 
would be able to do anything regardless of whether they had the specific 
permissions.

I think I made a commit recently that reduces the significance of the 
User group.  I'll poke at that as well and take a look at the admin 
error template.

Ulf Erikson wrote:
> Hoi Ben,
> 
> I have gather a few thoughts and comments from the last week..
> 
> Permission is checked in several different ways:
>   $perm->have_*, $perm->is_*, $perm->in_*, $perm->check_*
> The check_* functions often, but not always, show an error page if the 
> permission is not granted. The other functions return a boolean. Will 
> you please take a look at this and make it more consistent to make 
> things easier to understand?
> 
> The permission bits checked for are not always the correct ones:
>   Manager, Administrator, Users
> Since the "Admin" bit automatically grants permission to everything are 
> those functions still available. Please check again what requirements 
> you had intended at those points.
> 
> The User group is somewhat "magic". Everyone is included be default, and 
> it never shows up in the administrator tools. Could this (that it 
> doesn't show up) please be changed? It "breaks" the group editor 
> somewhat that the User group is missing, and since a Developer has all 
> permissions a User has is there no need to be member of both..
> 
>  From admin/user.php:
>     // Get user's groups (without dropping the user group)
>     $user_groups = $db->getCol(sprintf($QUERY['admin-user-groups'], 
> $userid));
> but 'admin-user-group' DOES drop the user group. It shouldn't. (i think 
> things went wrong when not everyone is a "User", or maybe even before)
> 
> There is no error.html in the templates/admin/ directory. This is needed 
> when/if something goes wrong with the database queries (which it at 
> least does when i play with trial-and-error). Could this please be added?
> 

[phpBT-dev] CVS: phpbt/languages es.php,1.9,1.10

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

Update of /cvsroot/phpbt/phpbt/languages
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2321/languages

Modified Files:
	es.php 
Log Message:
Trying to resolve some charset issues

Index: es.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/languages/es.php,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- es.php	5 Dec 2004 16:12:02 -0000	1.9
+++ es.php	15 Feb 2005 13:34:21 -0000	1.10
@@ -1,7 +1,7 @@
 <?php
 
 $STRING = array (
-  'lang_charset' => 'iso8859-1',
+  'charset' => 'iso8859-1',
   'That user does not exist' => 'Ese usuario no existe',
   'A bug can\'t be a duplicate of itself' => 'Un bug no puede ser un duplicado de si mismo',
   'That bug does not exist' => 'Ese bug no existe',

[phpBT-dev] CVS: phpbt/inc functions.php,1.48,1.49

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

Update of /cvsroot/phpbt/phpbt/inc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2321/inc

Modified Files:
	functions.php 
Log Message:
Trying to resolve some charset issues

Index: functions.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/inc/functions.php,v
retrieving revision 1.48
retrieving revision 1.49
diff -u -r1.48 -r1.49
--- functions.php	22 Jan 2005 16:13:18 -0000	1.48
+++ functions.php	15 Feb 2005 13:34:20 -0000	1.49
@@ -591,12 +591,11 @@
 		$headers .= "\n";
 		// There have to be no newline at the end of $headers
 	}
-	$charset = !empty($STRING['lang_charset']) ? 
-		$STRING['lang_charset'] : 'iso-8859-1';
+	
 	if (false/*HTML_EMAIL*/) {
-		$headers .= "Content-Type: text/html; charset=\"$charset\"\r\nContent-Transfer-Encoding: ";
+		$headers .= "Content-Type: text/html; charset=\"".CHARSET."\"\r\nContent-Transfer-Encoding: ";
 	} else {
-		$headers .= "Content-Type: text/plain; charset=\"$charset\"\r\nContent-Transfer-Encoding: ";
+		$headers .= "Content-Type: text/plain; charset=\"".CHARSET."\"\r\nContent-Transfer-Encoding: ";
 	}
 
 	// If configured to send MIME encoded emails
@@ -618,7 +617,6 @@
 	if (USE_GETTEXT) {
 		return $plural ? ngettext($string) : gettext($string);
 	} else {
-		@include_once('languages/'.LANGUAGE.'.php');
 		if (!empty($STRING[$string])) return $STRING[$string];
 		else return $string;
 	}

[phpBT-dev] CVS: phpbt include.php,1.129,1.130

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

Update of /cvsroot/phpbt/phpbt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2321

Modified Files:
	include.php 
Log Message:
Trying to resolve some charset issues

Index: include.php
===================================================================
RCS file: /cvsroot/phpbt/phpbt/include.php,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -r1.129 -r1.130
--- include.php	5 Dec 2004 17:01:32 -0000	1.129
+++ include.php	15 Feb 2005 13:34:19 -0000	1.130
@@ -64,6 +64,17 @@
 	}
 	define('OPEN_BUG_STATUSES', join(', ', 
 		$db->getCol("select status_id from " . TBL_STATUS ." where bug_open = 1")));
+	
+	// Set up translation and character set
+	@include_once('languages/'.LANGUAGE.'.php');
+	if (!defined('CHARSET')) {
+		if (!empty($STRING['charset'])) {
+			define('CHARSET', $STRING['charset']);
+		} else {
+			define('CHARSET', 'utf-8');
+		}
+	}
+
 }
 require_once ('inc/db/'.DB_TYPE.'.php');
 

[phpBT-dev] User Permission Levels

[Ulf E. <ulf...@fa...>]

Hoi,

I have implemented different permissions for users and developers when 
they are the reporter/owner of a bug and not. For instance, I allow 
comments from anyone who is logged in. Managers and project leaders may 
change almost everything at any time, users and developers only when 
they are reporter or owner of a bug. The severity is for the reporter 
only and the priority is for the owner only. (BTW, I have split your 
severity into report type and severity)

Now, there is a huge number of requests for all sorts of permission 
levels in the trackers. My implementation is good enough for me, but the 
way the new rules are enforced wouldn't attract everyone. I would be 
willing to try make my implementation general enough to satisfy other 
peoples needs as well, *if* there can be some discussion on what people 
actually want and how this can be achieved. The current silence isn't 
very encouraging..

What kind of user levels would you like to have? By what granularity? 
How would you like to be able to configure this (I'm thinking of my 
earlier group permission editor, but that wouldn't scale too well with 
an increasing number of permission flags..)? The more ideas the better. 
The more detailed descriptions on how to operate this the more likely 
that it might happen..

Here are some of the reports I have found that seem related. If you know 
more please post those links as well. It should be possible to find a 
solution general enough to be applied to all/most of these issues. 
Anyone willing to help find it?


User Permission Levels
http://sourceforge.net/tracker/index.php?func=detail&aid=829858&group_id=14939&atid=364939

Project Admin cannot change assignments
http://sourceforge.net/tracker/index.php?func=detail&aid=1060247&group_id=14939&atid=114939

Managers Cannot Change Bug Details
http://sourceforge.net/tracker/index.php?func=detail&aid=1017788&group_id=14939&atid=114939

Stricter editing ?
http://sourceforge.net/tracker/index.php?func=detail&aid=618641&group_id=14939&atid=364939

Guest login
http://sourceforge.net/tracker/index.php?func=detail&aid=579407&group_id=14939&atid=364939

Non-editable fields when not logged in
http://sourceforge.net/tracker/index.php?func=detail&aid=579849&group_id=14939&atid=364939

New user can set another reporter for bug
http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939

How to restrain task assignment only to users at admin group
http://sourceforge.net/tracker/index.php?func=detail&aid=782962&group_id=14939&atid=114939

Re: [phpBT-dev] [PATCH] minor change to installer

[Ulf E. <ulf...@fa...>]

* Ulf Erikson [2005-02-08 21:45]:
> I had some troubles on a server where the installer always reported 
> success on "test database connection". It turned out 'db_error' was 
> defined 'DB_Error'. Is this a known issue/bug for one or another version 
> of MySQL and/or php? Anyway, this patch use DB::isError for error 
> checking and patches isError to handle both cases..

This is due to php5. It seems that 'get_class()' no longer guarantees 
lowercase answers. Since PEAR itself fails to detect errors you get 
rather unpredictable results.. Newer versions of PEAR should fix this. 
Will you please upgrade before the next release candidate?

When trying to use the latest version of PEAR/DB I found that there is 
no PEAR_PATH used. Adding a PEAR_PATH for each include/require (such 
that they look like the included PEAR distro) it all works nicely again.


Next issue will be MySQL 4.1. You need to use mysqli.php instead of 
mysql.php from that version. Do you plan to support it in the release? 
That would require some testing..

-- 
Ulf

[phpBT-dev] Comments and thoughts

[Ulf E. <ulf...@fa...>]

Hoi Ben,

I have gather a few thoughts and comments from the last week..

Permission is checked in several different ways:
   $perm->have_*, $perm->is_*, $perm->in_*, $perm->check_*
The check_* functions often, but not always, show an error page if the 
permission is not granted. The other functions return a boolean. Will 
you please take a look at this and make it more consistent to make 
things easier to understand?

The permission bits checked for are not always the correct ones:
   Manager, Administrator, Users
Since the "Admin" bit automatically grants permission to everything are 
those functions still available. Please check again what requirements 
you had intended at those points.

The User group is somewhat "magic". Everyone is included be default, and 
it never shows up in the administrator tools. Could this (that it 
doesn't show up) please be changed? It "breaks" the group editor 
somewhat that the User group is missing, and since a Developer has all 
permissions a User has is there no need to be member of both..

 From admin/user.php:
	// Get user's groups (without dropping the user group)
	$user_groups = $db->getCol(sprintf($QUERY['admin-user-groups'], $userid));
but 'admin-user-group' DOES drop the user group. It shouldn't. (i think 
things went wrong when not everyone is a "User", or maybe even before)

There is no error.html in the templates/admin/ directory. This is needed 
when/if something goes wrong with the database queries (which it at 
least does when i play with trial-and-error). Could this please be added?

-- 
Ulf

[phpBT-dev] [PATCH] selectable group filters

[Ulf E. <ulf...@fa...>]

Hoi,

This patch introduces a group filter in the user list. Choose what group 
to show the active/inactive users of.

-- 
Ulf

[phpBT-dev] [PATCH] Editable group perms

[Ulf E. <ulf...@fa...>]

Hoi,

This patch allows administrators to edit the permission bits for created 
groups by point-and-click.

-- 
Ulf

[phpBT-dev] [PATCH] Move assignable bit to TBL_AUTH_PERM

[Ulf E. <ulf...@fa...>]

Hoi,

This patch removes the hardcoded "assignable" bit from TBL_AUTH_GROUP 
and instead adds a new entry in TBL_AUTH_PERM named "Assignable".

-- 
Ulf