remove tests, and update documentation

Author: Amxx

.changeset/crazy-bears-flash.md

@@ -6,7 +6,6 @@ NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/
 This directory provides ways to restrict who can access the functions of a contract or when they can do it.
 
 - {AccessManager} is a full-fledged access control solution for smart contract systems. Allows creating and assigning multiple hierarchical roles with execution delays for each account across various contracts.
-- {AccessManagerEnumerable} is an extension to {AccessManager} that enumerates role members and target functions each role can call.
 - {AccessManaged} delegates its access control to an authority that dictates the permissions of the managed contract. It's compatible with an AccessManager as an authority.
 - {AccessControl} provides a per-contract role based access control mechanism. Multiple hierarchical roles can be created and assigned each to multiple accounts within the same instance.
 - {Ownable} is a simpler mechanism with a single owner "role" that can be assigned to a single account. This simpler mechanism can be useful for quick tests but projects with production concerns are likely to outgrow it.
@@ -44,7 +43,3 @@ This directory provides ways to restrict who can access the functions of a contr
 {{AccessManaged}}
 
 {{AuthorityUtils}}
-
-=== Extensions
-
-{{AccessManagerEnumerable}}

contracts/access/README.adoc

@@ -161,7 +161,7 @@ image::access-manager.svg[AccessManager]
 The AccessManager is designed around the concept of role and target functions:
 
 * Roles are granted to accounts (addresses) following a many-to-many approach for flexibility. This means that each user can have one or multiple roles and multiple users can have the same role.
-* Access to a restricted target function is limited to one role. A target function is defined by one https://docs.soliditylang.org/en/v0.8.20/abi-spec.html#function-selector[function selector] on one contract (called target). 
+* Access to a restricted target function is limited to one role. A target function is defined by one https://docs.soliditylang.org/en/v0.8.20/abi-spec.html#function-selector[function selector] on one contract (called target).
 
 For a call to be authorized, the caller must bear the role that is assigned to the current target function (contract address + function selector).
 
@@ -210,11 +210,11 @@ const HOUR = 60 * 60;
 const GRANT_DELAY = 24 * HOUR;
 const EXECUTION_DELAY = 5 * HOUR;
 const ACCOUNT = "0x...";
-    
+
 await manager.connect(initialAdmin).setGrantDelay(MINTER, GRANT_DELAY);
 
 // The role will go into effect after the GRANT_DELAY passes
-await manager.connect(initialAdmin).grantRole(MINTER, ACCOUNT, EXECUTION_DELAY); 
+await manager.connect(initialAdmin).grantRole(MINTER, ACCOUNT, EXECUTION_DELAY);
 ```
 
 Note that roles do not define a name. As opposed to the xref:api:access.adoc#AccessControl[`AccessControl`] case, roles are identified as numeric values instead of being hardcoded in the contract as `bytes32` values. It is still possible to allow for tooling discovery (e.g. for role exploration) using role labeling with the xref:api:access.adoc#AccessManager-labelRole-uint64-string-[`labelRole`] function.
@@ -279,19 +279,13 @@ Similar to `AccessControl`, accounts might be granted and revoked roles dynamica
 
 The base `AccessManager` contract provides comprehensive role-based access control but does not support on-chain enumeration of role members or target function permissions by default. To track which accounts hold roles and which functions are assigned to roles, you should rely on the xref:api:access.adoc#AccessManager-RoleGranted-uint64-address-uint32-uint48-bool-[RoleGranted], xref:api:access.adoc#AccessManager-RoleRevoked-uint64-address-[RoleRevoked], and xref:api:access.adoc#AccessManager-TargetFunctionRoleUpdated-address-bytes4-uint64-[TargetFunctionRoleUpdated] events, which can be processed off-chain.
 
-If on-chain enumeration is required, you can use the xref:api:access.adoc#AccessManagerEnumerable[`AccessManagerEnumerable`] extension. This extension uses `EnumerableSet` internally and provides the following functions for role members:
-
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleTargetFunctionCount-uint64-address-[`getRoleMemberCount`]
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleMember-uint64-uint256-[`getRoleMember`]
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleMembers-uint64-uint256-uint256-[`getRoleMembers`]
-
-And these functions for target function permissions:
+If on-chain enumeration is required, it can be added implemented on top of the existing logic:
 
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleTargetFunctionCount-uint64-address-[`getRoleTargetFunctionCount`]
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleTargetFunction-uint64-address-uint256-[`getRoleTargetFunction`]
-* xref:api:access.adoc#AccessManagerEnumerable-getRoleTargetFunctions-uint64-address-uint256-uint256-[`getRoleTargetFunctions`]
+```solidity
+include::api:example$AccessManagerEnumerable.sol[]
+```
 
-These can be used to iterate over the accounts that have been granted a role and the functions that a role is allowed to call on specific targets:
+This adds function that can be queried to iterate over the accounts that have been granted a role and the functions that a role is allowed to call on specific targets:
 
 ```javascript
 // Enumerate role members
@@ -318,8 +312,6 @@ for (let i = 0; i < functionCount; ++i) {
 const allFunctions = await accessManager.getRoleTargetFunctions(MINTER_ROLE, target, 0, ethers.MaxUint256);
 ```
 
-Note that target function enumeration is organized per target contract, allowing you to query which functions a role can access on each specific target separately. This provides fine-grained visibility into the permission structure across your entire system of managed contracts.
-
 === Using with Ownable
 
 Contracts already inheriting from xref:api:access.adoc#Ownable[`Ownable`] can migrate to AccessManager by transferring ownership to the manager. After that, all calls to functions with the `onlyOwner` modifier should be called through the manager's xref:api:access.adoc#AccessManager-execute-address-bytes-[`execute`] function, even if the caller doesn't require a delay.