The ShowSavedSearches right and a patch for SavedSearches.pm


#1

Hello all,

Does anyone have experience with granting the ShowSavedSearches right? I
found that it wasn’t working as I expected and posted this question and
patch to the rt-devel list back in February and got no response. I
noticed that the behavior is still the same in RT 3.6.7, so I was hoping
that someone else in the user community might be able to tell me if I’m
misinterpreting the documentation or if the patched behavior is preferable.

Thanks in advance.

  -Bill-------- Original Message --------

Subject: SavedSearches.pm and the ShowSavedSearches right
Date: Tue, 26 Feb 2008 18:40:56 -0500
From: William J. Horka whorka@hmdc.harvard.edu
To: rt-devel@lists.bestpractical.com

Hello all,

I may be misinterpreting the documentation, but it appears to be that RT
is not behaving as documented with respect to the ShowSavedSearches
group right.

According to the RT wiki, “A user who has the ShowSavedSearches right to
a group is able to see/load the saved searches of that group. The user
must also have the global LoadSavedSearch right.”

However, in practice, it seems that the function
RT::SavedSearches::_PrivacyObjects which “returns a list of objects that
can be used to load saved searches from” does not select the group
objects based on the user having the ShowSavedSearches group right, but
rather selects them based on whether the user is a member of the group.

I’ve verified that the relevant code in
RT::SavedSearches::_PrivacyObjects is identical in the subversion
3.6-RELEASE and 3.7-EXPERIMENTAL branches, so this doesn’t appear to
have been yet identified as a bug.

The attached patch reflects the behavior I would expect to see based on
the documentation. Does this look correct?

   -Bill

William Horka
UNIX Systems Administrator
Harvard-MIT Data Center

SavedSearches.pm.ShowSavedSearches.patch (896 Bytes)


#2

William,

We grant all the search rights globally to all Privileged users. 

Because we limit queue access at the group level, any privileged user in
a group that has access to a queue can see, load, save, etc any search
created and used by any member in that group. We really haven’t had any
trouble with that setup at all. It certainly is a lot less maintenance
than trying to grant all those privileges on a user/queue basis. Hope
this helps.

Kenn
LBNLOn 6/17/2008 2:56 PM, William J. Horka wrote:

Hello all,

Does anyone have experience with granting the ShowSavedSearches right? I
found that it wasn’t working as I expected and posted this question and
patch to the rt-devel list back in February and got no response. I
noticed that the behavior is still the same in RT 3.6.7, so I was hoping
that someone else in the user community might be able to tell me if I’m
misinterpreting the documentation or if the patched behavior is preferable.

Thanks in advance.

 -Bill

-------- Original Message --------
Subject: SavedSearches.pm and the ShowSavedSearches right
Date: Tue, 26 Feb 2008 18:40:56 -0500
From: William J. Horka whorka@hmdc.harvard.edu
To: rt-devel@lists.bestpractical.com

Hello all,

I may be misinterpreting the documentation, but it appears to be that RT
is not behaving as documented with respect to the ShowSavedSearches
group right.

According to the RT wiki, “A user who has the ShowSavedSearches right to
a group is able to see/load the saved searches of that group. The user
must also have the global LoadSavedSearch right.”

However, in practice, it seems that the function
RT::SavedSearches::_PrivacyObjects which “returns a list of objects that
can be used to load saved searches from” does not select the group
objects based on the user having the ShowSavedSearches group right, but
rather selects them based on whether the user is a member of the group.

I’ve verified that the relevant code in
RT::SavedSearches::_PrivacyObjects is identical in the subversion
3.6-RELEASE and 3.7-EXPERIMENTAL branches, so this doesn’t appear to
have been yet identified as a bug.

The attached patch reflects the behavior I would expect to see based on
the documentation. Does this look correct?

  -Bill


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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


#3

Kenn,

Thanks for the response. Unfortunately this won’t work in our
environment because we need to grant users the ability to load saved
searches that were saved to other groups’ sets of saved searches.

For example, a group named Foo_Write has permissions to view and create
tickets in the Foo queue, as well as save searches to “Foo_Write’s saved
searches” in the Query builder. A group named Foo_Read has permissions
to view tickets in the Foo queue, as well as the ShowSavedSearches right
on the Foo_Write group. By my understanding of the documentation,
members of the Foo_Read group should be able to load from “Foo_Write’s
saved searches” in the Query builder.

However, this is not what happens in practice; the code in
SavedSearches.pm that populates the “Load saved search” box in the Query
builder looks for saved searches only in the groups that the user is a
member of – not all the groups that the user has the ShowSavedSearches
right on – and even allows the user to load saved searches from groups
they are a member of when they do not have the ShowSavedSearches right
on the group.

If my understanding is correct and the patch I proposed is accepted, you
would need to grant each group the ShowSavedSearches right on itself in
order for members of the group to be able to see the group’s saved
searches. This would create a bit of work for installations configured
like yours, but I still think it makes sense; other group privileges are
treated in this way, such as AdminGroup and AdminGroupMembership – you
wouldn’t want group members to have these rights by default with no way
to revoke them.

If my understanding is not correct, then what is the ShowSavedSearches
right for?

  -Bill

Kenneth Crocker wrote:

William,

We grant all the search rights globally to all Privileged users. 

Because we limit queue access at the group level, any privileged user in
a group that has access to a queue can see, load, save, etc any search
created and used by any member in that group. We really haven’t had any
trouble with that setup at all. It certainly is a lot less maintenance
than trying to grant all those privileges on a user/queue basis. Hope
this helps.

Kenn
LBNL

Hello all,

Does anyone have experience with granting the ShowSavedSearches right?
I found that it wasn’t working as I expected and posted this question
and patch to the rt-devel list back in February and got no response. I
noticed that the behavior is still the same in RT 3.6.7, so I was
hoping that someone else in the user community might be able to tell
me if I’m misinterpreting the documentation or if the patched behavior
is preferable.

Thanks in advance.

 -Bill

-------- Original Message --------
Subject: SavedSearches.pm and the ShowSavedSearches right
Date: Tue, 26 Feb 2008 18:40:56 -0500
From: William J. Horka whorka@hmdc.harvard.edu
To: rt-devel@lists.bestpractical.com

Hello all,

I may be misinterpreting the documentation, but it appears to be that RT
is not behaving as documented with respect to the ShowSavedSearches
group right.

According to the RT wiki, “A user who has the ShowSavedSearches right to
a group is able to see/load the saved searches of that group. The user
must also have the global LoadSavedSearch right.”

However, in practice, it seems that the function
RT::SavedSearches::_PrivacyObjects which “returns a list of objects that
can be used to load saved searches from” does not select the group
objects based on the user having the ShowSavedSearches group right, but
rather selects them based on whether the user is a member of the group.

I’ve verified that the relevant code in
RT::SavedSearches::_PrivacyObjects is identical in the subversion
3.6-RELEASE and 3.7-EXPERIMENTAL branches, so this doesn’t appear to
have been yet identified as a bug.

The attached patch reflects the behavior I would expect to see based on
the documentation. Does this look correct?

  -Bill


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

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

William Horka
UNIX Systems Administrator
Harvard-MIT Data Center