separated 'admins-and-groupings' into 2 endpoints 'groupings-admins' & 'all-groupings'

[mikhail-shkaralevich]

Ticket Link

Ticket

List of squashed commits

• Add new endpoints 'groupings-admins' & 'all-groupings'.
• Create new class GroupingAdmins to store a group of admins
• Create new class GroupingAll to store a list of all groupings
• Modify function groupingPaths() to make sure that only admins have access to all the groupings
• Write tests
• Cleanup code

Test Checklist

• Exhibits Clear Code Structure:
• Project Unit Tests Passed:
• Project Integration Tests Passed:
• Executes Expected Functionality:
• Tested For Incorrect/Unexpected Inputs:

[JorWo]

Overall, great work! Also make sure to update your code style file in IntelliJ and fixup the import order in all the Java files. You can send me or Isaac a message if you have any questions.

I will review your UI PR once the changes have been made to this PR because you are likely to have to make changes to the UI side too.

[JorWo]

Final thing, make sure the functions and classes created/touched in this PR have 100% test coverage or as close as to 100% as you can. Here is how to check the test coverage percentage: https://uhawaii.atlassian.net/wiki/spaces/SITARd/pages/12943618/jaCoCo+Code+Coverage

[JorWo]

I have a better idea for this function, let's change up the GroupingAdmins to store a GroupingGroupMembers (Note the "s" only after Members) instead of a Group. That would mean that grouperApiService.getMembersResult() should be called in this function. Also notice the constructor for GroupingGroupMembers takes in GetMembersResult. Making this change will match the code with our current API design.

[JorWo]

Also could you remove the space before (string adminUhIdentifier) on line 62? Thanks!

[mikhail-shkaralevich]

package edu.hawaii.its.api.groupings;

import edu.hawaii.its.api.wrapper.GetMembersResult;
import edu.hawaii.its.api.wrapper.Subject;

import java.util.List;

public class GroupingAdmins {

    private GroupingGroupMembers adminGroupingGroupMembers;

    public GroupingAdmins() {
        this.adminGroupingGroupMembers = new GroupingGroupMembers();
        this.adminGroupingGroupMembers.setResultCode("FAILURE");
    }

    public GroupingAdmins(GetMembersResult getMembersResult) {
        this.adminGroupingGroupMembers = new GroupingGroupMembers(getMembersResult);
        this.adminGroupingGroupMembers.setResultCode("SUCCESS");
    }

    public List<GroupingGroupMember> getAdminGroupMembers() { return adminGroupingGroupMembers.getMembers(); }

    public void setAdminGroupMembers(List<Subject> adminGroup) { this.adminGroupingGroupMembers.setMembers(adminGroup); }

    public String getResultCode() { return this.adminGroupingGroupMembers.getResultCode(); }
}

Does it look right?

[mikhail-shkaralevich]

Should it have a 3rd constructor taking List<Subjects> as a parameter?

[mikhail-shkaralevich]

I am a bit confused about how this should be implemented and what i need to return in the getters and set in the setters. Is it List<Subject> or GroupingGroupMembers

[JorWo]

The GroupingAdmins should continue to implement GroupingResult. The adminGroupingGroupMembers can just be admins for short.

You only need a 3rd constructor if you will use it.

The getter should be of type GroupingGroupMembers. The setter in this case is not needed and should be used as private a function to help with your constructors. You can see the other classes in the /groupings folder that do it like that.

[JorWo]

Sorry for the confusion, I took a deeper look into the GroupingGroupMembers class and it would seem better to remove the GroupingAdmins class and instead use the GroupingGroupMembers as the return type for grouping admins. That way we do not create any redundant classes.

[JorWo]

Looks good!