Queues - There is no mapping for statuses between these queues

Hello,

We’ve followed the instructions from :
http://bestpractical.com/docs/rtir/3.0/Constituencies.html
With the script provided in bin/add_constituency we’ve created new
constituencies.

Then using the webinterface I wanted to move a ticket from Incident
Reports queue to the “Incident Reports - ORG”.

However I do get the following error:
Ticket 14: There is no mapping for statuses between these queues.
Contact your system administrator.

Changing the Queue using Scrips also gave the same error.

Any idea?

rt-4.0.16
RT-IR-3.0.0

Thanks
Christophe

We’ve followed the instructions from :
http://bestpractical.com/docs/rtir/3.0/Constituencies.html
With the script provided in bin/add_constituency we’ve created new
constituencies.

Then using the webinterface I wanted to move a ticket from Incident
Reports queue to the “Incident Reports - ORG”.

However I do get the following error:
Ticket 14: There is no mapping for statuses between these queues.
Contact your system administrator.

Rather than moving the ticket, set the Constituency CF on the ticket.
What UI are you using that let’s you see and try to transfer the
ticket into one of the Constituency Queues?

-kevin

Date: Wed, 4 Sep 2013 10:44:26 +0200
From: Christophe Vandeplas christophe@vandeplas.com
To: rtir@lists.bestpractical.com
Subject: [Rtir] Queues - There is no mapping for statuses between these
queues.

Hello,

We’ve followed the instructions from :
http://bestpractical.com/docs/rtir/3.0/Constituencies.html
With the script provided in bin/add_constituency we’ve created new
constituencies.

Then using the webinterface I wanted to move a ticket from Incident
Reports queue to the “Incident Reports - ORG”.

However I do get the following error:
Ticket 14: There is no mapping for statuses between these queues.
Contact your system administrator.

Changing the Queue using Scrips also gave the same error.

Any idea?

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:
http://bestpractical.com/docs/rt/4.0.13/customizing/lifecycles.html

Landon Stewart :: lstewart@iweb.com
Lead Specialist, Abuse and Security Management
Spécialiste principal, gestion des abus et sécurité
http://iweb.com :: +1 (888) 909-4932

1 Like

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:
http://bestpractical.com/docs/rt/4.0.13/customizing/lifecycles.html

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:
http://bestpractical.com/docs/rtir/3.0/Constituencies.html#Constituency-Values

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

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:
http://bestpractical.com/docs/rt/4.0.13/customizing/lifecycles.html

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:
http://bestpractical.com/docs/rtir/3.0/Constituencies.html#Constituency-Values

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
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rtir

Thank you Kevin and Landon for the reply !

After fiddling a little bit more … woohoo, now I get it…

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?

Are you up to sending a patch to the docs making it clearer?
There are directions on getting a copy of the rtir source here
http://bestpractical.com/rtir/git.html
and these days github will even let you generate pull requests almost
directly from the UI.

Downsides:

  • everyone sees the statistics of the queues statuses in the “Quick
    search home screen” (number of new, open tickets)

This is a known problem with how Constituencies are implemented, and
not easy to resolve.

  • administrator user sees the newly created queues, however these
    queues are NOT functionally needed by the operator. (normal user
    doesn’t see these queues)

As long as it’s only Administrators, this is ok. Default permissions
should not be for DutyTeam or DutyTeam Foo members to see those
queues.

-kevin

Thank you Kevin and Landon for the reply !

After fiddling a little bit more … woohoo, now I get it…

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?

Are you up to sending a patch to the docs making it clearer?
There are directions on getting a copy of the rtir source here
http://bestpractical.com/rtir/git.html
and these days github will even let you generate pull requests almost
directly from the UI.

done:

Thank you Kevin and Landon for the reply !

After fiddling a little bit more … woohoo, now I get it…

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?

Are you up to sending a patch to the docs making it clearer?
There are directions on getting a copy of the rtir source here
http://bestpractical.com/rtir/git.html
and these days github will even let you generate pull requests almost
directly from the UI.

done:
https://github.com/bestpractical/rtir/pull/1

Thanks - I will have a look later this week or next and get it merged
down. I see a minor pod error we’ll have to correct (F<> is for
files, not for emphasis) but otherwise it looks good.

-kevin