I just wanted to report an issue or two and realized I did not have a
real user for it. Should I just use guest/guest or would it be better to
apply for a real account?
Also, is it really wise to keep the bug reporting & fixing stuff in an
instance that is used for testing, as well? I can see how it conveys the
trust you have in your product, but…
Richard
PS: I attached a screenshot of how RT 3.8.1 looks in Konqui. Kinda
weird
I just wanted to report an issue or two and realized I did not have a
real user for it. Should I just use guest/guest or would it be better to
apply for a real account?
Also, is it really wise to keep the bug reporting & fixing stuff in an
instance that is used for testing, as well? I can see how it conveys the
trust you have in your product, but…
Richard
PS: I attached a screenshot of how RT 3.8.1 looks in Konqui. Kinda
weird
I just wanted to report an issue or two and realized I did not have a
real user for it. Should I just use guest/guest or would it be better to
apply for a real account?
Also, is it really wise to keep the bug reporting & fixing stuff in an
instance that is used for testing, as well? I can see how it conveys the
trust you have in your product, but…
+1
PS: I attached a screenshot of how RT 3.8.1 looks in Konqui. Kinda
weird
The way css is done in this part of the UI should really be rewriten I
think, I opened a bug report that talk on related problems:
You won’t get more rights. It’s not practical for BP to manage user
privileges for everyone.On Mon, Sep 8, 2008 at 11:34 AM, Richard Hartmann < richih.mailinglist@gmail.com> wrote:
Also, is it really wise to keep the bug reporting & fixing stuff in an
instance that is used for testing, as well? I can see how it conveys
the
trust you have in your product, but…
We don’t use it for testing (other than the fact that we keep it
updated to a near bleeding-edge release of RT). However, there are
many folks on the net who think that it’s a great place to try
creating test tickets. The “Test” queue helps keep them from creating
bugs in RT complaining that the printer isn’t working.
We don’t use it for testing (other than the fact that we keep it
updated to a near bleeding-edge release of RT). However, there are
many folks on the net who think that it’s a great place to try
creating test tickets. The “Test” queue helps keep them from creating
bugs in RT complaining that the printer isn’t working.
I always figured that’s what the Test queue was for, a live demo for people to
play with, and sell their bosses on before dedicating local resources?
Cambridge Energy Alliance: Save money & the planet
We don’t use it for testing (other than the fact that we keep it updated to
a near bleeding-edge release of RT). However, there are many folks on the
net who think that it’s a great place to try creating test tickets. The
“Test” queue helps keep them from creating bugs in RT complaining that the
printer isn’t working.
That’s what i meant with ‘used for testing’. Written in an ambigious way, sorry
for that. What I mean is why not seperate the playground RT from the bug
tracking RT? With a cron-driven auto-restore, you could give all guests admin
rights and they would be able to play & test even more.
That’s what i meant with ‘used for testing’. Written in an ambigious way, sorry
for that. What I mean is why not seperate the playground RT from the bug
tracking RT? With a cron-driven auto-restore, you could give all guests admin
rights and they would be able to play & test even more.
Be careful about that. “All admin rights” will let your users run
arbitrary code on your RT server.
We have such a demo server for potential customers, but not one we
currently share with the general public.
We have about 90% of such a server. We just have rather a lot to do