The issue that you have is that you merge the concept of user and the concept of role. So if the same person is head of procurement in several tasks, that person would have several unrelated objects.
A first step forward would be to use sound separation of concerns, for example as follows:
As you see, I renamed your initial "User" into "Contributor" to avoid the confusion between a specific role and a more general concept (e.g. you had addUser() but no addManager() nor addHeadOfProcurement()).
This design increases the flexibility, yet your application will have the opportunity to enforce some constraints (e.g. if your auditors want you to enforce some segregation of duties).
Nevertheless, this design still relies on predefined roles. An admin could not create new roles, but just reuse the ones available in your class model.
If you want a higher level of flexibility, so that your admin can create new roles you could :
- either adopt an entity-component-system design for the roles. It means using composition of componennts instead of inheritance. Components would be individual responsibilities or behaviors, such as viewing tender, contributing with content, approving something, reset approvals, etc...
- or define the roles as a composite of sub-roles, untile some predefined leaf-roles which would be the most elementary responsibilities for tasks.
Of course this additional flexibility would add another layer of complexity.
