How to display email of Group Access Requestor to Owner

Users need the Manage Membership permission to see another users private email address.  The only workaround would be a custom notification and disable the OOTB notification, but it is not recommended as it is a privacy issue.

The use case is

WHEN a request for access is triggered
IF user is Group Owner
THEN show NAME and EMAIL in the Request Pane

OR show email in the Notification Mail

OR both

I understand the use case, but this assumes group owners are privileged enough to view personally identifiable information, which from a platform perspective is a user's choice outside of users who can generally manage the membership of the site.

Users can choose to provide a publicly facing email address in their profile if the field is made available, which is in essence consenting to the sharing of the information

I have to agree with @Wilfried Rijsemus that there should be a way for group owners to see the email address of a user requesting access. You just have to make sure you confirm with the user that they know they are sharing their registered email address with a discrete list of group owners at most. This new functionality would allow for a happier set of group owners on my community...

We run beta groups for new products and set them to private so we can be selective about who posts in the group. We make the beta manager the group owner. Normally the beta manager emails a set of people about the beta from another system. For example, something as simple as Outlook using the BCC line to keep the recipients from seeing who else has been emailed. It depends on the size and complexity of the beta and EAP.

Note:

• The beta manager will have decided who to invite using the person's email address as the key to identifcation.
• This set of people may not have registered on the community yet.
• The beta participant's email address is the unique identifier the beta manager *wants to use* to confirm the requester is the same person they originally emailed.

When a beta participant requests access, and the beta manager sees only the username, the manager cannot make a decision as to whether or not the user should be allowed access. If the manager is expecting 'john.smith@example.com' to join but only sees 'Wookiee74' (cool, but not helpful right now) the manager cannot confirm the access and the process stalls - it's not smooth.

1. Option 1 could be to change the beta process and have the beta manager email all beta participants and ask for their username and then add or invite these users to the group as members. This lowers adoption and creates a barrier. The set of email addresses may total hundreds. The beta manager has a thousand things to do at this phase and needs the system to help them.
   
   
2. Option 2 should be to change the request access page and insert a confirmation prompt that their email address will be shown to the current set of group owners (listed for inspection by the requester). The user positively selects 'I agree' and the button to request access is enabled. This would allow the beta manager to do whatever they want as a process to get the beta participant to request access. They then only have to approve the requests as them come in by comparing the email address to the list of recognizable addresses they originally emailed. To the manager this process makes more sense to them.

If Telligent implemented an unticked checkbox then the customer must actively confirm their consent and, if they do, sharing is OK. Example (picture always helps):

I have to agree with @Wilfried Rijsemus that there should be a way for group owners to see the email address of a user requesting access. You just have to make sure you confirm with the user that they know they are sharing their registered email address with a discrete list of group owners at most. This new functionality would allow for a happier set of group owners on my community...

We run beta groups for new products and set them to private so we can be selective about who posts in the group. We make the beta manager the group owner. Normally the beta manager emails a set of people about the beta from another system. For example, something as simple as Outlook using the BCC line to keep the recipients from seeing who else has been emailed. It depends on the size and complexity of the beta and EAP.

Note:

• The beta manager will have decided who to invite using the person's email address as the key to identifcation.
• This set of people may not have registered on the community yet.
• The beta participant's email address is the unique identifier the beta manager *wants to use* to confirm the requester is the same person they originally emailed.

When a beta participant requests access, and the beta manager sees only the username, the manager cannot make a decision as to whether or not the user should be allowed access. If the manager is expecting 'john.smith@example.com' to join but only sees 'Wookiee74' (cool, but not helpful right now) the manager cannot confirm the access and the process stalls - it's not smooth.

1. Option 1 could be to change the beta process and have the beta manager email all beta participants and ask for their username and then add or invite these users to the group as members. This lowers adoption and creates a barrier. The set of email addresses may total hundreds. The beta manager has a thousand things to do at this phase and needs the system to help them.
   
   
2. Option 2 should be to change the request access page and insert a confirmation prompt that their email address will be shown to the current set of group owners (listed for inspection by the requester). The user positively selects 'I agree' and the button to request access is enabled. This would allow the beta manager to do whatever they want as a process to get the beta participant to request access. They then only have to approve the requests as them come in by comparing the email address to the list of recognizable addresses they originally emailed. To the manager this process makes more sense to them.

If Telligent implemented an unticked checkbox then the customer must actively confirm their consent and, if they do, sharing is OK. Example (picture always helps):

That is a very elegant solution. That would REALLY solve the problem. Big kudos for this idea. Right now I have hard won Group Owners abandoning Telligent because they cannot judge who is requesting access.

Note in the scenario where a user is invited by email address and it is known, that the group owner should not have to approve the user any further even after they have registered for the community, unless the user abandons the flow.  

For additional feature requests however, I would suggest posting the idea here with full use case defined:
community.telligent.com/.../

This is only when requested access, not when invited, because the email is known then already. One case excludes the other.

Been there for 'years' community.telligent.com/.../improve-approve-deny-access-to-group-process-expose-email-and-provide-denial-dialog

To be fair  it has been there for less than a year at the time of this posting (posted May 2017).  We review this when planning for releases and many factors go into our decision to take features.  Placing an idea here does not guarantee a feature will be taken and that it will be taken in the next or even subsequent release.   It does not mean we find the contribution less valuable or unimportant, we simply have a process, this being one part of that process.

To clarify when I wrote...

The beta manager will have decided who to invite

...'invite' is outside of the Telligent system.  They may have to email a complex HTML email or attach a pack of information to the email.  They may very well not be using (and unable to use) an email client.  They generally want to use whatever they are currently using to do the 'inviting' and only come to the group, and hence Telligent to confirm the requests as/when/if they arrive.  All outgoing correspondence is from another system.

That is correct. The topic was on the table for quite some time but I posted it as an idea last year. We struggled at SDL with this topic as early as 2014. Just talked to jbackx@sdl.com on some on a related topic called GDPR in which we need to deal with the same deadlock of User Consent and Owner Trust. This is why I liked the proposal in this thread from ruckus. it is elegant and solves this part of the problem. The second part of the problem comes if the Owner decides to deny access.

I added in the idea the dialog that needs to happen when an owner decides to deny access. A harsh decision that would need clarification otherwise your hard won member will leave the community. That is currently not possible since the owner is not prompted a dialog box to explain the denial. Usually it is the wrong email domain (like hotmail) being used that cannot be granted since a company email is required. (Before becoming too technical, we are anticipating federated identities. This effectively means that if this person is no longer working at a certain company, access is automatically not granted to your community hence, the group because the authentication is done against the company's identity provider).

This solves a major account/access problem which occurs over time when you run a community in a B2B context. Access granted to private customer groups are automatically revoked if YOUR identity broker asks THEIR identity provider if this person still works at this company. This can only happen if you granted access on the right email in the first place.

So, although this idea may seem trivial, the reason why we need it is not. It is a real achilles heel of the Telligent platform. We are using Ping Identity BTW