Relationship classes: Let us read the origin table if the origin and destination tables have different privileges.
Sister idea to: Automatically match privileges between items in a ... - Esri Community
Most of the text is the same as that one since they are based off the same event.
This has bitten several colleagues recently.
As it currently stands (3.1), when you
The privileges were applied to a feature dataset and therefore the items within it, but not to the related tables corresponding to those items.
Users could see the feature dataset and the items within, but when they were added to the map, the "adding data" popup would appear, spin for a bit, then close before hitting the "finishing up" stage and actually adding to the map. Their records could also not be viewed in Catalog.
We could not figure out what the problem was until someone realized that the related standalone table did not have the same privileges applied.
No error message was given.
Updating the privileges for the related table fixed it.
So there are two actual problems here:
1) This idea: Having privileges unevenly applied to items in a relationship class makes it so that none of the data can be viewed.
2) Separate Idea: Items participating in a relationship class do not have privileges automatically applied
Please give us the ability to actually see the data for an item in a relationship class with privileges unevenly applied.
One thing to note is that this is only a problem for the origin table; if you have permissions to see the destination table but not the origin, the destination table will load just fine. If you can see the origin but not the destination, you can't look at the origin table at all.