From louie at ximian.com Thu Apr 1 15:37:32 2004 From: louie at ximian.com (Luis Villa) Date: Thu, 01 Apr 2004 10:37:32 -0500 Subject: About XML-RPC API In-Reply-To: <19C9EBE5-8361-11D8-8BF3-000A95DA505C@dberlin.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> <1080770800.17539.40.camel@localhost.localdomain> <19C9EBE5-8361-11D8-8BF3-000A95DA505C@dberlin.org> Message-ID: <1080833852.20053.15.camel@localhost.localdomain> On Wed, 2004-03-31 at 17:16 -0500, Daniel Berlin wrote: > >> It's not XML-RPC over SOAP, it's just XML-RPC. > >> > >> It's in redhat's bugzilla. I extracted it once into a standard > >> bugzilla > >> installation, it took me about 2 hours to do so. > > > > Have those patches somewhere, Dan? :) > > > > I didn't make the approriate changes to checksetup, etc. I just > installed all the new modules it required. > IE proper patches are more complex, but not prohibitively so. > If you just want the ripped out XMLRPC stuff, i can redo the patch I'd appreciate it- I think it's an important feature, and I'd love to test it as quickly as possible at bugzilla.gnome.org and maybe try to push it upstream from there. > (I've since discarded it, none of our gcc developers have time to play > with xml-rpc :P) pretty quickly. I know RH's developers have done some cool things with it, and I'm sure the gnome community will think of similar things once we deploy it. Luis From dberlin at dberlin.org Thu Apr 1 16:19:56 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Thu, 1 Apr 2004 11:19:56 -0500 Subject: About XML-RPC API In-Reply-To: <1080833852.20053.15.camel@localhost.localdomain> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> <1080770800.17539.40.camel@localhost.localdomain> <19C9EBE5-8361-11D8-8BF3-000A95DA505C@dberlin.org> <1080833852.20053.15.camel@localhost.localdomain> Message-ID: <6A08EEA0-83F8-11D8-8BF3-000A95DA505C@dberlin.org> >> I didn't make the approriate changes to checksetup, etc. I just >> installed all the new modules it required. >> IE proper patches are more complex, but not prohibitively so. >> If you just want the ripped out XMLRPC stuff, i can redo the patch > > I'd appreciate it- I think it's an important feature, and I'd love to > test it as quickly as possible at bugzilla.gnome.org and maybe try to > push it upstream from there. > Will do. >> (I've since discarded it, none of our gcc developers have time to play >> with xml-rpc :P) pretty quickly. > > I know RH's developers have done some cool things with it, and I'm sure > the gnome community will think of similar things once we deploy it. > No doubt you could. You guys actually use bug-reporting software that communicates with the bugzilla server (IE bug-buddy). We don't (don't ask, trying to push gcc past the base requirement of just a c compiler and a libc is already enough of a fight :P) :) > From roybryant at seventwentyfour.com Thu Apr 1 23:31:46 2004 From: roybryant at seventwentyfour.com (Roy at SEVENtwentyfour) Date: Thu, 01 Apr 2004 18:31:46 -0500 Subject: Broken link in www.bugzilla.org Message-ID: <200404012331.i31NVnRt021392@sinclair.syndicomm.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From kiko at async.com.br Thu Apr 1 23:58:33 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Thu, 1 Apr 2004 20:58:33 -0300 Subject: patch list filled by email In-Reply-To: <406B121C.7030402@t-online.de> References: <406B121C.7030402@t-online.de> Message-ID: <20040401235833.GA1044@async.com.br> On Wed, Mar 31, 2004 at 08:46:52PM +0200, Knueppel-Spenrath wrote: > Adding a comment to a bug is not really a problem, but adding the diffs > doesn't work. I've got no idea so that bugzilla puts the diffs into the > attachment list as a patch ;-( You'll want to look at attachment.cgi and see how it allows submission of patches. You might be interested in bug 119116, which Dave Swegan is supposed to be working on.. http://bugzilla.mozilla.org/show_bug.cgi?id=199116 Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From rlmcdo at netcabo.pt Fri Apr 2 07:51:34 2004 From: rlmcdo at netcabo.pt (Ricardo Oliveira) Date: 2 Apr 2004 08:51:34 +0100 Subject: Product version in Bug Activity Message-ID: <000001c41887$5573f1d0$6401a8c0@LordByron> Hi there folks. 1st post here. I've been using Bugzilla for some time now. Currently I'm using it out-of-the-box from the Debian unstable package. I think a useful feature was to keep track of the Product's version in the Bug Activity. For example, bug 100 detected in version 1.2.0, marked resolved in 1.2.4 and closed in 1.2.6. Shoold this be done? Any volunteers to do this? Besides me, that is :) Cya. Thanks. From gerv at mozilla.org Sat Apr 3 09:45:35 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 03 Apr 2004 10:45:35 +0100 Subject: Product version in Bug Activity In-Reply-To: <000001c41887$5573f1d0$6401a8c0@LordByron> References: <000001c41887$5573f1d0$6401a8c0@LordByron> Message-ID: <406E87BF.1040802@mozilla.org> Ricardo Oliveira wrote: > I think a useful feature was to keep track of the Product's version > in the Bug Activity. For example, bug 100 detected in version 1.2.0, > marked resolved in 1.2.4 and closed in 1.2.6. Shoold this be done? > Any volunteers to do this? Besides me, that is :) The version is already recorded in the bug activity when it changes. That screen is a direct reflection of an underlying database table which tracks only changes to bugs. IMO it wouldn't be good for it to start acquiring entries for fields which hadn't changed. Gerv From gerv at mozilla.org Sat Apr 3 12:06:40 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 03 Apr 2004 13:06:40 +0100 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040329180223.71664.qmail@web12506.mail.yahoo.com> References: <20040329180223.71664.qmail@web12506.mail.yahoo.com> Message-ID: <406EA8D0.4030005@mozilla.org> Bruce Armstrong [TeamSybase] wrote: > I've done a compile of Chart for ActiveState 5.8.3 (build 809), which is > the only module I couldn't find in either the Apache or ActiveState > repositories. However, I've discovered that ActiveState doens't have a > policy for accepting user submitted PPMs, and it doesn't appear that > Apache does either. Er... as far as I can tell, the Chart module is only used by the old charts, reports.cgi, which are deprecated and due for removal. Does that affect all this Windows stuff I'm not following and don't really understand? ;-) Gerv From bugreport at peshkin.net Sat Apr 3 16:02:53 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Sat, 03 Apr 2004 08:02:53 -0800 Subject: GD and libgd Message-ID: <406EE02D.8080706@peshkin.net> I'm tearing my hair out trying to build libgd and GD on a Solaris 9 / gcc 2.95.3 machine Anyone know of a combination that works? From bruce.armstrong at teamsybase.com Sat Apr 3 16:23:28 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Sat, 3 Apr 2004 08:23:28 -0800 (PST) Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <406EA8D0.4030005@mozilla.org> Message-ID: <20040403162328.99144.qmail@web12506.mail.yahoo.com> Perhaps this isn't an issue on the Unix side, but on the Windows side you have to get a version of the modules that have been compiled for the particular version of ActiveState that you're using. For the latest and greatest version of ActiveState, the ActiveState PPM repository doesn't contain a number of the modules that Bugzilla requires. The one that comes closest is the Apache PPM repository, but it still doesn't have the Chart module. In fact, I couldn't find a PPM respository that had a version of Chart that was compatible with the latest version of ActiveState. So I downloaded the source and compiled it myself for that version. However, that requires tools (MS VC++ 6.0) and skills that perhaps a small subset of the Windows users have. Unfotunately, the folks running those PPM repositories don't appear to allow folks to submit compiled modules to them. So if Bugzilla continues to use Chart, there is no good repository to point people to in order to get the modules for the latest version of ActiveState. The options are to: (a) tell people not to use that version or not to use Chart if they do, and/or (b) tell people they have to download the source for Chart and compile it themselves for that version of ActiveState, and/or (b) make the Chart module available on a PPM respository we control, and tell folks to get the rest of the modules from Apache and the Chart module from that other repository, and/or (c) make all of the modules available on a PPM repository we control, so that folks have 'one-stop-shopping' for those modules. It would also help clear up some confusion in that different PPM repository package the different modules into packages under slightly different names. Of course, if Chart is coming out, that's not an issue. Will it be out for the 2.18 release though? Gervase Markham wrote: Bruce Armstrong [TeamSybase] wrote: > I've done a compile of Chart for ActiveState 5.8.3 (build 809), which is > the only module I couldn't find in either the Apache or ActiveState > repositories. However, I've discovered that ActiveState doens't have a > policy for accepting user submitted PPMs, and it doesn't appear that > Apache does either. Er... as far as I can tell, the Chart module is only used by the old charts, reports.cgi, which are deprecated and due for removal. Does that affect all this Windows stuff I'm not following and don't really understand? ;-) Gerv - To view or change your list settings, click here: Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Sat Apr 3 20:07:49 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 03 Apr 2004 15:07:49 -0500 Subject: GD and libgd In-Reply-To: <406EE02D.8080706@peshkin.net> References: <406EE02D.8080706@peshkin.net> Message-ID: <406F1995.1040706@bugzilla.org> Joel Peshkin wrote: > > I'm tearing my hair out trying to build libgd and GD on a Solaris 9 / > gcc 2.95.3 machine > > Anyone know of a combination that works? libgd 1.8.4 and GD (perl) 1.41 That's what we had on bugzilla.mozilla.org when it was running on Solaris. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Sat Apr 3 22:07:16 2004 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 03 Apr 2004 23:07:16 +0100 Subject: Win32: what PPM repository to suggest in checksetup.pl? In-Reply-To: <20040403162328.99144.qmail@web12506.mail.yahoo.com> References: <20040403162328.99144.qmail@web12506.mail.yahoo.com> Message-ID: <406F3594.3050707@mozilla.org> Bruce Armstrong [TeamSybase] wrote: > Of course, if Chart is coming out, that's not an issue. Will it be out > for the 2.18 release though? Hard to tell. It depends how soon that is. I need to be confident of the stability of new charts first. But then, I really don't want to have to support old charts for the next six months... Gerv From rlmcdo at netcabo.pt Mon Apr 5 21:01:13 2004 From: rlmcdo at netcabo.pt (Ricardo Oliveira) Date: 5 Apr 2004 22:01:13 +0100 Subject: Product version in Bug Activity Message-ID: <000001c41b51$1ee98d60$6401a8c0@LordByron> >The version is already >recorded in the bug activity >when it changes. Ok, and that is helpful, my idea starts from that. >That screen is a direct >reflection of an underlying >database table which tracks >only changes to bugs. IMO it >wouldn't be good for it to >start acquiring entries for >fields which hadn't changed. What about creating some table schema that could be used in a join with 'bugs_activity' so that one could click in any line on the bug activity list and see - in a new detail page - a more extended bug snapshot at that point in time? Or, alternatively, have some sort of 'change columns' in activity list to do a custom list as in the query page. Don't you think a feature enhancement similar to this is worthwhile? From gerv at mozilla.org Wed Apr 7 07:34:26 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 07 Apr 2004 08:34:26 +0100 Subject: Product version in Bug Activity In-Reply-To: <000001c41b51$1ee98d60$6401a8c0@LordByron> References: <000001c41b51$1ee98d60$6401a8c0@LordByron> Message-ID: <4073AF02.4000902@mozilla.org> Ricardo Oliveira wrote: > What about creating some table schema that could be used in a join > with 'bugs_activity' so that one could click in any line on the bug > activity list and see - in a new detail page - a more extended bug > snapshot at that point in time? That would basically require taking a snapshot of the state of each bug every time it was changed. This would produce a lot of data very, very quickly... Gerv From mkanat at kerio.com Wed Apr 7 20:11:47 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Wed, 07 Apr 2004 13:11:47 -0700 Subject: Product version in Bug Activity In-Reply-To: <4073AF02.4000902@mozilla.org> References: <000001c41b51$1ee98d60$6401a8c0@LordByron> <4073AF02.4000902@mozilla.org> Message-ID: <1081368707.22378.0.camel@localhost.localdomain> On Wed, 2004-04-07 at 00:34, Gervase Markham wrote: > That would basically require taking a snapshot of the state of each bug > every time it was changed. This would produce a lot of data very, very > quickly... Actually, that information can be re-created by knowing the original state of the bug, and running through the bugs_activity table, or knowing the current state of the bug, and running the bugs_activity table backwards. -Max From gerv at mozilla.org Wed Apr 7 20:35:58 2004 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 07 Apr 2004 21:35:58 +0100 Subject: Product version in Bug Activity In-Reply-To: <1081368707.22378.0.camel@localhost.localdomain> References: <000001c41b51$1ee98d60$6401a8c0@LordByron> <4073AF02.4000902@mozilla.org> <1081368707.22378.0.camel@localhost.localdomain> Message-ID: <4074662E.8080505@mozilla.org> Maxwell Kanat-Alexander wrote: > Actually, that information can be re-created by knowing the original > state of the bug, and running through the bugs_activity table, or > knowing the current state of the bug, and running the bugs_activity > table backwards. Actually, I'm pretty sure the bugs_activity table doesn't (or, at least, hasn't in the past) store enough information for this to be possible for all types of change. Gerv From bugreport at peshkin.net Wed Apr 7 21:04:58 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Wed, 07 Apr 2004 14:04:58 -0700 Subject: Product version in Bug Activity In-Reply-To: <4074662E.8080505@mozilla.org> References: <000001c41b51$1ee98d60$6401a8c0@LordByron> <4073AF02.4000902@mozilla.org> <1081368707.22378.0.camel@localhost.localdomain> <4074662E.8080505@mozilla.org> Message-ID: <40746CFA.3040704@peshkin.net> Gervase Markham wrote: > Maxwell Kanat-Alexander wrote: > >> Actually, that information can be re-created by knowing the original >> state of the bug, and running through the bugs_activity table, or >> knowing the current state of the bug, and running the bugs_activity >> table backwards. > > > Actually, I'm pretty sure the bugs_activity table doesn't (or, at > least, hasn't in the past) store enough information for this to be > possible for all types of change. > > Gerv > Some work has already been done in that direction... http://bugzilla.mozilla.org/show_bug.cgi?id=193177 Though there is a problem... http://bugzilla.mozilla.org/show_bug.cgi?id=163643 From BacHoang at psv.com.vn Thu Apr 8 08:54:40 2004 From: BacHoang at psv.com.vn (Hoang, Bac) Date: Thu, 8 Apr 2004 15:54:40 +0700 Subject: Looking for module/patch supports User Defined Fields of Bugzilla Message-ID: <0531BED80997D6119B9B00D0B748B66A0917C9@MAIL> Hello Bugzilla developers, I've successfully deployed Bugzilla but it does not have ability to add user defined fields. Could you kindly help me find the above mentioned module/patch. Thank you very much, Bac P/s: I've examined the bug 91037 (http://bugzilla.mozilla.org/show_bug.cgi?id=91037) but it seems that this patch has not been stable enough? From bugreport at peshkin.net Thu Apr 8 12:28:21 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 08 Apr 2004 05:28:21 -0700 Subject: RFC: Detaching user name from email, LDAP and Single-Signon Message-ID: <40754565.6040707@peshkin.net> Please comment: In order to implement any of the systems that take Bugzilla out of the business of authenticating its users by sending them email, we need to make some common changes. 1) Add a field to profiles containing a (varchar(128)) identifier. This field should be added to the profile before any of the authentication systems start to use it. 2) LDAP Changes: A new LDAP configuration parameter is added to identify an optional LDAP attribute that specified a durable user identifier. In many environments, a person's userid and email address change when they marry and change names, but an employee number stays the same for the duration of emplyment. If the durable identifier is available, when a user logs in the identifier is used to locate the user's profile, and the LDAP email address and realname are used to set or update the database email address and realname. If the durable identifier is not available, LDAP would have to behave as it does today. 3) Single Signon Most single signon systems have a way to pass variables to a CGI containing the equivalent of fields from LDAP. The single signon module would accept the variables from the webserver and handle them in a similar manner to LDAP, using a durable identifier to locate the profile and auto-updating the email address and realname if it detects a change. 4) Detaching user identifier from email Once the system begins to maintain an identifier other than Realname or Email, it becomes possible to build configuration options to use that identifier in lieu of email addresses in presentation and selection of users. From gerv at mozilla.org Fri Apr 9 09:01:51 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 09 Apr 2004 10:01:51 +0100 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <40754565.6040707@peshkin.net> References: <40754565.6040707@peshkin.net> Message-ID: <4076667F.9040702@mozilla.org> Joel Peshkin wrote: > 1) Add a field to profiles containing a (varchar(128)) identifier. This > field should be added to the profile before any of the authentication > systems start to use it. So this field would be accessed by Auth modules and used as a correlator to relate Bugzilla accounts to accounts in Something Else? And it would be opaque to the rest of Bugzilla? Is 128 enough? > 3) Single Signon > Most single signon systems have a way to pass variables to a CGI > containing the equivalent of fields from LDAP. The single signon module > would accept the variables from the webserver and handle them in a > similar manner to LDAP, using a durable identifier to locate the profile > and auto-updating the email address and realname if it detects a change. We may want to provide convenience functions for Auth module owners to update profile information, so they all don't have to reimplement that code. Ideally, in fact, Auth module authors would not have to write Bugzilla database access code at all. > 4) Detaching user identifier from email > Once the system begins to maintain an identifier other than Realname > or Email, it becomes possible to build configuration options to use that > identifier in lieu of email addresses in presentation and selection of > users. Maybe I've misunderstood, but why would we ever want to display the string "o=Mozilla Foundation,cn=Asa Dotzler" instead of an email address or real name? Gerv From bugreport at peshkin.net Fri Apr 9 13:05:44 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Fri, 09 Apr 2004 06:05:44 -0700 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <4076667F.9040702@mozilla.org> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> Message-ID: <40769FA8.7050900@peshkin.net> Gervase Markham wrote: > Joel Peshkin wrote: > >> 1) Add a field to profiles containing a (varchar(128)) identifier. >> This field should be added to the profile before any of the >> authentication systems start to use it. > > > So this field would be accessed by Auth modules and used as a > correlator to relate Bugzilla accounts to accounts in Something Else? > And it would be opaque to the rest of Bugzilla? Correct. > Is 128 enough? > It would often be an employee ID number (generally less than 16 chars), but I could imagine it being a GUID of some sort as well. Once this is a varchar, there is no additional cost until we hit 255 characters, so 128 seems like a good round number. Beyond 255, it starts making a problem with indexing. >> 3) Single Signon >> Most single signon systems have a way to pass variables to a CGI >> containing the equivalent of fields from LDAP. The single signon >> module would accept the variables from the webserver and handle them >> in a similar manner to LDAP, using a durable identifier to locate the >> profile and auto-updating the email address and realname if it >> detects a change. > > > We may want to provide convenience functions for Auth module owners to > update profile information, so they all don't have to reimplement that > code. Ideally, in fact, Auth module authors would not have to write > Bugzilla database access code at all. > Agreed. The functions ( Bugzilla/Auth/Util ??) would need to .... Given a subset of {identifier, email, realname}.... If identifier is defined and matches an existing profile record, if email is defined, update email in profile (throw an error if the email matches a different record) if realname is defined, update realname in profile return userid If identifier is defined and does not match any existing profile record if email is defined and matches an existing profile record, update the profile's identifier if realname is defined, update realname in profile if email is defined and does not match any existing profile record, insert a new profile (with a random or impossible cypted password) return userid This would cover normal user login, cases where a user known to the auth system first logs into bugzilla, and cases where a user is created in bugzilla before the first time they ever log in themselves. At least in my site, internal users and daemons could hit an alternate URL and bypass the single-signon, so we would try the Auth/SSO first, then fall back on standard DB auth. That means that the Auth modules should also configure some variables like user->realname_from_auth, user->email_from_auth, and user->external_auth. Editprefs would use those to decide to supress the editing of realname and email and logout and useful-links would use those to supress the logout link. >> 4) Detaching user identifier from email >> Once the system begins to maintain an identifier other than >> Realname or Email, it becomes possible to build configuration options >> to use that identifier in lieu of email addresses in presentation and >> selection of users. > > > Maybe I've misunderstood, but why would we ever want to display the > string "o=Mozilla Foundation,cn=Asa Dotzler" instead of an email > address or real name? > Beats me, but someone wrote bug 51188, and I believe that there have been requests to use something else. I don't know of a scenario I like either. From kiko at async.com.br Fri Apr 9 19:58:57 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Fri, 9 Apr 2004 16:58:57 -0300 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <40769FA8.7050900@peshkin.net> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> Message-ID: <20040409195857.GE1862@async.com.br> On Fri, Apr 09, 2004 at 06:05:44AM -0700, Joel Peshkin wrote: > >Joel Peshkin wrote: > > > >>1) Add a field to profiles containing a (varchar(128)) identifier. > >>This field should be added to the profile before any of the > >>authentication systems start to use it. > > > > > >So this field would be accessed by Auth modules and used as a > >correlator to relate Bugzilla accounts to accounts in Something Else? > >And it would be opaque to the rest of Bugzilla? > > Correct. This field name is something like "other_id" or "external_auth_id"? So the "external" authentication mechanism can use it to map the external id to a Bugzilla id? Somehow I think this fits in another table, separate from profiles, but perhaps I'm being impractical. > >Is 128 enough? > > > It would often be an employee ID number (generally less than 16 > chars), but I could imagine it being a GUID of some sort as well. Once > this is a varchar, there is no additional cost until we hit 255 > characters, so 128 seems like a good round number. Beyond 255, it starts > making a problem with indexing. What if it's an entire LDAP identifier? > >>3) Single Signon > >> Most single signon systems have a way to pass variables to a CGI > >>containing the equivalent of fields from LDAP. The single signon > >>module would accept the variables from the webserver and handle them > >>in a similar manner to LDAP, using a durable identifier to locate the > >>profile and auto-updating the email address and realname if it > >>detects a change. > > >We may want to provide convenience functions for Auth module owners to > >update profile information, so they all don't have to reimplement that > >code. Ideally, in fact, Auth module authors would not have to write > >Bugzilla database access code at all. > Agreed. The functions ( Bugzilla/Auth/Util ??) would need to .... [snip - Joel goes on about having profile updated from the single signon system] Why isn't this done in User.pm? I discussed this with bbaetz and justdave a while back and the feeling I got was that profile queries and updates should be handled in the User module. > This would cover normal user login, cases where a user known to the auth > system first logs into bugzilla, and cases where a user is created in > bugzilla before the first time they ever log in themselves. Yeah, it sounds okay. I keep trying to fit NIS into the picture conceptually because it's a simple way to do a reality-check. From NIS we could grab the realname and identifier (which matches email) quite easily for this; writing the NIS module wouldn't actually be half as hard. > should also configure some variables like user->realname_from_auth, > user->email_from_auth, and user->external_auth. Editprefs would use > those to decide to supress the editing of realname and email and logout > and useful-links would use those to supress the logout link. Something like we the can_edit() method we have, today? > >>4) Detaching user identifier from email Perhaps this can just be covered by allowing user display to be configurable (a "display realname, email or both" radiobutton), without needing to require additional complexity. I can't come up with a non-contrived use case for this. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bugreport at peshkin.net Mon Apr 12 15:43:15 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 12 Apr 2004 08:43:15 -0700 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <20040409195857.GE1862@async.com.br> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> <20040409195857.GE1862@async.com.br> Message-ID: <407AB913.1000002@peshkin.net> Christian Robottom Reis wrote: >>This would cover normal user login, cases where a user known to the auth >>system first logs into bugzilla, and cases where a user is created in >>bugzilla before the first time they ever log in themselves. >> >> > >Yeah, it sounds okay. I keep trying to fit NIS into the picture >conceptually because it's a simple way to do a reality-check. From NIS >we could grab the realname and identifier (which matches email) quite >easily for this; writing the NIS module wouldn't actually be half as >hard. > > Actually, if you use the perl getpwent() funcion, NIS is the same as local unix auth. In both cases, the loginid (email address, if you add a suffix or send it to the local user) and realname can be grabbed from the line and the unix userid would persist even through a change of loginid and realname. From gerv at mozilla.org Tue Apr 13 21:14:33 2004 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 13 Apr 2004 22:14:33 +0100 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <20040409195857.GE1862@async.com.br> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> <20040409195857.GE1862@async.com.br> Message-ID: <407C5839.6040102@mozilla.org> Christian Robottom Reis wrote: > This field name is something like "other_id" or "external_auth_id"? So > the "external" authentication mechanism can use it to map the external > id to a Bugzilla id? > > Somehow I think this fits in another table, separate from profiles, but > perhaps I'm being impractical. Well... either everyone has one, or no-one has one. In the common case, no-one has one. So you could argue that an external table would be best. Gerv From bugreport at peshkin.net Tue Apr 13 21:33:41 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 13 Apr 2004 14:33:41 -0700 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <407C5839.6040102@mozilla.org> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> <20040409195857.GE1862@async.com.br> <407C5839.6040102@mozilla.org> Message-ID: <407C5CB5.4080108@peshkin.net> Gervase Markham wrote: > Christian Robottom Reis wrote: > >> This field name is something like "other_id" or "external_auth_id"? So >> the "external" authentication mechanism can use it to map the external >> id to a Bugzilla id? >> >> Somehow I think this fits in another table, separate from profiles, but >> perhaps I'm being impractical. > > > Well... either everyone has one, or no-one has one. In the common > case, no-one has one. So you could argue that an external table would > be best. > > Gerv > - Is that logic even true for a VARCHAR that takes 2 bytes for a zero-length entry? From kiko at async.com.br Tue Apr 13 21:48:36 2004 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 13 Apr 2004 18:48:36 -0300 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <407C5CB5.4080108@peshkin.net> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> <20040409195857.GE1862@async.com.br> <407C5839.6040102@mozilla.org> <407C5CB5.4080108@peshkin.net> Message-ID: <20040413214836.GJ3169@async.com.br> On Tue, Apr 13, 2004 at 02:33:41PM -0700, Joel Peshkin wrote: > >>This field name is something like "other_id" or "external_auth_id"? So > >>the "external" authentication mechanism can use it to map the external > >>id to a Bugzilla id? > >> > >>Somehow I think this fits in another table, separate from profiles, but > >>perhaps I'm being impractical. > > > >Well... either everyone has one, or no-one has one. In the common > >case, no-one has one. So you could argue that an external table would > >be best. > > Is that logic even true for a VARCHAR that takes 2 bytes for a > zero-length entry? I'm not dead set on it; I just wanted to explore the alternatives. What's your idea for the column name, to clarify things? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From erik-bug at dasbistro.com Tue Apr 13 22:26:36 2004 From: erik-bug at dasbistro.com (Erik Stambaugh) Date: Tue, 13 Apr 2004 15:26:36 -0700 Subject: RFC: Detaching user name from email, LDAP and Single-Signon In-Reply-To: <407C5839.6040102@mozilla.org> References: <40754565.6040707@peshkin.net> <4076667F.9040702@mozilla.org> <40769FA8.7050900@peshkin.net> <20040409195857.GE1862@async.com.br> <407C5839.6040102@mozilla.org> Message-ID: <20040413222635.GX1409@dasbistro.com> (by the way, hello again everybody!) On Tue, Apr 13, 2004 at 10:14:33PM +0100, Gervase Markham wrote: > Christian Robottom Reis wrote: > >This field name is something like "other_id" or "external_auth_id"? So > >the "external" authentication mechanism can use it to map the external > >id to a Bugzilla id? > > > >Somehow I think this fits in another table, separate from profiles, but > >perhaps I'm being impractical. > > Well... either everyone has one, or no-one has one. In the common case, > no-one has one. So you could argue that an external table would be best. I have a working model of the environment variable authentication Joel mentioned, and I was about to attempt arguing against putting the external ID in another table when something occurred to me. Our test bugzilla authenticates in one of three ways. Either the user gets authenticated externally, with everything including the unique identifier in the environment, or they can be authenticated without a unique identifier (not desired but unfortunately possible), or if the external auth system goes down or supplies nothing, it has a fallback where it uses the standard Bugzilla CGI authentication. What that means is, actually, some users have unique identifiers and some don't. The ones who do not have unique identifiers simply do not have the benefit of their name and email address automatically changing. But what occurred to me is that someone else using this feature may decide they want to use yet another authentication method on top of this, NIS for example. We could then need another type of ID string. So, yeah, I think this should go into another table, with the string itself and the auth method with which it's associated. -- Erik Stambaugh - erik at dasbistro.com - http://www.dasbistro.com/~erik/ From dberlin at dberlin.org Wed Apr 14 23:25:53 2004 From: dberlin at dberlin.org (Daniel Berlin) Date: Wed, 14 Apr 2004 19:25:53 -0400 Subject: About XML-RPC API In-Reply-To: <6A08EEA0-83F8-11D8-8BF3-000A95DA505C@dberlin.org> References: <40682270.4070102@nhst.no> <40682F37.1040602@mozilla.org> <1080570610.20928.12.camel@localhost.localdomain> <406AB0CC.3030403@nhst.no> <1080738974.15004.21.camel@localhost.localdomain> <16491.15686.486749.868518@magrathea.basistech.com> <51832706-835F-11D8-8BF3-000A95DA505C@dberlin.org> <1080770800.17539.40.camel@localhost.localdomain> <19C9EBE5-8361-11D8-8BF3-000A95DA505C@dberlin.org> <1080833852.20053.15.camel@localhost.localdomain> <6A08EEA0-83F8-11D8-8BF3-000A95DA505C@dberlin.org> Message-ID: <12C625D5-8E6B-11D8-83C3-000A95DA505C@dberlin.org> On Apr 1, 2004, at 11:19 AM, Daniel Berlin wrote: >>> I didn't make the approriate changes to checksetup, etc. I just >>> installed all the new modules it required. >>> IE proper patches are more complex, but not prohibitively so. >>> If you just want the ripped out XMLRPC stuff, i can redo the patch >> >> I'd appreciate it- I think it's an important feature, and I'd love to >> test it as quickly as possible at bugzilla.gnome.org and maybe try to >> push it upstream from there. >> > Will do. > >>> (I've since discarded it, none of our gcc developers have time to >>> play >>> with xml-rpc :P) pretty quickly. >> >> I know RH's developers have done some cool things with it, and I'm >> sure >> the gnome community will think of similar things once we deploy it. >> > No It's actually just two new files. No extra stuff is necessary (except the modules required by Bugzilla/RPC.pm) http://www.dberlin.org/~dberlin/xmlrpcforbugzilla.tgz tar xfpvz it in your bugzilla dir, set the permissions right, and away you go From justdave at bugzilla.org Thu Apr 15 08:10:46 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 15 Apr 2004 04:10:46 -0400 Subject: ThrowCodeError vs ThrowUserError Message-ID: <407E4386.5030307@bugzilla.org> Continuing some discussion from bug 238865... I'm probably opening a can of worms here, but I have some prior experiences here that lead me to want to change what we've been using as our guidelines for when to use ThrowCodeError and when to use ThrowUserError. The rule we've been using has been pretty much: "When in doubt, it's a code error, since it's better for usability to blame the program when it's the user's fault than blame the user when it's the program's fault. Programs don't have feelings, but users do, and blaming users wrongly hurts and frustrates them." However, I would postulate that blaming the program wrongly hurts the developers or the admin if the program actually isn't broken. We perhaps need a third way to safely blame neither? The current text surrounding all error messages thrown with ThrowCodeError basically says that Bugzilla is broken, and requests that you save the page and mail it to the maintainer. When I was working for AOL on the project we were doing for "Zippy", the "Zippy" folks would file a bug every time they saw a Code Error screen. We had hundreds of bugs filed because of it, and most were situations where they typed something funny in a text box or typoed a URL, and it really WAS the user's fault, just not something the program could squarely place the blame on (because it could have been a link on a web page, too). From what I've seen, I would say that the folks at "Zippy" are fairly typical of what you'd find in most corporate environments. That Code Error screen basically says "It's broken" and they'll say "we should be using some other bug tracker if this one is so broken that we're getting these all the time." What I posted on that bug is that ThrowUserError does not automatically blame the user. ThrowUserError does nothing but put your error message in a red box. You can make the error say whatever you want when designing the template for that error. So that error is not blaming the user unless you tell it to when you create the error template. A carefully constructed error message can opt out of blaming anyone. With ThrowCodeError, you don't get that option. "Bugzilla has suffered an internal error" it says in bold letters at the top. Those are mighty scary words. It asks the user to mail the page to the maintainer. This also means in a situation where the user shouldn't be mailing the page to the maintainer, we shouldn't be using that type of error. Thoughts from the peanut gallery? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Thu Apr 15 08:23:33 2004 From: justdave at bugzilla.org (David Miller) Date: Thu, 15 Apr 2004 04:23:33 -0400 Subject: ThrowCodeError vs ThrowUserError In-Reply-To: <407E4386.5030307@bugzilla.org> References: <407E4386.5030307@bugzilla.org> Message-ID: <407E4685.9030806@bugzilla.org> David Miller wrote: > Thoughts from the peanut gallery? OK, this flowed well, but it's not what I meant. :) Everyone's opinion is important. :) (At least until we make a final decision on it :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From meir.hazon at optier.com Thu Apr 15 08:39:35 2004 From: meir.hazon at optier.com (Meir Hazon) Date: Thu, 15 Apr 2004 04:39:35 -0400 Subject: Unregister meir.hazon@optier.com Message-ID: <08328692D63B8A4993AB63F779773B8348A900@VERIOVEXC008.VRO1.COM> -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of David Miller Sent: Thursday, April 15, 2004 10:11 AM To: developers at bugzilla.org Subject: ThrowCodeError vs ThrowUserError Continuing some discussion from bug 238865... I'm probably opening a can of worms here, but I have some prior experiences here that lead me to want to change what we've been using as our guidelines for when to use ThrowCodeError and when to use ThrowUserError. The rule we've been using has been pretty much: "When in doubt, it's a code error, since it's better for usability to blame the program when it's the user's fault than blame the user when it's the program's fault. Programs don't have feelings, but users do, and blaming users wrongly hurts and frustrates them." However, I would postulate that blaming the program wrongly hurts the developers or the admin if the program actually isn't broken. We perhaps need a third way to safely blame neither? The current text surrounding all error messages thrown with ThrowCodeError basically says that Bugzilla is broken, and requests that you save the page and mail it to the maintainer. When I was working for AOL on the project we were doing for "Zippy", the "Zippy" folks would file a bug every time they saw a Code Error screen. We had hundreds of bugs filed because of it, and most were situations where they typed something funny in a text box or typoed a URL, and it really WAS the user's fault, just not something the program could squarely place the blame on (because it could have been a link on a web page, too). From what I've seen, I would say that the folks at "Zippy" are fairly typical of what you'd find in most corporate environments. That Code Error screen basically says "It's broken" and they'll say "we should be using some other bug tracker if this one is so broken that we're getting these all the time." What I posted on that bug is that ThrowUserError does not automatically blame the user. ThrowUserError does nothing but put your error message in a red box. You can make the error say whatever you want when designing the template for that error. So that error is not blaming the user unless you tell it to when you create the error template. A carefully constructed error message can opt out of blaming anyone. With ThrowCodeError, you don't get that option. "Bugzilla has suffered an internal error" it says in bold letters at the top. Those are mighty scary words. It asks the user to mail the page to the maintainer. This also means in a situation where the user shouldn't be mailing the page to the maintainer, we shouldn't be using that type of error. Thoughts from the peanut gallery? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From john.fisher at znyx.com Thu Apr 15 15:18:51 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Thu, 15 Apr 2004 08:18:51 -0700 Subject: ThrowCodeError vs ThrowUserError In-Reply-To: <407E4685.9030806@bugzilla.org> References: <407E4386.5030307@bugzilla.org> <407E4685.9030806@bugzilla.org> Message-ID: <6.0.3.0.0.20040415081032.02659488@208.2.156.7> From Mr. Peanut: ;>) "Bugzilla has suffered an internal error" sounds like Hal 9000, and we all know what happened to him, errrr ummmm, it. I think the difference between the two types of error message is mis-defined: User errors should first and foremost direct the user to redoing the mistake in a correct way i.e. "Please go back and try again, maybe you mistyped?" "Bugzilla requires a six-character password, please try again" "You aren't configured to change products. Ask your administrator for help." Code errors should direct the developers to the actual problem so it can be addressed: "Bugzilla::MySub failed to get argument 3, here are arg1 arg2" "SendSQL returned a SQL error $@ " thanks John At 01:23 AM 4/15/2004, you wrote: >David Miller wrote: > >>Thoughts from the peanut gallery? > >OK, this flowed well, but it's not what I meant. :) Everyone's opinion is >important. :) (At least until we make a final decision on it :) > >-- >Dave Miller Project Leader, Bugzilla Bug Tracking System >http://www.justdave.net/ http://www.bugzilla.org/ >- >To view or change your list settings, click here: > John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From mkanat at kerio.com Thu Apr 15 18:49:43 2004 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Thu, 15 Apr 2004 11:49:43 -0700 Subject: ThrowCodeError vs ThrowUserError In-Reply-To: <407E4386.5030307@bugzilla.org> References: <407E4386.5030307@bugzilla.org> Message-ID: <1082054983.4114.15.camel@localhost.localdomain> On Thu, 2004-04-15 at 01:10, David Miller wrote: > Thoughts from the peanut gallery? Yeah, I think you're basically right about this. Right now, they probably are code errors -- the error being that the wrong error message is thrown. :-) For example, bad URLs should result in the error message "you have typed in a bad URL," or something like that. I think the guideline should be, "If we can give the user something to fix in the message, it's a UserError. If the user can't do anything about it, it's a CodeError." -Max -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From gerv at mozilla.org Thu Apr 15 22:40:36 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 15 Apr 2004 23:40:36 +0100 Subject: ThrowCodeError vs ThrowUserError In-Reply-To: <407E4386.5030307@bugzilla.org> References: <407E4386.5030307@bugzilla.org> Message-ID: <407F0F64.40004@mozilla.org> David Miller wrote: > The rule we've been using has been pretty much: > > "When in doubt, it's a code error, since it's better for usability to > blame the program when it's the user's fault than blame the user when > it's the program's fault. Programs don't have feelings, but users do, > and blaming users wrongly hurts and frustrates them." > > However, I would postulate that blaming the program wrongly hurts the > developers or the admin if the program actually isn't broken. We > perhaps need a third way to safely blame neither? That sort of makes sense; except that there should be no such thing as a "User Error" - ideally, the design of the program makes errors impossible or, if it can't, apologises and explains when the user makes one. So the text of ThrowUserError shouldn't blame the user. > The current text surrounding all error messages thrown with > ThrowCodeError basically says that Bugzilla is broken, and requests that > you save the page and mail it to the maintainer. Indeed. Such text should only be used when Bugzilla is actually definitely broken, rather than invalid input has been entered. This may mean we don't get bugs filed when there actually is a bug, but that's the price we have to pay. > When I was working for AOL on the project we were doing for "Zippy", I presume you mean "called 'Zippy'"; if it were "for Zippy", it would also have to be for Bungle, George, Rod, Jane and Freddy. ;-) (Bystanders: if you don't know who these people are, Google.) > What I posted on that bug is that ThrowUserError does not automatically > blame the user. ThrowUserError does nothing but put your error message > in a red box. I actually think even that's too strong. Gerv From erik at dasbistro.com Tue Apr 20 16:46:20 2004 From: erik at dasbistro.com (Erik Stambaugh) Date: Tue, 20 Apr 2004 09:46:20 -0700 Subject: Proposing a couple of alterations to Auth Message-ID: <20040420164619.GD7458@dasbistro.com> (Incidentally, my apologies go out to anyone to whom I subjected incoherent ramblings about Auth on #mozwebtools) I'm working on a new module for Bugzilla::Auth, and I've come across a couple of changes that Auth could probably use, so I want to see what everyone (cough-bbaetz-cough) has to say before I write any patches or file any bugs. The first thing I propose is breaking up the Auth directory by function. CGI and Cookie handle the way the password is provided to Bugzilla, while DB and LDAP manage verification or authentication styles. I'd like to divide these up into subdirectories (perhaps 'Login' and 'Verify'?). Once they are divided up, for my purposes, and probably for other people writing Auth modules, I'd like to create a new param that covers the method by which login and password information are provided, rather than authenticated. Something to sit alongside 'loginmethod'. This is mentioned as a future change in the comments in Bugzilla.pm. The trouble, now, is that the name 'loginmethod' seems too ambiguous. In fact, the first time I saw the param, I thought it referred to the method by which a user's information is provided to Bugzilla, when in fact it seems to cover the method of authenticating that information. I would like to change 'loginmethod' to something closer to its actual function. I also originally wanted 'loginmethod' to refer to the new param that provides actual login information, but I'm backing away from using that because of the confusion it might cause with anyone used to the old name. Possibly 'user_info_method' and 'user_verify_method'. There are probably better things to call them. Someone please suggest something. The final thing I'd like to alter (well, not *final* final, but final enough for this RFC) is to make both of the above params into ordered lists (a picklist that allows you to move the priority or execution order of each item up and down), allowing administrators to select a particular order in which multiple authentication or login methods can be used. This is particularly useful for my own purposes, and I think would be helpful for anyone using alternative methods of authentication. Unfortunately, there isn't really such a thing as an ordered list in the params, but after talking with justdave about this, I believe it can easily be done if the current work being done on bug 46296 makes it into CVS. ( http://bugzilla.mozilla.org/show_bug.cgi?id=46296 ) Also, Dave proposed having the possible values for these params actually determined by getting a listing of the contents of their respective module directories. I like that. Thoughts? -- Erik Stambaugh - erik at dasbistro.com - http://www.dasbistro.com/~erik/ From justdave at bugzilla.org Tue Apr 20 17:06:27 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 20 Apr 2004 13:06:27 -0400 Subject: Proposing a couple of alterations to Auth In-Reply-To: <20040420164619.GD7458@dasbistro.com> References: <20040420164619.GD7458@dasbistro.com> Message-ID: <40855893.4020901@bugzilla.org> Erik Stambaugh wrote: > The final thing I'd like to alter (well, not *final* final, but final > enough for this RFC) is to make both of the above params into ordered > lists (a picklist that allows you to move the priority or execution > order of each item up and down), allowing administrators to select a > particular order in which multiple authentication or login methods can > be used. This is particularly useful for my own purposes, and I think > would be helpful for anyone using alternative methods of > authentication. The *default* would use this, by the way, for the info-gathering modules. For example, you would want Cookie to be first in the list, and fall back on CGI if Cookie fails. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From Itay.Gat at Mobileye.com Thu Apr 22 17:34:15 2004 From: Itay.Gat at Mobileye.com (Itay Gat) Date: Thu, 22 Apr 2004 19:34:15 +0200 Subject: using bugzilla Message-ID: <40880217.6060206@Mobileye.com> Hi, Is it possible to add/remove menus and their contents via the template utility? For example instead of having a platform pull-down menu with possible platforms values, I would like to have a "technology" menu with different values. I would like to be able to change the number of such attributes associated with a bug - is it possible? After examining the perl cgi's it looks as though the application is reading these values from the database and not from the template. thanks, Itay. From gerv at mozilla.org Thu Apr 22 17:26:17 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 22 Apr 2004 18:26:17 +0100 Subject: using bugzilla In-Reply-To: <40880217.6060206@Mobileye.com> References: <40880217.6060206@Mobileye.com> Message-ID: <40880039.2050904@mozilla.org> Itay Gat wrote: > Is it possible to add/remove menus and their contents via the > template utility? This sort of question is best asked in the user support newsgroup: news://news.mozilla.org/netscape.public.mozilla.webtools However, the answer is partly yes - you can co-opt the platform and OS dropdowns to have different names and different values, but you can't add an extra dropdown without code changes. Gerv From Itay.Gat at Mobileye.com Thu Apr 22 18:34:35 2004 From: Itay.Gat at Mobileye.com (Itay Gat) Date: Thu, 22 Apr 2004 20:34:35 +0200 Subject: using bugzilla In-Reply-To: <40880039.2050904@mozilla.org> References: <40880217.6060206@Mobileye.com> <40880039.2050904@mozilla.org> Message-ID: <4088103B.2020907@Mobileye.com> Can you please direct me to wherein this newsgroup I may find the answer (e.g. any descriptive words that may lead me in the 30,000+ message list) - or tell me if this can be done via the templates. thanks, Itay Gervase Markham wrote: > Itay Gat wrote: > >> Is it possible to add/remove menus and their contents via the >> template utility? > > > This sort of question is best asked in the user support newsgroup: > news://news.mozilla.org/netscape.public.mozilla.webtools > > However, the answer is partly yes - you can co-opt the platform and OS > dropdowns to have different names and different values, but you can't > add an extra dropdown without code changes. > > Gerv > > - > To view or change your list settings, click here: > > From gerv at mozilla.org Thu Apr 22 17:37:49 2004 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 22 Apr 2004 18:37:49 +0100 Subject: using bugzilla In-Reply-To: <4088103B.2020907@Mobileye.com> References: <40880217.6060206@Mobileye.com> <40880039.2050904@mozilla.org> <4088103B.2020907@Mobileye.com> Message-ID: <408802ED.8080905@mozilla.org> Itay Gat wrote: > Can you please direct me to wherein this newsgroup I may find the > answer (e.g. any descriptive words that may lead me in the 30,000+ > message list) - or tell me if this can be done via the templates. As I said, this sort of question is best _asked_ in the user support newsgroup: news://news.mozilla.org/netscape.public.mozilla.webtools so please go and ask it there :-) Gerv From gerv at mozilla.org Fri Apr 23 08:40:14 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 23 Apr 2004 09:40:14 +0100 Subject: Open Source Directory Message-ID: <4088D66E.7010204@mozilla.org> Bugzilla gets a mention: http://www.egovos.org/rawmedia_repository/4e0c6c67_8ff0_4296_8d20_78406c648756?/document.pdf It's not very clear, I'm afraid - they didn't tell us how it would be presented, so I may have filled in some info wrong. And they've truncated some of it. But look at the very next entry down for an example of how bad it _could_ be... Gerv From sr at stephenreindl.de Fri Apr 23 09:16:21 2004 From: sr at stephenreindl.de (Stephen Reindl) Date: Fri, 23 Apr 2004 11:16:21 +0200 Subject: Open Source Directory In-Reply-To: <4088D66E.7010204@mozilla.org> Message-ID: <20040423.jwd.78028800@sreindl.dyndns.org> There was a mail some months ago from David to register on some repository. I think this was something regarding government and open source. Stephen Gervase Markham (gerv at mozilla.org) schrieb: > > Bugzilla gets a mention: > http://www.egovos.org/rawmedia_repository/4e0c6c67_8ff0_4296_8d20_78406c648756?/document.pdf > > It's not very clear, I'm afraid - they didn't tell us how it would be > presented, so I may have filled in some info wrong. And they've > truncated some of it. > > But look at the very next entry down for an example of how bad it > _could_ be... > > Gerv > - > To view or change your list settings, click here: > > From justdave at bugzilla.org Sat Apr 24 13:53:18 2004 From: justdave at bugzilla.org (David Miller) Date: Sat, 24 Apr 2004 09:53:18 -0400 Subject: Open Source Directory In-Reply-To: <20040423.jwd.78028800@sreindl.dyndns.org> References: <20040423.jwd.78028800@sreindl.dyndns.org> Message-ID: <408A714E.7040205@bugzilla.org> Stephen Reindl wrote: > There was a mail some months ago from David to register on some repository. I > think this was something regarding government and open source. > > Gervase Markham (gerv at mozilla.org) schrieb: > >>Bugzilla gets a mention: >>http://www.egovos.org/rawmedia_repository/4e0c6c67_8ff0_4296_8d20_78406c648756?/document.pdf That was Gerv, not me. :) And the link he just posted is the result of that registration. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Tue Apr 27 04:42:40 2004 From: justdave at bugzilla.org (David Miller) Date: Tue, 27 Apr 2004 00:42:40 -0400 Subject: Should Bugzilla 2.18 require Perl 5.6.1? Message-ID: <408DE4C0.70708@bugzilla.org> In hunting down various bugs, we've run into some more taint-related problems that are essentially bugs in Perl 5.6.0 that were fixed in 5.6.1. There are ways to work around them, but they're not fun. How many people are still using Perl 5.6.0 or older? Bugzilla 2.16.x currently requires Perl 5.00503 or newer. The 2.17 branch (which will soon be 2.18) currently already requires Perl 5.6.0 or newer. Would it hurt too many people if we go the extra step up to require Perl 5.6.1? I'm not aware of any distros still shipping 5.6.0. Mac OS X was the last one I knew of that was still shipping Perl 5.6.0, and they're shipping 5.8.1 now. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugreport at peshkin.net Tue Apr 27 05:00:56 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 26 Apr 2004 22:00:56 -0700 Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <408DE4C0.70708@bugzilla.org> References: <408DE4C0.70708@bugzilla.org> Message-ID: <408DE908.10903@peshkin.net> We also have decent instructions for people who need to build perl and anyone who cant build perl will likely have problems with the modules anyway. I suggest we bump to 5.6.1, possibly with a note in the docs about how to make a 5.6.1 install in a distinct directory. From bruce.armstrong at teamsybase.com Tue Apr 27 06:11:48 2004 From: bruce.armstrong at teamsybase.com (Bruce Armstrong [TeamSybase]) Date: Mon, 26 Apr 2004 23:11:48 -0700 (PDT) Subject: Should Bugzilla 2.18 require Perl 5.6.1? In-Reply-To: <408DE4C0.70708@bugzilla.org> Message-ID: <20040427061148.19070.qmail@web12504.mail.yahoo.com> ActiveState gives us Windows types a choice between 5.6.1 and 5.8.3. Shouldn't bother us a bit. David Miller wrote:In hunting down various bugs, we've run into some more taint-related problems that are essentially bugs in Perl 5.6.0 that were fixed in 5.6.1. There are ways to work around them, but they're not fun. How many people are still using Perl 5.6.0 or older? Bugzilla 2.16.x currently requires Perl 5.00503 or newer. The 2.17 branch (which will soon be 2.18) currently already requires Perl 5.6.0 or newer. Would it hurt too many people if we go the extra step up to require Perl 5.6.1? I'm not aware of any distros still shipping 5.6.0. Mac OS X was the last one I knew of that was still shipping Perl 5.6.0, and they're shipping 5.8.1 now. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: Bruce Armstrong [TeamSybase] --------------------------------- http://www.teamsybase.com Preach the gospel at all times. If necessary, use words. -- Francis of Assisi http://www.needhim.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtaylor at serablue.com Fri Apr 30 00:38:20 2004 From: dtaylor at serablue.com (David W. Taylor) Date: Thu, 29 Apr 2004 20:38:20 -0400 (EDT) Subject: Code Branch... In-Reply-To: <408802ED.8080905@mozilla.org> Message-ID: To All: This may not the best venue for this discussion, but I'll start here and make the rounds as needed. I would like to start building a web based technical support system based on the current Bugzilla code. The system would be loosely follow the design specifications found at http://www.serablue.com/os_files/DSF-SRS.pdf Furthermore, if there is no objection from Mozilla I would like to use the name "SupportZilla" to play on the Mozilla, Bugzilla, Issuezilla theme. Assuming, I adopt the Mozilla Public License as the licensing authority for this new project, to whom should I request permission (if anyone...) to undergo a project like this? Also, general comments about the idea would be appreciated. Sincerely, David Taylor From bugreport at peshkin.net Fri Apr 30 04:00:28 2004 From: bugreport at peshkin.net (Joel Peshkin) Date: Thu, 29 Apr 2004 21:00:28 -0700 Subject: Code Branch... In-Reply-To: References: Message-ID: <4091CF5C.3020202@peshkin.net> David W. Taylor wrote: >To All: > >This may not the best venue for this discussion, but I'll start here and >make the rounds as needed. > >I would like to start building a web based technical support system based >on the current Bugzilla code. The system would be loosely follow the >design specifications found at >http://www.serablue.com/os_files/DSF-SRS.pdf > > David, It seems that there is a set of features that such systems would need that are useful to a number of Bugzilla sites. Rather than starting by forking, why not prepare a list of features needed that are not in Bugzilla today? After examining the list, we may find that there is a set of features that make sense for both Bugzilla and your new project and should be done in common code. After that analysis, you can still decide to stay merged, fork, or track. -Joel From gerv at mozilla.org Fri Apr 30 08:52:14 2004 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 30 Apr 2004 09:52:14 +0100 Subject: Code Branch... In-Reply-To: References: Message-ID: <409213BE.7070209@mozilla.org> David W. Taylor wrote: > Furthermore, if there is no objection from Mozilla I would like > to use the name "SupportZilla" to play on the Mozilla, Bugzilla, > Issuezilla theme. Aside from any technical issues, I would recommend against this. The company which owns the Godzilla trademark, Toho, has given mozilla.org legal trouble in the past. We have come to an agreement which covers our use of "zilla" names, but no-one else's. We can't offer any protection to other projects who decide to use such a name. Even if that weren't true, we'd ask you not to use the name anyway. We've learnt from experience that people assume that any product called something-zilla is made by us, and we get support requests for it. So for those reasons, it would be good if you chose a different name. Gerv From john.fisher at znyx.com Fri Apr 30 16:54:22 2004 From: john.fisher at znyx.com (John P. Fisher) Date: Fri, 30 Apr 2004 09:54:22 -0700 Subject: Code Branch... In-Reply-To: References: <408802ED.8080905@mozilla.org> Message-ID: <6.0.3.0.0.20040430093205.02376628@208.2.156.7> David, its a little early to mention this, but I already have such a ( trouble ticket ) system running at my company. I wrote it, and there is a good chance my company would allow me to release it under an Open Source license. Based on a quick look at your specs: It conforms to all of your requirements, except: 1) it needs some speed optimization to reach your scaling goals ( I have 6000 tickets, but few users ) 2) the 'customer' connection is not being used yet, so that area is a little buggy 3) some of the statistical data you require would have to be added to the screens, however its all available 4) my design document is wildly out of date It exceeds your requirements by: Connects to your Bugzilla installation so tickets can refer to bug reports. ( need not be run on same machine as Bugzilla) Customers can generate their own new logins, once they have been given a customer-admin login Logins are generated manually by in-house engineers, or automatically by supplying the customer with a key and URL. Support for paid customer support Customers can only create/search/see their own tickets Support for multiple customer contracts within a single customer organization FAQ with automated generation of new faq items from closed tickets Notification by email on various changes to ticket status Crude ( but effective) templatization of html no plaintext passwords in db, the only plaintext passwords are present once in insecure http calls when the password is set. ( the next layer of security improvement requires HTTPS and the addition of taint mode ) Logging of user hits CSV reports ftp'd to users my system runs on perl not PHP, Apache and MySQL. Contact me with any questions. I'd be interested in working on a PHP version, too. John At 05:38 PM 4/29/2004, you wrote: >I would like to start building a web based technical support system based >on the current Bugzilla code. John P. Fisher at ZNYX Networks 805 683 1488 x 3245 john.fisher at znyx.com From dtaylor at serablue.com Fri Apr 30 19:52:15 2004 From: dtaylor at serablue.com (David W. Taylor) Date: Fri, 30 Apr 2004 15:52:15 -0400 (EDT) Subject: Code Branch... In-Reply-To: <409213BE.7070209@mozilla.org> Message-ID: In an effort to make things simpler now and down the road, I will begin researching another name for the support system. The legal questions aside, I would want to respect Mozilla's branding and not confuse users. Thanks for your feedback Gerv. David Taylor On Fri, 30 Apr 2004, Gervase Markham wrote: > David W. Taylor wrote: > > > Furthermore, if there is no objection from Mozilla I would like > > to use the name "SupportZilla" to play on the Mozilla, Bugzilla, > > Issuezilla theme. > > Aside from any technical issues, I would recommend against this. The > company which owns the Godzilla trademark, Toho, has given mozilla.org > legal trouble in the past. We have come to an agreement which covers our > use of "zilla" names, but no-one else's. We can't offer any protection > to other projects who decide to use such a name. > > Even if that weren't true, we'd ask you not to use the name anyway. > We've learnt from experience that people assume that any product called > something-zilla is made by us, and we get support requests for it. > > So for those reasons, it would be good if you chose a different name. > > Gerv > > - > To view or change your list settings, click here: > > From dtaylor at serablue.com Fri Apr 30 20:01:58 2004 From: dtaylor at serablue.com (David W. Taylor) Date: Fri, 30 Apr 2004 16:01:58 -0400 (EDT) Subject: Code Branch... In-Reply-To: <4091CF5C.3020202@peshkin.net> Message-ID: Joel, This weekend I will begin thinking about which features would be beneficial to both Bugzilla and the Support System. It would be great if there are places where my development team and I can devote some time to Bugzilla *before* beginning a separate code branch, but eventually I think the functionality of a Support System is sufficiently different to merit an entirely distinct trunk. -David Taylor On Thu, 29 Apr 2004, Joel Peshkin wrote: > David W. Taylor wrote: > > >To All: > > > >This may not the best venue for this discussion, but I'll start here and > >make the rounds as needed. > > > >I would like to start building a web based technical support system based > >on the current Bugzilla code. The system would be loosely follow the > >design specifications found at > >http://www.serablue.com/os_files/DSF-SRS.pdf > > > > > > David, > > It seems that there is a set of features that such systems would need > that are useful to a number of Bugzilla sites. Rather than starting by > forking, why not prepare a list of features needed that are not in > Bugzilla today? After examining the list, we may find that there is a > set of features that make sense for both Bugzilla and your new project > and should be done in common code. After that analysis, you can still > decide to stay merged, fork, or track. > > -Joel > > > - > To view or change your list settings, click here: > >