User Permissions revisited

The check against user permissions is somewhat crude, and does not precisely conform to access rights in gitlab:

Status Quo

• When the user logs in on the sharing platform, all group memberships are assigned as permissions to the user. (e.g. [ROLE_USER, SCOPE_api, SCOPE_email, SCOPE_openid, SCOPE_profile, SCOPE_read_api, SCOPE_read_registry, SCOPE_read_repository, SCOPE_read_user, SCOPE_sudo, SCOPE_write_registry, SCOPE_write_repository, sharing/university-innsbruck/java/accesstests], the permission groups starting with ROLE_ are gitsearch permissions, maintained by spring, the SCOPE_... permissions are oauth2-permissions (without current relevance), the rest are group permissions in gitlab)
• These gitlab group permissions are used to compare as a prefix against the namespace attribute of the elastic search metadata index of the gitlab project / exercise

deviation of permissions

1. Project permissions are not supported
2. With the guest role in a group a user can already view the search result (however cannot download anything). In gitlab the user cannot view the repository files.
3. It is unclear how renaming of groups is maintained in gitlab and gitsearch
4. Non-Problem: It seems that prefix search in namespace attribute is ok, because in gitlab it is not possible to reduce permissions of a member in a subgroup.

TODO:

• Make the problems more transparent for users
• Provide more test cases to check the permissions.