Public Sets are displaying in most/all users' Collaborative Sets list

[sarahjeansweeney]

Abbie reported to me yesterday that she has access to many Sets in her Collaborative Sets list that she didn't think she should, which appears to be true. For example, in her list of 91 collaborative sets she has access to the "Abod" and "Associated Files" Sets:

"Abod" was created by Michelle, is public, and has edit permissions for Archives staff (a group Abbie does not belong to):

"Associated Files" was created by me, is public, and has no other permissions.

I checked a few other random users, and they can see these sets, too. There are plenty of private sets that do not show up in these random users' collaborative sets, so it seems only public Sets are affected. The read permissions should determine that a user can access a set in the collaborative sets list, not the public/private permission.

[dgcliff]

Read permissions are public/private permission. Do you mean edit?

[sarahjeansweeney]

I mean the read/edit Grouper permissions, not the public/private Mass Permissions.

[dgcliff]

An item set to public with no more specificity in grouper permissions is by default readable by anyone.

[sarahjeansweeney]

Yes, readable, but readable should not equal collaborative. Collaborative should be specifically set by Grouper group membership.

[dgcliff]

Blacklight doesn't disambiguate read ability from public no specificity, to explicitly with groups. I can put in that extra filtering, but it'll slow down that page.

[sarahjeansweeney]

As users add more and more public sets, the page will slow anyway, so that seems like a reasonable solution. I think it's more important for users to only be able to access sets in the collaborative area that have been purposefully shared with them.

[dgcliff]

The way blacklight is constructed, pagination ensures that count is irrelevant for page speed. Processing is different. I'll put in the patch.