Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-22T22:15:24Z

Kajadhav:

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

'''Video:''' https://www.youtube.com/watch?v=pH1opJ1cArc

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending_Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed_Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/</code>

[[File:Rspp4.png|1000px]]

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://www.youtube.com/watch?v=pH1opJ1cArc

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:55:01Z

Kajadhav: /* Test Plan */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending_Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed_Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/</code>

[[File:Rspp4.png|1000px]]

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:54:50Z

Kajadhav: /* Test Plan */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending_Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed_Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/</code>

[[File:Rspp4.png|800px]]

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:54:40Z

Kajadhav: /* Test Plan */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending_Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed_Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/</code>
[[File:Rspp4.png|500px]]

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

File:Rspp4.png

2023-04-15T09:54:18Z

Kajadhav:

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:52:39Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending_Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed_Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:52:01Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Pending%20Request pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Processed%20Request processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/processed_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:50:55Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index pending_request]
|GET <code>/pending_request</code>
|returns a list of pending account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index processed_request]
|GET <code>/processed_request</code>
|returns previously accepted or rejected account requests
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|6
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Pending Request ====
'''Description''': This endpoint gives a list of all pending account requests. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Processed Request ====
'''Description''': This endpoint gives a list of all previously approved or rejected account requests.

'''Path''': GET <code>/pending_request</code>

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Approved",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Rejcted",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:46:12Z

Kajadhav: /* Update */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:45:08Z

Kajadhav: /* Swagger UI screenshot */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kajadhav.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

File:Swagger kajadhav.png

2023-04-15T09:44:49Z

Kajadhav:

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:43:38Z

Kajadhav: /* Files Modified */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:42:54Z

Kajadhav: /* Method: is_admin? */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-15T09:42:43Z

Kajadhav: /* Objectives */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-14T01:27:14Z

Kajadhav: /* Tests */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request with valid parameters
|-
| 4 || Test to create a new account request with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-14T01:19:44Z

Kajadhav: /* Tests */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request by user with valid parameters
|-
| 4 || Test to create a new account request by user with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name already exists in Users table
|-
| 7 || Test to create an account request whose email already exists in Users table
|-
| 8 || Test to Approve account request
|-
| 9 || Test to Approve account request but user with same name already exists
|-
| 10 || Test to Approve account request but user with same email already exists
|-
| 11 || Test to Reject account request
|-
| 12 || Test to check invalid status in PATCH /account_requests/:id
|-
| 13 || Test to check invalid status in PUT /account_requests/:id
|-
| 14 || Test to retrieve a specific account request with valid id
|-
| 15 || Test to retrieve a specific account request with invalid id
|-
| 16 || Test to delete a specific account request with valid id
|-
| 17 || Test to delete a specific account request with invalid id
|-
| 18 || Test to check insitituion index
|-
| 19 || Test to check insitituion show
|-
| 20 || Test to check insitituion create
|-
| 21 || Test to check insitituion update
|-
| 22 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-14T01:06:09Z

Kajadhav: /* Tests */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to create a new account request by user with valid parameters
|-
| 4 || Test to create a new account request by user with invalid or missing parameters
|-
| 5 || Test to create a account request twice
|-
| 6 || Test to create an account request whose name or email already exists in Users table
|-
| 7 || Test to accept account request
|-
| 8 || Test to reject account request
|-
| 9 || Test to check invalid status in PATCH /account_requests/:id
|-
| 10 || Test to check invalid status in PUT /account_requests/:id
|-
| 11 || Test to retrieve a specific account request with valid id
|-
| 12 || Test to retrieve a specific account request with invalid id
|-
| 13 || Test to delete a specific account request with valid id
|-
| 14 || Test to delete a specific account request with invalid id
|-
| 15 || Test to check insitituion index
|-
| 16 || Test to check insitituion show
|-
| 17 || Test to check insitituion create
|-
| 18 || Test to check insitituion update
|-
| 19 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-14T01:04:50Z

Kajadhav: /* Tests */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to list pending account requests
|-
| 2 || Test to list processed account requests
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to create a new account request by user with valid parameters
|-
| 5 || Test to create a new account request by user with invalid or missing parameters
|-
| 6 || Test to create a account request twice
|-
| 7 || Test to create an account request whose name or email already exists in Users table
|-
| 8 || Test to accept account request
|-
| 9 || Test to reject account request
|-
| 10 || Test to check invalid status in PATCH /account_requests/:id
|-
| 11 || Test to check invalid status in PUT /account_requests/:id
|-
| 12 || Test to retrieve a specific account request with valid id
|-
| 13 || Test to retrieve a specific account request with invalid id
|-
| 14 || Test to delete a specific account request with valid id
|-
| 15 || Test to delete a specific account request with invalid id
|-
| 16 || Test to check insitituion index
|-
| 17 || Test to check insitituion show
|-
| 18 || Test to check insitituion create
|-
| 19 || Test to check insitituion update
|-
| 20 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T01:15:52Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

'''IMPORTANT NOTE:''' '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs. Refer testing video below for more insights.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|-
| 26 || Test to check user creation and login
|-
| 27 || Test to check user retrival
|-
| 28 || Test to check insitituion index
|-
| 29 || Test to check insitituion show
|-
| 30 || Test to check insitituion create
|-
| 31 || Test to check insitituion update
|-
| 32 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T01:14:46Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

Note that '''ALL''' APIs other than POST <code>/account_request</code> are auth protected. So, on swagger you will first need to sign up as an Administrator using POST <code>/users</code> API before running such auth protected APIs.

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|-
| 26 || Test to check user creation and login
|-
| 27 || Test to check user retrival
|-
| 28 || Test to check insitituion index
|-
| 29 || Test to check insitituion show
|-
| 30 || Test to check insitituion create
|-
| 31 || Test to check insitituion update
|-
| 32 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:57:42Z

Kajadhav: /* Testing Video */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|-
| 26 || Test to check user creation and login
|-
| 27 || Test to check user retrival
|-
| 28 || Test to check insitituion index
|-
| 29 || Test to check insitituion show
|-
| 30 || Test to check insitituion create
|-
| 31 || Test to check insitituion update
|-
| 32 || Test to check insitituion delete
|}

==== Testing Video ====
https://drive.google.com/file/d/19iSwZKnEXSDk45Q45rsLLYbJ66PDH_xo/view?usp=sharing

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:24:21Z

Kajadhav: /* Test Screenshot */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|-
| 26 || Test to check user creation and login
|-
| 27 || Test to check user retrival
|-
| 28 || Test to check insitituion index
|-
| 29 || Test to check insitituion show
|-
| 30 || Test to check insitituion create
|-
| 31 || Test to check insitituion update
|-
| 32 || Test to check insitituion delete
|}

==== Testing Video ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:23:57Z

Kajadhav: /* Tests */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|-
| 26 || Test to check user creation and login
|-
| 27 || Test to check user retrival
|-
| 28 || Test to check insitituion index
|-
| 29 || Test to check insitituion show
|-
| 30 || Test to check insitituion create
|-
| 31 || Test to check insitituion update
|-
| 32 || Test to check insitituion delete
|}

==== Test Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:21:46Z

Kajadhav: /* Test Plan */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_requests_spec.rb</code>

5. <code>bundle exec rspec spec/requests/api/v1/roles_spec.rb</code>

6. <code>bundle exec rspec spec/requests/api/v1/users_spec.rb</code>

7. <code>bundle exec rspec spec/requests/api/v1/institution_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and not signed in
|-
| 2 || Test to check index with historic false and signed in with Administrator or Super Administrator.
|-
| 3 || Test to check index with historic false and signed in with any other role.
|-
| 4 || Test to check index with historic true and not signed in
|-
| 5 || Test to check index with historic true and signed in with Administrator or Super Administrator.
|-
| 6 || Test to check index with historic true and signed in with any other role.
|-
| 7 || Test to create a new account request by user with valid parameters
|-
| 8 || Test to create a new account request by admin with valid parameters
|-
| 9 || Test to create a new account request by user with invalid or missing parameters
|-
| 10 || Test to create a new account request by admin with invalid or missing parameters
|-
| 11 || Test to create a account request twice
|-
| 12 || Test to create an account request whose name or email already exists in Users table
|-
| 13 || Test to accept account request by admin
|-
| 14 || Test to reject account request by admin
|-
| 15 || Test to accept account request by user
|-
| 16 || Test to reject account request by user
|-
| 17 || Test to update account request with invalid or missing parameters
|-
| 18 || Test to retrieve a specific account request by user with valid id
|-
| 19 || Test to retrieve a specific account request by admin with valid id
|-
| 20 || Test to retrieve a specific account request by user with invalid id
|-
| 21 || Test to retrieve a specific account request by admin with invalid id
|-
| 22 || Test to delete a specific account request by user with valid id
|-
| 23 || Test to delete a specific account request by admin with valid id
|-
| 24 || Test to delete a specific account request by user with invalid id
|-
| 25 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:05:11Z

Kajadhav: /* Delete */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"message": "Account Request deleted"
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:03:42Z

Kajadhav: /* Update */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @new_user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:03:25Z

Kajadhav: /* Update */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject an Account Request or even Edit it. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH/PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 new intro",
"role_id": 2,
"institution_id": 1,
"status": "Approved"
}
</pre>

'''Response''':
<pre>
Success
{
"msg": "Account Request Approved and User successfully created.",
"user": {
"id": 25,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"email_on_review": false,
"email_on_submission": false,
"email_on_review_of_review": false,
"role": {
"id": 2,
"name": "Student"
},
"parent": {
"id": 19,
"name": "stubbjb"
},
"institution": {
"id": 1,
"name": "North Carolina State University"
}
}
}
status: :ok

Failure
{
error: @user.errors
}
status: :unprocessable_entity
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-13T00:00:01Z

Kajadhav: /* Show */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:58:20Z

Kajadhav: /* Show */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Response''':
<pre>
Success
{
"id": 2,
"name": "uone1",
"fullname": "uone1",
"email": "uone1m@g.com",
"status": "Rejected",
"self_introduction": "intro",
"created_at": "2023-04-12T16:15:35.253Z",
"updated_at": "2023-04-12T19:26:16.030Z",
"role_id": 2,
"institution_id": 1
}

status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:56:51Z

Kajadhav: /* Index */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|False by default. If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:55:59Z

Kajadhav: /* Create */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
{
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"self_introduction": "U3 intro",
"role_id": 2,
"institution_id": 1
}
</pre>

'''Response''':
<pre>
Success
{
"id": 3,
"name": "userthree",
"fullname": "User Three",
"email": "u3@gmail.com",
"status": "Under Review",
"self_introduction": "U3 intro",
"created_at": "2023-04-12T23:54:59.635Z",
"updated_at": "2023-04-12T23:54:59.635Z",
"role_id": 2,
"institution_id": 1
}
status: :ok

Failure
{
error: @account_request.errors
}
status: :unprocessable_entity
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:53:34Z

Kajadhav: /* Index */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Success
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
status: :ok

Failure
{
error: @account_requests.errors
}
status: :unprocessable_entity
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:51:25Z

Kajadhav: /* Index */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
[
{
"id": 1,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 2,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:51:07Z

Kajadhav: /* Index */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
[
{
"id": 5,
"name": "userone",
"fullname": "User One",
"email": "u1@gmail.com",
"status": "Under Review",
"self_introduction": "I'm an MCS student, request to add my Student account",
"created_at": "2023-04-12T19:04:34.769Z",
"updated_at": "2023-04-12T19:04:34.769Z",
"role_id": 2,
"institution_id": 1
},
{
"id": 4,
"name": "usertwo",
"fullname": "User Two",
"email": "u2@gmail.com",
"status": "Under Review",
"self_introduction": "U2's intro",
"created_at": "2023-04-12T16:21:28.549Z",
"updated_at": "2023-04-12T16:21:28.549Z",
"role_id": 2,
"institution_id": 1
}
]
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:47:58Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
VCL Swagger URL: http://152.7.178.99:3000/api-docs/
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:46:54Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
==== Swagger UI screenshot ====
[[File:Swagger kj p4.png|900px]]

{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

File:Swagger kj p4.png

2023-04-12T23:45:51Z

Kajadhav:

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:43:31Z

Kajadhav: /* API documentation */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|delete a specific account request
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:42:52Z

Kajadhav: /* Method: notify_supers_new_request */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: create_approved_user ====
If the Account Request is Approved, create a new user if all fields are valid and return it. If any invalid fields present, return error containing it's message.

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:41:57Z

Kajadhav: /* Method: requested_user_params */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: account_request_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:41:22Z

Kajadhav: /* Method: foreign */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: is_admin? ====
Validate if the currently logged in user is an admin. Throw error if not admin. Login and auth is managed via POST /users on Swagger

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:39:44Z

Kajadhav: /* Method: create */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user or admin to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:39:32Z

Kajadhav: /* Method: index */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic, that is previously approved or rejected account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:17:33Z

Kajadhav: /* Files Modified */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/api/v1/account_requests_controller.rb</li>
<li>app/controllers/api/v1/institutions_controller.rb</li>
<li>app/controllers/api/v1/users_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>config/application.rb</li>
<li>config/routes.rb</li>
<li>db/migrate/20230412013301_create_account_requests.rb</li>
<li>db/migrate/20230412013310_add_keys_to_account_requests.rb</li>
<li>spec/models/account_request_spec.rb</li>
<li>spec/requests/api/v1/account_requests_spec.rb</li>
<li>spec/requests/api/v1/institution_spec.rb</li>
<li>spec/requests/api/v1/roles_spec.rb</li>
<li>spec/requests/api/v1/users_spec.rb</li>
<li>swagger/v1/swagger.yaml</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:04:41Z

Kajadhav: /* Objectives */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending account requests, listing already approved or rejected requests, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like is_admin?, account_request_params, create_approved_user to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T23:00:47Z

Kajadhav: /* Functionality */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending requested accounts, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like action_allowed?, foreign, notify_supers_new_request to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems. Check account_requests_controller and users_controller for better understanding.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T22:59:18Z

Kajadhav: /* Objectives */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending requested accounts, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like action_allowed?, foreign, notify_supers_new_request to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

6. Implement simple Authorization for Swagger simply using session variables instead of complex code.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T22:58:07Z

Kajadhav: /* Models */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending requested accounts, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like action_allowed?, foreign, notify_supers_new_request to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below. For more details, check UML diagram above:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T22:57:01Z

Kajadhav: /* Functionality */

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending requested accounts, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like action_allowed?, foreign, notify_supers_new_request to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. For Authorization with swagger APIs, we use simply the session variable instead of using extra gems.

8. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress

CSC/ECE 517 Spring 2023 - E2331. Reimplement Account Request module

2023-04-12T22:52:55Z

Kajadhav:

== Project Overview ==

=== Background ===
In Expertiza, Account Creation can only be done by Admins and Super Admins. So, new users first request an account by clicking "Request Account" button on home page and filling out an account request form. After the user submits this form, the Admin or Super Admin is notified of the request and then he can decide to Accept or Reject such requests. If he accepts, then an email with new login details is sent to that user.

The Account Request module is responsible for performing all these functions. In this project, we aim to write RESTful endpoints for the Account Request module CRUD operations along with adding the corresponding controllers and model files. We also add a few other non CRUD custom actions to the controller files which are required for the app to function normally. And, we also aim to write tests for the corresponding model and controller files.

=== Objectives ===
1. Write RESTful endpoints of create, show, index, update, destroy to simulate creating and approving new user accounts, listing pending requested accounts, creating a new account request, and notifying super-admins about new account requests.

2. Add non CRUD custom actions like action_allowed?, foreign, notify_supers_new_request to support the above RESTful endpoints.

3. Return proper status codes and proper validation for RESTful endpoints.

4. Write models and controllers such that they use modern approaches to writing Ruby code, including utilizing language features and adhering to best practices for object-oriented design.

5. Write proper Rspec tests for all APIs, models, controllers.

== Team Members ==
Kaushik Jadhav (unity_id: kajadhav, github: kaushikjadhav01)

Aditi Vakeel (unity_id: avakeel, github: aditi-v79)

Shivesh Madan Nath Jha (unity_id: sjha7, github: ShiveshJha12)

== Mentor ==
Ankur Mundra (unity_id: amundra, github: amundra)

== Relevant Links ==
'''Github Repository:''' https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end

'''Pull Request:''' https://github.com/expertiza/reimplementation-back-end/pull/29

'''VCL Server:''' http://152.7.178.99:3000/

'''VCL Swagger UI:''' http://152.7.178.99:3000/api-docs/

== Files Modified ==
<ul>
<li>app/controllers/account_request_controller.rb</li>
<li>app/models/account_request.rb</li>
<li>app/controllers/users_controller.rb</li>
<li>spec/requests/api/v1/account_request_spec.rb</li>
</ul>

== Implementation ==
=== UML Diagram ===
[[File:UML class kj p4.png|1000px]]
=== Functionality ===
In this project, we aim to add the following functions:

1. Enable users to create a new Account Request.

2. Enable admins to create a new Account Request.

3. Enable admin to list pending requested accounts.

4. Enable admins to Accept or Reject Account Requests.

5. Enable admins to list previously accepted or rejected account requests.

6. Ensure that data is validated properly in all the above APIs.

7. Test cases for all the above.

[[File:P4f1.png|900px]]
[[File:P4f2.png|900px]]
[[File:P4f3.png|900px]]
[[File:P4f5.png|900px]]
[[File:P4f6.png|900px]]
[[File:P4f4.png|900px]]

=== Controllers ===
We create a new controller at <code>'''app/controllers/account_request_controller.rb'''</code> with following methods:

==== Method: index ====
This method gives a list of all pending account requests or historic account requests to Admin or Super Admin.

==== Method: create ====
This method allows any user to create a new Account Request. On successful submission, admins are notified.

==== Method: show ====
This method enables Admin or Super Admin to view a specific Account Request

==== Method: update ====
This method enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

==== Method: destroy ====
This method enables Admin or Super Admin to delete a specific Account Request

==== Method: foreign ====
If the registered user status is Approved and if the new_user couldn't be saved, foreign function saves the role id in @all_roles variable

==== Method: notify_supers_new_request ====
Notifies all the super admins by email that request for a new account has been created

==== Method: requested_user_params ====
The params in a controller looks like a Hash, but it's actually an instance of ActionController::Parameters, which provides several methods such as require and permit. The require method ensures that a specific parameter is present, and if it's not provided, the require method throws an error. It returns an instance of ActionController::Parameters for the key passed into require. The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.

=== Models ===
We create a new model <code>'''class AccountRequest'''</code> at <code>'''app/models/account_request.rb'''</code> and add validations to all input fields as shown below:

[[File:Model kj p4.png|800px]]

=== API documentation ===
{| class="wikitable" style="width: 100%;
!  #  !! Method !! Endpoint !! Description
|-
|1
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Index index]
|GET <code>/account_request</code>
|returns a list of pending account requests or previously accepted or rejected account requests
|-
|2
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Create create]
|POST <code>/account_request</code>
|creates a new account request
|-
|3
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Show show]
|GET <code>/account_request/:id</code>
|retreive a specific account request
|-
|4
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Update update]
|PATCH <code>/account_request/:id</code>
|accept or reject an account request
|-
|5
|[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2331._Reimplement_Account_Request_module#Delete delete]
|DELETE <code>/account_request/:id</code>
|deletes a participant from an assignment or a course
|}

==== Index ====
'''Description''': This endpoint gives a list of all pending account requests to Admin or Super Admin. A success response renders a JSON with all pending account requests.

'''Path''': GET <code>/account_request</code>

'''Parameters''':
{| class="wikitable" style="width: 100%;
!  #  !! Parameter !! Expected Value
|-
|1
|<code>historic</code>
|true or false
|If true, returns a list historically accepted or rejected account requests. If false, returns pending account requests.
|}

'''Response''':
<pre>
Work In Progress
</pre>

==== Create ====
'''Description''': This endpoint enables any user to create a new account request.

'''Path''': POST <code>/account_request</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Show ====
'''Description''': This endpoint enables Admin or Super Admin to view a specific Account Request.

'''Path''': GET <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Update ====
'''Description''': This endpoint enables Admin or Super Admin to Accept or Reject single or multiple Account Requests simultaneously. If accepted and if the account is not duplicate, the new account is generated for the user and the user is sent an email with the login credentials.

'''Path''': PATCH <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

==== Delete ====
'''Description''': This endpoint enables Admin or Super Admin to delete a specific Account Request.

'''Path''': DELETE <code>/account_request/:id</code>

'''Request Body''':
<pre>
Work In Progress
</pre>

'''Response''':
<pre>
Work In Progress
</pre>

== Design Pattern ==
A design pattern is a general repeatable solution to a commonly occurring problem in software design. It is a description or template for how to solve a problem that can be used in many different situations.

During the process of refactoring methods as well as method names,'''Strategy Pattern''' was used in the implementation. The Strategy pattern is most useful when you want to provide multiple ways of processing a request, without hard-coding knowledge about those different methods into the object that handles the request.

== Test Plan ==

The testing framework is RSpec. To test the RESTful APIs, we have used stubs and mocks. We have created some new models and added some associations in them which were required for stubbing.

To run the tests:

1. <code>git clone https://github.com/CSC-517-Spr23-kajadhav-avakeel-sjha7/reimplementation-back-end</code>

2. <code>cd reimplementation-back-end/</code>

3. <code>bundle install</code>

4. <code>bundle exec rspec spec/requests/api/v1/account_request_spec.rb</code>

====Tests====

{| class="wikitable" style="margin-left:40px"
|-
! Test ID !! Test Description
|-
| 1 || Test to check index with historic false and valid parameters.
|-
| 2 || Test to check index with historic false and invalid parameters.
|-
| 3 || Test to check index with historic true and valid parameters.
|-
| 4 || Test to check index with historic true and invalid parameters.
|-
| 5 || Test to create a new account request by user with valid parameters
|-
| 6 || Test to create a new account request by admin with valid parameters
|-
| 7 || Test to create a new account request by user with invalid parameters
|-
| 8 || Test to create a new account request by admin with invalid parameters
|-
| 9 || Test to accept account request by admin
|-
| 10 || Test to reject account request by admin
|-
| 11 || Test to accept account request by user
|-
| 12 || Test to reject account request by user
|-
| 13 || Test to retrieve a specific account request by user with valid id
|-
| 14 || Test to retrieve a specific account request by admin with valid id
|-
| 15 || Test to retrieve a specific account request by user with invalid id
|-
| 16 || Test to retrieve a specific account request by admin with invalid id
|-
| 17 || Test to delete a specific account request by user with valid id
|-
| 18 || Test to delete a specific account request by admin with valid id
|-
| 19 || Test to delete a specific account request by user with invalid id
|-
| 20 || Test to delete a specific account request by admin with invalid id
|}

==== Test Screenshot ====
Work in Progress

==== Swagger UI Screenshot ====
Work in Progress