The company I work for has been using RT strictly as internal company
workflow via the web.
There has recently been a request made to me for including part of the
ticket as secure so that the creator inputs the secure info when it is
in a certain queue, another part of the company (X) also has permission
to use this secure information, but then it gets forwarded to another
part of the company(Y) and they are not allowed to see this information.
This is a complicated situation, and the following questions come to
mind:
how do I limit who can see tickets in a certain queue? Currently
they all have global configuration of ACLs.
Should I create a showSecureInfo and an EditSecureInfo module and it
checks to see who the current viewer is to see whether they can view the
module?
after the ticket’s work has been complete
(status=resolved/status=dead), how should I allow this info to be
viewed? The same as 2)?
should this be done with related tickets, with the secure info going
in one and the task-related work going in another and then linking them?
Would this produce the correct relationship? How would I guarantee that
a user in Y couldn’t see the secure info?
I thought about copying Create.html into another file within an
.htaccess protected directory and forcing all tickets for that queue to
go to that directory (which would require a password), but I’m sure that
will only make things really messy.
how do I limit who can see tickets in a certain queue? Currently
they all have global configuration of ACLs.
Configure rights per queue instead of globally.
Should I create a showSecureInfo and an EditSecureInfo module and it
checks to see who the current viewer is to see whether they can view the
module?
Can you (ab)use Comments for this purpose? ie, give your Secure
people “ShowComment” and not the other group?
after the ticket’s work has been complete
(status=resolved/status=dead), how should I allow this info to be
viewed? The same as 2)?
Business process question.
should this be done with related tickets, with the secure info going
in one and the task-related work going in another and then linking them?
You could do, I guess.
Would this produce the correct relationship? How would I guarantee that
a user in Y couldn’t see the secure info?
Different queues with different access.
I thought about copying Create.html into another file within an
.htaccess protected directory and forcing all tickets for that queue to
go to that directory (which would require a password), but I’m sure that
will only make things really messy.
Don’t go that way.
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
after the ticket’s work has been complete
(status=resolved/status=dead), how should I allow this info to be
viewed? The same as 2)?
Business process question.
I am mostly a lurker here, but wanted to interject on this one.
Business process in relation to a crm environment is a school of thought all
to itself. Perhaps this is worthy of its own mailing list? I am comfortable
with the tech side of things and like to keep up to speed on the add ons and
updates etc, but, being able to compare nontetch notes with others that use
RT in various ways and ask the sort of questions like appears above would be
interesting and useful. It could be something like rt-business?
If this isn’t something Best Practical wants to do I wouldn’t mind hosting
such a mailing list. Assuming 1, its permitted by Jesse & Team and 2, there
is interest here in such a thing. I don¹t want to be the only guy on the
list
Mitchell - count me in. This is the information I am looking for as well.From: Mitchell Wright [mailto:webmaster@nimm.com]
Sent: Friday, December 13, 2002 6:59 AM
To: Phil Homewood; rt-users@lists.fsck.com; rt-devel@lists.fsck.com
Subject: Re: [rt-devel] quandry: secure parts of a ticket… should this be
done with related tickets?
after the ticket’s work has been complete
(status=resolved/status=dead), how should I allow this info to be
viewed? The same as 2)?
Business process question.
I am mostly a lurker here, but wanted to interject on this one.
Business process in relation to a crm environment is a school of thought all
to itself. Perhaps this is worthy of its own mailing list? I am comfortable
with the tech side of things and like to keep up to speed on the add ons and
updates etc, but, being able to compare nontetch notes with others that use
RT in various ways and ask the sort of questions like appears above would be
interesting and useful. It could be something like rt-business?
If this isn’t something Best Practical wants to do I wouldn’t mind hosting
such a mailing list. Assuming 1, its permitted by Jesse & Team and 2, there
is interest here in such a thing. I don¹t want to be the only guy on the
list
-----Original Message-----
From: Phil Homewood [mailto:pdh@snapgear.com]
Sent: Thursday, December 12, 2002 3:08 PM
Colleen wrote:
how do I limit who can see tickets in a certain queue? Currently
they all have global configuration of ACLs.
Configure rights per queue instead of globally.
ok, I tried this. It doesn’t seem to work as expected.
I have 10 users and 5 queues (1 of which is “secure” and should only
allow the 3 users with privileges"), lets say. I took away all their
global rights except for “modify self”.
I put in rights for all 10 users for the 4 ordinary queues and for the
secure queue, I only put permissions in for those 3 users. I logged out
and logged back in as an average user (no secure permissions) and I
tried to ‘Create a Ticket’ in the secure queue. I was allowed to do
this.
Isn’t that odd? How can I fix this?
Should I create a showSecureInfo and an EditSecureInfo module and
it
checks to see who the current viewer is to see whether they can view
the
module?
Can you (ab)use Comments for this purpose? ie, give your Secure
people “ShowComment” and not the other group?
I put in rights for all 10 users for the 4 ordinary queues and for the
secure queue, I only put permissions in for those 3 users. I logged out
and logged back in as an average user (no secure permissions) and I
tried to ‘Create a Ticket’ in the secure queue. I was allowed to do
this.
(You probably want to run those as the unix user corresponding
to your SuperUser, eg. root.)
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
-----Original Message-----
From: Phil Homewood [mailto:pdh@snapgear.com]
Sent: Monday, December 16, 2002 6:23 PM
To: rt-devel@lists.fsck.com
Subject: Re: [rt-devel] quandry: secure parts of a ticket… should
this
be done with related tickets?
Colleen wrote:
I put in rights for all 10 users for the 4 ordinary queues and for
the
secure queue, I only put permissions in for those 3 users. I logged
out
and logged back in as an average user (no secure permissions) and I
tried to ‘Create a Ticket’ in the secure queue. I was allowed to do
this.
Is rtadmin setgid rt?
Is /usr/local/rt/lib/RT/Interface/CLI.pm present?
Does your suidperl work?
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances
Is rtadmin setgid rt?
Is /usr/local/rt/lib/RT/Interface/CLI.pm present?
Does your suidperl work?
And a more subtle gotcha; is /usr/local/rt on a NFS-mounted partition with
root-squash enabled, and is the directory set so that only the RT
user/group can access it?
For that matter, is /usr/local/rt/{etc,lib} the RT directories ?
Bruce Campbell RIPE
Systems/Network Engineer NCC
www.ripe.net - PGP562C8B1B Operations/Security
-----Original Message-----
From: Phil Homewood [mailto:pdh@snapgear.com]
Sent: Monday, December 16, 2002 6:23 PM
To: rt-devel@lists.fsck.com
Subject: Re: [rt-devel] quandry: secure parts of a ticket… should
this
be done with related tickets?
Colleen wrote:
I put in rights for all 10 users for the 4 ordinary queues and for
the
secure queue, I only put permissions in for those 3 users. I logged
out
and logged back in as an average user (no secure permissions) and I
tried to ‘Create a Ticket’ in the secure queue. I was allowed to do
this.
I also re-tried the test of having an unprivaledged user create a ticket
in a queue they do not have rights for. The user is still allowed to do
this, unfortunately.
Sounds like “root” (at the Unix level) doesn’t correspond with
an RT SuperUser. This is getting somewhat hairy, just to fix a
simple sounding problem
Make sure (in the WebUI) that, under Configuration->Users->root,
the “Unix login” field shows “root”. Make sure, also, that
the “Let this user be granted rights” box is checked. You haven’t
toggled root’s “SuperUser” status in the DB, by any chance?
Hmm. All this just to find out the permissions… maybe it’d be
easier just to ask the DB directly…
Phil Homewood, Systems Janitor, www.SnapGear.com pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances