Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T03:49:12Z

Sbabu: /* Future Scope */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.
* However, it is to be noted that 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) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored as this view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the CRUD functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:ER_Updated.png |900px]]

== Implementation ==

Main files which were changed are
* app/models/participant.rb
* app/models/team.rb
* app/models/teams_user.rb
* app/models/user.rb

As the project tries to introduce participant_id as a replacement of user_id, we've calculated all the details with both user_id and participant_id (whichever is available based on whether the data is old or new). We've also added comments everywhere to show the code snippets which need to be removed once user_id is deprecated. (Check for '''comments with #E2243''')

Currently teams_user table has user_id or participant_id for now. So we've ensured that checks happen based on both the IDs unless user_id is removed. The default check is overridden to ensure newer datas which only have participant_id are also indexed and found using the function call here.

'''Code Snippet'''

TeamsUser.where(user_id: user_id).or(TeamsUser.where(participant_id: participant_id))

===find_by_team_id_and_user_id===

''.where'' function makes a lot of DB calls when asked for user_id, we've introduced a module called "'''''find_by_team_id_and_user_id()'''''" which will override ''.where'' function. If user_id is not present in the table, it loads based on participant_id instead, as you can have only one as the key and not both.

So wherever .where is used,
TeamsUser.where('team_id = ? and user_id = ?', @team.id, @user.id),
we've replaced it with
TeamsUser.find_by_team_id_and_user_id(@team.id, @user.id).

[[File:Find_by_team_id_and_user_id.png |600px]]

This way instead of changing the query for every call, we've used a single function for all the calls, thereby implementing '''DRY''' principle.

===add_participant_to_team===

The existing function to add a member
add_member(user,team.parent_id)
adds user to a team based on the user_id and team_id.

We've introduced a new function called
add_participant_to_team(student, team.parent_id)
which adds participant(student) to a team based on participant_id(or user_id wherever participant_id is not available)

This function takes participant and team_id, and assigns that participant to a team. In future, once user_id is removed, add_participant_to_team can be used as a replacement.

[[File:Add_participant_to_team.png|600px]]

=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== View Changes and Refactoring ==

One of the requirements in E2243 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.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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.

[[File:Student_Creates_Team_SendInvite.png|600px]]

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.

[[File:Student_Joins_Team_ReceivesInvite.png|600px]]

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.

[[File:Create_Teams_Instructors_Manually.png|600px]]

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.

[[File:Create_Teams_Instructors_Automatically.png|600px]]

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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb :

* ''object initialization''
* ''#update_duties''
* ''when user is added to assignment team''
* ''when user is added to assignment team''
* ''when user is added to course team''
* ''when user is already on an assignment team''
* ''when user is added to assignment team while on a team already''
* ''when user is already on a course team''

the new methods which use both participant_id and user_id have been incorporated as needed to ensure continued quality of the testing suite and maintenance of code coverage.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/course_team_spec.rb
* spec/models/invitation_spec.rb
* spec/models/student_task_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb
* spec/helpers/grades_helper_spec.rb
* spec/helpers/sign_up_sheet_helper_spec.rb

Controllers:
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/grades_controller_spec.rb
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb
* spec/controllers/invitations_controller_spec.rb

== Future Scope ==

# Create a migration to compute the participant_id field for all the rows in the teams_users table that currently have a user_id field.
# Remove the user_id column from the teams_users table.
# Rename the teams_user table to teams_participant so that this better reflects its new functionality and use cases in the system.
# Modify functions which use user_id and replace them with functions using participant_id only (Note: Look for code comments with #E2243 for all the replacement functions)

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

== Code Details ==
Github Pull Request - https://github.com/expertiza/expertiza/pull/2391

Repo - https://github.com/sak1997/expertiza/tree/beta

Demo - https://drive.google.com/file/d/1zWnHJNgSkioMd_xmB2L-7wPM2_OP7yka/view?usp=sharing

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T03:04:35Z

Sbabu: /* View Changes and Refactoring */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.
* However, it is to be noted that 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) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored as this view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the CRUD functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Implementation ==

Main files which were changed are
* app/models/participant.rb
* app/models/team.rb
* app/models/teams_user.rb
* app/models/user.rb

As the project tries to introduce participant_id as a replacement of user_id, we've calculated all the details with both user_id and participant_id (whichever is available based on whether the data is old or new). We've also added comments everywhere to show the code snippets which need to be removed once user_id is deprecated. (Check for '''comments with #E2243''')

Currently teams_user table has user_id or participant_id for now. So we've ensured that checks happen based on both the IDs unless user_id is removed. The default check is overridden to ensure newer datas which only have participant_id are also indexed and found using the function call here.

'''Code Snippet'''

TeamsUser.where(user_id: user_id).or(TeamsUser.where(participant_id: participant_id))

===find_by_team_id_and_user_id===

''.where'' function makes a lot of DB calls when asked for user_id, we've introduced a module called "'''''find_by_team_id_and_user_id()'''''" which will override ''.where'' function. If user_id is not present in the table, it loads based on participant_id instead, as you can have only one as the key and not both.

So wherever .where is used,
TeamsUser.where('team_id = ? and user_id = ?', @team.id, @user.id),
we've replaced it with
TeamsUser.find_by_team_id_and_user_id(@team.id, @user.id).

[[File:Find_by_team_id_and_user_id.png |600px]]

This way instead of changing the query for every call, we've used a single function for all the calls, thereby implementing '''DRY''' principle.

===add_participant_to_team===

The existing function to add a member
add_member(user,team.parent_id)
adds user to a team based on the user_id and team_id.

We've introduced a new function called
add_participant_to_team(student, team.parent_id)
which adds participant(student) to a team based on participant_id(or user_id wherever participant_id is not available)

This function takes participant and team_id, and assigns that participant to a team. In future, once user_id is removed, add_participant_to_team can be used as a replacement.

[[File:Add_participant_to_team.png|600px]]

=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== View Changes and Refactoring ==

One of the requirements in E2243 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.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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.

[[File:Student_Creates_Team_SendInvite.png|600px]]

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.

[[File:Student_Joins_Team_ReceivesInvite.png|600px]]

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.

[[File:Create_Teams_Instructors_Manually.png|600px]]

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.

[[File:Create_Teams_Instructors_Automatically.png|600px]]

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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb :

* ''object initialization''
* ''#update_duties''
* ''when user is added to assignment team''
* ''when user is added to assignment team''
* ''when user is added to course team''
* ''when user is already on an assignment team''
* ''when user is added to assignment team while on a team already''
* ''when user is already on a course team''

the new methods which use both participant_id and user_id have been incorporated as needed to ensure continued quality of the testing suite and maintenance of code coverage.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/course_team_spec.rb
* spec/models/invitation_spec.rb
* spec/models/student_task_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb
* spec/helpers/grades_helper_spec.rb
* spec/helpers/sign_up_sheet_helper_spec.rb

Controllers:
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/grades_controller_spec.rb
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb
* spec/controllers/invitations_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

== Code Details ==
Github Pull Request - https://github.com/expertiza/expertiza/pull/2391

Repo - https://github.com/sak1997/expertiza/tree/beta

Demo - https://drive.google.com/file/d/1RXINSdJYUv3Bd25epE8AP7vJgM6UXche/view (accessible only by users with ncsu.edu email address)

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:23:30Z

Sbabu: /* Automated Testing RSpec */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.
* However, it is to be noted that 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) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored as this view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb :

* ''object initialization''
* ''#update_duties''
* ''when user is added to assignment team''
* ''when user is added to assignment team''
* ''when user is added to course team''
* ''when user is already on an assignment team''
* ''when user is added to assignment team while on a team already''
* ''when user is already on a course team''

the new methods which use both participant_id and user_id have been incorporated as needed to ensure continued quality of the testing suite and maintenance of code coverage.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:21:43Z

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

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.
* However, it is to be noted that 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) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored as this view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:21:12Z

Sbabu: /* Changing the schema */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.
* However, it is to be noted that 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) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:13:32Z

Sbabu: /* Effects of code changes in the Expertiza Application */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:10:43Z

Sbabu: /* Given Requirements */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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 ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:10:30Z

Sbabu: /* Other Changes */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).

Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:09:36Z

Sbabu: /* Automated Testing RSpec */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.
In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' the new methods which use both participant_id and user_id are to be incorporated to ensure continued quality of testing.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:08:23Z

Sbabu: /* Fixed Test Files */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

==== Fixed Test Files ====

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:08:06Z

Sbabu: /* Automated Testing RSpec */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:06:04Z

Sbabu: /* Background */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:04:27Z

Sbabu: /* Fixed Test Files */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the below files, and we have worked on fixing these to work with the new and updated functionality. The main issues were involving tests using the old methods for creating a team, adding participants to the team etc.

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:03:17Z

Sbabu: /* Manual Testing */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-26T00:01:47Z

Sbabu: /* Manual Testing */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
# 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.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-25T23:59:56Z

Sbabu: i

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== 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:

# 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.
# 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.
# 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.
#

There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-25T23:51:14Z

Sbabu: /* Other Changes */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Updated logic for all the crud functionalities in teams_users controller (wherever applicable).
Fixed tests to incorporate the new logic as a result of using both user_id and participant_id in the teams_user logic.

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-25T23:50:32Z

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

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We have made partials and placed those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-25T23:50:09Z

Sbabu: /* Given Requirements */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===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. There are a number of workflows involving teams we have examined and worked on, which are elaborated below.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-24T22:15:31Z

Sbabu:

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===Changing the schema ===
* We need to rename the table table teams_users to teams_participants.
* Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

== View Changes and Refactoring ==

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-24T22:14:03Z

Sbabu: /* Team Members */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===Changing the schema ===
* We need to rename the table table teams_users to teams_participants.
* Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

==== View Changes and Refactoring ====

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

Mentor: Naman Shrimali

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-24T22:13:17Z

Sbabu: /* Test Plan */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===Changing the schema ===
* We need to rename the table table teams_users to teams_participants.
* Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

==== View Changes and Refactoring ====

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

=== Fixed Test Files ===

After our refactoring, we noticed failing tests in the following files, and we have worked on fixing these to work with the new and updated functionality:

Models:
* spec/models/assignment_team_spec.rb
* spec/models/team_spec.rb

Helper:
* spec/helpers/authorization_helper_spec.rb

Controllers:
* spec/controllers/join_team_request_controller_spec.rb
* spec/controllers/student_teams_controller_spec.rb
* spec/controllers/assessment360_controller_spec.rb
* spec/controllers/lottery_controller_spec.rb
* spec/controllers/sign_up_sheet_controller_spec.rb
* spec/controllers/submitted_content_controller_spec.rb
* spec/controllers/teams_users_controller_spec.rb

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-24T22:05:37Z

Sbabu: /* Changing the schema */

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===Changing the schema ===
* We need to rename the table table teams_users to teams_participants.
* Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

==== View Changes and Refactoring ====

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-24T22:05:18Z

Sbabu: added content to view section

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the design of the project.

== Background ==

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 works within Assignments is done by participants, not users. All the tables use participant_id to track contributions to assignments, except teams_users. In the documentation, it can be noted that 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.

As given in the specifications for the project, the name of the table "teams_users" should be changed to "teams_participants". The participant_id field should be added to the model, and references that use user_id should also incorporate participant_id.

== Given Requirements ==

===Changing the schema ===
* We need to rename the table table teams_users to teams_participants.
* Create a column that would be called “participant_id”, which will be a foreign key that references the participants table.
* Create a migration that fetches the assignment_id for each tuple from the teams table. We would find the participant with the help of the assignment_id we just got from the teams table and the user_id that is already present in the current table, and store its “id” in the participant_id column we created in the last step.

=== Refactoring the teams rendering (/views/student_teams/view.html.erb) ===
The logic in the team's view (where participants can see their team members) that iterates and fetches information of all the team members and displays them would be refactored so that it matches our new design.
The view is quite bloated and has lots of functionalities written on it. We’ll be making partials and placing those functionality in their specific partials.

=== Other Changes ===

Update logic for all the crud functionalities in teams_users controller (wherever applicable).
Rename the teams_users_controller to teams_participants_controller (and all its references)

== Schema Changes ==

In teams_users table, we can add a new column '''participant_id''' which is a foreign key from participants table and remove the column '''user_id'''. We plan to remove the '''user_id''' column '''only after data migration''' since the user_id field is used predominantly in several other controllers in a variety of ways, and as such its removal must be done carefully.

The participant_id field in the the teams_users relation is computed as follows:

* Finding Assignment ID By Team ID
The teams_users 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.

=== ER diagram for updated schema ===
[[File:Updated_Proposed_ERR_for_student_teams_E2243.png |900px]]

== Data Migration ==
=== Analysis ===

''user_id'' exists as a foreign key in 2 relations - Participants and teams_users. Although they crrespond to same attribute, user_id alone cannot be used to find corresponding Participants because same user_id can exist for multiple Participants - due to Expertiza's design wherein for every assignment, every user is added to participant's table. Therefore Participant ID can be mapped to (assignment_id, user_id) pair.

== Proposed Implementation ==

==== Finding Assignment ID using Team ID ====

Each team is associated with an assignment. The parent_id in teams table corresponds to assignment_id. Therefore, team_id in teams_users table can be used to get the Team object and in turn fetch the Assignment ID (present as parent_id in the teams table)

# Code snippet to fetch assignment_id based on team_id
assignment_id = Team.find(team_id).select(:parent_id)

==== Finding Participant ID By Assignment ID and User ID ====

The Assignment object can be fetched using the assignment ID. Each assignment contains a list of participants. The Participant object contains a user_id attribute. Since, a user can have only one entry in the Participants table for an assignment, we can use user_id to find the user's participant_id from this list.

# Code snippet to fetch participant_id based on assignment_id and user_id
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id user_id)

=== Approach One ===

The above mentioned code snippets can be used for each tuple in the teams_users table.

# Brute Force Code Snippet
TeamsUser.all.each do |teamsUser|
assignment_id = Team.find(teamsUser.team_id).select(:parent_id)
participant_id = Assignment.find(assignment_id).participants.find_by(:user_id teamsUser.user_id)
teamsUser.update_attribute(:participant_id, participant_id)
end

=== Approach Two ===
In the brute force approach (Approach One), database calls are made multiple times inside the loop. Moving the database calls out of the loop will give us a more efficient solution.

Steps:

# Load all the TeamUser objects.
# Load all the Team objects for all the team_ids in TeamUser object
# Create a map with team_id as key and assignment_id as value. The resultant map usage: map[team_id] = assignment_id
# Load all the Assignment objects for all the assignment_ids from the map in the previous step. Also eager fetch participants along with the assignments.
# Create a nested map with assignment_id and user_id as key and participant_id as value. The resultant map usage: map[assignment_id][user_id] = participant_id
# For all TeamUser objects, find the participant_id from the maps generated from the previous steps and update the participant_id attribute.

==== View Changes and Refactoring ====

One of the requirements in E2243 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

== Effects of code changes in the Expertiza Application ==

While the renaming of the table to teams_participants has rippling effects throughout the program since multiple files contain calls to this class, It must be noted that not much else needs to change apart from the class name. In most cases, only the class name would be changed since we are primarily adding a new field(participant_id) and not removing any existing fields.

In most use cases noted in the application for the teams_users class, the main use cases seen are computed the team_id from the user_id and assignment_id or manipulations on the users in a teams_user object - adding and removing a team members from a team, for instance.

The changes we plan to make here will not cause a need for changes in other parts of the application apart from the replacement of the class name to teams_participants.

== Impacted Files ==

* teams_users_controller.rb (expertiza/app/controller/teams_user_controller.rb)
We will be adding code here to compute the participant_id using the methodologies described above.

* teams_users.rb (expertiza/app/models/teams_user.rb)
The model will be updated (as can be seen in the ER diagram above) to have the participant_id added.

* teams_users(expertiza/app/views/teams_users)
The view will be updated to reflect the new name of the model, and contain new partials that make use of the participant_id field.

* teams_users_controller_spec.rb(expertiza/spec/controllers/teams_users_controller_spec.rb)
The test file for the controller will be modified so that existing test cases pass the new changes, and also introduce new test cases to increase test coverage.

== Test Plan ==

=== Manual Testing ===
There is limited scope for testing this feature manually, as the refactoring targets computing participant_id in the teams_users table. This will improve the performance, and will not be shown in the user's view.

=== 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.As per our proposed design, we're working on adding participant_id computation, which will not be used on the views for the end user.

In all the existing test cases in expertiza/spec/controllers/teams_users_controller_spec.rb -- ''object initialization'', ''#update_duties'', ''when user is added to assignment team'', ''when user is added to assignment team'', ''when user is added to course team'', ''when user is already on an assignment team'', ''when user is added to assignment team while on a team already'' and ''when user is already on a course team'' participant_id needs to be incorporated and modified.

The team is also planning to add more test scenarios based on the implementation of the proposed solution to increase the test coverage.

== Team Members ==
# Ashok Kumar Selvam (aselvam@ncsu.edu)
# Sri Athithya Kruth Babu (sbabu@ncsu.edu)
# Subramanian Venkataraman (svenka25@ncsu.edu)

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T02:28:26Z

Sbabu: /* Impacted Files */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T02:27:50Z

Sbabu: /* View Changes */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T02:23:36Z

Sbabu: /* Proposed Implementation */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T01:34:26Z

Sbabu: added effects section

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T01:17:18Z

Sbabu: /* Analysis */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-12T01:15:57Z

Sbabu: /* Background */

CSC/ECE 517 Spring 2022

2022-04-07T20:38:28Z

Sbabu:

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2200: Testing advice_controller]]
* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2208: Testing for submission_records_controller, profile_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2225: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]
* [[CSC/ECE 517 Spring 2022 - E2207: Testing for submitted_content_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2205: Testing for participants_controller, versions_controller]]
* [[CSC/ECE 517 Spring 2022 - E2212: Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2022 - S2200: Refactoring evaluation of SQL queries (Java/JUnit)]]
* [[CSC/ECE 517 Spring 2022 - S2222: Refactor impersonate_controller]]
* [[CSC/ECE 517 Spring 2022 - E2202- Testing for badges_controller, publishing_controller]]
*[[CSC/ECE 517 Spring 2022 - E2220: Refactor reputation_web_service_controller]]
* [[CSC/ECE 517 Spring 2022 - E2224: Refactor review_mapping_controller]]
* [[CSC/ECE 517 Spring 2022 - E2209: Testing for analytic helper.rb, join team requests helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix]]
* [[CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2201: Testing for assignment_questionnaire_controller.rb]]

== Final Projects ==

* [[CSC/ECE 517 Spring 2022 - E2245: View for results of bidding]]
* [[CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements]]
* [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail]]
* [[CSC/ECE 517 Spring 2022 - S2201: Improving User Experience for SQLFE]]
* [[CSC/ECE 517 Spring 2022 - E2236: Fix issues related to deadlines and late policies]]
* [[CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Spring 2022 - E2233. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Spring 2022 - E2234. Calibration submissions should be copied along with calibration assignments]]
* [[CSC/ECE 517 Spring 2022 - E2244. Support for saying your team pair-programmed]]
* [[CSC/ECE 517 Spring 2022 - E2246: Email your authors/reviewers, with complete tests]]
* [[CSC/ECE 517 Spring 2022 - E2229: Track the time students look at other submissions]]
* [[CSC/ECE 517 Spring 2022 - E2239: Further refactoring and improvement of review mapping helper.rb ]]
* [[CSC/ECE 517 Spring 2022 - E2240. Re-write waitlist functionality ]]
* [[CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view ]]
* [[CSC/ECE 517 Spring 2022 - E2243. Refactor student_teams functionality]]
* [[CSC/ECE 517 Spring 2022 - E2235. Issues related to meta-reviewing]]
* [[CSC/ECE 517 Spring 2022 - E2230. Integrate Suggestion Detection Algorithm]]
* [[CSC/ECE 517 Spring 2022 - E2238. Implementing and testing Import & Export controllers]]
* [[CSC/ECE 517 Spring 2022 - E2228. Refactor JavaScript on Expertiza]]

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-07T02:03:10Z

Sbabu: /* Impacted Files */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-07T02:01:49Z

Sbabu: /* Impacted Files */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-04T00:18:36Z

Sbabu: /* Schema Changes */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-01T23:57:29Z

Sbabu: /* Changing the schema */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-01T23:56:39Z

Sbabu: /* Background */

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-01T14:14:58Z

Sbabu: Added requirements

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-04-01T13:59:10Z

Sbabu: edited for clarity

CSC/ECE 517 Spring 2022 - E2243. Refactor student teams functionality

2022-03-31T01:38:09Z

Sbabu: created page

This page contains information about Expertiza Issue E2243. Refactor student teams functionality which was a project in CSC517 Spring 2022.

Please see below for a description of the project.

CSC/ECE 517 Spring 2022

2022-03-31T01:37:12Z

Sbabu: /* OSS Projects */

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-24T18:13:01Z

Sbabu: /* Automated Testing using RSPEC */

This page contains information about Expertiza Issue E2219 Improve assessment360_controller.rb which was a project in CSC517 Spring 2022. Please see below for a description of the improvements made, issues fixed, code changed, testing information, details required to peer-review the project, and future improvements.

== Peer Review Information ==

For users who would like to view and test the assessment 360 feature, the deployed Expertiza application can be found at the URL mentioned below and can be access using the credentials below:

URL: http://152.7.99.75:8080

Instructor login:

Username: '''instructor6'''

Password: '''password'''

Click on courses and then click on the icon on any one course to go to the assessment 360 page, or log in and paste this URL into the browser: http://152.7.99.75:8080/assessment360/index?course_id=184
The course ID here is an example, you can add the course ID of your choice.

[[File:E2219 Navigation.jpeg|800px]]

Please note that due to VCL constraints, the page will take few mins to load and render the data. Please wait for the page to '''load completely''' before starting the peer review.

== Introduction ==

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.
The Expertiza project contains a feature that allows instructors to get a full or 360-degree view of a course they teach that includes all students in the course, all assignments, and the scores of each student in each assignment, averages, and final scores as well. This feature, called assessment 360, was written in a previous year, and due to issues identified with the code such as variable names, redundancy, code smells etc, a need for improvement of the same was identified.

== Issues and Description of Fixes ==
In our work on improving this feature, we have handled the following issues and made the following improvements:

=== Refactoring ===

The previous implementation of the controller made a number of database calls, several of which were extraneous and not required. We have refactored the functions pertaining to these calls so that the number of unneeded calls to the database is reduced for loading teammate and metareviews.

The older implementation of the computation for class averages, and students average scores incorrectly factored in students who had not received grades for an assignment or who had not taken part in an assignment.
In addition to correcting this, we also simplified the process by refactoring the code(please see the next section for the code).

The past implementation of the controller was unclear and non-Rubyistic in naming conventions, function names, and implementation in the code. We have refactored the controller to make it more Rubyistic overall and also re-written parts of the code to make it more understandable, as well as more CRUD-like. Additionally, we made several methods whose functionality was required and used only inside this controller private.

=== UI changes ===
The previous implementation had 2 views – all_students_all_reviews and course_student_grade_summary. Both of these views cover some of the data required for a 360-degree view of the course.
We have combined these pages together into a single page that contains checkboxes which allow the user to select what data they would like to view and shows only those columns they would like to see. This both simplifies and enhances the functioning of the feature.

=== Variable Names, Cosmetic Issues, Comments ===

In the older implementation, there were some unclear variable names such as teamed_count, and some other minor cosmetic issues such as a hyphen being displayed for empty fields where a dash would more visible and clearer. These have been fixed in both the code and the UI of the application to be user-friendly and developer friendly.
Additionally, comments have been added everywhere to make the code easier to understand and modify for future improvements.

== Fix details and Code Explanation ==

=== Files Changed ===
The following files were altered and edited in the course of our work on this feature:
Assessment360_Controller.rb (under app/controller)
This file contains the controller for the assessment 360 feature which we have improved in our work. The code has been refactored to be cleaner, modular, easier to understand and also to incorporate DRY.

Index.html.erb (under app/views/assessment360)
The view for the assessment 360 feature have been combined as stated in the requirements and all the data is now viewable from the index.html.erb page. This page also features checkboxes so the user can view only the data they are interested in without cluttering caused by unneeded data.

=== Issue Fix Details ===

1) '''app/controllers/assessment360_controller.rb'''

[[File:E2219 assessment360 controller 1.png|800px]]

[[File:E2219 assessment360 controller 2.png|800px]]

[[File:E2219 assessment360 controller 3.png|800px]]

[[File:E2219 assessment360 controller 4.png|800px]]

'''Code changes'''

1. In all_student_all_reviews function, the DB calls are by creating init_data function.

2. The init_data function, removes DB calls inside nested for-loops (look for old code, below) which makes db call for every iteration, the code has been refactored in such a way that it preloads the required data using assignments.includes([:participants]) (look for new code, below). This way, instead of making multiple db calls across diff functions, we load the required data and thereby reduce the processing time.

3. The major change, which we've incorporated here is moving the functions which weren't used in other modules into private. Moving excess functions to private, helps keep the controller more CRUD-like and differentiates to the developer which functions are used by the controller to work, and which ones are the functions of the controller.

'''Old Code (with complex for loops and more db calls)'''

@course_participants.each do |cp|
# for each assignment
# [aggregrate_review_grades_per_stu, review_count_per_stu] --> [0, 0]
%w[teammate meta].each { |type| instance_variable_set("@#{type}_review_info_per_stu", [0, 0]) }
students_teamed = StudentTask.teamed_students(cp.user)
@teamed_count[cp.id] = students_teamed[course.id].try(:size).to_i
@assignments.each do |assignment|
@meta_review[cp.id] = {} unless @meta_review.key?(cp.id)
@teammate_review[cp.id] = {} unless @teammate_review.key?(cp.id)
assignment_participant = assignment.participants.find_by(user_id: cp.user_id)
next if assignment_participant.nil?
teammate_reviews = assignment_participant.teammate_reviews
meta_reviews = assignment_participant.metareviews
calc_overall_review_info(assignment,
cp,
teammate_reviews,
@teammate_review,
@overall_teammate_review_grades,
@overall_teammate_review_count,
@teammate_review_info_per_stu)
calc_overall_review_info(assignment,
cp,
meta_reviews,
@meta_review,
@overall_meta_review_grades,
@overall_meta_review_count,
@meta_review_info_per_stu)
end

'''Refactored Code (with limited iteration and db calls)'''
@assignments.each do |assignment|
assignment.participants.each do |assignment_participant|
reviews[assignment_participant.user_id] = {} unless reviews.key?(assignment_participant.user_id)
assignment_reviews = assignment_participant.public_send(reviews_type) if assignment_participant.respond_to? reviews_type
# If a student has not taken an assignment or if they have not received any grade for the same,
# assign it as nil(not returning anything). This helps in easier calculation of overall grade
score = calc_avg_score(assignment_reviews)
reviews[assignment_participant.user_id][assignment.id] = score unless score.nil?
end
end

2) '''app/views/assessment360/index.html.erb'''

[[File:E2219 indexhtmlerb 1.png|800px]]

[[File:E2219 indexhtmlerb 2.png|800px]]

[[File:E2219 indexhtmlerb 3.png|800px]]

1. We've created a new file called ''index.html.erb''. This file contains all the logic for the frontend of this module.

2. Major change that has been made is the addition of checkboxes. This way, users can filter the data that they view and view the data efficiently.

3. This page loads all the assignment data, and their metadata like - meta reviews, teammate reviews, peer score, topic and instructor grade. The table also contains Aggregate score and Total grade.

4. The checkboxes have been programmed in a way that whenever a checkbox is disabled, the corresponding column gets removed and the colspan rendering gets adjusted. Along with that, when all assignment parameters are unchecked, the assignment columns disappear completely. Same applies for aggregate score and Total Instructor Grade.

3) '''config/routes.rb'''

[[File:E2219 routes 1.png|800px]]

Removed old route to this page and pointed it to the newly created index page.

You can check all the issues fixed here - https://github.com/expertiza/expertiza/pull/2337

== Test Plan==

=== Automated Testing using RSPEC ===
Please note that we have removed several older tests which tested functions that are now private and inaccessible outside the controller class itself. However, the methods that call these private functions are still tested and tests are passing successfully.

1. After refactoring, most of our new test cases focus on functions which are the core of the controller - covering important aspects like who accesses the page, checking permissions for the page, how the page behaves on edge cases etc.

2. Using RSpec, the test cases cover various scenarios and tests each scenario in depth.
Eg, for access control, we check the access for all roles for a user comprehensively to ensure that only people with permissions can view the page.

3. Since most of the work in this module is computations in the back and rendering data in the frontend, we've ensured that the computations happen in their specific order and enough test cases are present for edge cases.

4. For backend computations, we've covered lot of edge cases like no participants to a course, when there are no reviews made by a participant, when assignment doesn't exists, insure existence_of being called before executing index page etc.

5. For frontend, we've covered cases like formatting of the data in the page, null dataset, score being int, float, null, displaying percentages when data is int, float, null etc.

Even though we've moved most of the code into private functions, the core functionalities of the controller are refactored and appropriate test cases are written to ensure high coverage.

Please run the following command to execute the tests:

rspec spec/controllers/assessment360_controller_spec.rb

=== Testing from UI ===
The following steps needs to be performed to test this code from UI:

1. Login as instructor(username: instructor6 , password: password). Please either do step 2 or 3, as both are not required.

2. Select Courses, and the page will show a list of courses. Please select the rightmost icons for any course (we recommend CSC517 Fall 2017, CSC517 Fall 2011 so there’s more data, but it can take some time for it load since there’s a lot of pre-loaded data in the VCL)

3. Alternatively, you can login and go to this URL: http://152.7.99.75:8080/assessment360/index?course_id=184

4. You should be able to see a webpage with a table and checkboxes at the top. This table is an instructor’s 360-degree view of a course, containing the scores of each students in the course for every assignment the instructor has added to Expertiza.

5. Unchecking some or all of the checkboxes removes and brings back various columns from/to the page. Please feel free to test this out.

== Scope for future improvement ==

The UI of the index page which shows all of the data can be improved to make it look neater and more aesthetically pleasing. The table’s positioning and centering can be improved for a more convenient experience overall.

The user’s preferred (checked on the UI checkboxes) can be saved to either the Database or a cache, and on subsequent reloads be the fields loaded on the page for a particular. We suggest using the database for this rather than a cache.

Lazy loading can be implemented for the columns the user last chose(assuming these are stored in the DB) and other columns can lazy-loaded if the user clicks on the checkboxes on the screen.

'''''course_student_grade_summary''''' function inside the assessment360_controller.rb contains few unnecessary db calls which can be refactored further to increase the efficiency and reduce the processing time of the module.

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-24T18:11:11Z

Sbabu: /* Testing from UI */

This page contains information about Expertiza Issue E2219 Improve assessment360_controller.rb which was a project in CSC517 Spring 2022. Please see below for a description of the improvements made, issues fixed, code changed, testing information, details required to peer-review the project, and future improvements.

== Peer Review Information ==

For users who would like to view and test the assessment 360 feature, the deployed Expertiza application can be found at the URL mentioned below and can be access using the credentials below:

URL: http://152.7.99.75:8080

Instructor login:

Username: '''instructor6'''

Password: '''password'''

Click on courses and then click on the icon on any one course to go to the assessment 360 page, or log in and paste this URL into the browser: http://152.7.99.75:8080/assessment360/index?course_id=184
The course ID here is an example, you can add the course ID of your choice.

[[File:E2219 Navigation.jpeg|800px]]

Please note that due to VCL constraints, the page will take few mins to load and render the data. Please wait for the page to '''load completely''' before starting the peer review.

== Introduction ==

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.
The Expertiza project contains a feature that allows instructors to get a full or 360-degree view of a course they teach that includes all students in the course, all assignments, and the scores of each student in each assignment, averages, and final scores as well. This feature, called assessment 360, was written in a previous year, and due to issues identified with the code such as variable names, redundancy, code smells etc, a need for improvement of the same was identified.

== Issues and Description of Fixes ==
In our work on improving this feature, we have handled the following issues and made the following improvements:

=== Refactoring ===

The previous implementation of the controller made a number of database calls, several of which were extraneous and not required. We have refactored the functions pertaining to these calls so that the number of unneeded calls to the database is reduced for loading teammate and metareviews.

The older implementation of the computation for class averages, and students average scores incorrectly factored in students who had not received grades for an assignment or who had not taken part in an assignment.
In addition to correcting this, we also simplified the process by refactoring the code(please see the next section for the code).

The past implementation of the controller was unclear and non-Rubyistic in naming conventions, function names, and implementation in the code. We have refactored the controller to make it more Rubyistic overall and also re-written parts of the code to make it more understandable, as well as more CRUD-like. Additionally, we made several methods whose functionality was required and used only inside this controller private.

=== UI changes ===
The previous implementation had 2 views – all_students_all_reviews and course_student_grade_summary. Both of these views cover some of the data required for a 360-degree view of the course.
We have combined these pages together into a single page that contains checkboxes which allow the user to select what data they would like to view and shows only those columns they would like to see. This both simplifies and enhances the functioning of the feature.

=== Variable Names, Cosmetic Issues, Comments ===

In the older implementation, there were some unclear variable names such as teamed_count, and some other minor cosmetic issues such as a hyphen being displayed for empty fields where a dash would more visible and clearer. These have been fixed in both the code and the UI of the application to be user-friendly and developer friendly.
Additionally, comments have been added everywhere to make the code easier to understand and modify for future improvements.

== Fix details and Code Explanation ==

=== Files Changed ===
The following files were altered and edited in the course of our work on this feature:
Assessment360_Controller.rb (under app/controller)
This file contains the controller for the assessment 360 feature which we have improved in our work. The code has been refactored to be cleaner, modular, easier to understand and also to incorporate DRY.

Index.html.erb (under app/views/assessment360)
The view for the assessment 360 feature have been combined as stated in the requirements and all the data is now viewable from the index.html.erb page. This page also features checkboxes so the user can view only the data they are interested in without cluttering caused by unneeded data.

=== Issue Fix Details ===

1) '''app/controllers/assessment360_controller.rb'''

[[File:E2219 assessment360 controller 1.png|800px]]

[[File:E2219 assessment360 controller 2.png|800px]]

[[File:E2219 assessment360 controller 3.png|800px]]

[[File:E2219 assessment360 controller 4.png|800px]]

'''Code changes'''

1. In all_student_all_reviews function, the DB calls are by creating init_data function.

2. The init_data function, removes DB calls inside nested for-loops (look for old code, below) which makes db call for every iteration, the code has been refactored in such a way that it preloads the required data using assignments.includes([:participants]) (look for new code, below). This way, instead of making multiple db calls across diff functions, we load the required data and thereby reduce the processing time.

3. The major change, which we've incorporated here is moving the functions which weren't used in other modules into private. Moving excess functions to private, helps keep the controller more CRUD-like and differentiates to the developer which functions are used by the controller to work, and which ones are the functions of the controller.

'''Old Code (with complex for loops and more db calls)'''

@course_participants.each do |cp|
# for each assignment
# [aggregrate_review_grades_per_stu, review_count_per_stu] --> [0, 0]
%w[teammate meta].each { |type| instance_variable_set("@#{type}_review_info_per_stu", [0, 0]) }
students_teamed = StudentTask.teamed_students(cp.user)
@teamed_count[cp.id] = students_teamed[course.id].try(:size).to_i
@assignments.each do |assignment|
@meta_review[cp.id] = {} unless @meta_review.key?(cp.id)
@teammate_review[cp.id] = {} unless @teammate_review.key?(cp.id)
assignment_participant = assignment.participants.find_by(user_id: cp.user_id)
next if assignment_participant.nil?
teammate_reviews = assignment_participant.teammate_reviews
meta_reviews = assignment_participant.metareviews
calc_overall_review_info(assignment,
cp,
teammate_reviews,
@teammate_review,
@overall_teammate_review_grades,
@overall_teammate_review_count,
@teammate_review_info_per_stu)
calc_overall_review_info(assignment,
cp,
meta_reviews,
@meta_review,
@overall_meta_review_grades,
@overall_meta_review_count,
@meta_review_info_per_stu)
end

'''Refactored Code (with limited iteration and db calls)'''
@assignments.each do |assignment|
assignment.participants.each do |assignment_participant|
reviews[assignment_participant.user_id] = {} unless reviews.key?(assignment_participant.user_id)
assignment_reviews = assignment_participant.public_send(reviews_type) if assignment_participant.respond_to? reviews_type
# If a student has not taken an assignment or if they have not received any grade for the same,
# assign it as nil(not returning anything). This helps in easier calculation of overall grade
score = calc_avg_score(assignment_reviews)
reviews[assignment_participant.user_id][assignment.id] = score unless score.nil?
end
end

2) '''app/views/assessment360/index.html.erb'''

[[File:E2219 indexhtmlerb 1.png|800px]]

[[File:E2219 indexhtmlerb 2.png|800px]]

[[File:E2219 indexhtmlerb 3.png|800px]]

1. We've created a new file called ''index.html.erb''. This file contains all the logic for the frontend of this module.

2. Major change that has been made is the addition of checkboxes. This way, users can filter the data that they view and view the data efficiently.

3. This page loads all the assignment data, and their metadata like - meta reviews, teammate reviews, peer score, topic and instructor grade. The table also contains Aggregate score and Total grade.

4. The checkboxes have been programmed in a way that whenever a checkbox is disabled, the corresponding column gets removed and the colspan rendering gets adjusted. Along with that, when all assignment parameters are unchecked, the assignment columns disappear completely. Same applies for aggregate score and Total Instructor Grade.

3) '''config/routes.rb'''

[[File:E2219 routes 1.png|800px]]

Removed old route to this page and pointed it to the newly created index page.

You can check all the issues fixed here - https://github.com/expertiza/expertiza/pull/2337

== Test Plan==

=== Automated Testing using RSPEC ===
Please note that we have removed several older tests which tested functions that are now private and inaccessible outside the controller class itself. However, the methods that call these private functions are still tested and tests are passing successfully.

1. After refactoring, most of our test cases focus on functions which are the core of the controller - covering important aspects like who accesses the page, checking permissions for the page, how the page behaves on edge cases etc.

2. Using RSpec, the test cases cover various scenarios and tests each scenario in depth.
Eg, for access control, we check the access for all roles for a user comprehensively to ensure that only people with permissions can view the page.

3. Since most of the work in this module is computations in the back and rendering data in the frontend, we've ensured that the computations happen in their specific order and enough test cases are present for edge cases.

4. For backend computations, we've covered lot of edge cases like no participants to a course, when there are no reviews made by a participant, when assignment doesn't exists, insure existence_of being called before executing index page etc.

5. For frontend, we've covered cases like formatting of the data in the page, null dataset, score being int, float, null, displaying percentages when data is int, float, null etc.

Even though we've moved most of the code into private functions, the core functionalities of the controller are refactored and appropriate test cases are written to ensure high coverage.

Please run the following command to execute the tests:

rspec spec/controllers/assessment360_controller_spec.rb

=== Testing from UI ===
The following steps needs to be performed to test this code from UI:

1. Login as instructor(username: instructor6 , password: password). Please either do step 2 or 3, as both are not required.

2. Select Courses, and the page will show a list of courses. Please select the rightmost icons for any course (we recommend CSC517 Fall 2017, CSC517 Fall 2011 so there’s more data, but it can take some time for it load since there’s a lot of pre-loaded data in the VCL)

3. Alternatively, you can login and go to this URL: http://152.7.99.75:8080/assessment360/index?course_id=184

4. You should be able to see a webpage with a table and checkboxes at the top. This table is an instructor’s 360-degree view of a course, containing the scores of each students in the course for every assignment the instructor has added to Expertiza.

5. Unchecking some or all of the checkboxes removes and brings back various columns from/to the page. Please feel free to test this out.

== Scope for future improvement ==

The UI of the index page which shows all of the data can be improved to make it look neater and more aesthetically pleasing. The table’s positioning and centering can be improved for a more convenient experience overall.

The user’s preferred (checked on the UI checkboxes) can be saved to either the Database or a cache, and on subsequent reloads be the fields loaded on the page for a particular. We suggest using the database for this rather than a cache.

Lazy loading can be implemented for the columns the user last chose(assuming these are stored in the DB) and other columns can lazy-loaded if the user clicks on the checkboxes on the screen.

'''''course_student_grade_summary''''' function inside the assessment360_controller.rb contains few unnecessary db calls which can be refactored further to increase the efficiency and reduce the processing time of the module.

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-24T18:09:43Z

Sbabu: /* Testing */

This page contains information about Expertiza Issue E2219 Improve assessment360_controller.rb which was a project in CSC517 Spring 2022. Please see below for a description of the improvements made, issues fixed, code changed, testing information, details required to peer-review the project, and future improvements.

== Peer Review Information ==

For users who would like to view and test the assessment 360 feature, the deployed Expertiza application can be found at the URL mentioned below and can be access using the credentials below:

URL: http://152.7.99.75:8080

Instructor login:

Username: '''instructor6'''

Password: '''password'''

Click on courses and then click on the icon on any one course to go to the assessment 360 page, or log in and paste this URL into the browser: http://152.7.99.75:8080/assessment360/index?course_id=184
The course ID here is an example, you can add the course ID of your choice.

[[File:E2219 Navigation.jpeg|800px]]

Please note that due to VCL constraints, the page will take few mins to load and render the data. Please wait for the page to '''load completely''' before starting the peer review.

== Introduction ==

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.
The Expertiza project contains a feature that allows instructors to get a full or 360-degree view of a course they teach that includes all students in the course, all assignments, and the scores of each student in each assignment, averages, and final scores as well. This feature, called assessment 360, was written in a previous year, and due to issues identified with the code such as variable names, redundancy, code smells etc, a need for improvement of the same was identified.

== Issues and Description of Fixes ==
In our work on improving this feature, we have handled the following issues and made the following improvements:

=== Refactoring ===

The previous implementation of the controller made a number of database calls, several of which were extraneous and not required. We have refactored the functions pertaining to these calls so that the number of unneeded calls to the database is reduced for loading teammate and metareviews.

The older implementation of the computation for class averages, and students average scores incorrectly factored in students who had not received grades for an assignment or who had not taken part in an assignment.
In addition to correcting this, we also simplified the process by refactoring the code(please see the next section for the code).

The past implementation of the controller was unclear and non-Rubyistic in naming conventions, function names, and implementation in the code. We have refactored the controller to make it more Rubyistic overall and also re-written parts of the code to make it more understandable, as well as more CRUD-like. Additionally, we made several methods whose functionality was required and used only inside this controller private.

=== UI changes ===
The previous implementation had 2 views – all_students_all_reviews and course_student_grade_summary. Both of these views cover some of the data required for a 360-degree view of the course.
We have combined these pages together into a single page that contains checkboxes which allow the user to select what data they would like to view and shows only those columns they would like to see. This both simplifies and enhances the functioning of the feature.

=== Variable Names, Cosmetic Issues, Comments ===

In the older implementation, there were some unclear variable names such as teamed_count, and some other minor cosmetic issues such as a hyphen being displayed for empty fields where a dash would more visible and clearer. These have been fixed in both the code and the UI of the application to be user-friendly and developer friendly.
Additionally, comments have been added everywhere to make the code easier to understand and modify for future improvements.

== Fix details and Code Explanation ==

=== Files Changed ===
The following files were altered and edited in the course of our work on this feature:
Assessment360_Controller.rb (under app/controller)
This file contains the controller for the assessment 360 feature which we have improved in our work. The code has been refactored to be cleaner, modular, easier to understand and also to incorporate DRY.

Index.html.erb (under app/views/assessment360)
The view for the assessment 360 feature have been combined as stated in the requirements and all the data is now viewable from the index.html.erb page. This page also features checkboxes so the user can view only the data they are interested in without cluttering caused by unneeded data.

=== Issue Fix Details ===

1) '''app/controllers/assessment360_controller.rb'''

[[File:E2219 assessment360 controller 1.png|800px]]

[[File:E2219 assessment360 controller 2.png|800px]]

[[File:E2219 assessment360 controller 3.png|800px]]

[[File:E2219 assessment360 controller 4.png|800px]]

'''Code changes'''

1. In all_student_all_reviews function, the DB calls are by creating init_data function.

2. The init_data function, removes DB calls inside nested for-loops (look for old code, below) which makes db call for every iteration, the code has been refactored in such a way that it preloads the required data using assignments.includes([:participants]) (look for new code, below). This way, instead of making multiple db calls across diff functions, we load the required data and thereby reduce the processing time.

3. The major change, which we've incorporated here is moving the functions which weren't used in other modules into private. Moving excess functions to private, helps keep the controller more CRUD-like and differentiates to the developer which functions are used by the controller to work, and which ones are the functions of the controller.

'''Old Code (with complex for loops and more db calls)'''

@course_participants.each do |cp|
# for each assignment
# [aggregrate_review_grades_per_stu, review_count_per_stu] --> [0, 0]
%w[teammate meta].each { |type| instance_variable_set("@#{type}_review_info_per_stu", [0, 0]) }
students_teamed = StudentTask.teamed_students(cp.user)
@teamed_count[cp.id] = students_teamed[course.id].try(:size).to_i
@assignments.each do |assignment|
@meta_review[cp.id] = {} unless @meta_review.key?(cp.id)
@teammate_review[cp.id] = {} unless @teammate_review.key?(cp.id)
assignment_participant = assignment.participants.find_by(user_id: cp.user_id)
next if assignment_participant.nil?
teammate_reviews = assignment_participant.teammate_reviews
meta_reviews = assignment_participant.metareviews
calc_overall_review_info(assignment,
cp,
teammate_reviews,
@teammate_review,
@overall_teammate_review_grades,
@overall_teammate_review_count,
@teammate_review_info_per_stu)
calc_overall_review_info(assignment,
cp,
meta_reviews,
@meta_review,
@overall_meta_review_grades,
@overall_meta_review_count,
@meta_review_info_per_stu)
end

'''Refactored Code (with limited iteration and db calls)'''
@assignments.each do |assignment|
assignment.participants.each do |assignment_participant|
reviews[assignment_participant.user_id] = {} unless reviews.key?(assignment_participant.user_id)
assignment_reviews = assignment_participant.public_send(reviews_type) if assignment_participant.respond_to? reviews_type
# If a student has not taken an assignment or if they have not received any grade for the same,
# assign it as nil(not returning anything). This helps in easier calculation of overall grade
score = calc_avg_score(assignment_reviews)
reviews[assignment_participant.user_id][assignment.id] = score unless score.nil?
end
end

2) '''app/views/assessment360/index.html.erb'''

[[File:E2219 indexhtmlerb 1.png|800px]]

[[File:E2219 indexhtmlerb 2.png|800px]]

[[File:E2219 indexhtmlerb 3.png|800px]]

1. We've created a new file called ''index.html.erb''. This file contains all the logic for the frontend of this module.

2. Major change that has been made is the addition of checkboxes. This way, users can filter the data that they view and view the data efficiently.

3. This page loads all the assignment data, and their metadata like - meta reviews, teammate reviews, peer score, topic and instructor grade. The table also contains Aggregate score and Total grade.

4. The checkboxes have been programmed in a way that whenever a checkbox is disabled, the corresponding column gets removed and the colspan rendering gets adjusted. Along with that, when all assignment parameters are unchecked, the assignment columns disappear completely. Same applies for aggregate score and Total Instructor Grade.

3) '''config/routes.rb'''

[[File:E2219 routes 1.png|800px]]

Removed old route to this page and pointed it to the newly created index page.

You can check all the issues fixed here - https://github.com/expertiza/expertiza/pull/2337

== Test Plan==

=== Automated Testing using RSPEC ===
Please note that we have removed several older tests which tested functions that are now private and inaccessible outside the controller class itself. However, the methods that call these private functions are still tested and tests are passing successfully.

1. After refactoring, most of our test cases focus on functions which are the core of the controller - covering important aspects like who accesses the page, checking permissions for the page, how the page behaves on edge cases etc.

2. Using RSpec, the test cases cover various scenarios and tests each scenario in depth.
Eg, for access control, we check the access for all roles for a user comprehensively to ensure that only people with permissions can view the page.

3. Since most of the work in this module is computations in the back and rendering data in the frontend, we've ensured that the computations happen in their specific order and enough test cases are present for edge cases.

4. For backend computations, we've covered lot of edge cases like no participants to a course, when there are no reviews made by a participant, when assignment doesn't exists, insure existence_of being called before executing index page etc.

5. For frontend, we've covered cases like formatting of the data in the page, null dataset, score being int, float, null, displaying percentages when data is int, float, null etc.

Even though we've moved most of the code into private functions, the core functionalities of the controller are refactored and appropriate test cases are written to ensure high coverage.

Please run the following command to execute the tests:

rspec spec/controllers/assessment360_controller_spec.rb

=== Testing from UI ===
The following steps needs to be performed to test this code from UI:

1. Login as instructor(username: instructor6 , password: password). Please either do step 2 or 3, as both are not required.

2. Select Courses, and the page will show a list of courses. Please select the rightmost icons for any course (we recommend CSC517 Fall 2017, CSC517 Fall 2011 so there’s more data, but it can take some time for it load since there’s a lot of pre-loaded data in the VCL)

3. Alternatively, you can login and go to this URL: <needs to be added>

4. You should be able to see a webpage with a table and checkboxes at the top. This table is an instructor’s 360-degree view of a course, containing the scores of each students in the course for every assignment the instructor has added to Expertiza.

5. Unchecking some or all of the checkboxes removes and brings back various columns from/to the page. Please feel free to test this out.

== Scope for future improvement ==

The UI of the index page which shows all of the data can be improved to make it look neater and more aesthetically pleasing. The table’s positioning and centering can be improved for a more convenient experience overall.

The user’s preferred (checked on the UI checkboxes) can be saved to either the Database or a cache, and on subsequent reloads be the fields loaded on the page for a particular. We suggest using the database for this rather than a cache.

Lazy loading can be implemented for the columns the user last chose(assuming these are stored in the DB) and other columns can lazy-loaded if the user clicks on the checkboxes on the screen.

'''''course_student_grade_summary''''' function inside the assessment360_controller.rb contains few unnecessary db calls which can be refactored further to increase the efficiency and reduce the processing time of the module.

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T20:13:34Z

Sbabu: added rspec command for tests

This page contains information about Expertiza Issue E2219 Improve assessment360_controller.rb which was a project in CSC517 Spring 2022. Please see below for a description of the improvements made, issues fixed, code changed, testing information, details required to peer-review the project, and future improvements.

== Peer Review Information ==

For users who would like to view and test the assessment 360 feature, the deployed Expertiza application can be found at the URL mentioned below and can be access using the credentials below:

URL: http://152.7.99.75:8080

Instructor login:

Username: '''instructor6'''

Password: '''password'''

Click on courses and then click on the icon on any one course to go to the assessment 360 page, or log in and paste this URL into the browser: http://152.7.99.75:8080/assessment360/index?course_id=184
The course ID here is an example, you can add the course ID of your choice.

[[File:E2219 Navigation.jpeg|800px]]

Please note that due to VCL constraints, the page will take few mins to load and render the data. Please wait for the page to '''load completely''' before starting the peer review.

== Introduction ==

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.
The Expertiza project contains a feature that allows instructors to get a full or 360-degree view of a course they teach that includes all students in the course, all assignments, and the scores of each student in each assignment, averages, and final scores as well. This feature, called assessment 360, was written in a previous year, and due to issues identified with the code such as variable names, redundancy, code smells etc, a need for improvement of the same was identified.

== Issues and Description of Fixes ==
In our work on improving this feature, we have handled the following issues and made the following improvements:

=== Refactoring ===

The previous implementation of the controller made a number of database calls, several of which were extraneous and not required. We have refactored the functions pertaining to these calls so that the number of unneeded calls to the database is reduced for loading teammate and metareviews.

The older implementation of the computation for class averages, and students average scores incorrectly factored in students who had not received grades for an assignment or who had not taken part in an assignment.
In addition to correcting this, we also simplified the process by refactoring the code(please see the next section for the code).

The past implementation of the controller was unclear and non-Rubyistic in naming conventions, function names, and implementation in the code. We have refactored the controller to make it more Rubyistic overall and also re-written parts of the code to make it more understandable, as well as more CRUD-like. Additionally, we made several methods whose functionality was required and used only inside this controller private.

=== UI changes ===
The previous implementation had 2 views – all_students_all_reviews and course_student_grade_summary. Both of these views cover some of the data required for a 360-degree view of the course.
We have combined these pages together into a single page that contains checkboxes which allow the user to select what data they would like to view and shows only those columns they would like to see. This both simplifies and enhances the functioning of the feature.

=== Variable Names, Cosmetic Issues, Comments ===

In the older implementation, there were some unclear variable names such as teamed_count, and some other minor cosmetic issues such as a hyphen being displayed for empty fields where a dash would more visible and clearer. These have been fixed in both the code and the UI of the application to be user-friendly and developer friendly.
Additionally, comments have been added everywhere to make the code easier to understand and modify for future improvements.

== Fix details and Code Explanation ==

=== Files Changed ===
The following files were altered and edited in the course of our work on this feature:
Assessment360_Controller.rb (under app/controller)
This file contains the controller for the assessment 360 feature which we have improved in our work. The code has been refactored to be cleaner, modular, easier to understand and also to incorporate DRY.

Index.html.erb (under app/views/assessment360)
The view for the assessment 360 feature have been combined as stated in the requirements and all the data is now viewable from the index.html.erb page. This page also features checkboxes so the user can view only the data they are interested in without cluttering caused by unneeded data.

=== Issue Fix Details ===

1) '''app/controllers/assessment360_controller.rb'''

[[File:E2219 assessment360 controller 1.png|800px]]

[[File:E2219 assessment360 controller 2.png|800px]]

[[File:E2219 assessment360 controller 3.png|800px]]

[[File:E2219 assessment360 controller 4.png|800px]]

'''Code changes'''

1. In all_student_all_reviews function, the DB calls are by creating init_data function.

2. The init_data function, removes DB calls inside nested for-loops (look for old code, below) which makes db call for every iteration, the code has been refactored in such a way that it preloads the required data using assignments.includes([:participants]) (look for new code, below). This way, instead of making multiple db calls across diff functions, we load the required data and thereby reduce the processing time.

3. The major change, which we've incorporated here is moving the functions which weren't used in other modules into private. Moving excess functions to private, helps keep the controller more CRUD-like and differentiates to the developer which functions are used by the controller to work, and which ones are the functions of the controller.

'''Old Code (with complex for loops and more db calls)'''

@course_participants.each do |cp|
# for each assignment
# [aggregrate_review_grades_per_stu, review_count_per_stu] --> [0, 0]
%w[teammate meta].each { |type| instance_variable_set("@#{type}_review_info_per_stu", [0, 0]) }
students_teamed = StudentTask.teamed_students(cp.user)
@teamed_count[cp.id] = students_teamed[course.id].try(:size).to_i
@assignments.each do |assignment|
@meta_review[cp.id] = {} unless @meta_review.key?(cp.id)
@teammate_review[cp.id] = {} unless @teammate_review.key?(cp.id)
assignment_participant = assignment.participants.find_by(user_id: cp.user_id)
next if assignment_participant.nil?
teammate_reviews = assignment_participant.teammate_reviews
meta_reviews = assignment_participant.metareviews
calc_overall_review_info(assignment,
cp,
teammate_reviews,
@teammate_review,
@overall_teammate_review_grades,
@overall_teammate_review_count,
@teammate_review_info_per_stu)
calc_overall_review_info(assignment,
cp,
meta_reviews,
@meta_review,
@overall_meta_review_grades,
@overall_meta_review_count,
@meta_review_info_per_stu)
end

'''Refactored Code (with limited iteration and db calls)'''
@assignments.each do |assignment|
assignment.participants.each do |assignment_participant|
reviews[assignment_participant.user_id] = {} unless reviews.key?(assignment_participant.user_id)
assignment_reviews = assignment_participant.public_send(reviews_type) if assignment_participant.respond_to? reviews_type
# If a student has not taken an assignment or if they have not received any grade for the same,
# assign it as nil(not returning anything). This helps in easier calculation of overall grade
score = calc_avg_score(assignment_reviews)
reviews[assignment_participant.user_id][assignment.id] = score unless score.nil?
end
end

2) '''app/views/assessment360/index.html.erb'''

[[File:E2219 indexhtmlerb 1.png|800px]]

[[File:E2219 indexhtmlerb 2.png|800px]]

[[File:E2219 indexhtmlerb 3.png|800px]]

1. We've created a new file called ''index.html.erb''. This file contains all the logic for the frontend of this module.

2. Major change that has been made is the addition of checkboxes. This way, users can filter the data that they view and view the data efficiently.

3. This page loads all the assignment data, and their metadata like - meta reviews, teammate reviews, peer score, topic and instructor grade. The table also contains Aggregate score and Total grade.

4. The checkboxes have been programmed in a way that whenever a checkbox is disabled, the corresponding column gets removed and the colspan rendering gets adjusted. Along with that, when all assignment parameters are unchecked, the assignment columns disappear completely. Same applies for aggregate score and Total Instructor Grade.

3) '''config/routes.rb'''

[[File:E2219 routes 1.png|800px]]

Removed old route to this page and pointed it to the newly created index page.

You can check all the issues fixed here - https://github.com/expertiza/expertiza/pull/2337

== Testing ==

=== Automated Testing using RSPEC ===
Please note that we have removed several older tests which tested functions that are now private and inaccessible outside the controller class itself. However, the methods that call these private functions are still tested and tests are passing successfully.

1. After refactoring, most of our test cases focus on functions which are the core of the controller - covering important aspects like who accesses the page, checking permissions for the page, how the page behaves on edge cases etc.

2. Using RSpec, the test cases cover various scenarios and tests each scenario in depth.
Eg, for access control, we check the access for all roles for a user comprehensively to ensure that only people with permissions can view the page.

3. Since most of the work in this module is computations in the back and rendering data in the frontend, we've ensured that the computations happen in their specific order and enough test cases are present for edge cases.

4. For backend computations, we've covered lot of edge cases like no participants to a course, when there are no reviews made by a participant, when assignment doesn't exists, insure existence_of being called before executing index page etc.

5. For frontend, we've covered cases like formatting of the data in the page, null dataset, score being int, float, null, displaying percentages when data is int, float, null etc.

Even though we've moved most of the code into private functions, the core functionalities of the controller are refactored and appropriate test cases are written to ensure high coverage.

Please run the following command to execute the tests:

rspec spec/controllers/assessment360_controller_spec.rb

=== Testing from UI ===
The following steps needs to be performed to test this code from UI:

1. Login as instructor(username: instructor6 , password: password). Please either do step 2 or 3, as both are not required.

2. Select Courses, and the page will show a list of courses. Please select the rightmost icons for any course (we recommend CSC517 Fall 2017, CSC517 Fall 2011 so there’s more data, but it can take some time for it load since there’s a lot of pre-loaded data in the VCL)

3. Alternatively, you can login and go to this URL: <needs to be added>

4. You should be able to see a webpage with a table and checkboxes at the top. This table is an instructor’s 360-degree view of a course, containing the scores of each students in the course for every assignment the instructor has added to Expertiza.

5. Unchecking some or all of the checkboxes removes and brings back various columns from/to the page. Please feel free to test this out.

== Scope for future improvement ==

The UI of the index page which shows all of the data can be improved to make it look neater and more aesthetically pleasing. The table’s positioning and centering can be improved for a more convenient experience overall.

The user’s preferred (checked on the UI checkboxes) can be saved to either the Database or a cache, and on subsequent reloads be the fields loaded on the page for a particular. We suggest using the database for this rather than a cache.

Lazy loading can be implemented for the columns the user last chose(assuming these are stored in the DB) and other columns can lazy-loaded if the user clicks on the checkboxes on the screen.

'''''course_student_grade_summary''''' function inside the assessment360_controller.rb contains few unnecessary db calls which can be refactored further to increase the efficiency and reduce the processing time of the module.

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-21T17:13:11Z

Sbabu:

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-21T00:14:57Z

Sbabu: /* Scope for future improvement */

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-21T00:14:06Z

Sbabu: /* Testing from UI */

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-21T00:05:32Z

Sbabu: Information about E2219 - Improve assessment360_controller.rb in Expertiza

CSC/ECE 517 Spring 2022

2022-03-20T21:19:11Z

Sbabu: /* OSS Projects */

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]

== Final Projects ==