The old (pre 2.0) contract changed significantly in the migration to the Roles paradigm: whitelisted accounts were now able to, in turn, give the whitelistee role to other accounts. Because of this, it was removed from the release.
We should settle on a new design, that addresses the following requirements:
whitelisted accounts have no special role-related powers (i.e they cannot add or remove other accounts to the whitelisted set)
whitelisters can add accounts to the whitelist, and remove them from it
It is not clear if the whitelisters should be able to add other accounts to the whitelisters set. I'd go with the standard Roles approach and allow them to add accounts, but not remove. If needed, this power can be easily removed with
contract WhitelisterRoleNoAdd is WhitelisterRole {
function addWhitelister(address account) public {
revert();
}
There's also the question of whether a Whitelistee is also a Role, or if it is simply a mapping of address to booleans. If it were a Role, it'd be different from the other ones in that the add operation should be internal instead of public (alternatively, we could couple Whitelistee and Whitelister and make addWhitelisteeonlyWhitelister). This may be an interesting case to experiment on.
I donât think âwhitelistedâ should be a role. I think all roles should have the same default interface, and that includes the public add operation. So it should be a simple mapping.
We shouldnât lose sight of the fact that this feature is motivated by legal requirements of some real-world contracts. @nventuro do you remember the details? I wonder if the peculiarities of whitelisters being a role are compatible with those legal requirements.
They arenât, which is what I meant by add being internal (like remove). It may be worthwhile to explore having a Role with a subset of the standard interface, to reuse the âsimple mappingâ operations in Roles (add, remove, is), along with their safety checks (no operations on the zero address, remove requires is, etc.).
An interesting point is what this could mean for the proposed autogeneration mechanism for role contracts: the Whitelistee's add function behaves differently than the others, in that only Whitelisters can call it. Some sort of parametrization might make sense, e.g. for the add function, which roles are allowed to call it (the same one by default).
Additionally, we wouldnât want the contract creator to be assigned the Whitelistee role during construction, so thatâs another point where they diverge.
I just noticed that, according to @mjdietzxhere, Whitelisters being able to remove the role from a Whitelistee is a non-optional requirement, which is yet another difference from the roles we already have.