Regardless, accounts with no password are automatically created when
a person submits a ticket. To give them a default password you have
to hack one of the files
So the uses is supposed to be able to enter just their e-mail address
in the Web UI login, leave the password field blank and be able to
login?
Normally the account is created by sending e-mail to RT for a ticket.
If that’s not feasible, I think you need to create the accounts by
hand.
The accounts are created automatically. That works. If I set their
password once created they can log in. I have 850 users though. 
I’m
sure I can hack the appropriate .pl file to set a default password. I
think someone sent me a message on where to find this.
How hard would it be to generate a random password and e-mail it to the
user? Anyone have any thoughts on how to do this?
There does not seem to be a way for them to change their password in the
web UI one they logged in. Is this the case? Any thoughts on how can I
deal with this?
I opted for the “not everyone gets an account” approach. I use a guest
account from a custom web form for users to create tickets. When a user
goes to the form, if they aren’t already logged in, they get logged in
as guest. And guest isn’t privileged, but can access all the forms I’ve
created for ticket submissions.
I’m not sure what your needs are, but that may be an alternative that’s
interesting to you. It’s not necessarily less work than creating the
passwords, but for my site it was better for the users.
Also, they should be able to login and click on Preferences to change
their password, unless I’ve missed something.
Matt
Randy Millis writes:
Matt Disney wrote:
I opted for the “not everyone gets an account” approach. I use a guest
account from a custom web form for users to create tickets. When a user
goes to the form, if they aren’t already logged in, they get logged in
as guest. And guest isn’t privileged, but can access all the forms I’ve
created for ticket submissions.
I’m not sure what your needs are, but that may be an alternative that’s
interesting to you. It’s not necessarily less work than creating the
passwords, but for my site it was better for the users.
Also, they should be able to login and click on Preferences to change
their password, unless I’ve missed something.
Matt
Hmmm. Maybe I’m misusing something. I wrote a simple form/cgi outside of RT
that simply sends a mail from the email address of the user (form submitted)
to the appropriate email address for the queue they are submitting to.
Phil
“They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety.”
-Benjamin Franklin, 1759
Yeah, I was going to do that, too, but I wanted to take the user
straight to the ticket after ticket creation. So I ended up copying a
lot of stuff out of the Ticket/Create.html page, making sure the user
gets logged in as guest automatically, and then I put that in the
NoAuth hierarchy. Oh, and I also wanted to be able to acces keywords
from that ticket creation form.
The trusty email form is the simplest way to solve the problem, but it
doesn’t give you the flexibility of setting specific ticket fields (due
date, keywords, etc…).
Matt
Phil Dibowitz writes: