Members of sites in whatever role can see all registered users

[pieter_shimanow]

Hi,

I am pretty new at configuring Alfresco (4.0 Enterprise). I am looking for a solution for the following issue:

Members of sites in whatever role can see all registered users, see site members  and invite new members.
However:
- Consumers should not be able to see registered users
- Consumers should not be able to see other site members
- Consumers should not be able to invite new site members

- Contributors should not be able to see registered users
- Contributors should not be able to invite new site members

I played around on the ACL in my local setup (public-services-security-context.xml), ACL is all over the place and changing ACL sometimes even breaks the page or other functionality.

What changes do I have to make?

Is there another way? Is there a (browser) interface for changes like this?

Thanks!

[afaust]

Hello,

in standard Alfresco, both Consumers / Contributors can not invite new members, so this should not be a problem.
Preventing users from seeing other users can not be done without some serious customization (including programming) to avoid breaking standard functionality and avoiding inconsistencies in the behavior. Alfresco Share is designed for social collaboration - forcibly isolating the users from one another is not a use case suited for a social collaboration tool.

Technically, you could modify READ permissions on the cmerson nodes representing users to differntiate visibility (based on sime kind of "to be implemented" logic / management functionality) based on roles. But from experience, this is not a trivial exercise as it can and most likely will interfere with authentication, authority management and other functionality dependant on a full view on users / group memberships.

What is the reason behind those requirements? Are they mandatory or open to alternatives (without specific alternatives in mind)?

Regards
Axel

[pieter_shimanow]

Hi Axel,

I will explain the scenarios:

1. our marketing dept works on images, texts and stuff which will be made available to distributors and shops around Europe. These distributors and shops will login and gather the stuff the want and download that. What we don't want is these distributors and shops being able to see who is also invited to this site. That is not of their concern. These distributors/shops have the role consumer.

2. we use alfresco to share and collaborate on documents in and outside the company. Now when a user in whatever role logs in he gets the dashboard and can see users present in the system. Consumers and contributors cannot invite people, but they sure can see them.

I understand now as roles are given to users per site, I gather this has to be done by putting those in a group.
I can create a group but how and where do I set these permissions?

Tx,

Pieter

[afaust]

Hello Pieter,

ok, as far as I understand only the external people should not be able to see other users / members. It would / might be okay if internal people see them (they are now contributors / collaborators), even if they are just consumers.

I would
<ol>
<li>Set up two global groups for internal and external users</li>
<li>Configured the Share header so that the People Finder is only available for the internal user group</li>
<li>Customize the People Finder page / web script to not display content or redirect if a user from the external group tried to access it via URL</li>
<li>Customize the Site Members dashlet web script to not display content if a user from the external group visits a dashboard</li>
</ol>

The only way external users would see other members would be via activities and the creator / modifier display. These could also be adapted, but require a bit more intensive customization.
This approach would not try to manipulate ACLs and thus not interfere with standard features.

I can think of a different approach using the internal/external user groups and ACL manipulation on /sys:system/syseople, but this would require some low-level Java implementation in the permission management using DynamicAuthority to get right - nothing that could be configured.


To your question: You set permissions using the "Manage Permission" action in the Share Repository / Document Library views. Alternatively, as an admin, you could also use some scripts (JavaScript) either via a "Run Script" action or the JavaScript Console add-on from the community.

Regards
Axel

[pieter_shimanow]

Hi Axel,

Thanks for your comment. I am going to look into these. I am a noob though, so I might return and ask you some more

Thanks!

Pieter

[pieter_shimanow]

Hi Axel,

I am changing the header as you describe in point 2. It looks easy to use "permissions" attribute but it apparently only works on "admin".
I also tried permissionGroup="GROUP_NAME" but it does not help me also..

Is there a list of values for permission/permissionGroups somewhere… I ran throug a lot of 'google' but could not find any.. or I don't understand what is in it..

Newbie as I am…

Thanks,

Pieter

[afaust]

Hello Pieter,

for permission, the only values that are supported out of the box are "admin" and "guest". To provide additional permission entries requires to <a href="http://blogs.alfresco.com/wp/developer/2011/08/05/customizing-alfresco-share-javascript-controllers/">customize the header.get.js via a Surf Extensibility module</a>, setting <blockcode>model.permissions["YourPermissionName"] = true|false;</blockcode> - the choice between true/false would need to depend on a group containment check for the current user via a ReST call to a Repository web script.
As you can see, this requires a bit of coding.

Regards
Axel

[pieter_shimanow]

Axel,

Thanks, "admin" being the administrator and "guest" being the rest of the users? So if no permission="admin" it is "guest"?

Greetz,

Pieter

[afaust]

Hello,

no, if no permission is set it is not restricted meaning visible to all users. If it is set, it is explicitly checked wether the current user fits the profile of admin or guest.

Regards
Axel

[pieter_shimanow]

Thanks, Now I re-read my question it actually is obvious.. stupid me.

So in order the achieve this I have to create a profile for the group I want to have this privileges.
Or is there also a way to hide or show this based on the group name?
Could this also be done with the attribute "condition"?

Searching on the argument "condition" does not gives too much results on too many other things as condition is too common.. .. unfortunately.

I could imagine there would be a condition="group.thegroupyouwant" or something like that.


I am a bit surprised though this issue not a standard feature. I have been browsing the forum and the rest of the net on this for the past few days, and I can find people with the same problem, but not the solution yet.
My worry now is how to keep this "hacking" and recoding alive when updating/upgrading in the future..

I am pretty new at this.

Thanks,

Pieter