nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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!

Find more posts tagged with

Comments

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 cm

erson 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/sys

eople, 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

afaust

Hello Pieter,

the problem with this possibly being "a standard feature" is that there is a myriad of ways the condition may be used or what a condition actually represents. I myself have used it to check wether a user has a user home (may not be the case in some situations) and if so, present a quick-link to that user home in the menu. Alfresco can't possibly support all variations on this and the current, standard methods of customization make it sufficiently easy for coders to add a new condition ("easy" does not include the specific logic necessary to determine if that condition applies) with a bare minimum of about 8 lines XML and 1 line JavaScript.

All that should be necessary is a JavaScript file header.get.js in /tomcat/shared/classes/alfresco/web-extension/site-webscripts/com/example/components/header with the following content:

model.permissions.myCondition = true | false; // true or false depending on logic of check, i.e. group containment (that logic is specific and not provided here)
‍‍‍

To activate it, this requires an extension module in an arbitrarily named XML in /tomcat/shared/classes/alfresco/web-extension/site-data/extensions with the following minimal content:

<extension>
   <modules>
      <module>
         <id>My Extension</id>
         <customizations>
            <customization>
               <sourcePackage>com.example.components.header</sourcePackage>
               <targetPackage>org.alfresco.components.header</targetPackage>
            <customization>
         </customizations>
      </module>
   </modules>
</extension>
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The final activation is done via an Admin Tool of share via the URI /share/page/modules/deploy

After that, you can use "myCondition" as a condition in the header configuration.

All this is standard customization and should be supported for the next few major versions - minor modifications may be necessary, but nothing major…

Regards
Axel