Expertiza_Wiki - User contributions [en]

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

2022-04-26T03:45:42Z

Svenka25: /* Added Future Scope and updated Demo URL */

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 migrate all data with user_id to participant_id
# Replace participant_id with user_id for all the data
# Rename teams_user to teams_participant
# Modify functions which use user_id and replace them with functions using participant_id (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

File:ER Updated.png

2022-04-26T03:44:44Z

Svenka25:

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

2022-04-26T02:20:38Z

Svenka25: /* add_participant_to_team */

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

== 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-26T02:19:41Z

Svenka25:

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

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

File:Add participant to team.png

2022-04-26T02:18:25Z

Svenka25:

File:Find by team id and user id.png

2022-04-26T02:13:40Z

Svenka25:

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

2022-04-26T02:00:17Z

Svenka25: /* Implementation */

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))

'''<Picture WIP with light background>'''

''.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).

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

The existing function to add a member
add_member(user,team.parent_id) --- add user to a team

We've introduced a new function called
add_participant_to_team(student, team.parent_id) --- adds participant(student) to a team

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.

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

== 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-26T01:59:15Z

Svenka25: /* Implementation */

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))

'''<Picture WIP with light background>'''

''.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).

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

There existing function to add a member
add_member(user,team.parent_id) --- add user to a team

We've introduced a new function called
add_participant_to_team(student, team.parent_id) --- adds participant(student) to a team

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.

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

== 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-26T01:16:57Z

Svenka25: /* 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. 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 ==

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

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

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

File:Create Teams Instructors Automatically.png

2022-04-26T01:16:17Z

Svenka25:

File:Student Joins Team ReceivesInvite.png

2022-04-26T01:10:31Z

Svenka25:

File:Student Creates Team SendInvite.png

2022-04-26T01:00:20Z

Svenka25:

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

2022-04-26T00:57:30Z

Svenka25: /* Updated Code Details

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

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

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

== 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.
[[File:Create_Teams_Instructors_Manually.png|900px]]

# 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/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)

File:Create Teams Instructors Manually.png

2022-04-26T00:39:02Z

Svenka25:

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

2022-04-12T04:14:55Z

Svenka25: Final update with Test Plan and 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.
* 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 ====

The existing views in relation to this functionality would not need to undergo signification refactoring since we are only adding a new field and removing any of the existing ones. That being said, we will be adding new partials to achieve similar views using the participant_id field instead of the user_id field in the partials for future changes to the application as mentioned in the specifications.

== 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-12T04:01:18Z

Svenka25: /* ER diagram for updated schema */

File:Updated Proposed ERR for student teams E2243.png

2022-04-12T04:00:54Z

Svenka25:

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

2022-04-07T00:56:01Z

Svenka25: Final Edits for Proposed Implementation

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

2022-04-07T00:28:46Z

Svenka25: Modifying Data Migration

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

2022-04-07T00:25:56Z

Svenka25: Edited Migration Analysis

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

2022-04-06T16:04:05Z

Svenka25: Added Proposed Implementation

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

2022-04-06T16:01:11Z

Svenka25: Updating Implementation

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T06:22:09Z

Svenka25: Final changes to the wiki page before submission deadline

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.

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

File:E2219 indexhtmlerb 3.png

2022-03-22T06:08:09Z

Svenka25:

File:E2219 indexhtmlerb 2.png

2022-03-22T06:08:00Z

Svenka25:

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T04:06:54Z

Svenka25:

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]]

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.

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

File:E2219 Navigation.jpeg

2022-03-22T04:03:24Z

Svenka25:

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T03:56:44Z

Svenka25:

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.

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.

'''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]]

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.

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

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T03:04:46Z

Svenka25:

CSC/ECE 517 Spring 2022 - E2219: Improve assessment360 controller.rb

2022-03-22T02:41:04Z

Svenka25:

File:E2219 routes 1.png

2022-03-22T02:30:08Z

Svenka25:

File:E2219 indexhtmlerb 1.png

2022-03-22T02:29:55Z

Svenka25:

File:E2219 assessment360 controller 4.png

2022-03-22T02:29:40Z

Svenka25:

File:E2219 assessment360 controller 3.png

2022-03-22T02:29:27Z

Svenka25:

File:E2219 assessment360 controller 2.png

2022-03-22T02:28:45Z

Svenka25:

File:E2219 assessment360 controller 1.png

2022-03-22T02:27:59Z

Svenka25: