The bug is related to role caching mechanism, so the 'EnableCaching' in the [RoleSettings] section must be set to 'true'.

Steps to reproduce:
1. Create any role which contain only one policy (just for having clear example of what is going on), for example create role which contain 'content/tipafriend' policy.
2. Assign created role to the Member group only.
3. Put the code below at the top of any template within admin-interface, for example in 'design/admin/templates/content/trash.tpl':

{def $has=fetch( 'user', 'has_access_to', hash( 'module', 'content', 'function', 'tipafriend', 'user_id', <checked_user_id> ) )}

<hr />
has access to content/tipafriend =

{if $has}

Yes

{else}

No

{/if}

<hr />

here <checked_user_id> must be replaced by your real member user's ID.
4. Go to the content/trash view in our case and look at the results of the executed template code. You will see:

member has access to content/tipafriend = No

that is obviously wrong.

5. Change <checked_user_id> in the edited template to the id of the admin user (14 by default).
5. Login as member user to the admin-interface, and open the same view (content/trash in our example). And you will the result below:

member has access to content/tipafriend = Yes

That is also definitely wrong.

The reason of the bug is located somewhere in the code which caches roles-policy stuff related to the currently logined user.