RT For an ISP

Dear All

I am trying to use RT for my dialup clients. I only want my clients to use
the web interface to create tickets and not the email interface. I have
created an unprivileged RT account for each of my users. The problem I have
is that when the user logs on and selects the queue I have provided he/she
can enter any value in the requestor field thus automatically creating a new
user as a watcher. The rightful requestor of the ticket (the account I have
created) cannot actually view the new ticket because he/she has no
permission to view it.
Is there a way of forcing the requestor to be the RT account I have already
created! Keeping in mind that I do not want users seeing all the tickets in
the queue - only their own tickets.
Any hints would be greatly appreciated

Mustafa Badawi

Have you found a fix for this yet?

Mustafa Badawi wrote:

This link might be of help: INPUT - Form Input

You should be able to (and note I havn’t checked this at all) modify the code that shows the ticket creation form and set the READONLY flag on the box for the Requestor.

That way the requestor, autofilled, gets displayed, but the user can’t edit it.

The other way would be to edit the same code, just don’t display the $ticket->requestor (not actual syntax) value in a pre-completed box, just display it as text instead.

So if the code said requestor> change this to just be $ticket->requestor thus removing the ability to change the value.

BenRFrom: rt-users-bounces@lists.bestpractical.com on behalf of Jason Fenner
Sent: Wed 22/02/2006 2:31 AM
To: Mustafa Badawi
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT For an ISP

Have you found a fix for this yet?

Mustafa Badawi wrote:

Dear All

I am trying to use RT for my dialup clients. I only want my clients to use
the web interface to create tickets and not the email interface. I have
created an unprivileged RT account for each of my users. The problem I have
is that when the user logs on and selects the queue I have provided he/she
can enter any value in the requestor field thus automatically creating a new
user as a watcher. The rightful requestor of the ticket (the account I have
created) cannot actually view the new ticket because he/she has no
permission to view it.
Is there a way of forcing the requestor to be the RT account I have already
created! Keeping in mind that I do not want users seeing all the tickets in
the queue - only their own tickets.
Any hints would be greatly appreciated

Mustafa Badawi



The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If you receive it in error, please let us know by reply email, do not disclose any information contained in it, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems.

We give no warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately. Privacy - Please be aware that information provided in response to this email may contain personal information, which Classic Blue may collect, and use for the purposes of marketing information technology products and services to you. For further information regarding Classic Blue’s privacy policies please refer to www.classicblue.com.au

Thanks for your reply.

Actually I was wondering if this could be done by configuring RT itself. It
would be more secure that way. If it is not configurable through RT I think
this would be a major drawback! It would be much more professional if my
clients logon to a self services portal and use it to send their tickets.
Having RT automatically create new users as watchers each time a client uses
a new name/email in the requestor field is nonsense! Moreover, the user gets
an error saying that he has no permissions to view the ticket since I have
only given the requestor the permission to view the ticket and in our case,
the requestor is not the person logged on to RT because he used another
name/email in the requestor field. I might have perceived the system wrongly
but this is the conclusion I came up with. If anyone has other ideas please
let me know.

Mustafa BadawiOn 2/21/06, Ben Robson ben.robson@classicblue.com.au wrote:

This link might be of help:
INPUT - Form Input

You should be able to (and note I havn’t checked this at all) modify the
code that shows the ticket creation form and set the READONLY flag on the
box for the Requestor.

That way the requestor, autofilled, gets displayed, but the user can’t
edit it.

The other way would be to edit the same code, just don’t display the
$ticket->requestor (not actual syntax) value in a pre-completed box,
just display it as text instead.

So if the code said requestor>
change this to just be $ticket->requestor thus removing the ability
to change the value.

BenR


From: rt-users-bounces@lists.bestpractical.com on behalf of Jason Fenner
Sent: Wed 22/02/2006 2:31 AM
To: Mustafa Badawi
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] RT For an ISP

Have you found a fix for this yet?

Mustafa Badawi wrote:

Dear All

I am trying to use RT for my dialup clients. I only want my clients to
use
the web interface to create tickets and not the email interface. I have
created an unprivileged RT account for each of my users. The problem I
have
is that when the user logs on and selects the queue I have provided
he/she
can enter any value in the requestor field thus automatically creating a
new
user as a watcher. The rightful requestor of the ticket (the account I
have
created) cannot actually view the new ticket because he/she has no
permission to view it.
Is there a way of forcing the requestor to be the RT account I have
already
created! Keeping in mind that I do not want users seeing all the tickets
in
the queue - only their own tickets.
Any hints would be greatly appreciated

Mustafa Badawi



The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html


The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If you receive it in error, please let us know by reply email, do not disclose any information contained in it, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems.

We give no warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately. Privacy - Please be aware that information provided in response to this email may contain personal information, which Classic Blue may collect, and use for the purposes of marketing information technology products and services to you. For further information regarding Classic Blue’s privacy policies please refer to
www.classicblue.com.au

Mustafa Badawi wrote:

Thanks for your reply.

Actually I was wondering if this could be done by configuring RT
itself. It would be more secure that way. If it is not configurable
through RT I think this would be a major drawback! It would be much
more professional if my clients logon to a self services portal and
use it to send their tickets. Having RT automatically create new users
as watchers each time a client uses a new name/email in the requestor
field is nonsense!

This may be the case for your application, but in general, autocreating
users is not a bad thing. I would guess that most users of RT have
people email requests in to their system, thereby needing to create
users on the fly. Look around on the wiki. You should be able to
customize that page so that they can not change the contents of the
requestor box. I would recommend looking at
Request Tracker Wiki for more on this.

Moreover, the user gets an error saying that he has no permissions to
view the ticket since I have only given the requestor the permission
to view the ticket and in our case, the requestor is not the person
logged on to RT because he used another name/email in the requestor
field. I might have perceived the system wrongly but this is the
conclusion I came up with. If anyone has other ideas please let me know.

Mustafa Badawi

This link might be of help:
http://www.htmlhelp.com/reference/html40/forms/input.html
 
You should be able to (and note I havn't checked this at all)
modify the code that shows the ticket creation form and set the
READONLY flag on the <INPUT> box for the Requestor.
 
That way the requestor, autofilled, gets displayed, but the user
can't edit it.
 
The other way would be to edit the same code, just don't display
the $ticket->requestor (not actual syntax) value in a
pre-completed <INPUT> box, just display it as text instead.
 
So if the code said <INPUT NAME=requestor
VALUE=$ticket->requestor>  change this to just be
<B>$ticket->requestor</B> thus removing the ability to change the
value.
 
BenR

------------------------------------------------------------------------
*From:* rt-users-bounces@lists.bestpractical.com
<mailto:rt-users-bounces@lists.bestpractical.com> on behalf of
Jason Fenner
*Sent:* Wed 22/02/2006 2:31 AM
*To:* Mustafa Badawi
*Cc:* rt-users@lists.bestpractical.com
<mailto:rt-users@lists.bestpractical.com>
*Subject:* Re: [rt-users] RT For an ISP

Have you found a fix for this yet?

Mustafa Badawi wrote:

>Dear All
>
>I am trying to use RT for my dialup clients. I only want my
clients to use
>the web interface to create tickets and not the email interface. I
have
>created an unprivileged RT account for each of my users. The
problem I have
>is that when the user logs on and selects the queue I have
provided he/she
>can enter any value in the requestor field thus automatically
creating a new
>user as a watcher. The rightful requestor of the ticket (the
account I have
>created) cannot actually view the new ticket because he/she has no
>permission to view it.
>Is there a way of forcing the requestor to be the RT account I
have already
>created! Keeping in mind that I do not want users seeing all the
tickets in
>the queue - only their own tickets.
>Any hints would be greatly appreciated
>
>Mustafa Badawi
>
> 
>
>------------------------------------------------------------------------
>
>_______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>
>Download a free sample chapter of RT Essentials from O'Reilly
Media at http://rtbook.bestpractical.com
>
>WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
>San Francisco - Find out more at
http://bestpractical.com/services/training.html
>


_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
<http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users>

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O'Reilly
Media at http://rtbook.bestpractical.com

WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html

............................................................................................................................

This email (including all attachments) is intended solely for the named addressee. It is confidential and may contain legally privileged information. If you receive it in error, please let us know by reply email, do not disclose any information contained in it, delete it from your system and destroy any copies. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. Emails may be interfered with, may contain computer viruses or other defects and may not be successfully replicated on other systems.



We give no warranties in relation to these matters. If you have any doubts about the authenticity of an email purportedly sent by us, please contact us immediately.  Privacy - Please be aware that information provided in response to this email may contain personal information, which Classic Blue may collect, and use for the purposes of marketing information technology products and services to you.  For further information regarding Classic Blue's privacy policies please refer to 

www.classicblue.com.au <http://www.classicblue.com.au>
............................................................................................................................


The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati

Thanks Drew, but it seems that someone has messed up the link you
provided!!! any mirrors or alternatives?On 2/22/06, Drew Barnes barnesaw@ucrwcu.rwc.uc.edu wrote:

Mustafa Badawi wrote:

Thanks for your reply.

Actually I was wondering if this could be done by configuring RT
itself. It would be more secure that way. If it is not configurable
through RT I think this would be a major drawback! It would be much
more professional if my clients logon to a self services portal and
use it to send their tickets. Having RT automatically create new users
as watchers each time a client uses a new name/email in the requestor
field is nonsense!

This may be the case for your application, but in general, autocreating
users is not a bad thing. I would guess that most users of RT have
people email requests in to their system, thereby needing to create
users on the fly. Look around on the wiki. You should be able to
customize that page so that they can not change the contents of the
requestor box. I would recommend looking at
Request Tracker Wiki for more on
this.

Moreover, the user gets an error saying that he has no permissions to
view the ticket since I have only given the requestor the permission
to view the ticket and in our case, the requestor is not the person
logged on to RT because he used another name/email in the requestor
field. I might have perceived the system wrongly but this is the
conclusion I came up with. If anyone has other ideas please let me know.

Mustafa Badawi

On 2/21/06, Ben Robson < ben.robson@classicblue.com.au mailto:ben.robson@classicblue.com.au> wrote:

This link might be of help:
http://www.htmlhelp.com/reference/html40/forms/input.html

You should be able to (and note I havn't checked this at all)
modify the code that shows the ticket creation form and set the
READONLY flag on the <INPUT> box for the Requestor.

That way the requestor, autofilled, gets displayed, but the user
can't edit it.

The other way would be to edit the same code, just don't display
the $ticket->requestor (not actual syntax) value in a
pre-completed <INPUT> box, just display it as text instead.

So if the code said <INPUT NAME=requestor
VALUE=$ticket->requestor>  change this to just be
<B>$ticket->requestor</B> thus removing the ability to change the
value.

BenR

*From:* rt-users-bounces@lists.bestpractical.com
<mailto:rt-users-bounces@lists.bestpractical.com> on behalf of
Jason Fenner
*Sent:* Wed 22/02/2006 2:31 AM
*To:* Mustafa Badawi
*Cc:* rt-users@lists.bestpractical.com
<mailto:rt-users@lists.bestpractical.com>
*Subject:* Re: [rt-users] RT For an ISP

Have you found a fix for this yet?

Mustafa Badawi wrote:

>Dear All
>
>I am trying to use RT for my dialup clients. I only want my
clients to use
>the web interface to create tickets and not the email interface. I
have
>created an unprivileged RT account for each of my users. The
problem I have
>is that when the user logs on and selects the queue I have
provided he/she
>can enter any value in the requestor field thus automatically
creating a new
>user as a watcher. The rightful requestor of the ticket (the
account I have
>created) cannot actually view the new ticket because he/she has no
>permission to view it.
>Is there a way of forcing the requestor to be the RT account I
have already
>created! Keeping in mind that I do not want users seeing all the
tickets in
>the queue - only their own tickets.
>Any hints would be greatly appreciated
>
>Mustafa Badawi
>
>
>

>
>_______________________________________________
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>Be sure to check out the RT Wiki at http://wiki.bestpractical.com
>
>Download a free sample chapter of RT Essentials from O'Reilly
Media at http://rtbook.bestpractical.com
>
>WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston

and

>San Francisco - Find out more at
http://bestpractical.com/services/training.html
>


_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
<http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users>

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O'Reilly
Media at http://rtbook.bestpractical.com

WE'RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston

and

San Francisco - Find out more at
http://bestpractical.com/services/training.html

This email (including all attachments) is intended solely for the

named addressee. It is confidential and may contain legally privileged
information. If you receive it in error, please let us know by reply email,
do not disclose any information contained in it, delete it from your system
and destroy any copies. This email is also subject to copyright. No part of
it should be reproduced, adapted or transmitted without the written consent
of the copyright owner. Emails may be interfered with, may contain computer
viruses or other defects and may not be successfully replicated on other
systems.

We give no warranties in relation to these matters. If you have any

doubts about the authenticity of an email purportedly sent by us, please
contact us immediately. Privacy - Please be aware that information provided
in response to this email may contain personal information, which Classic
Blue may collect, and use for the purposes of marketing information
technology products and services to you. For further information regarding
Classic Blue’s privacy policies please refer to

www.classicblue.com.au <http://www.classicblue.com.au>



The rt-users Archives

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at
http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at
http://bestpractical.com/services/training.html


Drew Barnes
Applications Analyst
Raymond Walters College
University of Cincinnati

Actually I was wondering if this could be done by configuring RT itself. It
would be more secure that way. If it is not configurable through RT I think
this would be a major drawback! It would be much more professional if my
clients logon to a self services portal and use it to send their tickets.
Having RT automatically create new users as watchers each time a client use=
s
a new name/email in the requestor field is nonsense! Moreover, the user get=

I don't follow your logic.  Obviously each ticket needs to contain
whatever email address was used, so that you can send any response
back to the requestor. 

RT doesn't actually store that email address with the ticket.
Instead, it puts it in a separate table called "Users" and
stores the internal id of the row (user) with the ticket.

Think of it this way -- a watcher or requestor is not
a simple email address, it is a complicated structure that
can hold name, phone, comments, and so on.  And, if a given
watcher ends up connected to many tickets, RT can tell you that.
There is a lot of sense in this design.

You want only the requestor to view the ticket?  You need to
identify the logged-on person, before you can determine what
he is a reqestor for. How else would you do that?  Generally,
if a person uses multiple email addresses, it's quite hard
to know it's the same person.

   bobg

Thanks Drew, but it seems that someone has messed up the link you
provided!!! any mirrors or alternatives?

See the revisions link? You can page thru all the revisions of the wiki
page… if you go back to rev 56 you can see the page as it should exist

http://wiki.bestpractical.com/index.cgi?action=revisions&page_name=Clean
lyCustomizeRT&revision_id=54

I was going to get some editor permissions on the wiki so I could help
clean this stuff up… Just waiting on Jesse :wink: (jesse
is obviously a busy guy)

duncan

See the revisions link? You can page thru all the revisions of the wiki
page… if you go back to rev 56 you can see the page as it should exist

http://wiki.bestpractical.com/index.cgi?action=revisions&page_name=Clean
lyCustomizeRT&revision_id=54

I was going to get some editor permissions on the wiki so I could help
clean this stuff up… Just waiting on Jesse :wink: (jesse
is obviously a busy guy)

I need to find 15 minutes to sit down and write up the “manual” for what
needs doing. But yeah. I’m flying something like 45,000 miles in Q1
2006. Busy is a bit of an understatement. What I really need to do is
actually sit down and write up a couple of job postings.

Jesse