Read Ideas permission applying in latest takes precedence fashion

Scenario (in v11.1.1.9982):

Create Sub-Group of Joinless group (which is 2 levels down from Root) and set the permissions of new group to Private (Listed). Add forum applications and an Ideation. Add a Browse Ideations and Browse Forums widget to the Sub-Group home page.

As group creator/owner (and site admin), can see everything as expected.

Edit site role permissions for the following: Everyone = Remove all permissions (one must be logged in to know of this group's existence); Registered User = Remove all permissions except Read Group, View Group Name in Lists, and substitute Join Group instead of Join Group by Request (as the goal is to suppress content from the group unless the user opts in to the group on their own).

As group creator/owner (and site admin), the Browse Ideations widget now reports no results could be found (despite the Ideation quite clearly existing), Browse Forums still shows correct forum applications.
As a generic Registered User, all widgets report no results could be found (as expected) with button to click to join group (as expected).

Return to edit Group Permissions, Select Owners from Group Roles, make no changes and click Save.

As group creator/owner (and site admin), can once again see everything as expected.
As a generic Registered User, the Browse Ideation widget now shows the name of the ideation created (should not be visible, and clicking on it returns the "Page Not Found" error as if you navigated to a page which you aren't supposed to know about (that at least is expected)) while the Browse Forums widget reports no results could be found (as expected) with button to click to join group (as expected).

It seems that whichever permission was last applied to seemingly any role, is the permission that is applied to all roles.

Parents
  • Can you include some screenshots of your settings and what users see? I'm not able to replicate your setup. Private groups are intended to be completely hidden until you are a member of the group, with the Listed/Unlisted modifier just noting whether the group name appears in lists and searches. So my registered user just gets an Access Denied page when trying to navigate to the group home page.

  • Registered Users only permission in group (all others everywhere else are unchecked):

    Owner has every permission checked.

    Group Owner's view of group home page prior to applying Registered User permission (expected):

    Group Owner's view of group home page after applying Registered User permission (unexpected):

    Registered User's view of group home page after applying Registered User permission (expected):

    Registered User's view of group home page after saving Group Owner permissions making no changes (unexpected):

    Group Owner's view of group home page after saving Group Owner permissions making no changes (expected):

Reply
  • Registered Users only permission in group (all others everywhere else are unchecked):

    Owner has every permission checked.

    Group Owner's view of group home page prior to applying Registered User permission (expected):

    Group Owner's view of group home page after applying Registered User permission (unexpected):

    Registered User's view of group home page after applying Registered User permission (expected):

    Registered User's view of group home page after saving Group Owner permissions making no changes (unexpected):

    Group Owner's view of group home page after saving Group Owner permissions making no changes (expected):

Children
  • I've got the same setup for Registered Users but still get the Access Denied page. And my admin user can see the group page/content as normal even after saving Registered Users permission. I'm not actually sure what is expected here... Have you tried the setup with other group types?

  • I get the same results in every type I tried (I didn't try Joinless as that would defeat the purpose of a joinable group).

    My expectation would be that the Read Ideas permission would control the visibility of the Ideation name (in line with how other application Read permissions behave).

    Is there an "effective permissions" tool that could be used to show where the visibility setting is really deriving from to help troubleshoot the issue?

  • I was able to reproduce the missing ideation list using a Public Closed group, but a refresh fixed it and I could see things as normal. I also found that "Join Group By Request" needed to be checked in order to see the join message for a user who wasn't a member.

    You're definitely doing a deep dive into customizing permissions, and that's great! However, if you are having specific issues I might recommend either submitting a support ticket, or looking into a Professional Services engagement.

  • After refreshing, did it also appear for your non-member user in the background of the page?

    I didn't think this was too deep of a dive, but maybe I slipped down a rabbit hole (to mix metaphors). I'll also need to know what drives the visibility of the ideation in lists because I'll also have a joinless group that's driven by site roles and should not leak its name/contents, especially as permissions for that group change.