I think you should be able to solve this by adjusting the rolesToTransfer list in /configuration/episerver.common/sites/site/integration in web.config.

Based on the behavior described I assume the list currently consists of: <add name="*" />

If you replace this with the list of the roles that you actually need to get replicated into the Common/Community user system from the membership/role provider (if any?) your other group memberships added on the site should no longer be affected by the user integration process.

Thank you, but no luck.

More information.

Since AD is used the users cant be users to CommunityMembers role. I had to grant users from AD role access to functions.
Seems like a cookie issue, but its maybe a session variable?!

That's odd.

Regarding what you wrote about "CommunityMembers", that should not be the case if you have adjusted rolesToTransfer not to include that role.

Worth noting is, of course, that the integration config only affects the behavior of the user integration system from that point on - if a user has already been removed from a group that won't be reversed, the system will just not keep doing that.

For now I'm still assuming that the behavior is related to the user integration, so I'll include a short explanation of the somewhat unfortunately named settings for the user integration in hope that it may help figuring out what is happening as well as some expectations:

rolesToSynchronize: Determines, based on role membership, which users are synchronized into the Common/Community user system when logged in.

rolesToTransfer: Determines, when a user is being synchronized, which role memberships are to be transferred along with the user. For any role in this list (or all roles if the list contains "*"), the configured membership/roleproviders will be considered the master (the Common/Community group memberships will be adjusted to match those in the providers).

Hence if you have code on the site which adds users to common/community groups you do not want those group names to be in the rolesToTransfer list or it will keep removing those as long as the membership/roleproviders do not say that the user has those roles.

Does inheritance work in Relate/Circuit?

E.g could I add an AD Group to existing CommunityMembers role?  
Say that the AD role name for all AD users is "XX Personel".

I do not have code that adds the user to role. Should I implement this in an overload for the login process;

if (user.belongsTo("XX Personel" && user.belongsTo("CommunityMembers")==false)
   user.addToRole("CommunityMembers");

(Literal code, not actual)

(yes, as you've notice, not very in to EPiserver Community  :)

In general nested groups in Relate should work. If you add your Personel group in the rolesToTransfer setting and in community admin mode add the Personel group as a child group of CommunityMembers, members of Personel should be considered members of CommunityMembers. But there are some weaknesses/incompatibilities in how these nested groups are exposed through the RoleManager (which does not know of hierarchies) which means that e.g HttpContext.Current.User.IsInRole("CommunityMembers") / IsInRole("Personel") (can't remember which) might not return what you expect it to. This has been improved in EPiServer 7. But for the internal access checks in the Community framework the nesting works.

However, at least in the Relate templates  (I expect MedStore to work similarily, but I don't know for sure), users are automatically added to CommunityMembers when created so you should not need the nesting for this. In general, at least for Relate, there's seldom a need to have any roles in rolesToTransfer. Sometimes you may want to add some admin groups to rolesToSynchronize, and then either give those groups admin/modreate rights in Community admin, or add them as child groups of the CommunityAdmins/CommunityModerators groups. Or add CommunityAdmins and CommunityModerators to the AD and add them to rolesToTransfer to move the appointment of admins to the AD. Or neither, just manually add the admins and moderators to their respective groups in Community admins mode. And of course if you build some custom functionality which relies on membership of one or more AD groups you need to synchronize those to use the Community Access rights with them.

Did I make anything clearer or just more confusing?

Magnus, your response bring a positive outlook in regards to make this mess work :)

AD users are unfortuably not added to CommunityMembers, nor does the nested groups work as hoped.

However, I don't know if AD users not being a member of CommunityMembers if the real issue why a user gets thrown out of the group when closing the browser, but it is my suspicion and by best guess.

Thank you both for your replies.

Have checking things more in deptht now and user is still member of club according to ClubHandler GetMembership but user has no access to add entry  via when using EntitySecurityHandler.Instance.CheckAccess

User has to leave group and join again to get access to write blog entry or start new discussion in forum under clubs.

Before moving on from the original idea that this could be a misconfiguration of the user integration system, could you post the integration configuration from the episerver.common section?

<integration>
          <rolesToSynchronize>
            <add name="*" />
          </rolesToSynchronize>
          <rolesToTransfer>
		<add name="*" />
<!--            <add name="Personal XX,Moderatorintranat,Administratorintranat" />-->
          </rolesToTransfer>
        </integration>

Now it looks like this since the commented row messes everything up - e g users cannot access some pages in EPi-tree structure.    

Ok.

It sounds like you will want something like this:

<integration>
<rolesToSynchronize>
<add name="*" />
</rolesToSynchronize>
<rolesToTransfer>
<add name="Personal XX" />
<add name="Moderatorintranat" />
<add name="Administratorintranat" />
</rolesToTransfer>
</integration>

(No "*" entry for rolesToTransfer and one entry per role.)

Regarding the other problem with the EPiServer CMS page tree(?) you will want to make sure that the membership and role provider configuration correctly references the AD providers (and from the sound of it those providers alone).

Since the logged in user still was member of group but lost its access I enforced re-joining which enabled the access.

bool isMemberOfClub = false;
            if (SelectedClub != null)
            {
                isMemberOfClub = SelectedClub.IsMember(CurrentUser);
            }

            //run a check is user is member of club (if owner of blog is a club) och add user as member to the club
            if (SecurityManager.Instance.CanAddEvent(CurrentUser, calendar) == false && isMemberOfClub)
                ClubExensions.AddMemberToClub(CurrentUser, SelectedClub);

Here's another way you could deal with this issue. Changing rolesToTransfer didn't cut it for me either so i made a stored procedure to fix it. RolestoTransfer probebly should work, and it may be some code somewhere on my site that breaks this. Bur until i find i real solution, his seems to be a working workaround.

http://world.episerver.com/Blogs/Jonas-Lindau/Dates/2013/5/Users-disappear-from-clubs-access-groups-when-using-AD-and-Relatea-workaround/