User Rights conundrum

I have a problem that hopefully someone out there can help with :

o Customers submit cases from potentially a variety of email addresses.

o For simplification, we want to give a customer a single login to RT to
check status on tickets.

o We want this login to be able to look at a give queue, and view and
comment on the individual tickets in that queue.

o We don’t want the customer to do or see anything else.

I’ve tried setting up per queue group and user rights to do this but it
seems a little permissive, letting the login look at and modify other
aspects of the ticket.

Because we send mail to this queue, we also have the everyone group setup
with the following rights :

CreateTicket, CommentOnTicket, ReplyToTicket, ModifySelf (to let folks
change passwords)

I don’t know if this is conflicting with the per user rights I want to
setup, or if this is another problem.

Has anyone solved this problem ? Any help gratefully received :slight_smile:

Cheers,

Al

Ignore me… sorry for the spam. The permissions I set do work as expected.

However, the interface still displays a lot of extra (unneeded in this
case) content in the Jumbo, People, Dates tabs etc…

Any simple way to turn this off for a given user ?On Mon, 6 Oct 2003, Alan Horn wrote:

Date: Mon, 6 Oct 2003 14:50:36 -0700 (PDT)
From: Alan Horn ahorn@deorth.org
To: rt-users@lists.fsck.com
Subject: [rt-users] User Rights conundrum…

I have a problem that hopefully someone out there can help with :

o Customers submit cases from potentially a variety of email addresses.

o For simplification, we want to give a customer a single login to RT to
check status on tickets.

o We want this login to be able to look at a give queue, and view and
comment on the individual tickets in that queue.

o We don’t want the customer to do or see anything else.

I’ve tried setting up per queue group and user rights to do this but it
seems a little permissive, letting the login look at and modify other
aspects of the ticket.

Because we send mail to this queue, we also have the everyone group setup
with the following rights :

CreateTicket, CommentOnTicket, ReplyToTicket, ModifySelf (to let folks
change passwords)

I don’t know if this is conflicting with the per user rights I want to
setup, or if this is another problem.

Has anyone solved this problem ? Any help gratefully received :slight_smile:

Cheers,

Al


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

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Ignore me… sorry for the spam. The permissions I set do work as
expected.

However, the interface still displays a lot of extra (unneeded in this
case) content in the Jumbo, People, Dates tabs etc…

Any simple way to turn this off for a given user ?

Did You have a look at the SelfService Interface? It’s easy to miss for
privileged users, but try to open

$WebBaseURL/SelfService/

to see what I mean.

Regards,
Harald

I have a problem that hopefully someone out there can help with :

o Customers submit cases from potentially a variety of email addresses.

o For simplification, we want to give a customer a single login to RT to
check status on tickets.

I have a similar desire, and have been experimenting with a solution
along the following lines:

  • Set permissions so that unprivileged users can use the SelfService
    interface to view their own tickets, and tickets for which they are
    a CC.

  • Create a special RT login for the customer, and let several of the
    customer’s employees share the password. Give this special account
    the ability to access the Selfservice interface. (“Let this user
    access RT”: yes; “Let this user be given rights”: no; Password: not
    null). I’ll call this “user X” below.

  • Let each employee of the customer submit tickets via email as usual.
    The email addresses from which they do this will not have any rights
    in RT (not even the ability to access the SelfService interface). I’ll
    call them users A, B and C below.

  • Write a scrip that adds user X as a CC on tickets created by users
    A, B and C. At present, I have all the email addresses hard coded
    in the scrip, with logic like “if requestor matches this regexp then
    add the following CC”. It would be nice to have a more scalable way
    of doing this, perhaps via extra fields in the database (which the
    scrip could use), or via the “delegation” system (such as a way of
    saying “User A delegates to user X all rights that user A would have
    as the requestor or CC of any ticket”).

  • Now, when users A, B, or C at the customer submit tickets, the scrip
    adds user X as a CC. User X can use the SelfService interface to
    see all the tickets raised by users A, B or C.

–apb (Alan Barrett)