Hi George,

It is actually possible to "filter" the access inside a protected content area. As you mentioned the "protection" is being inherited from the top and down - as long as you do not define a new public access restriction at a lower level.

Example:

• root
• • page
• • page
• • member area (public access for member group "members")
• • • department A ("members" inherited)
• • • department B ("members" inherited)
• • • department C ("members" inherited)
• • • • department C subpage ("members", inherited)

If you need to filter the acces inside the member area, you could add a new member group "depC" - and assign public access criteria directly on the page "department C" for only "depC".

• root
• • page
• • page
• • member area (public access for member group "members")
• • • department A ("members", inherited)
• • • department C (only "depC" which means that "members" do not have access any longer)
• • • • department C subpage (only "depC", inherited)

Do not assign "members" for the filtered area since this would open up this area to everybody with access to the members area.

Example with members:

• Annie (member group "members")
• John (member groups "members, depC")
• Richard (member group "depC")

In this scenario John would be able to access the entire member area, Annie everything but "department C" and Richard ONLY "department C".

The tricky part is that a member like Richard that has been assigned only to the member group "depC" but not "members" would not be able to see the content of the members area frontpage and other general pages inside the area. In this case you might need to add navigation or direct links to filtered areas elsewhere than inside the members area.

In short, the important way of handling a filtered structure is to add filters to the content on lower levels and give access to multiple member groups if needed on the members profile.

I hope that I understood your question correctly and that the above mentioned scenario can help you solve the challenge.

/Søren

Hi Søren,

First of all, thank you for your detailed answer.

So, if I understand correctly, in case that you setup multiple nested protected areas in the content (e.g. nested public protection features) each one will operate independently of its ancestor(s). Moreover member groups need to be configured for each one of them not taking into account any inherited member group settings.

In your example, if I was to create a new member group (e.g. directors) and decide to provide access to the entire “Members Area” content node, I would have to add the group to the public access of the “Members Area” content node and once more to the public access of the “Department C” content node. Right?

This seems like a very challenging task for back-office administrators in case that there is a large number of member groups and “public access” enabled, since administrators have to remember each content node’s public access settings in order to manage security efficiently. Is there any alternative approach that provides easier and more flexible security management?

Finally I have one more question, is public access feature integrated with Lucene search? For example, if a word is matched within any content page of the above “Members Area” node, will Lucene return different search results to each one of the three members (Annie, John, Richard) taking into account their respective member groups or is this something not provided out of the box and the developer should filter the results programmatically?

Thanks in advance,

George.

Hi George,

First of all I'd like to answer your first question regarding a new member group like "Directors".

If you need a new member group it would only be because you needed to have a new area inside the Members Area that is only meant for in this case directors.

So basically all directors would be assigned to the member group "members" as well giving them access to the entire Members Area (though not including the Directors Area unless they would also be assigned to the "directors" member group.

I fully understand that it might seem confusing, so to be able to help you further I'd suggest that you explain the exact setup including sub areas to filter. Then I'd be happy to help you with the structure.

Regarding the Lucene search question I'm not able to give you a bullet proof answer. I would recommend you to start up a new thread to get good feedback.

/Søren

Dear Søren,

Thanks one again for your answer.

My question about setting up a new member group (Director) was intended to clarify the fact that when nested Public Access areas are used then they operate independently of each other and it was not a question set on the basis of a real scenario.

In any case, we may assume that in your example there is another content sub-tree under the root called "Managers Area" (which is a sibling of the "Members Area") that allows access to members that are assigned the "Director" member group. This is setup up by a new Public Access feature on the "Managers Area" content node which provides access only to the "Directors" member group.

Now, let's assume that the "Director" member group should also provide access to the entire "Members Area" as well. Let's also assume that you may not move content nodes or restructure the content in general. In this case the administrator should add the "Director" member group both to the Public Access feature setup on the "Members Area" node and to the Public Access feature setup on the "Department C" node. Is this correct?

Thanks in advance,

George.

Hi George,

I'm afraid that you're complicating things to much. You do not need multiple Members Area (or Managers Area). You only need to assign multiple member groups to the member (or members) in question, ie Directors.

In the example John is a member of both Members and depC (let's rename them to Directors). Since he's a member of both groups he will have acces to the entire Members Area.

In other words, you handle filtering by giving a MEMBER multiple accesses by assigning multiple MEMBER GROUPS ... and NOT by creating multiple areas with similar or identical content. Always avoid duplicate content.

/Søren

Dear Søren,

I am not trying to complicate things, I am trying to understand how to manage Public Access areas when either the content is changing or new groups of people with different access rights need to be created.

Based on your original example, please take a look to the following content tree:

• root
• • page
• • page
• • member area (public access for member group "members")
• • • department A ("members" inherited)
• • • department B ("members" inherited)
• • • department C (public access for member group "depC")
• • • • department C subpage ("depC", inherited)
• • managers area (public access for member group "Director")

Now, if I wanted to provide access to all members of the “Director” member group to the entire “Members Area” (including “Department C”) I would have to do one of the following:

• Either add the member groups “Member” and “DepC” to all the members of the “Director” member group.
• Or add the member group “Director” to the Public Access area of the ”Members Area” node and to the Public Access area of the “Department C” node.

Is this correct?

Thanks in advance,

George

Hi George,

this is a brilliant example where you have added the managers area ... which again would not be needed if you changed the name of the department C to Managers area, in other words filtered the access for directors who probably also (should) have access to the rest of the Members area.

Hypothetically you could then change department A to Board members and filter the acces to this area by creating a new member group for "Board members".

Now IF a board member should only have access to this specific area, you would only assign the member group "Board members" to him/her. But if this board member was also a Director, you should also assign the "Directors" member group .... and of course, if he/she was supposed to have access to the entire (not filtered) Members Area you'd need to assign the "Members" member group.

A default member would only be assigned to the Members group and have access to the filtered areas.

On the other hand, with this setup you might keep it very simple at have multiple areas on the same level and just keep all content separated. It's a question of preferred structure. There's no need for filtering in depth if the different areas are not sharing content.

I hope that this all makes sense.

/Søren

is working on a reply...