I see the same. If they have one role or the other, then everything is fine. Once they have both, then it seems the webtop menu permissions stop working. I am still only able to edit those items I have given permission for, but I can see the other content types and their corresponding menu items. Very strange.
I’ve had no spare time to look into it yet, but Ken will be investigating during the day today as we’ve run into the same issue with a client (specifically, the permissions for role combinations).
The way permissions are calculated in p700 should be identical to p630 and p620, so if there is a bug then it’s perhaps some fix that wasn’t merged forward… We’ll let you know when we have more info.
Either that or this issue exists in p620 and p630 also.
I have a client on p630 who uses these quite heavily and hasn’t complained about it yet, but I haven’t tested it myself since upgrading them from p620 to p630 (that was a few months ago). If I get a chance, I’ll test it, but I should note that they have their permissions set up the old way (the way that would usually take me an hour to setup with permission sets, etc).
Does anyone know if this was ever addressed or fixed? I have a lot of clients I’ve been holding off on upgrading to FC7 due to this bug in FarCry security not allowing users to have multiple roles.
I’m doing some testing on this at the moment. So far I’ve done this;
-
Created a “publisher” user who is only in the Publishers group which is mapped to the Publishers role. They have access to the Dashboard, Site and Content tabs. After logging in, everything looks fine.
-
Created a “migrator” user who is only in the (custom) Migrators group which is mapped to the (custom) Migrators role. They only have access to the Dasboard and (custom) Migration tab. After logging in, everything looks fine.
-
Created a “pubmig” user who is in both the Publishers and Migrators group which are mapped to the roles as above. After logging in, they can see the Dashboard, Site, Content and Migration tabs, everything appears to be fine…
Next I’ll try with another new, custom role instead of Publishers.
-
Created a “siteeditor” user who is only in the (custom) Site Editors group which is mapped to the (custom) Migrators role. They only have access to the Dasboard and Site tab. After logging in, everything looks fine. (The user cannot access the Site Builder because they don’t have the “developer” permission, but it does still appear in the navigation).
-
Created a “sitemig” user who is in both the Site Editors and Migrators group which are mapped to the roles as above. After logging in, they can see the Dashboard, Site and Migration tabs, everything appears to be fine.
These tests were all with relatively simple webtop permissions set only at the “tab” level, and no real overlap in which tabs the roles could see (apart from always having Dashboard access). Next I’ll try it with other combinations of more deeply nested webtop permission.
I’ve changed the “Site Editor” role to have access to an “Articles” menu item under the Content tab, and the “Migrator” role has access to “Media & Categories” and “Google Analytics” (but not articles).
Tested the two accounts with a single role and they work fine.
Tested the “sitemig” account which is assigned both roles, and they can correctly access the combination of menu items inside the Content tab (Articles, Media & Categories, Google Analytics).
@Jeff: Could you perhaps provide screenshots of the webtop permissions for the roles you are having problems with? (I figure that’s easier than typing our your webtop menu structure?).
cheers,
Justin
We're thinking that this is somehow related to a combination of custom roles that were created pre-upgrade.
But what's strange is that the dynamic webtop permissions that you can customise in each role and the permissions calculation itself was implemented back in 6.2.
The things that changed in 7 were some performance tweaks in the caching the way the navigation is outputted (due to the webtop redesign, all in one page rather than in 2 separate frames).
Perhaps you could try to recreate the problem using a fresh install of Fandango or Chelsea sample apps and then send me a dump of the DB? (MySQL would be preferable) :) Otherwise I might need to see your apps running on a dev/staging server or something. Happy to put the effort in to trying to solve this if I can somehow see it being reproduced.
Cheers,
Justin
Ok, I’ve found a combination of permissions that is now granting the user access to menu items it shouldn’t see… I’ll see if I can make some progress on debugging and fixing it 
Quick update: I’m currently testing a fix that solves the webtop navigation permissions issue, and has the added benefit of performing the permission calculations (and caching) around 25-35% faster than before. This is only noticeable on the very first login for a role after the app has been restarted, otherwise the webtop permission lookups have almost no cost.
The fix is now in p700:
@jeff and @seancoyne would you mind giving it a test and let me know how you go? 
cheers,
Justin
Tested and working here. Thanks! regarding the login speed improvement, I wonder if it will help with this bug at all [closed] FarCry v7.x login request time
Sorry for the late response. I had to create new roles (and it takes a while with that annoying alert() page refresh bug when creating roles - not sure if that bug was ever logged). But after some time I was able to create and test different scenarios and all seemed to work without error which is very awesome. Thank you!
Thanks!
It would definitely apply when it’s the first login for a role after an app restart, but for subsequent logins using the same role(s) the call to getAllItems() will effectively be 0
Can you describe the alert() page refresh bug a bit more? I haven’t see any alert dialogs while setting up new roles, and I’ve definitely interacted with each wizard step (I’ve been using Chrome). A screenshot would help heaps. I think you can paste straight into the comments box here even.
Yeah, I’ll create a new bug though. Right now I’m seeing it and I’m in FF, but I think it happens in any browser. Feel free to close this bug. Thanks.