Introduce organization-wide roles

[strazdinsg]

Instead of having simple ADMIN and MEMBER roles, we need to extend the roles for organizations.

Suggested naming of roles:

• ADMIN - global admin of the whole AutoPacker system. Gets access to everything, "root" user.
• MEMBER - general user registered in the AutoPacker system, not necessary member of any organization. Can see all public data in the portal.
• ORGADMIN_ - admin of organization with ID=orgId. For example, ORGADMIN_1, ORGADMIN_77.
• ORGMEMBER_ - member of organization with ID=orgId. Can see all private information (private projects) for the organization, but can't modify any projects (except those owned by the user).

This issue would involve implementing the roles in the AuthorizationService. Implementation of necessary role check in the backend and frontend will be separate issues.

[strazdinsg]

@ANicholasson @MrPrecise Comments on role naming and logic?

[ANicholasson]

I think it's good to prefix with ORG as it is mentioned.

For the logic part: Will need to add the roles to the general-api registered keycloak client. Will then have to get the IDs of the roles in keycloak or some value we can use to get the RoleRepresentation (probably the role name is enough actually). And add them to the database somehow. The logic for authorizing a organization user would be as followed.

1. Check if the user trying to access the organization is part of that organization (has a reference)
2. If the user has a reference, find the role that the user has for that organization

So will probably need a many-to-many relation between user and OrgRole (some table) and between user and org. Not sure how the database architecture should look like.

[strazdinsg]

After looking at the entity structure I see that there can be a much simpler system for organization membership management: many-to-many relationship between Organization and User, where the relationship also includes a role as a string. Will try to implement that and simplify the entities during the process.