Handling different clients with queues

RTIR
1

Hello all,
I would like to hear opinions on the recommended way of dealing with
incidents from different clients.
I will have various clients each one with a different constituency and
I would like to “isolate” each one with access controls, so I was
thinking of creating multiple incidents queues for each.
I’ve searched the archives and found a message saying that plain
vanilla RTIR wouldn’t be suitable but this was back in 2004.
Thanks.

Cheers,
Colin

2

Hi,

Read documentation in the RTIR tarball about multiple constituencies.On Tue, Jan 31, 2012 at 16:25, Colin colintempler@gmail.com wrote:

Hello all,
I would like to hear opinions on the recommended way of dealing with
incidents from different clients.
I will have various clients each one with a different constituency and
I would like to “isolate” each one with access controls, so I was
thinking of creating multiple incidents queues for each.
I’ve searched the archives and found a message saying that plain
vanilla RTIR wouldn’t be suitable but this was back in 2004.
Thanks.

–
Cheers,
Colin

Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives

Best regards, Ruslan.

3

Hi,

Read documentation in the RTIR tarball about multiple constituencies.

Thank you Ruslan.
Reading through lib/RT/IR/Constituencies.pod, the correct procedure would be:

  • create a new Incident queue for each client
  • create a new constituency for each queue
  • create a new group and users for each queue
    Is that correct?

Also on the documentation I don’t understand this part:
For example the following objects affect the rights users can have to
the constituency ‘EDUNET’:
Queue ‘Incident Reports - EDUNET’ =item * Queue ‘Incidents - EDUNET’
=item * Queue ‘Inestigations - EDUNET’ =item * Queue ‘Blocks - EDUNET’
=item * Group ‘DutyTeam EDUNET’
What are those ‘=item *’ ?

Cheers,
Colin

4

Hi,

Read documentation in the RTIR tarball about multiple constituencies.

Thank you Ruslan.
Reading through lib/RT/IR/Constituencies.pod, the correct procedure would be:

  • create a new Incident queue for each client
  • create a new constituency for each queue
  • create a new group and users for each queue
    Is that correct?

Not sure, it’s been a while since I touched that part.

You can find add_constituency script that comes with the tarball. Take
a look inside. I really would recommend you to try all this in a test
environment first to see if it works for you or not. It works like it
works and not very extendable because of a lot of black magic used in
the code.

We have a few customers that use this part, but we think that it’s
very special solution to be used broadly. We would love to hear more
about workflows where people need this solution to understand how to
replace the magic thing with something easier to use, maintain,
customize and extend.

Also on the documentation I don’t understand this part:
For example the following objects affect the rights users can have to
the constituency ‘EDUNET’:
Queue ‘Incident Reports - EDUNET’ =item * Queue ‘Incidents - EDUNET’
=item * Queue ‘Inestigations - EDUNET’ =item * Queue ‘Blocks - EDUNET’
=item * Group ‘DutyTeam EDUNET’
What are those ‘=item *’ ?

It’s all described in details. Experiment with the script in a test setup.

–
Cheers,
Colin

Best regards, Ruslan.

5

Reading through lib/RT/IR/Constituencies.pod, the correct procedure would be:

  • create a new Incident queue for each client
  • create a new constituency for each queue
  • create a new group and users for each queue
    Is that correct?

Not sure, it’s been a while since I touched that part.

Ok, I now have tested this. Here’s the output instead of writing down:

perl add_constituency --name CLIENT1

defined(%hash) is deprecated at
/usr/local/libdata/perl5/site_perl/Locale/Maketext/Lexicon.pm line
281.
(Maybe you should just omit the defined()?)
Check that the constituency exists

If you continue then we’ll…

  • add new constituency value: ‘CLIENT1’.
  • create queue ‘Incidents - CLIENT1’ if it doesn’t exist
  • create queue ‘Incident Reports - CLIENT1’ if it doesn’t exist
  • create queue ‘Investigations - CLIENT1’ if it doesn’t exist
  • create queue ‘Blocks - CLIENT1’ if it doesn’t exist
  • create group ‘DutyTeam CLIENT1’ if it don’t exist
  • create group ‘ReadOnly CLIENT1’ if it don’t exist
  • grant basic set of rights to the groups on the queues

I have done some tests and the only thing I see missing for my
workflow is a different CustomField, the same as Constituency. In this
case a “Constituency - CLIENT1” would be created as well.
Now the reason behind this is as I’m opening a ticket for CLIENT1, no
other Constituency should be visible.
Right now with only one CustomField Constituency where all
constituency are put, all clients have access to them and can select
them on a new ticket.
What do you think?

Cheers,
Colin