Thank you Kevin and Landon for the reply !
After fiddling a little bit more … woohoo, now I get it…
To explain what I’m tried to do:
- I have multiple constituencies ( FOO, BAR, … )
- Each member of the constituency/duty team should be able to see ALL
the tickets about his/her constituency (so not only tickets linked to
the specific user) but NONE of the other tickets
- A member of the main Duty Team should see all the tickets
I tried to follow this guide:
http://bestpractical.com/docs/rtir/3.0/Constituencies.html#Managing-Constituency-Values
However some things were not really clear to me.
Kevin,
Would you be able to update the Constituencies.html documentation a
little bit to make it clear that the newly created Queues are there
only for technical reasons, and are NOT meant to be used directly
reasons?
In the end I found the correct way to do this:
- install the software
- for “advanced permissions constituencies” : ./add_constituency
–name FOO for each constituency
- for “normal constituencies” : use the webinterface
For users:
- for external-constituencies users , create user, set “Let this user
be granted rights (Privileged)”, put him in the “DutyTeam - FOO”
- for internal users , create user, set “Let this user be granted
rights (Privileged)”, put him in the “DutyTeam”
Downsides:
- everyone sees the statistics of the queues statuses in the “Quick
search home screen” (number of new, open tickets)
- administrator user sees the newly created queues, however these
queues are NOT functionally needed by the operator. (normal user
doesn’t see these queues)
Do NOT try:
- move the ticket to the “Incident Reports - FOO”, “Investigations - FOO” queues
Greets
ChristopheOn Thu, Sep 5, 2013 at 5:30 AM, Kevin Falcone falcone@bestpractical.com wrote:
On Wed, Sep 04, 2013 at 04:07:10PM -0700, Landon Stewart wrote:
You must set up the ‘maps’ section of the %Lifecycles variable in your RT_SiteConfig.pm.
You can see the current (and probably default) setting at /Admin/Tools/Configuration.html. You
will probably have the default one in RTIR_Config.pm that you can copy into RTIR_SiteConfig.pm
where you can then modify it.
The point of this is to map statuses between queues. The status “new” in Incident Reports
would probably map to “new” in “Incident Reports - ORG” but they have to be explicitly mapped
out.
I found it quite confusing personally but got through it. Here’s some documentation on it:
Customizing/Lifecycles - RT 4.0.13 Documentation - Best Practical
Why are you defining a mapping between the IR queue and one of the
Constituency queues for IR? Incident Reports - ORG is a queue used
only for rights management (it allows RTIR to separate rights for
DutyTeam ORG from those in the DutyTeam or those in another
DutyTeam).
This is explained at the end of this section of the docs the user
referred to:
Constituencies - RTIR 3.0.4 Documentation - Best Practical
If you’re actually moving tickets into the Constituency queues that
a) sounds like a bug in either rights or something else that you’re
even offered the option.
b) breaks every saved search in RTIR that tries to do things like show
you the relevant IRs.
c) (really b part 2) would cause Incidents to no longer list the IR
because it isn’t in the IR queue.
I assume you’ve done something like add new searches for specific
subqueues, but that’s not how constituencies were designed, and I
don’t see how the RTIR → Incident Reports menu (which links to a
search) would work with your changes.
As an aside, if you were going to move IRs between two IR queues, why
wouldn’t you just give them both the incident_reports lifecycle so you
don’t lose proper statuses and actions? That seems much less fraught
than mapping into a Lifecycle with more statuses.
So - again - why do you need a mapping between Incident Reports and
Incident Reports $constituency ?
-kevin
Rtir mailing list
Rtir@lists.bestpractical.com
The rtir Archives