CSC/ECE 517 Spring 2023 - E2328 Refactor student teams functionality

From Expertiza_Wiki
Jump to navigation Jump to search

This page contains information about Expertiza Project E2328 which is a continuation of E2304. Refactor student teams functionality was a project in CSC517 Spring 2023.

Please see below for a description of the design of the project and the previous changes done.

Introduction & Prior Work

The Expertiza project is software to create reusable learning objects through peer review. It also supports team projects, and the submission of almost any document type, including URLs and wiki pages.

Users & Participants: Everyone who took the CSC517 OODD class at NC State is a user in Expertiza, and instructors can add users as participants in an assignment so that they can access it to contribute, make changes and submit their work to be graded.

Almost all of the work within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. The team_users table references users instead of participants. This anomaly in the teams_users relation causes problems with how student teams are rendered in the UI, and it doesn’t mix well with the new functionality that was recently introduced. The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id. Ideally, the application should use only participant_id, but to handle the existing data in the database without running a massive migration, the application should be able to handle both old records that use user_id and new ones that shall, from after this project is completed, use participant_id instead.


Requirements

1. Make changes in teams_users to use participant_id instead of user_id.

2. Migrate old data to incorporate these changes as well.

3. Squash the migration files in a single file

4. Fix the build failing issue

5. Analyze previously found issue in E2304: Find which row has participant_id as null in teams_participant table and why

6. Query for participant_id to be null, find the user id and team id for this row, and see why the migration conditions didn’t satisfy

7. student_teams view page is quite bloated. Split into partials.


Design Plan

Analysis from project E2304:

Since the user_id field is used predominantly in several other controllers in a variety of ways, we cannot remove the user_id column without major changes in the application. After performing migration changes to populate the participant_id, we found that there were multiple rows in the teams_participants (earlier teams_users) table which did not have any participant id linked to it. This seems to be a data inconsistency issue in the database provided.

Changing the schema

  • Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.
  • Use this participant_id field in all operations for teams going forward.
  • To fix null participant rows anomaly, create a migration to create new participant rows in the participants table for those teams_participants entries which do not have a corresponding entry in participants table. This is to fix the data mismatch issue.

Note: This must also work with the existing functionality and data which makes use of user_id, so the code written must take both into account in its working.


Refactoring the teams rendering (/views/student_teams/view.html.erb)

Make 5 partials to split the view and place the functionality into them respectively.

Other Changes

Ensure spells checks and other failures handled so that the build passes on the PR

Note: No specific design pattern is being used as we are only adding a column to an existing table and mapping the participant_id to the teams_participant table and refactoring the code which access this model.

Schema Changes

The participant_id field in the the teams_participants relation is computed as follows using a migration file:

  • Finding Assignment ID By Team ID

The teams_participants table contains team_id, user_id and duty_id but not the participant_id. Since the same user_id can be associated with multiple participant_ids (since the same user can participate in multiple assignments and gets a unique participant_id in each assignment they take part in), we need to get the user_ids in the assignment for which we need the particular user's participant_id. For this reason, we need to first find the assignment_id.

  • Finding Participant ID By Assignment ID and User ID

With the assignment_id retrieved, we can find the list of participant_ids that participated in the assignment, and using the user_id, get the participant_id which is saved in the participants table.

  • If the above participant_id is not found ( due to data issue ) we create a new Participant and use that participant's id to avoid code from breaking.

The migration file will have both up and down functionalities to revert the changes if required.

ER diagram for updated schema

Implementation

One of the requirements in E2328 is the refactoring of the student teams view in views/student_teams/view.html.erb

This view is quite cluttered and as a result, makes editing, understanding and extension difficult and tiresome for any future updates to the expertiza application. The code in this file can be modularized to obtain simpler and easier-to-understand, which is what we have achieved. The view was reafactored to incorporate partials, and some of the partials created as a result are:

  • _invited_people.html.erb : partial for displaying the invited participants to the assignment team
  • _display_advertisements.html.erb : partial for displaying advertisements in the view
  • _send_invitaions.html.erb : partial for the send invitations functionality
  • _received_invitations.html.erb : partial to display the received invitations for the current user

Please see the next sections for some screenshots of the UI related to the above described partials. Main files which will be changed on splitting the view into partials are as follows:

New files added:

  • app/views/student_teams/_display_advertisements.html.erb
  • app/views/student_teams/_invited_people.html.erb
  • app/views/student_teams/_received_invitations.html.erb
  • app/views/student_teams/_send_invitations.html.erb
  • app/views/student_teams/_team_display.html.erb

Existing files modified:

  • app/student_teams/view.html.erb

Test Plan

Manual Testing

The changes in teams_users means we need to re-examine the flows and user stories through where teams_users is used. This, in practice, means that we manually have checked the different ways in which a team for an assignment can be created in expertiza, and other associated operations such as removal of a user from a team, addition of a new user, deletion of a team etc. This testing was necessary to ensure that the functionality in expertiza still worked as expected even after our refactoring was completed.

The main user stories we examined are:

1. Student creates a team: A student, newly added to an assignment, opens the application and goes to "my team" after opening the assignment on expertiza. He enters his team's name and the team is created.

2. Student joins a team: A student, is invited to join a team for an assignment, and accepts. He is added to an existing team, possibly created by another student or instructor.

3. Instructor creates a team manually: An instructor who wishes to create a team with certain students on it, chooses the assignment on expertiza, and clicks on the icon to add a new team and in the manual section, creates a new team by giving a team name. They add students or participants to the newly created team and can remove them too.

4. Instructor creates teams automatically: An instructor wishes to assign all the students involved in an assignment randomly to teams of a certain size. They open expertiza, choose the assignment, and then click on the icon to add a new team, and in the "create teams automatically" section, enter the team size they wish to use. The system then creates teams of the specified size, adding students randomly to teams which is reflected in both student and instructor views.

In addition to verifying team creation in all of the above scenarios, we also verified other operations such as addition of a team member after the team capacity was exhausted, deletion and re-addition of the same user, invitations to already existing participants in the same team etc and ensure the system was working as expected in these scenarios as well.

Automated Testing RSpec

Since this is a refactoring project, the scope of testing is limited to the changes made as part of refactoring and also to ensure that the existing test cases do not break or are modified accordingly. This can be done with manual testing. None of the existing test cases were breaking with our changes.


Team Members

  1. Tanvi Sinha (tsinha2@ncsu.edu)
  2. Shreya Maheshwari (smahesh4@ncsu.edu)
  3. Rishikesh Pravin Yelne (ryelne@ncsu.edu)

Mentor: Divyang Doshi

Code Details

Github Pull Request - https://github.com/expertiza/expertiza/pull/2563

Repo - https://github.com/tanvi9sinha/expertiza

Demo - https://drive.google.com/file/d/1_mFaB9T5mTM8RfdcHgcgtp4IhzKliuBz/view?usp=share_link

[1] contains detailed information on the previous team's work on this feature.

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2023_-_E2328_Refactor_student_teams_functionality&oldid=150323"