feat(MultiGroupsForUsers): Added support for user to be part of multiple secondary groups and assume different secondary roles

[JaideepPalit]

Added support for user to be part of multiple secondary groups and assume different secondary roles

• Which issue is this pull request belonging to and how is it solving it? (User can be part of multiple groups. #1163)
• Did you add or update any new dependencies that are required for your change? - No

Issue: closes #1163

How To Test?

• Test Admin -> Users Page - edit Secondary Groups
• Old Functionality should be tested without secondary groups for View/Create/Update/Delete/Moderation Request/Clearing Request for Project, Component, Releases, Licenses
• Validated correct permissions are given based on secondary Roles and whether it covers all scenarios
• Basic way to test this PR is. First Preference goes to Primary Roles. Then check for Secondary roles.
  • For example
    • User from GROUP1 has Primary role as USER but has secondary Roles as ADMIN in GROUP2. then in GROUP1 he acts as normal user but in GROUP2 he acts as ADMIN.
    • Test Create/Update/Delete/List Projects, Search Projects, (Moderation Request - View/Accept/Decline for Project, Component, Releases, Licenses ) , Clearing Request on below logic like -
      • Currently if a CR belongs to different group , it is not visible/editable to user from other group,
        • Now secondary group can be added and user can view CRs from other groups
      • Project from user1@sw360.org - DEPARTMENT with visibility as Group and Moderator.
        • Should not be visible/editable to user2@sw360.org - DEPARTMENT, Should be visible/editable by admin@sw360.org
        • Edit secondary department with different roles and test functionality
      • Similarly for Moderation Request.

Note - Both UI and REST API needs to be tested

• Read/Write Rules-

  • Clearing Request-

    • Readable, if user in same group as Project BusinessUnit
    • Writable/Editable - if User has write access to Project via Primary Roles/Secondary Roles AND User is has Primary Role or Secondary role in that Group atleast CLEARING_EXPERT

  • Moderation Request

    • Readable/Writable/Editable
      • Project - Users with Primary Roles or Secondary Roles in that department atleast Clearing Admin and if Project is not closed -> creator, ProjectResponsible and Moderators
      • Release/Component - Users with Primary Roles or Secondary Roles in that department atleast Clearing Admin and if Project is not closed -> creator and Moderators
      • License - Users with Primary Roles or Secondary Roles in that department atleast Clearing Admin

  • Project

    • Read - According to Visibility including Secondary Group
    • Others

    @Override
    public boolean isActionAllowed(RequestedAction action) {
        ImmutableSet<UserGroup> clearingAdminRoles=ImmutableSet.of(UserGroup.CLEARING_ADMIN,
                UserGroup.CLEARING_EXPERT);
        ImmutableSet<UserGroup> adminRoles=ImmutableSet.of(UserGroup.ADMIN,
                UserGroup.SW360_ADMIN);
        if (action == RequestedAction.READ) {
            return isVisible(user).test(document);
        } else if (document.getClearingState() == ProjectClearingState.CLOSED) {
            switch (action) {
                case WRITE:
                case ATTACHMENTS:
                    return PermissionUtils.isUserAtLeast(ADMIN, user) || isUserOfOwnGroupHasRole(clearingAdminRoles, UserGroup.CLEARING_ADMIN) || isUserOfOwnGroupHasRole(adminRoles, UserGroup.ADMIN);
                case DELETE:
                case USERS:
                case CLEARING:
                case WRITE_ECC:
                    return PermissionUtils.isAdmin(user) || isUserOfOwnGroupHasRole(adminRoles, UserGroup.ADMIN);
                default:
                    throw new IllegalArgumentException("Unknown action: " + action);
            }
        } else {
            return getStandardPermissions(action);
        }
    }
    
    
    protected boolean getStandardPermissions(RequestedAction action) {
        ImmutableSet<UserGroup> clearingAdminRoles=ImmutableSet.of(UserGroup.CLEARING_ADMIN,
                UserGroup.CLEARING_EXPERT);
        ImmutableSet<UserGroup> adminRoles=ImmutableSet.of(UserGroup.ADMIN,
                UserGroup.SW360_ADMIN);
        switch (action) {
            case READ:
                return true;
            case WRITE:
            case ATTACHMENTS:
                return PermissionUtils.isUserAtLeast(ADMIN, user) || isContributor() || isUserOfOwnGroupHasRole(clearingAdminRoles, UserGroup.CLEARING_ADMIN) || isUserOfOwnGroupHasRole(adminRoles, UserGroup.ADMIN);
            case DELETE:
            case USERS:
            case CLEARING:
                return PermissionUtils.isAdmin(user) || isModerator() || isUserOfOwnGroupHasRole(adminRoles, UserGroup.ADMIN);
            case WRITE_ECC:
                return PermissionUtils.isAdmin(user) || isUserOfOwnGroupHasRole(adminRoles, UserGroup.ADMIN);
            default:
                throw new IllegalArgumentException("Unknown action: " + action);
        }
    }
    

Have you implemented any additional tests? - No

Checklist

Must:

• All related issues are referenced in commit messages and in PR

Signed-off-by: Jaideep Palit jaideep.palit@siemens.com

[akapti]

Reviewed the code, suggested some changes.

[akapti]

I guess button with label Save would make more sense here instead of Edit in modal pop-up.
& how about keeping 1 row added by default on load of modal pop-up instead of making user add the very first row?

One more thing, clicking on Edit button without adding any rows, makes a call to backend and show the success/error message, as shown in above screenshot. (not an appropriate use case, ideally Save button should be disabled or a backend call should not happen unless a row is added)

[JaideepPalit]

I guess button with label Save would make more sense here instead of Edit in modal pop-up.

• Changed Edit button to Save button

One more thing, clicking on Edit button without adding any rows, makes a call to backend and show the success/error message, as shown in above screenshot. (not an appropriate use case, ideally Save button should be disabled or a backend call should not happen unless a row is added)

Use case - Save without any row

• User has some Secondary roles and Groups, now all of those secondary group and roles needs to be removed.

how about keeping 1 row added by default on load of modal pop-up instead of making user add the very first row?

• kindly refer above use-case,
• Since it is optional to have secondary roles , it was made inline with other parts of sw360 like external id and additional roles
  

[JaideepPalit]

Thanks for review.
Incorporated changes according to review comments

[mcjaeger]

Ideas for testing:

• access to project of secondary group
• moderation request routing based on secondary group
• moderation request acceptance with secondary group
• ECC admin of secondary group
• clearing request of secondary group
• Security admin of secondary group
• license admin (edit license based on secondary group)
• set clearing of project to closed based on secondary group
• review liferay listings of site roles
• REST API: view project based on secondary group
• write project attributes even with primary group non clearing admin, but secondary group clearing admin

[akapti]

Reviewed the code. looks good to me.

[shi9qiu]

I did some tests for this functionality and found some possible bugs. However, I am newer of sw360, if there is something wrong, please let me know.

Test Report for Multi Groups

Test 1: Old functionality Test

Description:
Test old functionalities without secondary departments.

Test Case 1.1:
Test View/Create/Update/Delete/Moderation Request/Clearing Request for Project, Component, Releases, Licenses.

Result 1.1:
OK (As far as I can tell, no problem found.)

Test 2: Edit Secondary Department Test

Description:
Test whether the secondary departments and roles can be added/deleted/modified/viewed correctly in "User" page.

Test Case 2.1:
Login as "admin@sw360.org-DEPARTMENT-Administrator,User", then add a secondary department as "DEPARTMENT" and role as "User" to "user2@sw360.org-DEPARTMENT2-User".

Result 2.1:
NG (The pull-down list of "Enter Secondary department" does not include "DEPARTMENT". If I typed in and save, I got the success message. However when I reloaded the page, the secondary department and user is not saved.)
OK (Delete/modify/view departments and roles is OK.)

Test 3: Project functionality Test with secondary departments and roles

Description:
Test the functionalities of secondary department and role in "Project".

Test Case 3.1: (View/List)
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) is visible.
Login as user4@sw360.org (primary:DEPARTMENT4 as User, no secondary), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) is visible.

**Result 3.1: **
OK (TestProject3 is visible for admin4@sw360.org, not visible for user4@sw360.org.)

Test Case 3.2: (Update/Edit)
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as Admin), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) can be edited.
Login as user4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) can be edited.

Result 3.2:
OK (admin4@sw360.org can edit the project. user4@sw360.org can not edit the project but can send a moderation request.)

**Test Case 3.3: **(Delete)
Login as user4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) can be deleted.
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as Admin), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) can can be deleted.

Result 3.2:
OK (user4@sw360.org can not delete the project but can send a moderation request. admin4@sw360.org can delete the project.)

Test Case 3.4: (Create)
Login as user4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), create a project named as TestProject3.user4 (Created by:user4@sw360.org, Group:DEPARTMENT3, Moderators:admin4@sw360.org).
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as Admin), create a project named as TestProject3.admin4 (Created by:admin4@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org).
Login as user3@sw360.org (primary:DEPARTMENT3 as User, no secondary), check whether the two new projects are visible.

Result 3.4:
NG (user4@sw360.org and admin4@sw360.org can create the new projects, but the groups of the new projects are DEPARTMENT4 even I type in DEPARTMENT3. The two new projects is not visible for user3@sw360.org.)

**Test Case 3.5: **(View/accept/decline a moderation request)
Login as user4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), send two moderation requests of TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org).
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as Admin), check whether TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org) can accept and reject the moderation request.

Result 3.5:
NG (admin4@sw360.org can not see the moderation request.)

Test Case 3.6: (Create/view/accept/decline clearing request)
Login as user4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as User), create a clearing request for TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org).
Login as admin4@sw360.org (primary:DEPARTMENT4 as User, secondary:DEPARTMENT3 as Admin), create a clearing request for TestProject3 (Created by:user3@sw360.org, Group:DEPARTMENT3, Moderators:admin3@sw360.org).

Result 3.6:
OK (user4@sw360.org can not create a clearing request while admin4@sw360.org can.)

[smrutis1]

Given a test from REST side with the below scenarios successfully.

Testing Steps: (With primary role as "User" and secondary role "Clearing Admin"):

1. Able to create, fetch, update project.
2. Fetching secondary group project with visibility-EVERYONE & updating it.
3. Updated visibility to BUISNESSUNIT_AND_MODERATORS and reading & updating the project.
4. Listing projects, releases, components.

[JaideepPalit]

Hi @shi9qiu ,Thank you for the test.
Fixed all the issues mentioned.

Test Case 2.1:
- Fixed

**Test Case 3.5: **(View/accept/decline a moderation request)
- Fixed

Test Case 3.4: (Create)
- when a user creates a project, the BusinessUnit/Group of Project will always be evaluated based on Primary Group of user and secondary group or any other value would not be considered.
- Disabled the Group textbox in the UI, to eliminate confusion.

[shi9qiu]

Thank you! @JaideepPalit

I will do more test about this!

[JaideepPalit]

(from discussion)

1. Remove Admin from dropdown list of Secondary Department Roles list. Instead SW360 Admin can be used.
   • fixed
2. Fix UI issues in the popup dialog box.
   • Remove Save Button after save is done. - fixed
3. Admin -> User -> Table . Sort by Secondary Department and Roles not working as expected.
   • fixed
4. Implemented Secondary Group and Roles feature for Component and Releases
   • Release
     • ECC Update
       • Old Feature - User will be able to update ECC related information, if User is ECC_ADMIN or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - User will be able to update ECC related information, if User is ECC_ADMIN or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Vulnerability Read/Update
       • Old Feature - User will be able to update Vulnerability related information, if User is SECURITY_ADMIN or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - User will be able to update Vulnerability related information, if User is SECURITY_ADMIN or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Other Information - Update
       • Old Feature - User will be able to update Other information, if User is Contributor or CLEARING_ADMIN or CLEARING_EXPERT or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - User will be able to update Other information, if User is Contributor or CLEARING_ADMIN or CLEARING_EXPERT or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Moderation Request (ECC Info not updated) would be sent to
       • Old Feature - Moderation Request would be sent to Creator, Moderator , Clearing_Admin or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - Moderation Request would be sent to Creator, Moderator , Clearing_Admin or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Moderation Request (ECC Info updated) would be sent to
       • Old Feature - Moderation Request would be sent to Admin, or SW360_ADMIN ECC_ADMIN with same department as creator of Release as Primary Role
       • New Feature - Moderation Request would be sent to Admin, or SW360_ADMIN ECC_ADMIN with same department as creator of Release as Primary Role or secondary role
   • Component
     • Vulnerability Read/Update
       • Old Feature - User will be able to update Vulnerability related information, if User is SECURITY_ADMIN or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - User will be able to update Vulnerability related information, if User is SECURITY_ADMIN or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Other Information - Update
       • Old Feature - User will be able to update Other information, if User is Contributor or CLEARING_ADMIN or CLEARING_EXPERT or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - User will be able to update Other information, if User is Contributor or CLEARING_ADMIN or CLEARING_EXPERT or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department
     • Moderation Request would be sent to
       • Old Feature - Moderation Request would be sent to Creator, Moderator , Clearing_Admin or ADMIN or SW360_ADMIN as Primary Role
       • New Feature - Moderation Request would be sent to Creator, Moderator , Clearing_Admin or ADMIN or SW360_ADMIN as Primary Role or secondary role in any secondary Department

Note - ADMIN can be replaced with SW360_ADMIN here

[smrutis1]

Few tests from my side w.r.t components and release update with primary role as "User" and secondary role as "Clearing Admin" in test instance.

• Able to update all releases/components irrespective of the created by user's role.

[KoukiHama]

Question : #831 is fixed by this pull request ?

[JaideepPalit]

Resolved Merge Conflict

[JaideepPalit]

Question : #831 is fixed by this pull request ?

Hi @KoukiHama , from our internal discussion few weeks back, it was suggested that

• when a user creates a project, the BusinessUnit/Group of Project will always be evaluated based on Primary Group of user and secondary group or any other value would not be considered.
• To avoid confusion , Disable the Group textbox in the UI.

Maybe we can discuss more in today's telco.

[KoukiHama]

when a user creates a project, the BusinessUnit/Group of Project will always be evaluated based on Primary Group of user and secondary group or any other value would not be considered.

To avoid confusion , Disable the Group textbox in the UI.

I got it! Thank you! @JaideepPalit

[shi9qiu]

I have tested what I tested before. It seems no problem for me now. Removing "ADMIN" and keeping "SW360_ADMIN" is good for me. As a newcomer, I was confusing about the difference between them before. Of course, the functionality needs more tests. I will do more if I am available.