Background

Currently, the membership module holds the map that binds a member to all the roles of the members at any time. By role, we here not only mean a type, like a storage provider or a counsilor, but also a specific instance of that role, so e.g. storage provider 66 or counsilor 210 .

Specifically for the role to member binding, there is the storage field.

pub MembershipIdByActorInRole get(membership_id_by_actor_in_role): map ActorInRole<T::ActorId> => T::MemberId;

and also, each member profile holds the set of current actor roles

pub struct Profile<T: Trait> {
    /// The set of registered roles the member has enrolled in.
    pub roles: ActorInRoleSet<T::ActorId>,
}

Whenever a member is to enter or leave a role, in some other module, then suitable calls have to be made to keep this state in the membership module up to date.

Quite separately from this, the membership module happens to have the ability to gate whether a member can, in fact, enter or leave a role at any given time, and also includes a static list of role types that allows it to possibly enforce role type-specific policies. The types are currently defined by

pub enum Role {
    StorageProvider,
    Publisher,
    CuratorLead,
    Curator,
}

Problem

Needless complexity caused by role entry gating

Currently, we do not even have any proposal for what sort of actual gating policy we would want to implement that would be role-specific. This appears to be a totally made-up requirement, and it is the only reason the specific role types are encoded in Role. Moreover, the only uniform policy which appears semi-plausible, that a disabled member, cannot enter a given role, does not appear to be of much real use. If we give up this idea entirely, then all of these checks go away, which greatly simplifies all of the other modules. One particularly impractical consequence of the current gating is for example that when hiring, one has to recheck that someone who is chosen for a position is still eligible for entry into the role after the initial check that is made when they apply. This is because entry permission could have changed in the intermediate time.

Move membership to role binding out

Keeping the binding information in the membership module requires more runtime state, which ultimately can get out of synch. Its safer and simpler to have each module keep the relevant membership id in the already existing representation of the role, e.g.

struc Curator {
...
member_id: T::MemberId
}