Following the Materialized View Permission Trail

Before revoking a grantee's permission, you need to identify grantees directly or indirectly granted the permission from the original grantee.

The grant chain traces how a grantee has in turn granted a permission to other grantees.

Consider the following:

Bob is granted all permissions with administrative rights.
Bob grants Joe SELECT permission without administrative rights. Bob also grants Jane SELECT and INSERT permissions with administrative rights.
Jane grants Mike and Joe SELECT and DELETE permissions with administrative rights. Jane also grants Beth and Mary SELECT permissions without administrative rights.
Note: Joe has now been granted the SELECT permission twice, with different administrative rights, by different grantors.
Joe grants Beth SELECT permission without administrative rights
Note: Beth has now been granted the SELECT permission twice, by different grantors.
Mike grants Sarah SELECT and UPDATE permission with administrative rights. Mike also grants Alice SELECT permission without administrative rights.
Sarah grants Alex, Beth, and Role1 SELECT and UPDATE permissions without administrative rights.
Note: Beth has now been granted the SELECT permission multiple times, by different grantors.

The permissions list would appear similar to:
Scenario 1 - Views and Materialized Views - Grant Chain Before Revoke

You want to revoke SELECT permission from Jane. To determine the potential impact on other users and roles, do the following:

Tip: For complex grant trails, create a tree diagram to visually track the grant chain.

Sort the list by Grantor and locate all instances of administrative grants of SELECT by Jane.

Note: There are four instances of Jane granting permissions. Since we are revoking the SELECT permission only, only those grants involving the SELECT permission will be impacted. Therefore, revoking Jane's SELECT permission will also revoke the permission from Mary, Mike, and Beth. Of the SELECT permissions, we need to follow those involving administrative rights.
Locate Mike in the Grantor column.

Note: Mike granted SELECT to Sarah and Alice. Both were granted the SELECT permission as an indirect (once removed) result of Jane. It does not matter whether the grant included administrative rights. Therefore, their SELECT permission will also be revoked when Jane's is revoked. Since Alice was granted SELECT without administrative rights, her grant chain ends. Since Sarah was granted SELECT with administrative rights, her grant chain continues.
Locate Sarah in the Grantor column.

Note: Sarah granted SELECT to Beth and Alex. Both were granted the SELECT permission as an indirect (twice removed) result of Jane. Again, administrative rights do not matter, and since neither grant was with administrative rights, the grant chain ends.

To summarize, revoking Jane's SELECT permission revokes the permission from Mike, Joe, Beth, and Mary, through direct granting or permissions by Jane, but also revokes the permission from Alice, Sarah, Alex, and Role1 as a result of indirect from Jane. The permissions list after revoking Jane's SELECT permission would appear similar to:
Scenario 1 - Views and Materialized Views - Grant Chain Before Revoke - Summary

It is important to note that it is possible for a user to retain an "identified" permission after revoke it the same permission was granted by multiple grantors. In this scenario, both Bob and Jane granted the SELECT permission to Joe, so Joe retains the SELECT permission granted by Bob. If a grantee has been granted multiple permissions, only those permissions explicitly selected are revoked. In this scenario, only the SELECT permission was revoked from Joe. The DELETE permission remains granted, even though it was also granted by Jane.
Scenario 1 - Views and Materialized Views - Grant Chain Before Revoke - Exceptions