Hi, I have some question about Request Tracker:
Can a user (requestor) see (or see and update) ONLY his requests with
RT via Web??
Can I use encript password in the table “users” in the field “password”??
Can I use another table name for the users, for example “people”??
Thanks!!
Jose
p.d: Sorry about my bad English!! :((
Can a user (requestor) see (or see and update) ONLY his requests with
RT via Web??Can I use encript password in the table “users” in the field “password”??
Can I use another table name for the users, for example “people”??
all of these sound like they would take hacking the code.
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
Can a user (requestor) see (or see and update) ONLY his requests with
RT via Web??
Not in RT1, but we’ll implement it for RT 2.0. It’s ready in August,
maybe.
It might be possible to hack this for RT1.
Can I use encript password in the table “users” in the field “password”??
No, but I don’t think the security would be significantly raised by that
anyway. I will eventually implement authentication via SSL certificates,
but only after 2.0 is out.
Can I use another table name for the users, for example “people”??
External authentication (including alternative tables and alternative
fields - though that should really be handled by sql VIEWS … which mysql
unfortunately doesn’t support at the moment) will come, but only after 2.0
is out.
It might be possible to hack RT1 to accept other tablenames for the users.
It should all be in lib/rt/database.pm IIRC.
p.d: Sorry about my bad English!! :((
…and RT will probably be translated to Spanish, but only after 2.0 is out
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
line 191 of Date/Kronos.pm
sub _get_alt {
my $self = shift;
my $subclass = shift;
## if it doesn't exist
if (!exists($self->{_alt}->{$subclass})) {
## Pass convertion to the AUTOLOAD function:
$self->{_alt}->{$subclass} = $self->$subclass;
^^^^^^^^^^^ Spurious $ Sign.
Also, i’m getting this error on queries and was wondering what the deal is
Internal Error
You might ask your local RT admin what
dbih_getcom handle 'DBI::db=HASH(0x89253e8)' is not a DBI handle (has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm line 394, chunk 124.
means. If he has configured RT smartly, he will get that error message sent by mail or to his pager or something. Anyway, you'll probably have to nag
about it to get this problem fixed. This is an unfriendly error message.
I can see the one default ticket (#1) so i know i’m connecting
to the database.
cheers,
_Michael.
Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net
line 191 of Date/Kronos.pm
sub _get_alt {
my $self = shift;
my $subclass = shift;## if it doesn't exist if (!exists($self->{_alt}->{$subclass})) { ## Pass convertion to the AUTOLOAD function: $self->{_alt}->{$subclass} = $self->$subclass; ^^^^^^^^^^^ Spurious $ Sign.
No, it should be like that. Do you get error messages about it?
Also, i’m getting this error on queries and was wondering what the deal is
Internal Error
“Internal Error” says nada - the real culprit is either located in
the web error logs, or the RT error log.
dbih_getcom handle ‘DBI::db=HASH(0x89253e8)’ is not a DBI handle (has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm line 394, chunk 124.
!@#$@#$%
I haven’t got the faintest clue about what this means. It seems to be a
problem with Apache::Session. I hate Apache::Session FWIW I get those
messages even though I’m not using DBI with Apache::Session, and I still
get those pesky warnings. Anyway, things work out when I ignore them.
I can see the one default ticket (#1) so i know i’m connecting
to the database.
That’s nice. You’re getting somewhere, just slowly.
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
dbih_getcom handle 'DBI::db=HASH(0x89253e8)' is not a DBI handle (has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm line 394, chunk 124.
Obviously RT dies because of this. Are you using perl 5.6.0? What is
written at line 394 of Session.pm?
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
dbih_getcom handle ‘DBI::db=HASH(0x89253e8)’ is not a DBI handle
(has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm
line 394, chunk 124.!@#$@#$%
i get this as well when using rt2 at home (where it doesn’t segfault
apache. :P)
Michael, are you using mod_perl and perl 5.003?
Tobias, I hate to bring it up, but would it be possible for you and Jesse
to pick either CGI or mod_peril, so that those of us willing to help out
can work a little more effectively? Is the ‘official’ development platform
mod_perl + 5.003?
Thanks,
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
dbih_getcom handle 'DBI::db=HASH(0x89253e8)' is not a DBI handle (has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm line 394, chunk 124.Obviously RT dies because of this. Are you using perl 5.6.0? What is
written at line 394 of Session.pm?
actually, it goes on ahead and prints your query data - or at least, some
more HTML, under the error message(s).
at least, it does on my system.
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
actually, it goes on ahead and prints your query data - or at least, some
more HTML, under the error message(s).at least, it does on my system.
Uh … sounds weird, can you save it (the HTML code, or make a screen
dump) and let me have a look?
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
actually, it goes on ahead and prints your query data - or at least, some
more HTML, under the error message(s).at least, it does on my system.
Uh … sounds weird, can you save it (the HTML code, or make a screen
dump) and let me have a look?
yes… im in the middle of wussing out and going back a rev on perl, which
means soaking work’s bandwidth for modules. 
luckily, i’m getting pretty
quick at it.
if Michael doesn’t beat me to it, that is.
Blue Lang Unix Systems Admin
QSP, Inc., 3200 Atlantic Ave, Ste 100, Raleigh, NC, 27604
Home: 919 835 1540 Work: 919 875 6994 Fax: 919 872 4015
And so i says to him|her…
dbih_getcom handle 'DBI::db=HASH(0x89253e8)' is not a DBI handle (has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm line 394, chunk 124.Obviously RT dies because of this. Are you using perl 5.6.0? What is
written at line 394 of Session.pm?
sub STORE {
my $self = shift;
my $key = shift;
my $value = shift;
$self->{data}->{$key} = $value;
$self->{status} |= MODIFIED; # line 394
return $self->{data}->{$key};
}
_Michael.
Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net
And so i says to him|her…
dbih_getcom handle ‘DBI::db=HASH(0x89253e8)’ is not a DBI handle
(has no magic) at /usr/lib/perl5/site_perl/5.005/Apache/Session.pm
line 394, chunk 124.!@#$@#$%
i get this as well when using rt2 at home (where it doesn’t segfault
apache. :P)Michael, are you using mod_perl and perl 5.003?
perl 5.005_03 (comes with Redhat 6.2)
mod_perl-1.24
apache_1.3.12
_Michael
Michael Jastremski … AIM:rstfinsyn
WORK:liquidation.com ME:westphila.net/mike
PHOTO:opl.megaglobal.net … BIZ:megaglobal.net
Tobias, I hate to bring it up, but would it be possible for you and Jesse
to pick either CGI or mod_peril,
No. The release should be platform independent - and we’re using
HTML::Mason which really is mod_perl-geared, so it would be wrong not to
choose mod_perl for those that are already using mod_perl. And a plain
.cgi version will just be too slow. Well, Jesse has mentionated that we
might reorganize it into a server/client version. I’ll probably have to
develop a running “RT server” here anyway, as it should be possible to
create RT tickets directly from our game clients.
so that those of us willing to help out
can work a little more effectively?
I don’t think it will hinder the efficiency that much. Certainly, there
are a lot of troubles with the Apache setup, but except for that I expect
most of the troubles with the current RT2 to be elsewhere (and not in the
bin/ directory).
Is the ‘official’ development platform
mod_perl + 5.003?
I’d daresay the official platform is mysql + apache + mod_perl + the last
perl before 5.6.0 (wasn’t that 5.005?). I’m using perl 5.6.0 and fcgi.
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
Obviously RT dies because of this. Are you using perl 5.6.0? What is
written at line 394 of Session.pm?sub STORE {
my $self = shift;
my $key = shift;
my $value = shift;$self->{data}->{$key} = $value; $self->{status} |= MODIFIED; # line 394
Really weird, the stack trace must be fucked up. The real problem is of
course located somewhere else.
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
Platform indepent does not mean that we have to support every web technology
known to man mod_perl is the blessed web tech for RT2. Tobias wants
to hack the CGI side and Iäm not going to stop him grin The ´client-server´
future that I referred to is using HTML::Mason to generate SOAP or XML-RPC
responses to client queries… Anyway, I should go, as I canät handle this
austrian cybercafe keyboard
jesseOn Fri, Jun 09, 2000 at 08:09:38PM +0200, Tobias Brox wrote:
Tobias, I hate to bring it up, but would it be possible for you and Jesse
to pick either CGI or mod_peril,No. The release should be platform independent - and we’re using
HTML::Mason which really is mod_perl-geared, so it would be wrong not to
choose mod_perl for those that are already using mod_perl. And a plain
.cgi version will just be too slow. Well, Jesse has mentionated that we
might reorganize it into a server/client version. I’ll probably have to
develop a running “RT server” here anyway, as it should be possible to
create RT tickets directly from our game clients.so that those of us willing to help out
can work a little more effectively?I don’t think it will hinder the efficiency that much. Certainly, there
are a lot of troubles with the Apache setup, but except for that I expect
most of the troubles with the current RT2 to be elsewhere (and not in the
bin/ directory).Is the ‘official’ development platform
mod_perl + 5.003?I’d daresay the official platform is mysql + apache + mod_perl + the last
perl before 5.6.0 (wasn’t that 5.005?). I’m using perl 5.6.0 and fcgi.–
“The trouble with the world is that the stupid are
cocksure and the intelligent are full of doubt.”
- Bertrand Russell
Rt-devel mailing list
Rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I’m reasonably sure that at least two of the electric blue kangeroos
I saw were real.