Unwieldy users list

I can see as I add new users and queues that the list of users going
down the side of a new queue creation page is going to quickly become
unwieldy. Any suggestions or has this already been addressed in v2?

Thanks,
Eriks

R. Eriks Goodwin, CEO
UniMatrix International Corporation
2101 East Main Street, Suite 900
Richmond, Virginia 23223-7050, U.S.A.
Tel: 804-780-0590 Fax: 804-780-0591

Computers * Web Sites * SDSL, T-1, T-3, DS-3

http://www.unimatrix.com

I can see as I add new users and queues that the list of users going
down the side of a new queue creation page is going to quickly become
unwieldy. Any suggestions or has this already been addressed in v2?

Yeah, that has been a problem here also. The v2 admin interface hasn’t
been made yet, but we should think of some better solution. Suggestions?
Maybe optionally allow people to enter a login instead of selecting from a
list?

Tobias Brox
aka TobiX
+47 22 925 871

Tobias Brox wrote:

I can see as I add new users and queues that the list of users going
down the side of a new queue creation page is going to quickly become
unwieldy. Any suggestions or has this already been addressed in v2?

Yeah, that has been a problem here also. The v2 admin interface hasn’t
been made yet, but we should think of some better solution. Suggestions?
Maybe optionally allow people to enter a login instead of selecting from a
list?

You could allow users to be pulled together into groups, and add a list
of groups to different queues? Depends on how your organise your users,
but in my case we have a set of “front line people” who have a certain
level of access, and core people who have another set to the queues.

At the moment this is done manually, but the ability to group them
together would be useful and less error prone.

Regards,
Anil Madhavapeddy

You could allow users to be pulled together into groups, and add a list
of groups to different queues? Depends on how your organise your users,
but in my case we have a set of “front line people” who have a certain
level of access, and core people who have another set to the queues.

nod. I’m basically solving this “problemacy” today in SQL. Basically,
I’d say that what you’d like to do is really to copy queue rights - but it
might also make sense to grant access and subscriptions at a group level
instead of at an individual level.

Jesse; what about adding a “group” table binding a user id with a group
id?

Tobias Brox
aka TobiX
+47 22 925 871

You could allow users to be pulled together into groups, and add a list
of groups to different queues? Depends on how your organise your users,
but in my case we have a set of “front line people” who have a certain
level of access, and core people who have another set to the queues.

nod. I’m basically solving this “problemacy” today in SQL. Basically,
I’d say that what you’d like to do is really to copy queue rights - but it
might also make sense to grant access and subscriptions at a group level
instead of at an individual level.

Jesse; what about adding a “group” table binding a user id with a group
id?

I’d like to not deal with groups in 2.0; When we do it, I’d very much like
to do it right. I’m really tired right now, so I’m not going to go into what I
was thinking of as an interim hack for now.

Jesse


Tobias Brox
aka TobiX
+47 22 925 871


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Transporters are so ungodly. if god had wanted us to travel great distances
instantaneously, he would have given us an internal
materialisation/dematerialisation control.
– Shoshe Cole

I can see as I add new users and queues that the list of users going
down the side of a new queue creation page is going to quickly become
unwieldy. Any suggestions or has this already been addressed in v2?

Yeah, that has been a problem here also. The v2 admin interface hasn’t
been made yet, but we should think of some better solution. Suggestions?
Maybe optionally allow people to enter a login instead of selecting from a
list?

One possibility would be two drop downs, one where you select the
user name, the other where you select the access rights, and a button
to assign the selected rights. (Pro: takes very little screen space;
Con: requires separate action for each user)

Another possibility is creating a separate page for assignment of
queue rights. This could be linked from the main queue page and could
be more densely populated with users/rights pairs (e.g., a full table
rather than a single column). This could also allow for sorting by
user or “current access” rights. (Pro: minimizes screen space; Con:
requires new screen/separate action – complicates admin interface).

On a related note (to manageability of users), I’d be interested in
some sort of external authentication API (to allow authentication
separate from username/passwords in the rt database).

— Eric

Eric Goodman | “The opinions expressed by Eric do not
Workstation Support Group | represent the opinions of anyone who
UC Santa Cruz | matters.”
ericg@cats.ucsc.edu | — (modified from) “Cartoon Planet”

One possibility would be two drop downs, one where you select the
user name, the other where you select the access rights, and a button
to assign the selected rights. (Pro: takes very little screen space;
Con: requires separate action for each user)

What we’ll probably end up doing is seperating out the ACL managment system
and allowing to restrict the set of ACLs displayed with a filter. The whole
thing’s been gutted.

On a related note (to manageability of users), I’d be interested in
some sort of external authentication API (to allow authentication
separate from username/passwords in the rt database).

I’ll ponder this. Do people who want an external authentication mechanism
want it in addition to rt internal authentication or instead of it?
Additionally, will all users use the external mechanism or only some users?

jesse

— Eric


Eric Goodman | “The opinions expressed by Eric do not
Workstation Support Group | represent the opinions of anyone who
UC Santa Cruz | matters.”
ericg@cats.ucsc.edu | — (modified from) “Cartoon Planet”


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

jesse reed vincent – jrvincent@wesleyan.edu – jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Any e-mail sent to the SLA will immediately become the intellectual property
of the SLA and the author of said message will enter into a period of
indentured servitude which will last for a period of time no less than seven
years.

Jesse wrote:

On a related note (to manageability of users), I’d be interested in
some sort of external authentication API (to allow authentication
separate from username/passwords in the rt database).

I’ll ponder this. Do people who want an external authentication mechanism
want it in addition to rt internal authentication or instead of it?
Additionally, will all users use the external mechanism or only
some users?

Would be very very useful. Given that the vast majority of deployments
for this would probably be in an environment with some sort of existing
authentication environment …

Personally, I’d use it instead of the internal authentication, but I
could see an “or” facility being useful (do a local database lookup
if external auth fails).

Something abstract like PAM would be cool, as that opens up a large
number of possibilities (I think it supports NIS, and certainly
passwd, shadow and database auth).

Of course, SSL support becomes pretty vital then … the whole thing
is wide open to snooping otherwise, which is an advantage of the
existing system; it allows users to have an insecure web authentication
without compromising their actual system passwords. (con: they keep
on forgetting one of them).

Anil

Jesse wrote:> On Mon, May 01, 2000 at 02:31:01PM -0700, Eric Goodman wrote:

SNIP

I’ll ponder this. Do people who want an external authentication mechanism
want it in addition to rt internal authentication or instead of it?
Additionally, will all users use the external mechanism or only some users?

    jesse

I had been using our *NIX login as authentication for our users with another
web-based product we were trying. It works well because you do not have to create
passwords when adding users. The only problem with this package in the auth
module was that you could only be all *NIX auth, or no *NIX auth. Would be nice
to see a combination of both, that way you could still set up group id/passwords
if needed.

Thanks,

Stephen Lawrence
-Support Technician & Webmaster
-Examen, Inc.
-stephenl@examen.com
-916-921-4300 ext. 703

Jesse jesse@fsck.com writes:

On a related note (to manageability of users), I’d be interested in
some sort of external authentication API (to allow authentication
separate from username/passwords in the rt database).

I’ll ponder this. Do people who want an external authentication mechanism
want it in addition to rt internal authentication or instead of it?
Additionally, will all users use the external mechanism or only some users?

We would love to have a combination of external authentication in
addition to the internal auth mechanisim. That way we could let our
existing users use their ordinary UNIX (or more precisly Kerberos IV/V)
usernames/passwords (of course using SSL).

One other thing I relly would like to see in rt 2.0 is a way to use a
“self” user and password for every ticket. I.e when you are opening a
ticket in rt you get, in addition to the ticket number, a uniqe password.
With the ticket number and password you can authenticate yourself to the
ticket and view and add more info to the ticket.

/torkel

PAM would work (ie: pam_mysql.so).

_F

At 02:28 PM 5/3/00 +0200, Björn Torkelsson wrote:

One other thing I relly would like to see in rt 2.0 is a way to use a
“self” user and password for every ticket. I.e when you are opening a
ticket in rt you get, in addition to the ticket number, a uniqe password.
With the ticket number and password you can authenticate yourself to the
ticket and view and add more info to the ticket.

Yes, it is important. We did think a bit about this approach (having some
kind of ticket-password which gave access only to one ticket) as an add-on
to 1.0, but I guess we have more or less forgotten about it.

Jesse is currently working on a new and improved ACL system - though
simpler than the thoughts I have aired here earlier. It’s loosely
documented in docs/design_docs/acl (i.e. from the CVS, tag rt-1-1).

There will be less difference between Requestors and ordinary users, and
there will be possibilities for setting up rights for requestors to see
their own tickets. I’d say adding a random requestor password and sending
it away in an autoreply will be a trivial thing to do through the Scrips
system.

Tobias Brox
aka TobiX
+47 22 925 871

Hi all,

Has anyone got any pointers to settings up a web submission interface to
RT? You know, so that users can fill in a problem request through a form?
I could get it to email the form contents to RT, but perhaps I can submit
the form contents to RT some other way through cgi?

Paul

Has anyone got any pointers to settings up a web submission interface to
RT? You know, so that users can fill in a problem request through a form?
I could get it to email the form contents to RT, but perhaps I can submit
the form contents to RT some other way through cgi?

Attached is something i hacked together to do this. Its ugly, but you
should be able to get it to work without much modification. It uses a
form to collect the info, then directly calls the
(add_request|add_transaction) procedures in rt/database/database.pm.

e

submit.cgi (5.93 KB)

Yeah,
Use expect to run a cli session.
I have a working script that does that, e-mail me for a copy.

-Feargal.

Feargal Reilly,
Systems Administrator,
The Communications Interactive Agency.
Phone: +353-86-8157621On Wed, 03 May 2000, Paul Reilly wrote:

Hi all,

Has anyone got any pointers to settings up a web submission interface to
RT? You know, so that users can fill in a problem request through a form?
I could get it to email the form contents to RT, but perhaps I can submit
the form contents to RT some other way through cgi?

Paul


rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Has anyone got any pointers to settings up a web submission interface to
RT? You know, so that users can fill in a problem request through a form?

RT already comes with a form interface. You can get directly to new
problem entry via:

http://…/rt/webrt.cgi?queue_id=blah&display=Create_Step2

I could get it to email the form contents to RT, but perhaps I can submit
the form contents to RT some other way through cgi?

Indeed you can.

Charlie Brady
Aurema Pty Ltd
PO Box 305, Strawberry Hills, NSW 2012, Australia
Email:charlieb@aurema.com, Tel: +61 2 9698 2322, Fax: +61 2 9699 9174
“I think it would be a good idea.” Gandhi, on Western Civilisation.

Hi

I am having some problems with the web interface

I keep getting File does not exist: /var/www/html/NoAuth

I can’t see why its going to /var/www/html/NoAuth … See config below

Also I get Out of memory!
Callback called exit.

I did have 512Mb RAM so i increased it to 2Gb still the same error

Here is my /etc/http/conf.d/rt3.conf file

Alias /rt3 “/usr/share/rt3/html/share/html”

PerlRequire /usr/share/rt3/html/bin/webmux.pl

AllowOverride All
Options ExecCGI FollowSymLinks

RewriteEngine On
RedirectMatch permanent (.*)/$ $1/index.html
AddDefaultCharset UTF-8
SetHandler perl-script
PerlHandler RT::Mason

Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/