Skip to Main Content
HCL Connections Ideas Portal

Welcome to the HCL Connections Product Ideas Lab! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by the HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events, please visit our HCL Connections page.

Status Under Consideration
Created by Guest
Created on Jan 13, 2019

In Community Activities remove the option to make other users readers when the community is public anyway

The security in Community Activities in public & moderated communities is confusing and implies a level of security that isn't valid: 

Working for a customer on creating some documentation I found the following.

In Community Activities you have the option to limit what community members can do and you can even assign specific rights to specific community members. Great! But...

Looking at the interface of the Add Members page you get confused. The option allows you to select specific users and give them either the Owner, Author or Reader role. Below that is an option to specify that other community members should have Read access.

My assumption would be that if I DON'T tick that box only the members I selected will see the activity and all others will not as I didn't tell the system to make them readers. And this seems confirmed by the resulting security overview when I save my changes as that does not list the members, only the community owners (who are managers regardless).

Do I change it and tick the box, the members will explicitly be listed as readers.

So logically I would assume that the situation in these two cases is different and that the members don't have read access in the first and DO have read access in the second case.

But what if the community is a public or moderated community? 

And here is where the confusion comes in. As this activity is in a public community the activity is automatically public too and therefore visible to all. The tick box in those cases has no meaning at all and all members (in fact everyone) can see the activity and everything in it regardless of that setting. This isn't however mentioned on the Members page of the activity itself and that is where I (and other users I asked) got confused. You have to realize that because the community is public, the security on the activity is different from what is implied in the activity itself.

If the activity is part of a restricted community the security works as implied and additional members won't have access unless specifically assigned with that tick box.

So yes. Technically there is nothing wrong and all is working as designed. But from a logic and usability point of view I think this is potentially dangerous. As people will not realize it and might be thinking access is restricted while it is not.The reason for this is that the expectation of most users is that explicit security options (like that tick box giving you the option to assign or not assign reader rights to community members) generally overrules implicit rules (like the fact that the community is public and therefore the activity is too).

(also posted on my blog under: http://www.femkegoedhart.com/2019/01/13/ibm-connections-activities-implicit-versus-explicit-expectations/)

  • Attach files
  • Guest
    Reply
    |
    Jan 13, 2019

    Please also fix in release 5.5 !!