I’m setting up an approval mechanism and was hoping that there was some
way in which I could get an approval ticket owned by a group.
What I’m trying to do is have a ticket require approval, but the
approval can come from any one of several people.
Is this doable?
-Bitt
William Faulk wrote:
I’m setting up an approval mechanism and was hoping that there was some
way in which I could get an approval ticket owned by a group.What I’m trying to do is have a ticket require approval, but the
approval can come from any one of several people.Is this doable?
Hmm. Thinking about it, I could create a queue that only that group can
take ownership of tickets from (or even see for that matter), but since
I really want to do this for a large number of groups, that means a lot
of queues.
So it’s doable, but is there a better way?
-Bitt
William Faulk wrote:
I’m setting up an approval mechanism and was hoping that there was some
way in which I could get an approval ticket owned by a group.What I’m trying to do is have a ticket require approval, but the
approval can come from any one of several people.Is this doable?
Hmm. Thinking about it, I could create a queue that only that group can
take ownership of tickets from (or even see for that matter), but since
I really want to do this for a large number of groups, that means a lot
of queues.So it’s doable, but is there a better way?
RT does not let more than one user or a group to own a ticket. I
think this is a deficiency that could be overcome in RT with some
work but haven’t had time to look into.
What we do is assign the group as an AdminCc role and give that role
proper rights to approve the ticket. I have also hacked RT so that
e-mail alerts will go to a group e-mail address instead of each member
of the group individually. That way the person who is on-call and
monitoring the group mailbox will take care of the ticket.
-Todd
Todd Chapman wrote:
What we do is assign the group as an AdminCc role and give that role
proper rights to approve the ticket.
So you assign the group as AdminCC, or you explode the group members and
add them all as AdminCCs? Assigning the group as AdminCC makes it show
up in the Approval ticket as an AdminCC, but members of the group don’t
seem to have the rights I assigned.
-Bitt
Todd Chapman wrote:
What we do is assign the group as an AdminCc role and give that role
proper rights to approve the ticket.So you assign the group as AdminCC, or you explode the group members and
add them all as AdminCCs? Assigning the group as AdminCC makes it show
up in the Approval ticket as an AdminCC, but members of the group don’t
seem to have the rights I assigned.
Yes, I add the group as an AdminCc and I give the AdminCc role
the necessary rights. I also associate an e-mail address with
the group which is used instead of individual member addresses.
Todd Chapman wrote:
Yes, I add the group as an AdminCc and I give the AdminCc role
the necessary rights. I also associate an e-mail address with
the group which is used instead of individual member addresses.
Okay, I must be being an idiot. I can’t get this to work.
I have a group named Unix. The template by which the Approval ticket
gets created contains the lines:
Queue: CCR-Approval
AdminCC: Unix
My username, wfaulk, is in the group Unix. When I view the approval
ticket as a ticket, it shows “AdminCC: Unix” and “Queue: CCR-Approval”.
I’ve given the AdminCC role every permission on that queue that exists.
(I know I don’t need them all, but I’m debugging.)
The user wfaulk still cannot approve that ticket.
What am I doing wrong?
Thanks so much for the help, BTW. I know I’m being a pain.
-Bitt
PS: Your clock seems to be about 45 minutes slow.
Todd Chapman wrote:
Yes, I add the group as an AdminCc and I give the AdminCc role
the necessary rights. I also associate an e-mail address with
the group which is used instead of individual member addresses.Okay, I must be being an idiot. I can’t get this to work.
I have a group named Unix. The template by which the Approval ticket
gets created contains the lines:Queue: CCR-Approval
AdminCC: UnixMy username, wfaulk, is in the group Unix. When I view the approval
ticket as a ticket, it shows “AdminCC: Unix” and “Queue: CCR-Approval”.I’ve given the AdminCC role every permission on that queue that exists.
(I know I don’t need them all, but I’m debugging.)The user wfaulk still cannot approve that ticket.
What am I doing wrong?
Thanks so much for the help, BTW. I know I’m being a pain.
Can you see the ticket in the approval menu? What is the error
when you try to approve?
My clock is just dandy.
PS: Your clock seems to be about 45 minutes slow.
Oops. You are right, my clock is off.
Todd Chapman wrote:
Can you see the ticket in the approval menu? What is the error
when you try to approve?
Yes. “Approval #12: Permission Denied”
-Bitt
Todd Chapman wrote:
Can you see the ticket in the approval menu? What is the error
when you try to approve?Yes. “Approval #12: Permission Denied”
Did you try logging out and back in? If so, SQL server logs
of the SQL statements would help.
Todd Chapman wrote:
Did you try logging out and back in? If so, SQL server logs
of the SQL statements would help.
Yes. Many times. I’m using SQLite, so there aren’t really any SQL logs
to fall back on, but other rights I’ve assigned seem to work properly.
However, assigning an individual instead of a group as AdminCC with the
same rights doesn’t seem to work, either.
-Bitt
Todd Chapman wrote:
Did you try logging out and back in? If so, SQL server logs
of the SQL statements would help.Yes. Many times. I’m using SQLite, so there aren’t really any SQL logs
to fall back on, but other rights I’ve assigned seem to work properly.
However, assigning an individual instead of a group as AdminCC with the
same rights doesn’t seem to work, either.-Bitt
Approving is just resolving under a different name. Can the user
or member of the group resolve the ticket in the ticket update
page?
Todd Chapman wrote:
Approving is just resolving under a different name. Can the user
or member of the group resolve the ticket in the ticket update
page?
Nope. Nor can I take it.
However, I made a mistake in an earlier statement. If I set the AdminCC
to be an individual user, that user can Approve/Resolve it; I made a
mistake in testing that before.
So, the complete symptom is that if the AdminCC is set to a group,
members of that group do not seem to be given the rights assigned to the
AdminCC role, while they would if they were assigned individually.
I can see that this could be workarounded pretty easily by putting some
perl in the Template to expand the group, but it’d be tidier for it to
just be the group, and it works for you, right?
I’m running RT 3.2.2. Is that the same version you’re running? Maybe
there’s a join that RT is using that isn’t supported by SQLite?
-Bitt
Todd Chapman wrote:
Approving is just resolving under a different name. Can the user
or member of the group resolve the ticket in the ticket update
page?Nope. Nor can I take it.
However, I made a mistake in an earlier statement. If I set the AdminCC
to be an individual user, that user can Approve/Resolve it; I made a
mistake in testing that before.So, the complete symptom is that if the AdminCC is set to a group,
members of that group do not seem to be given the rights assigned to the
AdminCC role, while they would if they were assigned individually.I can see that this could be workarounded pretty easily by putting some
perl in the Template to expand the group, but it’d be tidier for it to
just be the group, and it works for you, right?I’m running RT 3.2.2. Is that the same version you’re running? Maybe
there’s a join that RT is using that isn’t supported by SQLite?-Bitt
The way RT is designed to work members of the group should
have the same rights when the group is assigned as AdminCc
as if the individual members were assigned. It may be a
SQLite problem, but the necessary query isn’t that
complicated.
If SQLite can’t log the queries then maybe DBIx::SearchBuilder
can do it…
Okay, new information. Instead of setting the group Unix as AdminCC, it
created a new unprivileged user “Unix” with the comment “Autocreated
when added as a watcher”.
Are you sure my syntax in the template for setting a group AdminCC is
correct. Do I need to use some perl like $Groups{‘Unix’}->Id or something?
-Bitt
Okay, new information. Instead of setting the group Unix as AdminCC, it
created a new unprivileged user “Unix” with the comment “Autocreated
when added as a watcher”.Are you sure my syntax in the template for setting a group AdminCC is
correct. Do I need to use some perl like $Groups{‘Unix’}->Id or something?-Bitt
Ah! So the AdminCC is not you. I don’t know the template syntax.
To me the standard examples of doing approvals in RT are backwards
so I do them using scrips and custom fields.
You could create the approvals in a different queue that has
queue level AdminCc already set. Or figure out the syntax. I
would but I have to run…
-Todd
Todd Chapman wrote:
Okay, new information. Instead of setting the group Unix as AdminCC, it
created a new unprivileged user “Unix” with the comment “Autocreated
when added as a watcher”.Are you sure my syntax in the template for setting a group AdminCC is
correct. Do I need to use some perl like $Groups{‘Unix’}->Id or something?Ah! So the AdminCC is not you. I don’t know the template syntax.
To me the standard examples of doing approvals in RT are backwards
so I do them using scrips and custom fields.
Uh, what?
The AdminCC cannot be me. I am trying to set it to a group. Or am I
totally missing what you’re saying?
To restate the problem, I want a new ticket created in a certain queue
to automatically generate an approval so that that approval can be
approved by one of multiple people.
You’ve suggested that I can do that by setting the AdminCC for the
approval to a group and giving the AdminCC role approval rights, which
sounds feasible.
But now you’re just realizing that I’m not trying to set the AdminCC to
me? I’m not sure what information has gotten lost.
You could create the approvals in a different queue that has
queue level AdminCc already set.
If I was going to do that, I wouldn’t need to bother with the whole
AdminCC at all. I could just create the approval in a queue where the
appropriate group has rights. But that means a different queue for each
group’s approvals, and that doesn’t sound tidy.
Or figure out the syntax.
Well, it works for a user, as long as I specify the user’s email address
instead of his login ID. What value needs to go in that field in order
for it to reference a group instead?
-Bitt
Well, it works for a user, as long as I specify the user’s email address
instead of his login ID. What value needs to go in that field in order
for it to reference a group instead?-Bitt
I looked into the RT code and think I have an answer. RT is using the
Action/CreateTickets.pm module to do this work. Looking at that
code, the example suggest that AdminCc template field needs to be
an e-mail address, but looking further it takes whatever you
give it and feeds it as arguments to Ticket::Create(). Looking
at that code (Ticket_Overlay.pm) we see that Create tries to do
a LoadOrCreateByEmail for the AdminCcs unless the AdminCc is
a number, in which case it is the PrincipalId of the user/group.
So this is what I would try in your template:
AdminCc: {RT::Group->new($RT::SystemUser)->Load(“Unix”)->PrincipalId()}
Let me know how it works.
-Todd
Todd Chapman wrote:
I looked into the RT code and think I have an answer. RT is using the
Action/CreateTickets.pm module to do this work. Looking at that
code, the example suggest that AdminCc template field needs to be
an e-mail address, but looking further it takes whatever you
give it and feeds it as arguments to Ticket::Create(). Looking
at that code (Ticket_Overlay.pm) we see that Create tries to do
a LoadOrCreateByEmail for the AdminCcs unless the AdminCc is
a number, in which case it is the PrincipalId of the user/group.
That’s quite the research. Thanks.
So this is what I would try in your template:
AdminCc: {RT::Group->new($RT::SystemUser)->Load(“Unix”)->PrincipalId()}
This fails to create the approval at all. Looking in the syslog, it’s
listing the errors:
RT: Group → Load called with a bogus argument (/usr/local/rt3/lib/RT/Group_Overlay.pm:265)
RT: Ticket creation failed: Can’t call method “PrincipalId” on an undefined value at template line 5.
Unix is definitely the name of the group. Maybe that’s not the right
argument? Yeah. Group->Load() takes an ID, which is what we’re trying
to get. Some trial and error reveals that this works, though:
AdminCC: {$g = RT::Group->new($RT::SystemUser), $g->LoadUserDefinedGroup(“Unix”), $g->id}
I couldn’t get it to work as one statement, so I had to split it up like
that.
Both “RT::Group->new($RT::SystemUser)->LoadUserDefinedGroup(“Unix”)->id”
and “$g = RT::Group->new($RT::SystemUser)->LoadUserDefinedGroup(“Unix”),
$g->id” generated errors about “Can’t locate object method “id” via
package “Found Object” (perhaps you forgot to load “Found Object”?) at
template line 5”. Splitting it up fixes it, though, and places the
correct thing in the AdminCC field on the approval; it lists the group
and all the members of the group.
Thanks so much for your help. I’m going to put this in the Wiki.
-Bitt
AdminCC: {$g = RT::Group->new($RT::SystemUser),
$g->LoadUserDefinedGroup(“Unix”), $g->id}I couldn’t get it to work as one statement, so I had to split it up like
that.Both “RT::Group->new($RT::SystemUser)->LoadUserDefinedGroup(“Unix”)->id”
and “$g = RT::Group->new($RT::SystemUser)->LoadUserDefinedGroup(“Unix”),
$g->id” generated errors about “Can’t locate object method “id” via
package “Found Object” (perhaps you forgot to load “Found Object”?) at
template line 5”. Splitting it up fixes it, though, and places the
correct thing in the AdminCC field on the approval; it lists the group
and all the members of the group.Thanks so much for your help. I’m going to put this in the Wiki.
I’m not sure why you would need to split it into two. It looks
like you have a comma between the two statements. It should
be a semicolon.