CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role
E1963 Changing assignment Participant role
Background
- E1963 This project aims to enable the instructor to change the role of an assignment participant. There are two ways to add a new assignment participant, first being through the Add button on the assignment participant page. Another way is to import via a spreadsheet with the list of users that are to be added. The motivation of E1963 was to enable the instructors adding these users using either of the methods mentioned above to change these users' role. A user can have one of the following roles - participant, reader, reviewer, submitter.
- The existing UI had the a dropdown that displayed the role of the user: submitter, reviewer, quiz-taker, or "participant" (a "participant" can perform all three roles). We have added a Submit button below each dropdown to enable the instructor to change the role of the user. On clicking the submit button, the role associated with that user is changed in the persistent storage. We have also added a flash message which confirms the change to the user.
The following issues were targeted in this project:
- #1: The instructor does not have the option to change the role of the user, once he/she has been added to the assignment. Thus, if the instructor wishes to change the role of a user from say a reviewer to a submitter, he/she is not able to save the changes.
- #2: With the changes made for the issue mentioned above, the instructor will be able to save the changes manually. We would like to maintain the same behavior when the assignment participants are imported from excel. Upon creating a new user using an Excel import, the user should have the role of a participant by default. An instructor was then unable to change the role of the assignment participant.
Manage Assignments -> Add new participant icon under Actions
Current implementation
For each of the assignment participant record, there is a dropdown which contains the role of the participant. When the instructor attempts to change the value in the dropdown, it is not reflected in the backend, as there is no call associated with it, to submit the changes. Thus when the user revisits the page, the changes would he would have made are not retained.
Authorization of the user is based on the flags can_submit, can_review and can_take_quiz flags, which are set to be true or false based on the role of the user. By default, the user is assigned the role of a participant in any assignment. Thus, the goal is to modify these flags and save them in the database when the role of the assignment participant is changed, so that it is a persistent change. Authorization of the users based on the flags can be deduced as follows:
- Participant has can_submit=true, can_review=true and can_take_quiz=true
- Reader has can_submit= false, can_review=true and can_take_quiz= true
- Submitter has can_submit=true, can_review= false and can_take_quiz=false
- Reviewer has can_submit=false, can_review= true and can_take_quiz=false
Problems:
- 1. There is no way to change the role of the user, once the user has been added to the assignment as a participant. (Submit button now resolves this issue.)
- 2. Instructor is not given any confirmation that the role of the participant has been reverted to the original value once he/she navigates somewhere else. This is misleading for an instructor as the he/she might be under the impression that the changes he/she made have been saved. (Flash message now lets the user know about the change.)
Snapshots depicting the issue
- As an Instructor, go to Manage Assignments
- Click on add participant
- Note that the user on the first record is currently a "Reader"
- Change the role of the "Reader" to say "Submitter"
- Refresh or re-navigate to this page and note that the changes are reverted
Implementation
Changes are made in the partial for participants "_participant.rb", so that the submit button is rendered on the view. Upon changing the selected value for the user role, 'update_authorizations' method is called from participants controller which passes the participant id as a parameter to the method to change its role in the database. The selected role is passed as a parameter 'authorization' to the update authorization method that updates the can_submit, can_take_quiz, and can_review flags appropriately for each role as described above for the selected participant id.
Implementing the above mentioned changes, allows the instructor to change the value of role in the dropdown which retains the corresponding record on tap of the Submit button. We have verified that the changes in the above mentioned flags are reflected in the database. The instructor will be presented with a success message on changing the role of the selected participant, on clicking submit. The instructor can revisit the page and expect the updated value to be retained. Both the problems listed above are taken care of such as the instructor is facilitated with an option to change the participant, as well as knows that the change made will be durable.
Snapshots after the changes
- Submit button has been added to each row of assignment participants
- Change the "Reader" to "Submitter", on the first record and click on submit. Changes have been persisted. Flash message confirmation is also provided to the Instructor to let him/her know of the change.
Additional Changes
(These changes were not part of the assigned issue E1963, these are additional issues that we encountered while fixing E1963)
In addition to the above-mentioned issue, we fixed a few other issues that we observed , which were relevant to Assignment Participant and Course Participant Controllers, namely:
1. Export Details in Assignment Participants view: We noticed that a a blank csv file was getting generated on exporting detail button in Manage Assignments. We discovered that the reason for this issue is that in the import method, the model defined was that of AssignmentParticipant whereas all the parsing methods for export were present in Assignment model. We did the required changes, tested the functionality and note that this is working fine now. The changes for this are made in the common module - export_file_controller.rb following which the export and export_details methods are now called from the assignment.rb as opposed to assignment_participant.rb where there are no export methods and their corresponding implementations. Now, the Export Detail button generates a comma-seperated file with the following headers:
- Assignment Name
- Assignment Instructor
- Team ID / Author ID
- Reviewee (Team / Student Name)
- Reviewer
- Question / Criterion
- Question ID
- Answer / Comment ID
- Answer / Comment
- Score
2. Along with the previous issue, we found that since the partials were shared among Assignment Participant and Course Participant, Course Participant also had the Export Details section and the corresponding button. However, it is not required and we believe that it should be removed from the view. We consulted Dr. Gehringer and based on his feedback as well, we removed the semi-view consisting of "Export Details" from Course Participant. The changes are made in the file "start.html.erb" by using conditional rendering of the partial based on the model name.
The view before change:
The view after change:
3. Missing Handle: Assignment Participant on adding a new Assignment Participant: We observed that when a new assignment participant is created, if a user already exists with the username, the existing user is added to that Assignment and his existing handle attribute in Users table is mapped to the handle attribute in Participants table. However, if a new user is added not currently in the Users table, a new entry is created first in the Users table and is then replicated in the Participants table. Although, we noticed that the handle attribute in Participants table was coming as null. We fixed this issue by making change in the define_attributes method in ImportFileHelper.rb.
4. Import Assignment Participants was not working - It is expected that if a user does not exist in the system, on importing assignment participants, a user will be created and he/she will be added to the assignment as a participant. With the current implementation, the user was getting created, however corresponding AssignmentParticipant was not getting created due to a validation with respect to handle. We have fixed this issue by setting the handle in AssignmentParticipants to be the same as the name of the user created (in accordance with the current functionality - when a user is added as an AssignmentParticipant from the UI). This facilitates us to import AssignmentParticipants. The mandatory minimal attributes required to import an assignment participant are :
- Username
- Full name
- Email id
- Password.
5. The role in the Assignment Participant view doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"
The view before change:
The view after change:
6. The role in the Course Participant view doesn't have a header unlike all the other attributes on the view. We added a header for the role, thereby increasing the readability and consistency on the UI. The required changes are made in the partial "_user_list.html"
The view before change:
The view after change:
Test Plan
Rspec test has been added to check the update authorizations functionality in the participants_controller_spec.rb. The test verifies the change of flags mentioned above as per the authorization of the user. The tests also checks whether the expected flash message is visible on the UI. Code coverage is 100% for all the code that we have added in the controllers, as part of this project.
To make sure we covered all of our code (100%) with test cases we used Ruby Code Coverage plugin of RubyMine and SimpleCov gem. After manually running the test file, the SimpleCov gem highlights the lines of code which are covered by our test cases with green color, and with red color for lines for which are not covered by our test cases. The image below shows the output of SimpleCov gem for the file participants_controller_spec.rb with 100% code coverage (all green).
Please see the coverage of the code as shown in the screenshot below:
Please find the tests added below:
describe '#validate_authorizations' do
#Test case for successful update of participant to reviewer, expects the success flash message
it 'updates the authorizations for the participant to make them reviewer' do
allow(Participant).to receive(:find).with('1').and_return(participant)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:success]).to eq 'The role of the selected participants has been successfully updated.'
expect(participant.can_review).to eq(true)
expect(participant.can_submit).to eq(false)
expect(participant.can_take_quiz).to eq(false)
end
#Test for case where we expect to encounter an error in update_attributes method
it ' throws an exception while validating authorizations' do
allow(Participant).to receive(:find).with('1').and_return(participant)
allow(participant).to receive(:update_attributes).and_raise(StandardError)
params = {authorization: 'reviewer', id: 1}
session = {user: instructor}
get :update_authorizations, params, session
expect(flash[:error]).to eq 'The update action failed.'
end
end
Team
- Natansh Negi (nnegi2@ncsu.edu)
- Richa Dua (rdua2@ncsu.edu)
- Roshani Narasimhan (rnarasi2@ncsu.edu)
Mentor: Sharique Khan (mkhan8@ncsu.edu)