CSC/ECE 517 Fall 2023 - E2384. Reimplement user controller.rb, user.rb and its child classes

Description of Project

The project aims at reimplementing user controller.rb, user.rb and it's associated child classes. The project reimplementing functionalities specific to the above classes and write extensive rspec tests for the same.

Problem Statement

Background: Background: The User model is a key component of the Expertiza application, handling user data and authentication/authorization features. It is linked to other models such as Participant, TeamsUser, and Invitation, allowing for associations and a personalized user experience.

Reimplementation (What needs to be done): To set up the project, follow these instructions.

Reimplement the search_users, find_user methods in user.rb
Reimplement the role, paginate_list functionality in users_controller.rb
Write thorough RSpec tests for the newly implemented functionalities

Objectives

Reimplement methods pertaining to controller.rb, user.rb and it's associated child classes. More specifically reimplement search_users, find_user methods in user.rb.
Reimplement the role, paginate_list functionality in users_controller.rb.
Ensure proper naming of the methods, variables.
Incorporate suggestions from project3.
Ensure the PR checks are successfull and all test cases are passing.
Compose comprehensive RSpec tests for the changes done to ensure the robustness and reliability of the entire system.

Development Strategy

We have started the development activity using TDD approach. We start by creating test cases for the functionality in hand. Since it is reimplementation, the existing code and functionality makes it much easier to select comprehensive test cases. This is followed by writing clean and simple code to pass the test cases. We are also incorporating comments we received as part of project 3. We identified few more places where naming could be better and we will be incorporating the suggested changes in the reimplementation project.

Revised User.rb:

search_users Method:
1. The 'search_users' method will be reimplemented to accept parameters such as 'role', 'user_id', 'letter', and 'search_by'.
2. It will construct a SQL query based on the provided parameters to filter users.
3. The method will return a list of users that match the search criteria.

find_user Method:
1. The 'find_user' method will be reimplemented to locate a user based on the provided login.
2. It will first try to find the user by email. If not found, it will attempt to find the user by name.
3. The method will return the found user or 'nil' if no matching user is found.

Revised UsersController.rb:

role Action:
1. The 'role' action will be reimplemented to handle requests related to user roles.
2. It may return information about the role of a specific user or perform other role-related functionalities.

paginate_list Action:
1. The 'paginate_list' action will be reimplemented to handle paginated listing of users.
2. It will retrieve a paginated list of users based on certain criteria, making it easier to display users in chunks.

Revised Instructor.rb:

get_user_list Method:
1. The 'get_user_list' method in the 'Instructor' class will be reimplemented to fetch a list of users based on the instructor's role.
2. The method will likely consider the instructor's courses/assignments and return a list of users associated with those courses/assignments.

RSpec Tests:

User.rb Tests:
1. RSpec tests for the 'search_users' method will ensure that the method correctly filters users based on the provided parameters.
2. Tests for the 'find_user' method will validate that it successfully locates users by email or name.

UsersController.rb Tests:
1. RSpec tests for the 'role' action will validate its behavior, ensuring it returns the expected role-related information.
2. Tests for the 'paginate_list' action will check that it correctly paginates the list of users.

Instructor.rb Tests:
1. Tests for the 'get_user_list' method in the 'Instructor' class will ensure it fetches the correct list of users based on the instructor's role and associated courses/assignments.

#	Task	Status	Notes
1	Reimplement `search_users` method in User.rb	To Do	This method will be updated to accept parameters such as `role`, `user_id`, `letter`, and `search_by`.
2	Reimplement `find_user` method in User.rb	To Do	This method will be updated to locate a user based on the provided login.
3	Reimplement `role` action in UsersController.rb	To Do	This action will be updated to handle requests related to user roles.
4	Reimplement `paginate_list` action in UsersController.rb	To Do	This action will be updated to handle paginated listing of users.
5	Reimplement `get_user_list` method in Instructor.rb	To Do	This method will be updated to fetch a list of users based on the instructor's role.
6	Write RSpec tests for User.rb	To Do	New tests will be written for the `search_users` and `find_user` methods.
7	Write RSpec tests for UsersController.rb	To Do	New tests will be written for the `role` and `paginate_list` actions.
8	Write RSpec tests for Instructor.rb	To Do	New tests will be written for the `get_user_list` method.

Test Plan

Sr No	Test Description
1	seacrh_users method in User.rb
1.1	Scenario 1: Test user search by name
1.2	Scenario 2: Test user search by email
1.3	Scenario 3: Test user search by fullname
2	find_user method in User.rb
2.1	Scenario 1: Test locate user by name
2.2	Scenario 2: Test locate user by email
3	Role method in user_controller.rb
3.1	Scenario 1: Role instance to be invalid scenario
3.2	Scenario 2: Role instance to be valid scenario for student
3.3	Scenario 3: Role instance to be valid scenario for instructor
3.4	Scenario 4: Role instance to be valid scenario for admin
4	paginate_list method in user_controller.rb
4.1	Scenario 1: checks that paginate_list does not fail with controller
4.2	Scenario 2: checks that paginate_list does not fail with post
5	get_user_list method in instructor.rb
5.1	Scenario 1: Checking all users from participants of a given assignments

Implementation

We started by looking at the existing implementation thoroughly. We drafted test cases for these implementations. This would be followed by adding code to address failing test cases. Our goal is to ensure that any code written follows the design principles and facilitate readability and maintainability of the code.

API Documentation

Endpoint: Search Users

Description

This endpoint allows you to search for users based on various fields if the requesting user is a Super Administrator.

Request

Method: GET

URL: /api/v1/users/search_users

Parameters:

user_id: The ID of the requesting user. This is used to check if the user is a Super Administrator.
word: The search term. This is used to perform a LIKE query on the specified field.
search_by: The field to search by. This can be 'name', 'email', 'full_name', 'id', or 'role'.

Response

Status Code: 200 OK

Body: A list of users that match the search term in the specified field. If the requesting user is not a Super Administrator, it returns the user with the given user_id.

Example

Request:

GET /api/v1/users/search_users?user_id=1&word=r&search_by=role

Response:

[
    {
        "id": 1,
        "name": "root",
        "full_name": "New Super Administrator",
        "email": "root@example.com",
        "email_on_review": false,
        "email_on_submission": false,
        "email_on_review_of_review": false,
        "role": {
            "id": 1,
            "name": "Super Administrator"
        },
        "parent": {
            "id": null,
            "name": null
        },
        "institution": {
            "id": null,
            "name": null
        }
    },
    {
        "id": 2,
        "name": "admin",
        "full_name": "Administrator",
        "email": "admin@example.com",
        "email_on_review": true,
        "email_on_submission": true,
        "email_on_review_of_review": true,
        "role": {
            "id": 2,
            "name": "Administrator"
        },
        "parent": {
            "id": 1,
            "name": "root"
        },
        "institution": {
            "id": 1,
            "name": "Institution 1"
        }
    },
    {
        "id": 3,
        "name": "user",
        "full_name": "Regular User",
        "email": "user@example.com",
        "email_on_review": false,
        "email_on_submission": false,
        "email_on_review_of_review": false,
        "role": {
            "id": 3,
            "name": "Instructor"
        },
        "parent": {
            "id": 2,
            "name": "admin"
        },
        "institution": {
            "id": 2,
            "name": "Institution 2"
        }
    }
]

Test RSpec

describe '.search_users' do

 let(:super_admin_role) { Role.find_or_create_by(name: 'Super Administrator') }
 let(:user) { create(:user, role: super_admin_role) }

 context 'when the user is a Super Administrator' do
   it 'returns users with matching roles' do
     # Test scenario: When searching by role, it should return users with matching roles.
     result = User.search_users(user, 'Admin', 'role')
     expect(result).to include(user)
   end

   it 'returns an empty array if no users match the criteria' do
     # Test scenario: When no users match the specified criteria, it should return an empty array.
     result = User.search_users(user, 'Nonexistent', 'name')
     expect(result).to eq([])
   end
 end

 context 'when the user is not a Super Administrator' do
   let(:regular_user) { create(:user) }

   it 'returns unauthorized when the user is not a Super Administrator' do
     result = User.search_users(regular_user, 'paolajones', 'name')
     expect(result).to eq('Not Authorized')
   end
 end

end

Team

Mentor

Devashish Vachhani

Members

Doddaguni, Sachin R
Mahesh, Amogh
Villar, Sergio Vargas