Group links widget not showing option to join group

As I finished typing this post up, I decided to take one more look at Widget Studio to compare the two widgets. When looking at Group Links > Content, I took a look specifically at : 

#if (!$member.IsRoleMember)
					#if ($member.MembershipType == "Owner" || $member.MembershipType == "Manager" || $member.MembershipType == "Member" || $member.MembershipType == "PendingMember")
						#set ($canLeaveGroup = $member.MembershipType != "Owner" || $core_v2_groupUserMember.List($groupId, "%{MembershipType = 'Owner', PageSize = 1}").TotalCount > 1)
						#if ($canLeaveGroup)
							<li class="navigation-list-item leave-group">
								<a href="#" class="internal-link leave-group" data-messagename="widget.${core_v2_widget.WrapperElementId}.canceljoin">
									#if ($member.MembershipType == "PendingMember")
										$core_v2_language.GetResource("Hubs_CancelJoinRequest")
									#else
										$core_v2_language.GetResource("Hubs_LeaveGroup")
									#end
								</a>
							</li>
							#set($hasLinks = true)
						#end
					#elseif ($canJoinGroupByRequest || $canJoinGroup)
						#if ($group.GroupType == "PublicOpen")
							<li class="navigation-list-item join-group">
								<a href="#" class="internal-link join-group" data-messagename="widget.${core_v2_widget.WrapperElementId}.join">
									$core_v2_language.GetResource('Hubs_JoinGroup')
								</a>
							</li>
							#set($hasLinks = true)
						#elseif ($group.GroupType == "PublicClosed")
							<li class="navigation-list-item">
								<a href="#" class="internal-link join-group" data-messagename="widget.${core_v2_widget.WrapperElementId}.requestjoin">
									$core_v2_language.GetResource('Hubs_ApplyToJoin')
								</a>
							</li>
							#set($hasLinks = true)

I'm still trying to learn more about widget development, but it seems to me that there's missing logic here. The widget defines what to do (or not to do) with Joinless groups (a few lines earlier), then what to do for Existing Members, Public Open, and Public Closed groups in this block. I don't see anything defined to call out Private groups.

This makes some sense since I'm using our permissions and role settings to circumvent the Group Privacy options, but I'd still expect them to be defined. Is this a bug and/or just a really obscure use case? I'd think updating (line 103 for me) from :

#elseif ($canJoinGroupByRequest || $canJoinGroup)
						#if ($group.GroupType == "PublicOpen")
						

to 

#elseif ($canJoinGroupByRequest || $canJoinGroup)
						#if ($group.GroupType == "PublicOpen" || $group.GroupType == "PrivateListed" || $group.GroupType == "PrivateUnlisted")
						

would take care of this use case, but I'm not sure if that would have any other ramifications (or if my change is "correct"). Any insight/validation is appreciated!

This sounds like a fun challenge! High level breakdown for me:

1. Private group
2. Give a role permissions to read/join private group
3. Assign role to user not in the private group
4. Expected: User should be able to read the group and request to join it

Too simplified? What did I miss?

Thanks for simplifying that for me Grant! 

The only thing I'd add is the Group Banner's "Join Alert" banner respects the setting but the Group Links widget doesn't (plus all the other code things I added in my other reply -- I saw you typing as I was writing that)

Well I can say I see the same as you! The banner at the bottom would inform a user they need to join to participate, but the Groups-Links widget seems to have some other logic going on. Will ask around why that is.

Taking a step back now - why would you like it set up this way? If assigning a role to be able to see the group - why not add as a member via the role? Gauge engagement of a user actually joining on their own after seeing the content? Thanks for expanding!

The widget logic appears to be based on the default permissions of the site, which is why its checking and allowing only Public Open and Public Closed to show links.  It should really just be relying on the permission check to handle situations where the default permissions have been altered.

Probably something like this will work, haven't tested it though.

#elseif ($canJoinGroup)
 <li class="navigation-list-item join-group">
   <a href="#" class="internal-link join-group" data-messagename="widget.${core_v2_widget.WrapperElementId}.join">
       $core_v2_language.GetResource('Hubs_JoinGroup')
   </a>
 </li>
 #set($hasLinks = true)
#elseif ($canJoinGroupByRequest)
 <li class="navigation-list-item">
   <a href="#" class="internal-link join-group" data-messagename="widget.${core_v2_widget.WrapperElementId}.requestjoin">
       $core_v2_language.GetResource('Hubs_ApplyToJoin')
   </a>
 </li>
 #set($hasLinks = true)
#end

Thanks Grant Pankonien  and Mathew D'Amico (mdamico) ! 

Mathew - Thanks for putting that code together! I'll give this a shot with some testing and see if I need to make any changes. It looks good to me, but I trust your untested code more than my reading the untested code I'll report back what I find. 

Grant - 

Grant Pankonien said:

Taking a step back now - why would you like it set up this way? If assigning a role to be able to see the group - why not add as a member via the role? Gauge engagement of a user actually joining on their own after seeing the content? Thanks for expanding!

Adding all members of the role as group members is where I'd love to get to someday, but there are a few limitations:

• This is a private group for our partner network, and that would auto-subscribe ANYONE who works at a partner company to the group. That network can be extensive and would include community members who are not necessarily on our site for "partner content." The content in this group is more focused at sales/marketing roles, so if a developer who works for a partner (company) joins our site, they'd be inundated with that sales/marketing content.   
  • In addition, as a company, we have multiple types of partners (I want to say 7?), so different partner types have access to different applications in the group.   
• I have the  Subscribe Users To Group Applications automation set up on this group, so that's in a sense "forcing" extra notifications on the aforementioned audience ^
• We just re-launched this group with a new UI/UX about a month ago. The old UI/UX was "not great" so it was something that was swept under the rug a little. Now that the refresh is done I would be more open to auto-joining people, as would my group stakeholders. We want to finish some outstanding tasks/projects first though. 
• Due to the way we handle SSO (both from our company and our connector to our community), I'm unsure of some of the possible long-term effects, so I'd want to do a little more testing that I haven't had a chance to do yet. 

Overall, the structure has worked pretty well for us, minus some smaller side effects like this. If you ever want to see the end-to-end processes in more detail to understand the use case(s), I'm happy to show you. 

Alex Nassi said:

If you ever want to see the end-to-end processes in more detail to understand the use case(s), I'm happy to show you. 

I'll shoot a message!