Expertiza_Wiki - User contributions [en]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-25T01:52:44Z

Mramani: Added UI testing

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic, However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
#* ex. max members = 4, trigger activated when the team size reaches 3
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
[[File:New flow.jpg]]

'''Files Modified'''

Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb

 
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
 

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive.
[[File:WEdit1.png]]

# Reduce the number of conditional statements checking for mentor.
# Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.
# Make the code DRYer
[[File:Edit.png]]

'''Correct Previous Design''' 

1. Remove mentors from being included in a team's number of members count.

2. Change the View to make mentor separate from the team. 
[[File:Wstart3.png]]

Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).
[[File:WEdit4.png]]

Fix the SUBMIT button issue during role selection

[[File:Wstart.png]]
[[File:Wstart1.png]]
'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
# The email code has to be moved to the email module.
# Code written in team file has to be moved to the assignment team file.

'''Remove Duplicate Functions''' 
Example: 
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

== Testing ==
# Some existing test cases have been modified, which has to be reverted. 
# RSpec tests for the email functionality will be added. 
# Run and pass the existing RSpec Tests. 
# Develop New RSpec Tests for the new code additions (additional features). 
# Test the UI for the deployed project. 

== Functionalities to be added ==

* The mentor should be able to check submissions of his team. 
This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.
* A new rubric must be created for the mentor who is also included in the review process.
A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.
* Accommodate changes in team members/assigned topics after a mentor has been assigned.
This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.

== UI Testing ==
Part 1: 
* Login as the instructor6 
* In the assignments view, select the add participants icon. 
* Now, all the existing participants and their roles and permissions are visible. Add a new participant or change permissions. This could be a member or mentor for our case. 
* Fix the max team size of the project. This size will decide when to add a mentor. (Here set as 4) 

Part 2: 
* Login as student575 (added to the program by the instructor) 
* In the assignments view, select program 1. Within that select your team link. 
* Currently there is no team. Create a new team. 
* Invite student573 (who's also a participant in this project) 
* Invite student574 (who's also a participant in this project) 
Part 3: 
* Login as student573. 
* In the assignments view, select program 1. Within that select your team link. 
* There will be an invite from user575, accept it. 
* Will be added to the team and a mentor is assigned. (here it is 563) 
*Check for a received email regarding team information. 

Part4: 
* Login as student574. 
* Steps are the same as Part3. The difference will be in the email received. No new team formed or mentor assigned. Only 574 is added to the team and he alone gets the email. 

Part5: 
*Login as student563. (Mentor) 
* In the assignments view, select program 1. Within that select your team link. All the mentor's teams for that project will be listed. 
* The mentor would have gotten an email when a new team is formed and they are added as the mentor. 

==Team Roster ==
*Rajan Anbazhagan - ranbazh@ncsu.edu 
*Sreenidhi Ganapathi Raman - sganapa4@ncsu.edu 
*Mohnish Ramani - mramani@ncsu.edu 
*Thomas Winter - thwinter@ncsu.edu 

Mentor: Srujana Rachakonda - srachak@ncsu.edu

== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-24T21:41:17Z

Mramani: added team

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic, However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
#* ex. max members = 4, trigger activated when the team size reaches 3
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
[[File:New flow.jpg]]

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive like, from able_to_review to can_review.
# Reduce the number of conditional statements checking for mentor.
# Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.

'''Files to be Modified'''

Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb

 
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
 

'''Correct Previous Design'''
# Remove mentors from being included in a team's number of members count.
# Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
# The email code has to be moved to the email module.
# Code written in team file has to be moved to the assignment team file.

'''Remove Duplicate Functions''' 
Example: 
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

== Testing ==
# Some existing test cases have been modified, which has to be reverted. 
# RSpec tests for the email functionality will be added. 
# Run and pass the existing RSpec Tests. 
# Develop New RSpec Tests for the new code additions (additional features). 
# Test the UI for the deployed project. 

== Functionalities to be added ==

* The mentor should be able to check submissions of his team. 
This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.
* A new rubric must be created for the mentor who is also included in the review process.
A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.
* Accommodate changes in team members/assigned topics after a mentor has been assigned.
This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.
==Team Roster ==
*Rajan Anbazhagan - ranbazh@ncsu.edu 
*Sreenidhi Ganapathi Raman - sganapa4@ncsu.edu 
*Mohnish Ramani - mramani@ncsu.edu 
*Thomas Winter - thwinter@ncsu.edu 

Mentor: Srujana Rachakonda - srachak@ncsu.edu

== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:33:04Z

Mramani: /* Change in Work Flow Diagram */

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic, However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
#* ex. max members = 4, trigger activated when the team size reaches 3
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
[[File:New flow.jpg]]

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive like, from able_to_review to can_review.
# Reduce the number of conditional statements checking for mentor.
# Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.

'''Files to be Modified'''

Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb

 
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
 

'''Correct Previous Design'''
# Remove mentors from being included in a team's number of members count.
# Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
# The email code has to be moved to the email module.
# Code written in team file has to be moved to the assignment team file.

'''Remove Duplicate Functions''' 
Example: 
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Check.png]]

== Testing ==
# Some existing test cases have been modified, which has to be reverted. 
# RSpec tests for the email functionality will be added. 
# Run and pass the existing RSpec Tests. 
# Develop New RSpec Tests for the new code additions (additional features). 
# Test the UI for the deployed project. 

== Functionalities to be added ==

* The mentor should be able to check submissions of his team. 
This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.
* A new rubric must be created for the mentor who is also included in the review process.
A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.
* Accommodate changes in team members/assigned topics after a mentor has been assigned.
This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.

== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:32:32Z

Mramani: /* Functionalities to be added */

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic, However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
#* ex. max members = 4, trigger activated when the team size reaches 3
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
[[File:New flow.jpg]]

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive like, from able_to_review to can_review.
# Reduce the number of conditional statements checking for mentor.
# Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.

'''Files to be Modified'''

Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb
*...
 
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
*... 

'''Correct Previous Design'''
# Remove mentors from being included in a team's number of members count.
# Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
# The email code has to be moved to the email module.
# Code written in team file has to be moved to the assignment team file.

'''Remove Duplicate Functions''' 
Example: 
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Check.png]]

== Testing ==
# Some existing test cases have been modified, which has to be reverted. 
# RSpec tests for the email functionality will be added. 
# Run and pass the existing RSpec Tests. 
# Develop New RSpec Tests for the new code additions (additional features). 
# Test the UI for the deployed project. 

== Functionalities to be added ==

* The mentor should be able to check submissions of his team. 
This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.
* A new rubric must be created for the mentor who is also included in the review process.
A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.
* Accommodate changes in team members/assigned topics after a mentor has been assigned.
This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.

== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:30:30Z

Mramani: /* Functionalities to be added */ Added explanation

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently, Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic, However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
# Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
#* ex. max members = 4, trigger activated when the team size reaches 3
# Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far.
# Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members.
# Possibly notify the team members that they have been assigned the mentor with contact information.

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of the responses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioural design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
The reason to take this approach is we have a certain question which needs to be answered, based on the answer the flow moves. It follows a sequence which follows this behaviour pattern well.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
=== Change in Work Flow Diagram ===
[[File:New flow.jpg]]

'''Refactor Code to follow good coding practices''' 
Example: 
# Rename method names more meaningfully and intuitive like, from able_to_review to can_review.
# Reduce the number of conditional statements checking for mentor.
# Rename variable names to reduce confusion like changing lowest_team_no to lowest_number_of_teams.

'''Files to be Modified'''

Models:
*app/models/assignment_team.rb
*app/models/assignment_participants.rb
*app/models/team.rb
*app/models/team_users.rb
*...
 
Views:
*app/views/student_task/view
*app/views/student_teams/view
*app/views/shared_scripts/_add_individual
*app/views/participants/_participant
*... 

'''Correct Previous Design'''
# Remove mentors from being included in a team's number of members count.
# Change the conditional statement that checks if a mentor has to be added to the team. (The strength of the team has to be greater than 50% of the team size).

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
# The email code has to be moved to the email module.
# Code written in team file has to be moved to the assignment team file.

'''Remove Duplicate Functions''' 
Example: 
Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Check.png]]

== Testing ==
# Some existing test cases have been modified, which has to be reverted. 
# RSpec tests for the email functionality will be added. 
# Run and pass the existing RSpec Tests. 
# Develop New RSpec Tests for the new code additions (additional features). 
# Test the UI for the deployed project. 

== Functionalities to be added ==

# The mentor should be able to check submissions of his team.
*This will be an add on feature to this functionality which would make it more intuitive. The type of user will be used as a way to approach this. This was earlier implemented to an extent but there was difficulty accessing the content of another user. This needs to be investigated more.
# A new rubric must be created for the mentor who is also included in the review process.
* A need is felt that mentor should be assessed a different rubric than the rest of the team, this can be achieved by modifying the rubric form based on the type of user and make only the corresponding details visible to them.
# Accommodate changes in team members/assigned topics after a mentor has been assigned.
*This is planned to be addressed as per the new flow diagram, where a check will be performed to see what type of a team it is, new or modified one.

== Reference ==
[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1994._Mentor_management_for_assignments_without_topics Previous Work]

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:25:40Z

Mramani: /* Design Pattern */ added more content

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:22:52Z

Mramani: Changed new workflow change pic

File:New flow.jpg

2020-04-14T03:21:49Z

Mramani:

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-14T03:08:39Z

Mramani: reference added

File:New flow mentor1.jpg

2020-04-08T05:11:37Z

Mramani: Mramani uploaded a new version of File:New flow mentor1.jpg

File:New flow mentor1.jpg

2020-04-08T05:09:37Z

Mramani: Mramani uploaded a new version of File:New flow mentor1.jpg

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T05:08:15Z

Mramani: added new modified flow chart

File:New flow mentor1.jpg

2020-04-08T05:07:04Z

Mramani:

File:Orig flow mentor.jpg

2020-04-08T04:39:25Z

Mramani: Mramani uploaded a new version of File:Orig flow mentor.jpg

File:Orig flow mentor.jpg

2020-04-08T04:32:01Z

Mramani: Mramani uploaded a new version of File:Orig flow mentor.jpg

File:Orig flow mentor.jpg

2020-04-08T04:27:05Z

Mramani: Mramani uploaded a new version of File:Orig flow mentor.jpg

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T04:25:44Z

Mramani:

File:Orig flow mentor.jpg

2020-04-08T04:22:01Z

Mramani: Mramani uploaded a new version of File:Orig flow mentor.jpg

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T02:15:44Z

Mramani: added example to refactoring principle

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
ex. max members = 4, trigger activated when the team size reaches 3 
2) Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far. 
3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members. 
4) Possibly notify the team members that they have been assigned the mentor with contact information. 

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of them reponses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
'''Refactor Code to follow good coding practices''' 
Example: 
1. Rename method names more meaningfully and intuitive like, from able_to_review to can_review

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
1. The email code has to be moved to the email module 
2. Code written in team file has to be moved to the assignment team file. 
'''Remove Duplicate Functions'''

Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Issus1.png]]

''' Testing ''' 
1)Some existing test cases have been modified, which has to be reverted. 
2)The email functionality does not have any tests, which has to be added. 

== Functionalities to be added ==

1) Mentor should be able to check submissions of his team.

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T01:51:50Z

Mramani:

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
ex. max members = 4, trigger activated when the team size reaches 3 
2) Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far. 
3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members. 
4) Possibly notify the team members that they have been assigned the mentor with contact information. 

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of them reponses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
'''Refactor Code to follow good coding practices'''

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
1. The email code has to be moved to the email module 
2. Code written in team file has to be moved to the assignment team file. 
'''Remove Duplicate Functions'''

Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Issus1.png]]

''' Testing ''' 
1)Some existing test cases have been modified, which has to be reverted. 
2)The email functionality does not have any tests, which has to be added. 

== Functionalities to be added ==

1) Mentor should be able to check submissions of his team.

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T01:51:00Z

Mramani: added one more example to wrong location code.

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
ex. max members = 4, trigger activated when the team size reaches 3 
2) Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far. 
3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members. 
4) Possibly notify the team members that they have been assigned the mentor with contact information. 

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of them reponses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
'''Refactor Code to follow good coding practices'''

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
1. The email code has to be moved to the email module
2. Code written in team file has to be moved to the assignment team file.
'''Remove Duplicate Functions'''

Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Issus1.png]]

''' Testing ''' 
1)Some existing test cases have been modified, which has to be reverted. 
2)The email functionality does not have any tests, which has to be added. 

== Functionalities to be added ==

1) Mentor should be able to check submissions of his team.

CSC/ECE 517 E2024 Mentor management for assignments without topics

2020-04-08T01:21:22Z

Mramani:

CSC/ECE 517 E2024 Mentor management for assignments without topics

== Problem Statement ==

Currently Expertiza has no way to associate mentors with teams. For assignments with topics, like the OSS project, mentors are associated with topics, and then whichever team is assigned to the topic inherits the mentor for that topic However, for assignments without topics (like Program 2), there is no good way to “automatically” assign mentors to projects. The instructor needs to watch teams being formed, and every time a new team is formed, a new mentor needs to be assigned, outside of Expertiza. This leads to a lot of work for the instructor, as well as sometimes long delays before a team is assigned a mentor.

== Project Goal ==

Develop a trigger that: 
1) Is activated when any team has been formed that has k members, where k is greater than 50% of the maximum team capacity 
ex. max members = 4, trigger activated when the team size reaches 3 
2) Assign a mentor to the team. Mentors should be evenly assigned to teams, so a good strategy is to assign the mentor who has the fewest teams to mentor so far. 
3) Notify the mentor via email that they are now assigned to a specific team, and provide the email addresses of the team members. 
4) Possibly notify the team members that they have been assigned the mentor with contact information. 

== Previous Work ==
=== Design Pattern ===

Since the trigger they implemented would need multiple handlers and each of them reponses in different actions, they decided to use Chain of Responsibility as the design pattern. Chain of Responsibility is a behavioral design pattern that lets you pass requests along a chain of handlers. Upon receiving a request, each handler decides either to process the request or to pass it to the next handler in the chain.
[[File:Cor.PNG]]

=== Work Flow Diagram ===
[[File:Orig flow mentor.jpg]]
[[File:Orig flow mentor1.jpg]]

== Improvement on the Previous Work ==
'''Refactor Code to follow good coding practices'''

'''Code placed in the wrong locations to be moved to the desired locations.''' 
Example: 
The email code has to be moved to the email module

'''Remove Duplicate Functions'''

Though there is a method "team" to list the members of a team, a new method has been created, which is to be removed.

[[File:Issus1.png]]

''' Testing ''' 
Some existing test cases have been modified, which has to be reverted. The email functionality does not have any tests, which has to be added.

== Functionalities to be added ==

1) Mentor should be able to check submissions of his team.

File:Orig flow mentor1.jpg

2020-04-08T01:16:14Z

Mramani:

File:Orig flow mentor.jpg

2020-04-08T01:15:20Z

Mramani:

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-04-01T03:22:20Z

Mramani: Added test snips to testing plan

This wiki page describes the work done under E2002 OSS Program for Spring 2020, in the CSC/ECE 517 course.

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza is a complete instructor-student usage website where the instructor can assign assignments, deadlines, grades, etc that is required for the course. Similarly, the students can use this website to perform the tasks required as part of the course like project or assignments submission, forming groups and collaborating with them, as well as reviewing projects and teammates.

This project focuses on a specific feature of expertiza which allows administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account.
The demonstration for the feature is as shown below.

[[File:Impersonate guide.jpg|figure 1|frame|center]]

[[File:Non impersonate.jpg|figure 2|frame|center]]

[[File:Impersonated view.jpg|figure 3|frame|center]]

===Problem Statement===
The aim of the project is to refactor the impersonate controller. The pre-existing code had the following major issues.
*All functions related to impersonate controller were present in a single method ( from figure 4a and 4b)
*Presence of repetitive code ( from figure 4a and 4b)
*3 levels of block nesting (from figure 5)
* Too many return statements (from figure 6)
[[File:initial code1.jpg| figure 4a| frame|center]]
[[File:initial code2.jpg| figure 4b| frame|center]]
[[File:code climate3.jpg| figure 5| frame|center]]
[[File:code climate2.jpg| figure 6| frame|center]]

This project is focused on resolving the issues mentioned above.

===About Impersonate Controller===
Expertiza allows the administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account. For example, an instructor impersonating a student’s account can view their assignments, stage deadlines, peer reviews and anything else that the student can view.

One thing to be noted is that most of these users can only impersonate users for whom they are a parent. For example, instructor6 is a parent of student3841 and not student3836; as a result, instructor6 can impersonate only 3841.

===Impersonate functionality navigation===
1. Instructor login: username -> instructor6, password -> password

when logged in as an instructor, under the manage option in the ribbon as in Figure 1, select impersonate user.
Upon redirected to impersonate page, enter the account which needs to be impersonated. It impersonates that user provided that user can be impersonated. Now a new button called revert appears on the ribbon as in figure 3, this can be used to revert the impersonation and return to the instructor profile.

===Problem Solution===
The above-mentioned issues have been tackled by refactoring the impersonate controller by splitting into many smaller methods which are later called by the main impersonate controller.

The following are the refactored new methods that help in tackling the issue1 apart from each being specifically for some issue rectification:
*check_if_user_impersonateable
*display_error_msg
*overwrite_session
*check_if_special_char
*do_main_operartion

=====check_if_user_impersonateable=====
This method plays the main role in tackling issue3 - 3 levels of block nesting apart from issue1.

'''Intial Code'''
<pre>
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
</pre>
''' After recfactoring - Moved to separate method'''
<pre>
def check_if_user_impersonateable
if params[:impersonate].nil?
user = User.find_by(name: params[:user][:name])
if !@original_user.can_impersonate? user
@message = "You cannot impersonate '#{params[:user][:name]}'."
temp
AuthController.clear_user_info(session, nil)
else
overwrite_session
end
else
if !params[:impersonate][:name].empty?
user = User.find_by(name: params[:impersonate][:name])
overwrite_session
end
end
end
</pre>

=====display_error_msg=====
This method is used to tackle issues1, 2 and 4. All the error message related code is moved to this method.
<pre>
def display_error_msg
if params[:user]
@message = "No user exists with the name '#{params[:user][:name]}'."
elsif params[:impersonate]
@message = "No user exists with the name '#{params[:impersonate][:name]}'."
else
if params[:impersonate].nil?
@message = "You cannot impersonate '#{params[:user][:name]}'."
else
if !params[:impersonate][:name].empty?
@message = "You cannot impersonate '#{params[:impersonate][:name]}'."
else
@message = "No original account was found. Please close your browser and start a new session."
end
end
end
rescue Exception => e
flash[:error] = @message
redirect_to :back
end
</pre>
=====overwrite_session=====
This method reduces the number of return statements used in impersonate controller, apart from reducing the size of the controller.

====== Initial Code======
<pre>
if params[:impersonate].nil?
# check if special chars /\?<>|&$# are used to avoid html tags or system command
if warn_for_special_chars(params[:user][:name], "Username")
redirect_back
return
end
user = User.find_by(name: params[:user][:name])
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
session[:super_user] = session[:user] if session[:super_user].nil?
AuthController.clear_user_info(session, nil)
session[:original_user] = original_user
session[:impersonate] = true
session[:user] = user
else
flash[:error] = message
redirect_back
return
end
else
# Impersonate a new account
if !params[:impersonate][:name].empty?
# check if special chars /\?<>|&$# are used to avoid html tags or system command
if warn_for_special_chars(params[:impersonate][:name], "Username")
redirect_back
return
end
user = User.find_by(name: params[:impersonate][:name])
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
AuthController.clear_user_info(session, nil)
session[:user] = user
session[:impersonate] = true
session[:original_user] = original_user
else
flash[:error] = message
redirect_back
return
end
</pre>
====== After Refactoring - Moved to a separate method and accessed through the adapter method do_main_operation======
<pre>
def overwrite_session
#if not impersonatable, then original user's session remains
if params[:impersonate].nil?
user = User.find_by(name: params[:user][:name])
session[:super_user] = session[:user] if session[:super_user].nil?
AuthController.clear_user_info(session, nil)
session[:original_user] = @original_user
session[:impersonate] = true
session[:user] = user
else
#if some user is to be impersonated, their session details are overwritten onto the current to impersonate

if !params[:impersonate][:name].empty?
user = User.find_by(name: params[:impersonate][:name])
AuthController.clear_user_info(session, nil)
session[:user] = user
session[:impersonate] = true
session[:original_user] = @original_user
else
user = User.find_by(name: params[:user][:name])
AuthController.clear_user_info(session, nil)
session[:user] = session[:super_user]
user = session[:user]
session[:super_user] = nil
end
end
end
</pre>
=====check_if_special_char=====
This code is used to reduce one functionality performed under the impersonate controller. This method checks to see if the given username is acceptable.
<pre>
def check_if_special_char
if warn_for_special_chars(params[:user][:name], "Username")
redirect_back
return
end
end
</pre>
=====do_main_operation=====
This like an adapter method that is used to interface the impersonate method with display_error_msg and check_if_user_impersonatable. One main purpose to do this is to make the methods flexible for change apart from reducing the number of lines from the impersonate controller.
<pre>
def do_main_operation(user)
if user
check_if_user_impersonateable
else
display_error_msg
end
end
</pre>

=== Test Plan ===
The project can be tested from the UI as follows.

Checking if impersonating a user is working
1. Input: User that can be impersonated
- Login as the instructor (username -> instructor6 , password -> password
- Under "Manage" tab, select "impersonate user" option
- In the form, give the user ID as "student5890"
Now you will be able to see that user "student5890" has been impersonated.

[[File:imp test 1.jpg| figure 7| frame|center]]
[[File:imp test 2.jpg| figure 8| frame|center]]

[[File:imp test 4.jpg| figure 9| frame|center]]

2. Input: Reverting from impersonated account

We will have the user "student5890" impersonated.
- Press the blue revert button at the top of the window
Now you will have returned to the instructor profile

[[File:imp test 4.jpg| figure 10| frame|center]]
[[File:imp test 8.jpg| figure 11| frame|center]]

3. Input: User that cannot be impersonated
- Login as the instructor (username -> instructor6 , password -> password
- Under "Manage" tab, select "impersonate user" option
- In the form, give the user ID as "super_administrator2"
Now you will be able to see a message being displayed on the screen, that tells that the given user cannot be impersonated.
[[File:imp test 6.jpg| figure 12| frame|center]]
[[File:imp test 5.jpg| figure 13| frame|center]]

4. Input: User that does not exist
- Login as the instructor (username -> instructor6 , password -> password
- Under "Manage" tab, select "impersonate user" option
- In the form, give the user ID as "studentstudent"
Now you will be able to see a message being displayed on the screen, that tells that the given user does not exist.
[[File:imp test 7.jpg| figure 14| frame|center]]
[[File:imp test 3.jpg| figure 15| frame|center]]

File:Imp test 8.jpg

2020-04-01T03:17:23Z

Mramani:

File:Imp test 7.jpg

2020-04-01T03:09:14Z

Mramani:

File:Imp test 6.jpg

2020-04-01T03:09:02Z

Mramani:

File:Imp test 5.jpg

2020-04-01T03:08:50Z

Mramani:

File:Imp test 4.jpg

2020-04-01T03:08:35Z

Mramani:

File:Imp test 3.jpg

2020-04-01T03:08:22Z

Mramani:

File:Imp test 2.jpg

2020-04-01T03:08:09Z

Mramani:

File:Imp test 1.jpg

2020-04-01T03:07:50Z

Mramani:

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-03-31T20:39:29Z

Mramani: added code snips and explained the methods

This wiki page describes the work done under E2002 OSS Program for Spring 2020, in the CSC/ECE 517 course.

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza is a complete instructor-student usage website where the instructor can assign assignments, deadlines, grades, etc that is required for the course. Similarly, the students can use this website to perform the tasks required as part of the course like project or assignments submission, forming groups and collaborating with them, as well as reviewing projects and teammates.

[[File:Impersonate guide.jpg|figure 1|frame|center]]

[[File:Non impersonate.jpg|figure 2|frame|center]]

[[File:Impersonated view.jpg|figure 3|frame|center]]

===Problem Statement===
The aim of the project is to refactor the impersonate controller. The pre-existing code had two major issues.
*All functions related to impersonate controller were present in a single method ( from figure 4a and 4b)
*Presence of repetitive code ( from figure 4a and 4b)
*3 levels of block nesting (from figure 5)
* Too many return statements (from figure 6)
[[File:initial code1.jpg| figure 4a| frame|center]]
[[File:initial code2.jpg| figure 4b| frame|center]]
[[File:code climate3.jpg| figure 5| frame|center]]
[[File:code climate2.jpg| figure 6| frame|center]]

===About Impersonate Controller===
Expertiza allows the administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account. For example, an instructor impersonating a student’s account can view their assignments, stage deadlines, peer reviews and anything else that the student can view. One thing to be noted is that most of these users con only impersonate users for whom they are a parent. For example, instructor6 is a parent of student3841 and not student3836; as a result, instructor6 can impersonate only 3841.

===Impersonate functionality navigation===
1. Instructor login: username -> instructor6, password -> password

when logged in as an instructor, under the manage option in the ribbon as in Figure 1, select impersonate user. Upon redirected to impersonate page, enter the account which needs to be impersonated. If possible it impersonates that user. Now a new button called revert appears on the ribbon as in figure 3, this can be used to revert the impersonation and return to the instructor profile.

===Problem Solution===
The above-mentioned issues have been tackled by refactoring the impersonate controller by splitting into many smaller methods which are later called by the main impersonate controller.

The following are the refactored new methods that help in tackling the issue1 apart from each being specifically for some issue rectification:
*check_if_user_impersonateable
*display_error_msg
*overwrite_session
*check_if_special_char
*do_main_operartion

=====check_if_user_impersonateable=====
This method plays the main role in tackling issue3 - 3 levels of block nesting apart from issue1.

'''Intial Code'''
<pre>
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
</pre>
''' After recfactoring - Moved to separate method'''
<pre>
def check_if_user_impersonateable
if params[:impersonate].nil?
user = User.find_by(name: params[:user][:name])
if !@original_user.can_impersonate? user
@message = "You cannot impersonate '#{params[:user][:name]}'."
temp
AuthController.clear_user_info(session, nil)
else
overwrite_session
end
else
if !params[:impersonate][:name].empty?
user = User.find_by(name: params[:impersonate][:name])
overwrite_session
end
end
end
</pre>

=====display_error_msg=====
This method is used to tackle issues1, 2 and 4. All the error message related code is moved to this method.
<pre>
def display_error_msg
if params[:user]
@message = "No user exists with the name '#{params[:user][:name]}'."
elsif params[:impersonate]
@message = "No user exists with the name '#{params[:impersonate][:name]}'."
else
if params[:impersonate].nil?
@message = "You cannot impersonate '#{params[:user][:name]}'."
else
if !params[:impersonate][:name].empty?
@message = "You cannot impersonate '#{params[:impersonate][:name]}'."
else
@message = "No original account was found. Please close your browser and start a new session."
end
end
end
rescue Exception => e
flash[:error] = @message
redirect_to :back
end
</pre>
=====overwrite_session=====
This method reduces the number of return statements used in impersonate controller, apart from reducing the size of the controller.

====== Initial Code======
<pre>
if params[:impersonate].nil?
# check if special chars /\?<>|&$# are used to avoid html tags or system command
if warn_for_special_chars(params[:user][:name], "Username")
redirect_back
return
end
user = User.find_by(name: params[:user][:name])
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
session[:super_user] = session[:user] if session[:super_user].nil?
AuthController.clear_user_info(session, nil)
session[:original_user] = original_user
session[:impersonate] = true
session[:user] = user
else
flash[:error] = message
redirect_back
return
end
else
# Impersonate a new account
if !params[:impersonate][:name].empty?
# check if special chars /\?<>|&$# are used to avoid html tags or system command
if warn_for_special_chars(params[:impersonate][:name], "Username")
redirect_back
return
end
user = User.find_by(name: params[:impersonate][:name])
if user
unless original_user.can_impersonate? user
flash[:error] = "You cannot impersonate #{params[:user][:name]}."
redirect_back
return
end
AuthController.clear_user_info(session, nil)
session[:user] = user
session[:impersonate] = true
session[:original_user] = original_user
else
flash[:error] = message
redirect_back
return
end
</pre>
====== After Refactoring - Moved to a separate method and accessed through the adapter method do_main_operation======
<pre>
def overwrite_session
#if not impersonatable, then original user's session remains
if params[:impersonate].nil?
user = User.find_by(name: params[:user][:name])
session[:super_user] = session[:user] if session[:super_user].nil?
AuthController.clear_user_info(session, nil)
session[:original_user] = @original_user
session[:impersonate] = true
session[:user] = user
else
#if some user is to be impersonated, their session details are overwritten onto the current to impersonate

if !params[:impersonate][:name].empty?
user = User.find_by(name: params[:impersonate][:name])
AuthController.clear_user_info(session, nil)
session[:user] = user
session[:impersonate] = true
session[:original_user] = @original_user
else
user = User.find_by(name: params[:user][:name])
AuthController.clear_user_info(session, nil)
session[:user] = session[:super_user]
user = session[:user]
session[:super_user] = nil
end
end
end
</pre>
=====check_if_special_char=====
This code is used to reduce one functionality performed under the impersonate controller. This method checks to see if the given username is acceptable.
<pre>
def check_if_special_char
if warn_for_special_chars(params[:user][:name], "Username")
redirect_back
return
end
end
</pre>
=====do_main_operation=====
This like an adapter method that is used to interface the impersonate method with display_error_msg and check_if_user_impersonatable. One main purpose to do this is to make the methods flexible for change apart from reducing the number of lines from the impersonate controller.
<pre>
def do_main_operation(user)
if user
check_if_user_impersonateable
else
display_error_msg
end
end
</pre>
=== Test Plan ===

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-03-31T19:39:39Z

Mramani:

File:Code climate1.jpg

2020-03-31T18:58:13Z

Mramani:

File:Code climate2.jpg

2020-03-31T18:58:03Z

Mramani:

File:Code climate3.jpg

2020-03-31T18:57:45Z

Mramani:

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-03-31T18:24:47Z

Mramani: added intial code pics and usage guide images

This wiki page describes the work done under E2002 OSS Program for Spring 2020, in the CSC/ECE 517 course.

===Peer Review Information===
1. Instructor login: username -> instructor6, password -> password

when logged in as an instructor, under the manage option in the ribbon as in Figure 1, select impersonate user. Upon redirected to impersonate page, enter the account which needs to be impersonated. If possible it impersonates that user. Now a new button called revert appears on the ribbon as in figure 3, this can be used to revert the impersonation and return to the instructor profile.

[[File:Impersonate guide.jpg|figure 1|frame|center]]

[[File:Non impersonate.jpg|figure 2|frame|center]]

[[File:Impersonated view.jpg|figure 3|frame|center]]

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza is a complete instructor-student usage website where the instructor can assign assignments, deadlines, grades, etc that is required for the course. Similarly, the students can use this website to perform the tasks required as part of the course like project or assignments submission, forming groups and collaborating with them, as well as reviewing projects and teammates.

===Problem Statement===
The aim of the project is to refactor the impersonate controller. The pre-existing code had two major issues.
*All functions related to impersonate controller were present in a single method
*Presence of repetitive code
These two issues can be clearly in the code below in figures 4a and 4b, taken from the initial file.
[[File:initial code1.jpg| figure 4a| frame|center]]
[[File:initial code2.jpg| figure 4b| frame|center]]

===About Impersonate Controller===
Expertiza allows the administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account. For example, an instructor impersonating a student’s account can view their assignments, stage deadlines, peer reviews and anything else that the student can view. One thing to be noted is that most of these users con only impersonate users for whom they are a parent. For example, instructor6 is a parent of student3841 and not student3836; as a result, instructor6 can impersonate only 3841.

===Problem Solution===
These two issues have been tackled by
Creating new methods which were called inside the impersonate controller. The new methods were:

*checkif_user_impersonateable
*display_error_msg
*clear_session

File:Initial code2.jpg

2020-03-31T18:14:20Z

Mramani:

File:Initial code1.jpg

2020-03-31T18:14:04Z

Mramani:

File:Non impersonate.jpg

2020-03-31T17:54:52Z

Mramani: Mramani uploaded a new version of File:Non impersonate.jpg

File:Impersonated view.jpg

2020-03-31T17:53:29Z

Mramani: Mramani uploaded a new version of File:Impersonated view.jpg

File:Non impersonate.jpg

2020-03-31T17:31:27Z

Mramani:

File:Impersonated view.jpg

2020-03-31T17:31:03Z

Mramani:

File:Impersonate guide.jpg

2020-03-31T17:28:15Z

Mramani:

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-03-23T22:58:35Z

Mramani:

This wiki page describes the work done under E2002 OSS Program for Spring 2020, in the CSC/ECE 517 course.

===Peer Review Information===
1. Instructor login: username -> instructor6, password -> password

when logged in as an instructor, under the manage option in the ribbon, select impersonate user. Upon redirected to impersonate page, enter the account which needs to be impersonated. If possible it impersonates that user. Now a new button called revert appears on the ribbon, this can be used to revert the impersonation and return to the instructor profile.

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza is a complete instructor-student usage website where the instructor can assign assignments, deadlines, grades, etc that is required for the course. Similarly, the students can use this website to perform the tasks required as part of the course like project or assignments submission, forming groups and collaborating with them, as well as reviewing projects and teammates.

===Problem Statement===
The aim of the project is to refactor the impersonate controller. The pre-existing code had two major issues.
*All functions related to impersonate controller were present in a single method
*Presence of repetitive code

These two issues have been tackled by
Creating new methods which were called inside the impersonate controller. The new methods were:

*checkif_user_impersonateable
*display_error_msg
*clear_session

===About Impersonate Controller===
Expertiza allows the administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account. For example, an instructor impersonating a student’s account can view their assignments, stage deadlines, peer reviews and anything else that the student can view. One thing to be noted is that most of these users con only impersonate users for whom they are a parent. For example, instructor6 is a parent of student3841 and not student3836; as a result, instructor6 can impersonate only 3841.

Main Page/CSC/CSC 517 Spring 2020 Refactor impersonate controller

2020-03-23T22:55:41Z

Mramani: Creation of the page

This wiki page describes the work done under E2002 OSS Program for Spring 2020, in the CSC/ECE 517 course.

===Peer Review Information===
1. Instructor login: username -> instructor6, password -> password

when logged in as an instructor, under the manage option in the ribbon, select impersonate user. Upon redirected to impersonate page, enter the account which needs to be impersonated. If possible it impersonates that user. Now a new button called revert appears on the ribbon, this can be used to revert the impersonation and return to the instructor profile.

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open-source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza is a complete instructor-student usage website where the instructor can assign assignments, deadlines, grades, etc that is required for the course. Similarly, the students can use this website to perform the tasks required as part of the course like project or assignments submission, forming groups and collaborating with them, as well as reviewing projects and teammates.

===Problem Statement===
The aim of the project is to refactor the impersonate controller. The pre-existing code had two major issues.
1. All functions related to impersonate controller were present in a single method
2.Presence of repetitive code

These two issues have been tackled by
1. Creating new methods which were called inside the impersonate controller. The new methods were:
a.checkif_user_impersonateable
b.display_error_msg
c.clear_session

===About Impersonate Controller===
Expertiza allows the administrators, instructors or teaching assistants to impersonate another user (like a student) and access their account. For example, an instructor impersonating a student’s account can view their assignments, stage deadlines, peer reviews and anything else that the student can view. One thing to be noted is that most of these users con only impersonate users for whom they are a parent. For example, instructor6 is a parent of student3841 and not student3836; as a result, instructor6 can impersonate only 3841.