Rights, rights, rights

Hi everyone,

Phew! There are a lot of different ways to setup rights. Our RT 3.6.6
users are checked against our Active Directory server and created
automatically. For some reason when someone sends e-mail, and an account
doesn’t already exist for them, the e-mail fails (I guess this is
because there wasn’t a password to authenticate the user). So I had to
give ‘Everyone’ some permissions.

Here’s what I did… Does anyone see a problem with this?

Configuration → Global → Group Rights:

Everyone
AssignCustomFields
CreateTicket
SeeCustomField

Privileged
AssignCustomFields
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

Requestor
AssignCustomFields
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket

User defined groups: Management
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifyQueueWatchers
ModifySelf
ModifyTicket
OwnTicket
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

User defined groups: RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
DelegateRights
DeleteTicket
EditSavedSearches
LoadSavedSearch
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifySelf
ModifyTemplate
ModifyTicket
OwnTicket
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Queue specific rights are given for groups by queue…

Configuration → Queues → Unix → Group Rights:

User defined groups: Unix
AssignCustomFields
CommentOnTicket
CreateTicket
ModifyTicket
OwnTicket
ReplyToTicket
SeeQueue
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Thanks!
js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastion,

Whew! You have really given alot of people alot of rights. By granting 

“AssignCustomFields” to everyone, you have opened the dor to let every
tom dick and harry create any number of fields for their tickets that
might be redundant to what someone else has created and you have a lot
of redundant, non-centralized, hard to maintain, info flying around that
you have no control over because you gave that control to everyone. If
you like a lot of maintenence work then, I guess that’s ok. You also
grant the same rights for roles that you have already granted to
privileged users. That is also redundant as if they have the right as a
"privileged: user, then they have it, period. They don’t need it again.
That, too, will create a nightmare of debugging as when you make a
rights change in one place and it doesn’t work, you will wonder why.
Typically, or at least for a measure of control, you might want to sit
down and evaluate exactly what you want certain roles to do on which
specific queues, what kind of control you want to have over all of it
and what kind of control you want to have for each queue. Do you want
each queue to be managed and controlled independently of other queues?
What kind of users will have access to each queue? Will there be
“support” groups and “user (requestors)” groups? How much access should
they have in a queue? This is a lot of process and decide on.
What is the purpose or function of your RT installation? What kind of
users will be on the system (i.e. technical support people for each
queue, seperate requestors for each queue, etc.). What kind of
communication do you want for each queue. Do you want requestors to see
technical comments made by technical people that work on the tickets in
a specific queue? Try to define all of this and let me know. I’ll be
able to provide more precise and specific advice when I have that info.

Kenn
LBNLOn 2/6/2008 7:22 AM, Jean-Sebastien Morisset wrote:

Hi everyone,

Phew! There are a lot of different ways to setup rights. Our RT 3.6.6
users are checked against our Active Directory server and created
automatically. For some reason when someone sends e-mail, and an account
doesn’t already exist for them, the e-mail fails (I guess this is
because there wasn’t a password to authenticate the user). So I had to
give ‘Everyone’ some permissions.

Here’s what I did… Does anyone see a problem with this?

Configuration → Global → Group Rights:

Everyone
AssignCustomFields
CreateTicket
SeeCustomField

Privileged
AssignCustomFields
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

Requestor
AssignCustomFields
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket

User defined groups: Management
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifyQueueWatchers
ModifySelf
ModifyTicket
OwnTicket
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

User defined groups: RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
DelegateRights
DeleteTicket
EditSavedSearches
LoadSavedSearch
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifySelf
ModifyTemplate
ModifyTicket
OwnTicket
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Queue specific rights are given for groups by queue…

Configuration → Queues → Unix → Group Rights:

User defined groups: Unix
AssignCustomFields
CommentOnTicket
CreateTicket
ModifyTicket
OwnTicket
ReplyToTicket
SeeQueue
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Thanks!
js.

Hi everyone,

Phew! There are a lot of different ways to setup rights. Our RT 3.6.6
users are checked against our Active Directory server and created
automatically. For some reason when someone sends e-mail, and an account
doesn’t already exist for them, the e-mail fails (I guess this is
because there wasn’t a password to authenticate the user). So I had to
give ‘Everyone’ some permissions.

Here’s what I did… Does anyone see a problem with this?
Several:

  • see comments below inlined

  • as almost all privileged users have right to reply to tickets then
    most probably Ccs and AdminCcs lists of your tickets will be a big
    mess. With this right granted directly to groups people don’t have to
    add themself as watchers (Owner, Ccs, AdminCcs) to reply to a ticket.
    That’s often result in double replies from different persons, people
    don’t get notifications as they’re not associated with tickets in any
    way.

  • do you really want to grant all those SeeScrip, Template and bla-bla
    to mortals who really don’t care about managing RT instance?

Configuration → Global → Group Rights:

Everyone
AssignCustomFields
drop this

CreateTicket
SeeCustomField

Privileged
AssignCustomFields
drop this, most probably you want to leave it for admins only

CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

Requestor
AssignCustomFields
drop this!

CreateSavedSearch
drop this, makes not much sense

CreateTicket
drop this. useless

EditSavedSearches
LoadSavedSearch
drop both

ModifySelf
drop this

ReplyToTicket
SeeCustomField
SeeGroup
drop this

SeeQueue
drop this

ShowSavedSearches
drop this

ShowTicket

User defined groups: Management
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifyQueueWatchers
ModifySelf
ModifyTicket
OwnTicket
ReplyToTicket
SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

User defined groups: RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
CommentOnTicket
CreateSavedSearch
CreateTicket
DelegateRights
DeleteTicket
EditSavedSearches
LoadSavedSearch
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifySelf
ModifyTemplate
ModifyTicket
OwnTicket
do you really want your admins to own tickets? then add them to two
groups instead of granting them this right. People often make mistakes
and add admins as owners when really they don’t care at all about
tickets.

ReplyToTicket
the same as above and other rights like StealTicket

SeeCustomField
SeeGroup
SeeQueue
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Queue specific rights are given for groups by queue…

Configuration → Queues → Unix → Group Rights:

User defined groups: Unix
AssignCustomFields
CommentOnTicket
CreateTicket
ModifyTicket
OwnTicket
ReplyToTicket
SeeQueue
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments
StealTicket
TakeTicket
Watch
WatchAsAdminCc

Thanks!
js.

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

Whew! You have really given alot of people alot of rights.

Kenneth and Ruslan,

Thanks for your feedback! I did a lot of testing, and wasn’t sure if you
inherited rights or not, so many of the basic rights were duplicated.
Thanks for explaining that bit. :slight_smile:

Ok, so a brief description of our processes is in order… It’s very
simple really… Anyone can open a ticket. Requestors should be able to
view and reply to their own ticket. Anyone else should be able to view
all tickets, add themselves as CC, but not modify tickets that aren’t
theirs. We have 3-4 queues, and most of the requests will be coming in
by e-mail, sorted (by procmail), and a ticket opened in the appropriate
queue. Specific groups, like “Telecom” for example, have priviledges to
work on tickets in their own queue (also called “Telecom”). They should
also be able to transfer tickets to other queues in case someone sent
their e-mail to the wrong queue. The “Management” group should have the
ability to modify any ticket in any queue.

So, in a nutshell, that’s about it.

After your comments, I made the following adjustments:

Configuration → Global → Group Rights:

Everyone
CreateTicket
SeeCustomField

Privileged
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

User defined groups: Management
ModifyQueueWatchers
ModifyTicket
OwnTicket
ReplyToTicket
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

There’s also an RT-Admin group to manage users and RT configs:

RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifyTemplate
ModifyTicket
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments

For each Queue (“Telecom” in this example), I have additional rights for
the associated group. I’ve specified some AdminCCs by default because
we’re transitioning from an e-mail based process. Eventually I’ll remove
the AdminCCs and create a Scrip/Template to e-mail the group members
when a ticket is created in their queue. After that it’ll be up to them
to decide if they want to own the ticket or add themselves as Ccs or
AdminCcs.

Configuration → Queues → Telecom → Watchers:

Administrative Cc:
Telecom
Management

Configuration → Queues → Telecom → Group Rights:

User defined groups: Telecom
CommentOnTicket
ModifyTicket
OwnTicket
ReplyToTicket
ShowOutgoingEmail
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

BTW, I appreciate your time with this. The faster I can tweak this
config, the better chance it’ll be adopted. Our current e-mail based
process has to go… :slight_smile:

I should also mention that I’ve configured the ___Approval queue. For
some reason it’s showing up on the user’s home page. I thought the
___Approval queue would be hidden… Should it be?

I’m still tweaking the approval process. There’s some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip “On Create Notify AdminCcs with template Transaction” and the
___Approval queue scrip “On Create Notify AdminCcs with template New
Pending Approval”. It looks like I’ll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

Thanks!
js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

js,

My RightsMatrix RT extension can help with understanding and assigning
rights.

For example you can use it to assign right to a group and then look at
individuals in that group to make sure they have the right you assigned and
exactly how they got that right.

-ToddOn 2/7/08, Jean-Sebastien Morisset jsmoriss@mvlan.net wrote:

On Wed, Feb 06, 2008 at 11:19:48AM -0800, Kenneth Crocker wrote:

  Whew! You have really given alot of people alot of rights.

Kenneth and Ruslan,

Thanks for your feedback! I did a lot of testing, and wasn’t sure if you
inherited rights or not, so many of the basic rights were duplicated.
Thanks for explaining that bit. :slight_smile:

Ok, so a brief description of our processes is in order… It’s very
simple really… Anyone can open a ticket. Requestors should be able to
view and reply to their own ticket. Anyone else should be able to view
all tickets, add themselves as CC, but not modify tickets that aren’t
theirs. We have 3-4 queues, and most of the requests will be coming in
by e-mail, sorted (by procmail), and a ticket opened in the appropriate
queue. Specific groups, like “Telecom” for example, have priviledges to
work on tickets in their own queue (also called “Telecom”). They should
also be able to transfer tickets to other queues in case someone sent
their e-mail to the wrong queue. The “Management” group should have the
ability to modify any ticket in any queue.

So, in a nutshell, that’s about it.

After your comments, I made the following adjustments:

Configuration → Global → Group Rights:

Everyone
CreateTicket
SeeCustomField

Privileged
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

User defined groups: Management
ModifyQueueWatchers
ModifyTicket
OwnTicket
ReplyToTicket
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

There’s also an RT-Admin group to manage users and RT configs:

RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifyTemplate
ModifyTicket
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments

For each Queue (“Telecom” in this example), I have additional rights for
the associated group. I’ve specified some AdminCCs by default because
we’re transitioning from an e-mail based process. Eventually I’ll remove
the AdminCCs and create a Scrip/Template to e-mail the group members
when a ticket is created in their queue. After that it’ll be up to them
to decide if they want to own the ticket or add themselves as Ccs or
AdminCcs.

Configuration → Queues → Telecom → Watchers:

Administrative Cc:
Telecom
Management

Configuration → Queues → Telecom → Group Rights:

User defined groups: Telecom
CommentOnTicket
ModifyTicket
OwnTicket
ReplyToTicket
ShowOutgoingEmail
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

BTW, I appreciate your time with this. The faster I can tweak this
config, the better chance it’ll be adopted. Our current e-mail based
process has to go… :slight_smile:

I should also mention that I’ve configured the ___Approval queue. For
some reason it’s showing up on the user’s home page. I thought the
___Approval queue would be hidden… Should it be?

I’m still tweaking the approval process. There’s some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip “On Create Notify AdminCcs with template Transaction” and the
___Approval queue scrip “On Create Notify AdminCcs with template New
Pending Approval”. It looks like I’ll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

Thanks!
js.

Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

[snip!]

I should also mention that I’ve configured the ___Approval queue. For
some reason it’s showing up on the user’s home page. I thought the
___Approval queue would be hidden… Should it be?

I’m still tweaking the approval process. There’s some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip “On Create Notify AdminCcs with template Transaction” and the
___Approval queue scrip “On Create Notify AdminCcs with template New
Pending Approval”. It looks like I’ll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

I might as well explain how I configured the Approval process too. :slight_smile:

Configuration → Global → Scrips:

On ApprovlReq Create Tickets with template Create Approval
(I ran an insert in the DB for this. It seems to work fine.)

Configuration → Global → Templates:

Create Approval
===Create-Ticket: management-approvalSubject: Approval for Ticket #{$Tickets{“TOP”}->Id}: {$Tickets{‘TOP’}->Subject}
Queue: ___Approvals
Type: approval
Owner: Nobody
Cc: {$Tickets{‘TOP’}->RequestorAddresses}
Cc: {$Tickets{‘TOP’}->OwnerObj->EmailAddress}
DependedOnBy: {$Tickets{“TOP”}->Id}
RefersTo: {$Tickets{“TOP”}->Id}
CustomField1: {$Tickets{‘TOP’}->FirstCustomFieldValue(‘1’)}
CustomField5: {$Tickets{‘TOP’}->FirstCustomFieldValue(‘5’)}
ContentType: text/plain
Content: A request regarding “{$Tickets{‘TOP’}->Subject}” in the {$Tickets{‘TOP’}->QueueObj->Name} queue needs management approval. Please approve / resolve or reject this ticket to proceed.

Original Ticket Request:

{$Tickets{'TOP'}->Transactions->First->Content}
ENDOFCONTENT

At one point I tried using an AdminCc with the ‘Management’ group
members, but instead I’ve listed the Management group as Admin Watchers
for the ___Approval queue…

Configuration → Queues → ___Approvals → Watchers:

Administrative Cc:
Management

Configuration → Queues → ___Approvals → Group Rights:

User defined groups: Management
CommentOnTicket
ModifyTicket
OwnTicket
ReplyToTicket
ShowTicket
ShowTicketComments
StealTicket
TakeTicket

Configuration → Queues → ___Approvals → Scrips:

On Create Notify AdminCcs with template New Pending Approval
(This conflicts with a global 'On Create' scrip.)

Configuration → Queues → ___Approvals → Templates:

New Pending Approval
Subject: New Pending Approval: {$Ticket->Subject}

There is a new item pending your approval: "{$Ticket->Subject()}",
a summary of which appears below.

Please visit the following URL to approve or reject this ticket.
You can also use {$RT::WebURL}Approvals/ to batch-process all your
pending approvals.

Ticket Approval URL:
{$RT::WebURL}Approvals/Display.html?id={$Ticket->id}

{$Transaction->Content()}

So… What do you think? On the right track? Off the track a bit? :slight_smile:

Thanks,
js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien,

It looks better, that's for sure. Let me show what I have, with an 

explanation for why, and you can take it from there, Obviously, every
installation will have it’s different infrastructure needs, but on the
whole, what I’m doing and (more importantly) WHY will provide more
instruction and understanding of how these rights work. I’m absolutely
sure that anyone who has used RT with more than 10 queues (especially
for technical support) for more than a couple years would be able to
show you the same stuff as I’m about to. Here we go:

Global Rights:
1. Everyone: none. We only allow privileged users to use our system and
anyone with an LDAP userID and password can sign on and become one.
2. Privileged: “CreateSavedSearch”, “EditSavedSearch”,
LoadSavedSearch", “ShowSavedSearch”, and “ModifySelf”. With the
exception of “ModifySelf”, these rights get (to use your term) INHERITED
the moment a user has the rights to see tickets in a queue. Rather than
setting up these rights at the queue level for specific groups or roles,
I did it once at the Global level because without the rights to see
tickets at the queue level, they are meaningless. That way, I can focus
on ticket rights at the queue level without adding search rights.
“ModifySelf” is required for us because we want people (LDAP) to be able
to sign-in themselves and this right allows that within our “AutoCreate”
set up.
3. Unprivileged: none. This entity does not exist in our system.

Roles:
1. AdminCc: We use the AdminCc as a “Queue Manager”. So there are some
rights we grant globally because it would be redundant at the queue
level and some at the queue level for security reasons. For example, if
we granted “ModifyTicket” for the AdminCc at the Global level, then this
person could modify a ticket in a queue they do NOT manage.
“AdminGroupMembership” - we allow our Queue managers to add users to
any group they see fit. It’s based on their own need and that way I
don’t have to go around adding users to groups all the time. Let them do
the work.
“AssighCustomFields” - we grant this right because we don’t want Tom,
Dick, and Harry creating a bunch of misnamed, misused, redundant Custom
Fields and then have to undo the mess. This allows the AdminCc to see
any and all Custom Fields and use what they need for their queue.
“DelegateRights” - we grant this right because it allows the AdminCc to
“grant” rights (up to and only those granted TO the AdminCc) to groups
that will be accessing that particular queue.
“ModifyACL” - This allows the AdminCc to modify any ACL (Access Control
List) that they create.
“ModifyOwnMembership” - allows modification of membership of any group.
“SeeGroup” - We want all Queue managers/AdminCc’s to see all groups.
They may need to give one rights to their queue and I don’t want to have
to do it.
“ShowConfigTab” - AHA! This is the right that saves me time as it
allows our Queue Managers to do some of this work (i.e.
AdminGroupMembership).
“ShowScrips” - We want our Queue Managers to know what’s scrips are
blobal and that way they can use them as examples for any “queue-level”
scrip they want to add to their own queue.
“ShowTemplate” - same as above.
“WatchAsAdminCc” - This gives the right to add oneself as an “AdminCc”
of any ticket and therefore receive any correspondence that is normally
sent to AdminCc’s due to scrips for tickets in that queue. Although this
seems like it should be at the queue level, we grant the AdminCc a
certain amount of freedom. Let’s say they are interested in a ticket
they depend on, but is NOT in their queue. They may want to see the
correspondence going on for that ticket.
2. CC: For us, a CC is an “interested” party that wants to receive
communication of what’s going on in a queue.
“ReplyToTicket” - this allows all CC’s for all queues to reply to any
correspondence that is sent to them, regardless of queue. Usually, they
only get the correspondence for the queue they are listed as CC for, so
there’s no problem. However, if they are listed as a CC on a ticket in a
different queue and received email from a ticket, they could now reply.
“SeeQueue” - the CC can look at what tickets are in the queue via
WebUI. By making this right global, it is “inherited” by the CC listed
as a CC watcher for a queue.
“ShowTicket” - the CC can look at each individual ticket in that queue.
By making this right global, it is “inherited” by the CC listed as a CC
watcher for a queue.
“Watch” - the CC can add themselves as the CC on any ticket they might
be interested in.
3. Owner: For us, this is the person that works on the request ticket.
Makes modifications to the ticket to show progress, change status,
dates, etc. “THERE CAN BE ONLY ONE!”. For you “highlander” fans, we feel
that the only person who should have complete modification rights to a
ticket is the owner (and maybe the Queue manager/AdminCc). Therefore, we
grant this right globally to save us the queue level maintenance. When
we create a new queue for a new software application, we DON’T have to
grant this right.
4. Requestor: For us, this is the person making the request/sending in
a email ticket. We want certain rights to be inherited at the queue
level for all requestors, regardless of queue.
“ReplyToTicket” - the ability to correspond about their OWN ticket.
“SeeQueue” - the ability to see their ticket in the queue it was sent to.
“ShowTicket” - the ability to “see” their ticket, depending on what
rights are granted to the requestor at the queue level. For example, one
Queue Manager/AdminCc may grant the right to “ShowTicketComments” and
another may not. So this global right will not grant them the right to
see comments or outgoing email or to comment on a ticket, etc.
“Watch” - As the requestor of “their” ticket, we want them to inherit
the ability to add an interested party as a “cc” on “their” ticket.

Queue-Level Rights: On a queue by queue basis, we let the Queue
Manager/AdminCc grant/modify/remove certain rights for System level
users, Roles, and user-defined groups. An example of these rights follows:

System Groups:
1. Everyone: none.
2. Privileged: “CreateTicket”. This right is not granted on the global
level because there are some queues that do NOT WANT to get tickets from
just anyone. So we let them decide. If they do, they grant that
privilege here. If not, they grant it to certain user-defined groups.
3. UnPrivileged: none.

Roles:
1. AdminCc; Again, for us, the AdminCc is the “BOSS” of a queue. They
create, assign, delete tickets. We grant these rights at the queue level
because it might cause trouble at the global level (or already HAS):
“CreateTicket” - the AdminCc of a queue should be able to create ticket
for their own support team/group.
“DeleteTicket” - same as above.
“ModifyACL” - Same as global right but at queue-level. This keeps
AdminCc’s of other queues from messing with the rights in other queues.
“ModifyQueueWatchers” - again, for THIS queue, we want the AdminCc to
decide who can use “their” queue.
“ModifyTickets” - This allows the queue manager to override dates, etc.
on a ticket in the queue they manage, not just the owner.
“ShowACL” - let’s the boss see what’s up in “their” queue.
“StealTicket” - the boss can also “re-assign” a ticket to a different
team/group member.
2. CC; usually none. We do have a few queues where the AdminCc wants
the CC to see any correspondence they get so they grant “WatchAsAdminCc”.
3. Owner; Maybe “DeleteTicket”. It depends on how the AdminCc wants to
manage the tickets. Sometimes only the AdminCc can delete a ticket.
4. Requestor; In addition to the global rights they inherit, the
AdminCc may allow them to:
“CommentOnTicket” - this let’s the requestor add their own comments to
a ticket without letting them “Modify” a ticket in other areas.
“ShowOutgoingEmail” - this allows the requestor to see the
correspondence on a ticket. Some queue managers may NOT want that.
“ShowTicketComments” - this allows the requestor to see the comments
made on a ticket. Some queue managers may NOT want that (nasty comments
about the IQ of the requestor) so it isn’t granted at all.

User-Defined Groups: For each queue (1 queue per application software),
there is (usually) 1 or more user groups that can send/create tickets.
There is only 1 group that is allowed to do the technical support. So,
the rights granted a specific to queue/function.
1. User (requeator) group: these are the users that the queue manager
allows to create request tickets. Their rights are:
“CommentOnTicket” - well, maybe. Depends on the boss.
“CreateTicket” - well, duh. that’s the whole point here.
“ReplyToTIcket” - this may seem redundant to the same right for
requestors. NOT. It allows OTHER members of the requestor users group to
respond to ticket correspondence on ticket they did NOT send/create. If
the ticket is part of a project that has bunchs of children and
dependencies, I may want all members ot that request “group” to
participate at this level.
“SeeQueue” - allows all members of the group (not just the requestor)
to see what’s in the queue.
“ShowOutgoingEmail” - this allows the group to see the correspondence
on a ticket. Some queue managers may NOT want that.
“ShowTicket” - this allows the group to see any ticket in the queue.
Some queue managers may NOT want that.
“ShowTicketComments” - this allows the group to see the comments made
on a ticket. Some queue managers may NOT want that (nasty comments about
the IQ of the requestor) so it isn’t granted at all.
“Watch” - same as global right but just for this queue/group.

2.Support group (usually technical support): we have only one of these 

per queue. We don’t want others fooling around and messing with tickets
they are not supporting.
“CommentOnTicket” - everyone in the group can add their comments to any
ticket in the queue. Support on a project level may easily need this.
“CreateTicket” love those children.
“OwnTicket” - obvious.
“ReplyToTicket”, “SeeQueue”, “ShowOutGoingEmail”, “ShowTicket”,
“ShowTicketCOmments”, “StealTicket” (maybe. if the boss allows),
“TakeTicket”, “Watch” - these are all pretty self explanatory and we
want our support team to be able to have them.

Anyway, after reading this you should be able to evaluate your needs 

(in terms of rights) a little better. Hope it helps.

Kenn
LBNLOn 2/7/2008 7:09 AM, Jean-Sebastien Morisset wrote:

On Wed, Feb 06, 2008 at 11:19:48AM -0800, Kenneth Crocker wrote:

Whew! You have really given alot of people alot of rights.

Kenneth and Ruslan,

Thanks for your feedback! I did a lot of testing, and wasn’t sure if you
inherited rights or not, so many of the basic rights were duplicated.
Thanks for explaining that bit. :slight_smile:

Ok, so a brief description of our processes is in order… It’s very
simple really… Anyone can open a ticket. Requestors should be able to
view and reply to their own ticket. Anyone else should be able to view
all tickets, add themselves as CC, but not modify tickets that aren’t
theirs. We have 3-4 queues, and most of the requests will be coming in
by e-mail, sorted (by procmail), and a ticket opened in the appropriate
queue. Specific groups, like “Telecom” for example, have priviledges to
work on tickets in their own queue (also called “Telecom”). They should
also be able to transfer tickets to other queues in case someone sent
their e-mail to the wrong queue. The “Management” group should have the
ability to modify any ticket in any queue.

So, in a nutshell, that’s about it.

After your comments, I made the following adjustments:

Configuration → Global → Group Rights:

Everyone
CreateTicket
SeeCustomField

Privileged
CreateSavedSearch
CreateTicket
EditSavedSearches
LoadSavedSearch
ModifySelf
SeeCustomField
SeeGroup
SeeQueue
ShowSavedSearches
ShowTicket
Watch

User defined groups: Management
ModifyQueueWatchers
ModifyTicket
OwnTicket
ReplyToTicket
ShowACL
ShowOutgoingEmail
ShowScrips
ShowTemplate
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

There’s also an RT-Admin group to manage users and RT configs:

RT-Admin
AdminAllPersonalGroups
AdminCustomField
AdminGroup
AdminGroupMembership
AdminOwnPersonalGroups
AdminQueue
AdminUsers
AssignCustomFields
ModifyACL
ModifyCustomField
ModifyOwnMembership
ModifyQueueWatchers
ModifyScrips
ModifyTemplate
ModifyTicket
ShowACL
ShowConfigTab
ShowOutgoingEmail
ShowSavedSearches
ShowScrips
ShowTemplate
ShowTicket
ShowTicketComments

For each Queue (“Telecom” in this example), I have additional rights for
the associated group. I’ve specified some AdminCCs by default because
we’re transitioning from an e-mail based process. Eventually I’ll remove
the AdminCCs and create a Scrip/Template to e-mail the group members
when a ticket is created in their queue. After that it’ll be up to them
to decide if they want to own the ticket or add themselves as Ccs or
AdminCcs.

Configuration → Queues → Telecom → Watchers:

Administrative Cc:
Telecom
Management

Configuration → Queues → Telecom → Group Rights:

User defined groups: Telecom
CommentOnTicket
ModifyTicket
OwnTicket
ReplyToTicket
ShowOutgoingEmail
ShowTicketComments
StealTicket
TakeTicket
WatchAsAdminCc

BTW, I appreciate your time with this. The faster I can tweak this
config, the better chance it’ll be adopted. Our current e-mail based
process has to go… :slight_smile:

I should also mention that I’ve configured the ___Approval queue. For
some reason it’s showing up on the user’s home page. I thought the
___Approval queue would be hidden… Should it be?

I’m still tweaking the approval process. There’s some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip “On Create Notify AdminCcs with template Transaction” and the
___Approval queue scrip “On Create Notify AdminCcs with template New
Pending Approval”. It looks like I’ll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

Thanks!
js.

Jean-Sebastien,

I've heard of manywho have trouble getting rights to act consistently 

at the approvals level. That’s why I created my own approvals method by
just setting up a “regular” queue to collect the tickets initially and
then granting the appropriate rights. When approved, the person
approving can move the ticket to the correct queue OR a scrip could do
it if there was a simple choice of where. This makes it simple AND the
ticket number remains the same from approval to support and audit
doesn’t get confused.

Kenn
LBNLOn 2/7/2008 7:24 AM, Jean-Sebastien Morisset wrote:

On Thu, Feb 07, 2008 at 03:09:54PM +0000, Jean-Sebastien Morisset wrote:

On Wed, Feb 06, 2008 at 11:19:48AM -0800, Kenneth Crocker wrote:
[snip!]
I should also mention that I’ve configured the ___Approval queue. For
some reason it’s showing up on the user’s home page. I thought the
___Approval queue would be hidden… Should it be?

I’m still tweaking the approval process. There’s some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip “On Create Notify AdminCcs with template Transaction” and the
___Approval queue scrip “On Create Notify AdminCcs with template New
Pending Approval”. It looks like I’ll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

I might as well explain how I configured the Approval process too. :slight_smile:

Configuration → Global → Scrips:

On ApprovlReq Create Tickets with template Create Approval
(I ran an insert in the DB for this. It seems to work fine.)

Configuration → Global → Templates:

Create Approval
===Create-Ticket: management-approval
Subject: Approval for Ticket #{$Tickets{“TOP”}->Id}: {$Tickets{‘TOP’}->Subject}
Queue: ___Approvals
Type: approval
Owner: Nobody
Cc: {$Tickets{‘TOP’}->RequestorAddresses}
Cc: {$Tickets{‘TOP’}->OwnerObj->EmailAddress}
DependedOnBy: {$Tickets{“TOP”}->Id}
RefersTo: {$Tickets{“TOP”}->Id}
CustomField1: {$Tickets{‘TOP’}->FirstCustomFieldValue(‘1’)}
CustomField5: {$Tickets{‘TOP’}->FirstCustomFieldValue(‘5’)}
ContentType: text/plain
Content: A request regarding “{$Tickets{‘TOP’}->Subject}” in the {$Tickets{‘TOP’}->QueueObj->Name} queue needs management approval. Please approve / resolve or reject this ticket to proceed.

Original Ticket Request:

{$Tickets{'TOP'}->Transactions->First->Content}
ENDOFCONTENT

At one point I tried using an AdminCc with the ‘Management’ group
members, but instead I’ve listed the Management group as Admin Watchers
for the ___Approval queue…

Configuration → Queues → ___Approvals → Watchers:

Administrative Cc:
Management

Configuration → Queues → ___Approvals → Group Rights:

User defined groups: Management
CommentOnTicket
ModifyTicket
OwnTicket
ReplyToTicket
ShowTicket
ShowTicketComments
StealTicket
TakeTicket

Configuration → Queues → ___Approvals → Scrips:

On Create Notify AdminCcs with template New Pending Approval
(This conflicts with a global 'On Create' scrip.)

Configuration → Queues → ___Approvals → Templates:

New Pending Approval
Subject: New Pending Approval: {$Ticket->Subject}

There is a new item pending your approval: "{$Ticket->Subject()}",
a summary of which appears below.

Please visit the following URL to approve or reject this ticket.
You can also use {$RT::WebURL}Approvals/ to batch-process all your
pending approvals.

Ticket Approval URL:
{$RT::WebURL}Approvals/Display.html?id={$Ticket->id}

{$Transaction->Content()}

So… What do you think? On the right track? Off the track a bit? :slight_smile:

Thanks,
js.

Todd,

I'm about to install 3.6.4. I have Rights Matrix running in 3.4.4 now. 

Is there anything I need to do when I install 3.6.4 to keep my the
“MATRIX” (he he. sorry. I couldn’t help it) running?

Kenn
LBNLOn 2/7/2008 8:10 AM, Todd Chapman wrote:

js,

My RightsMatrix RT extension can help with understanding and assigning
rights.

For example you can use it to assign right to a group and then look at
individuals in that group to make sure they have the right you assigned
and exactly how they got that right.

RTx::RightsMatrix - Bulk editing GUI for RT rights - metacpan.org

-Todd

On 2/7/08, Jean-Sebastien Morisset <jsmoriss@mvlan.net mailto:jsmoriss@mvlan.net> wrote:

On Wed, Feb 06, 2008 at 11:19:48AM -0800, Kenneth Crocker wrote:
 >
 >       Whew! You have really given alot of people alot of rights.

Kenneth and Ruslan,

Thanks for your feedback! I did a lot of testing, and wasn't sure if you
inherited rights or not, so many of the basic rights were duplicated.
Thanks for explaining that bit. :-)

Ok, so a brief description of our processes is in order... It's very
simple really... Anyone can open a ticket. Requestors should be able to
view and reply to their own ticket. Anyone else should be able to view
all tickets, add themselves as CC, but not modify tickets that aren't
theirs. We have 3-4 queues, and most of the requests will be coming in
by e-mail, sorted (by procmail), and a ticket opened in the appropriate
queue. Specific groups, like "Telecom" for example, have priviledges to
work on tickets in their own queue (also called "Telecom"). They should
also be able to transfer tickets to other queues in case someone sent
their e-mail to the wrong queue. The "Management" group should have the
ability to modify any ticket in any queue.

So, in a nutshell, that's about it.

After your comments, I made the following adjustments:

Configuration -> Global -> Group Rights:

Everyone
    CreateTicket
    SeeCustomField

Privileged
    CreateSavedSearch
    CreateTicket
    EditSavedSearches
    LoadSavedSearch
    ModifySelf
    SeeCustomField
    SeeGroup
    SeeQueue
    ShowSavedSearches
    ShowTicket
    Watch

User defined groups: Management
    ModifyQueueWatchers
    ModifyTicket
    OwnTicket
    ReplyToTicket
    ShowACL
    ShowOutgoingEmail
    ShowScrips
    ShowTemplate
    ShowTicketComments
    StealTicket
    TakeTicket
    WatchAsAdminCc

There's also an RT-Admin group to manage users and RT configs:

RT-Admin
    AdminAllPersonalGroups
    AdminCustomField
    AdminGroup
    AdminGroupMembership
    AdminOwnPersonalGroups
    AdminQueue
    AdminUsers
    AssignCustomFields
    ModifyACL
    ModifyCustomField
    ModifyOwnMembership
    ModifyQueueWatchers
    ModifyScrips
    ModifyTemplate
    ModifyTicket
    ShowACL
    ShowConfigTab
    ShowOutgoingEmail
    ShowSavedSearches
    ShowScrips
    ShowTemplate
    ShowTicket
    ShowTicketComments

For each Queue ("Telecom" in this example), I have additional rights for
the associated group. I've specified some AdminCCs by default because
we're transitioning from an e-mail based process. Eventually I'll remove
the AdminCCs and create a Scrip/Template to e-mail the group members
when a ticket is created in their queue. After that it'll be up to them
to decide if they want to own the ticket or add themselves as Ccs or
AdminCcs.

Configuration -> Queues -> Telecom -> Watchers:

Administrative Cc:
    Telecom
    Management

Configuration -> Queues -> Telecom -> Group Rights:

User defined groups: Telecom
    CommentOnTicket
    ModifyTicket
    OwnTicket
    ReplyToTicket
    ShowOutgoingEmail
    ShowTicketComments
    StealTicket
    TakeTicket
    WatchAsAdminCc

BTW, I appreciate your time with this. The faster I can tweak this
config, the better chance it'll be adopted. Our current e-mail based
process has to go... :-)

I should also mention that I've configured the ___Approval queue. For
some reason it's showing up on the user's home page. I thought the
___Approval queue would be hidden... Should it be?

I'm still tweaking the approval process. There's some conflicts between
the global scrips and the approval queue scrips. For example, the global
scrip "On Create Notify AdminCcs with template Transaction" and the
___Approval queue scrip "On Create Notify AdminCcs with template New
Pending Approval". It looks like I'll have to move that global scrip
into each queue instead to avoid duplicate e-mails with the ___Approval
queue.

Thanks!
js.
--
Jean-Sebastien Morisset, Sr. UNIX Administrator <jsmoriss@mvlan.net
<mailto:jsmoriss@mvlan.net>>
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
<mailto:sales@bestpractical.com>


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Kenneth,

There should be no glitch in the Matrix. No deja vu. :wink:

Now playing: The Kleptones -
Sniffhttp://www.foxytunes.com/artist/the+kleptones/track/sniff
posted with FoxyTunes http://www.foxytunes.com/signatunes/On 2/7/08, Kenneth Crocker KFCrocker@lbl.gov wrote:

Todd,

    I'm about to install 3.6.4. I have Rights Matrix running in 3.4.4now.

Is there anything I need to do when I install 3.6.4 to keep my the
“MATRIX” (he he. sorry. I couldn’t help it) running?

Kenn
LBNL

On 2/7/2008 8:10 AM, Todd Chapman wrote:

js,

My RightsMatrix RT extension can help with understanding and assigning
rights.

For example you can use it to assign right to a group and then look at
individuals in that group to make sure they have the right you assigned
and exactly how they got that right.

RTx::RightsMatrix - Bulk editing GUI for RT rights - metacpan.org

-Todd

Jean-Sebastien,

I’ve heard of manywho have trouble getting rights to act
consistently at the approvals level. That’s why I created my own approvals
method by just setting up a “regular” queue to collect the tickets
initially and then granting the appropriate rights. When approved, the
person approving can move the ticket to the correct queue OR a scrip could
do it if there was a simple choice of where. This makes it simple AND the
ticket number remains the same from approval to support and audit
doesn’t get confused.

Yeah, I seem to be dealing with a few ‘peculiar’ behaviors. For example,
if I add the Management group as AdminCc watchers for the Queue, the
batch Approval feature doesn’t list any tickets. I’ve had to use this in
my approval creation template:

AdminCc: {
my $groupname = ‘Management’;
my $groups = RT::Groups->new( $RT::SystemUser );
$groups->LimitToUserDefinedGroups();
$groups->Limit(
‘FIELD’ => ‘Name’,
‘OPERATOR’ => ‘=’,
‘VALUE’ => $groupname );
$groups->First->Id;
}

Getting the whole Approval thing working is a bit of a chore.

BTW, I found why the ___Approval queue was showing up on the Home page:
Privileged users had SeeQueue globally. I removed that right and added
it back per Queue instead, except for the ___Approval queue, of course.
:slight_smile:

Thanks everyone for your help! It’ll be nice to get this working and get
people’s noses out of their Inbox! :slight_smile:

js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Kenneth,

There should be no glitch in the Matrix. No deja vu. :wink:

Todd,

Nice little module. Thanks! It’s already helped me cleanup a few rights.
:slight_smile:

js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien,

It looks better, that’s for sure. Let me show what I have, with an
explanation for why, and you can take it from there, Obviously, every
installation will have it’s different infrastructure needs, but on the
whole, what I’m doing and (more importantly) WHY will provide more
instruction and understanding of how these rights work. I’m absolutely
sure that anyone who has used RT with more than 10 queues (especially
for technical support) for more than a couple years would be able to
show you the same stuff as I’m about to. Here we go:

Kenneth,

OMG, that’s was an amazing reply! Thanks! I implemented just about
everything, but had to give Everyone access to create tickets. I hadn’t
thought of seperating queue owners into regular and admin - it makes
perfect sense. It also off-loads the tedious maintenance tasks from
myself and the unix guys. :slight_smile:

I have everything working very nicely, thanks to your help. Now I’m
tackling approvals. :slight_smile:

Thanks again,
js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Jean-Sebastien,

Jesse just started up a Library of documentation on ../rt-docs. I have 

a complete RT Queue Admin guide there.

Kenn
LBNLOn 2/8/2008 10:04 AM, Jean-Sebastien Morisset wrote:

On Thu, Feb 07, 2008 at 11:00:04AM -0800, Kenneth Crocker wrote:

Jean-Sebastien,

It looks better, that’s for sure. Let me show what I have, with an
explanation for why, and you can take it from there, Obviously, every
installation will have it’s different infrastructure needs, but on the
whole, what I’m doing and (more importantly) WHY will provide more
instruction and understanding of how these rights work. I’m absolutely
sure that anyone who has used RT with more than 10 queues (especially
for technical support) for more than a couple years would be able to
show you the same stuff as I’m about to. Here we go:

Kenneth,

OMG, that’s was an amazing reply! Thanks! I implemented just about
everything, but had to give Everyone access to create tickets. I hadn’t
thought of seperating queue owners into regular and admin - it makes
perfect sense. It also off-loads the tedious maintenance tasks from
myself and the unix guys. :slight_smile:

I have everything working very nicely, thanks to your help. Now I’m
tackling approvals. :slight_smile:

Thanks again,
js.

Jean-Sebastien,

Jesse just started up a Library of documentation on …/rt-docs. I
have a complete RT Queue Admin guide there.

Thanks Kenneth (and Jesse). Just a little question though…
“…/rt-docs” is relative to what? :slight_smile:

js.
Jean-Sebastien Morisset, Sr. UNIX Administrator jsmoriss@mvlan.net

Todd Chapman wrote:

Kenneth,

There should be no glitch in the Matrix. No deja vu. :wink:

Todd,
I’m attempting to install RTx-RightsMatrix-0.03.00 on top of RT 3.6.5
and make test is bitching wildly! I’m not keen on running a make install
with make test flailing about…

Any thoughts?

Here’s the make test output:

~/RTx-RightsMatrix-0.03.00# make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-MExtUtils::Command::MM” “-e”
“test_harness(0, ‘inc’, ‘blib/lib’, ‘blib/arch’)” t/*.t
t/00setup…Name “RT::DatabaseName” used only once: possible typo
at t/00setup.t line 14.

Must test against rt3regression!

No tests run!

t/00setup…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-178
Failed 178/178 tests, 0.00% okay
t/01groups…Name “RT::DatabaseName” used only once: possible typo
at t/01groups.t line 16.

Must test against rt3regression

No tests run!

t/01groups…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-37
Failed 37/37 tests, 0.00% okay
t/02acl…Name “RT::DatabaseName” used only once: possible typo
at t/02acl.t line 16.

Must test against rt3regression

No tests run!

t/02acl…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-28
Failed 28/28 tests, 0.00% okay
t/03util…Name “RT::DatabaseName” used only once: possible typo
at t/03util.t line 16.

Must test against rt3regression

No tests run!

t/03util…dubious
Test returned status 255 (wstat 65280, 0xff00)
DIED. FAILED tests 1-41
Failed 41/41 tests, 0.00% okay
t/pod-coverage…ok
t/pod…ok
Failed Test Stat Wstat Total Fail List of Failed
t/00setup.t 255 65280 178 356 1-178
t/01groups.t 255 65280 37 74 1-37
t/02acl.t 255 65280 28 56 1-28
t/03util.t 255 65280 41 82 1-41
Failed 4/6 test scripts. 284/290 subtests failed.
Files=6, Tests=290, 3 wallclock secs ( 2.49 cusr + 0.70 csys = 3.19 CPU)
Failed 4/6 test programs. 284/290 subtests failed.
make: *** [test_dynamic] Error 255

Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England