CSC/ECE 517 Fall 2017/E17A6. Fix account creation over web to work reasonably

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction to Expertise

Expertiza is a educational website that allows school users to submit peer reviews on assignments. To register to use this website, one needs to be either a course TA or Instructor and send a request to expertiza administrator to get approved. The request function only serves TAs and Instructors, so students won't be able to register. A student account is created by instructors or TAs. The whole purpose of this approval process is because students have no point of using this website without enrolling to an instructors course first, so they shouldn't request accounts from expertiza but from their instructors and TAs.

A pending request page that displays all the requests should also be able to perform actions like approve or reject with an note.

However, currently, all of these are done manually, which means no pending request page currently exists, no simple approve or reject action, and no user experience, and all users are added into the database through command line operations in the database(only instructor and TA roles which is acceptable currently but not when more other institutions try to user Expertiza).

In addition, we also want users be able to add their institution if it does not show under the list provided by us.


Problem Statement

Overall Introduction

Request account function is currently not working properly. A new user who tries to request an expertiza account can do so, but the instructor can see yet has no power to approve any request. The approval process is currently done manually, which is cumbersome. Our mission is to fix the request account functionality so that whoever requests for a new accounts can be approved by instructor clicking a button, and secondly, optimize the functionality to improve user experience.


Detailed Requirements and Plan

1. Add institution <br\> -A registering user should be able to choose their institution from a drop-down menu, but they should also be able to add an institution if they couldn't find one. <br\>

-The new institution should be saved as a new record into the institution table<br\>

-New account request should be saved to requested_users table with correct institution id.<br\>

2.superadmin, admin should be able to approve/decline requests<br\>

-add a new drop-down item under “Administration > Show…” so requests can be visually displayed and handled<br\>

-enable the "approve" function for admin and superadmin<br\>

-make clickable user email address so a conversation is possible<br\>

3. The record retain after admin's approval/rejection and an email will be sent to remind<br\>

-an email should be sent when a request is approved or declined<br\>

-all record should be kept on the page even it has been handled<br\>

Use Case Diagram

The following is the use case diagram for the feature that we are going to implement.


Fix 1. Add institution

- redesign the view shown in the previous section to include a field named institution in the current form to allow user to submit their institution if they couldn't find one in the list, and save it into the table corresponding to the form it submits to.

- design a requested_user table to save all account requests

Fix 2. Add new Page and Action

- to create an new view that can show all pending account requests and include actions like approve and reject to allow instructors to process requests on the same page

- create corresponding new controller with methods corresponding to actions like reject, approve and index.

Fix 3. The record retains after admin's approval and email reminder

- redesign the view and model to retain the request record after super-admin or admin approves the request.

- add an email tag in the corresponding view, so there will be an email send to email address offered by requester after approval/rejection.

Screens after the modification

1. First of all, a new user need to click 'REQUEST ACCOUNT' to create a new account.



2. In the 'request new' page, in the original version, the user can only choose an institution from the drop-down menu. After our modification, the user can choose the 'Not List' choice in the drop-down menu and type in an institution when (s)he is not able to find his(her) institution in the drop-down menu.


3. After log in as an admin/super admin, the user can see a drop-down item under 'Administration->Show->Pending Users' to see all account requests.



4. After clicking the 'Pending Users', the admin can see a list of new account requests and the emails are clickable to send email to the requesting user. Also, after the admin accepts the request, the record should retain in the view and an email informing the requestor will be sent to the requestors' given email address.



5. After clicking the email address, the sending email page will pop up and admin can converse requestors.


Design Pattern

1. MVC

The project is implemented in Ruby on Rails that uses MVC architecture. It separates an application’s data model, user interface, and control logic into three distinct components (model, view and controller, respectively).

2. Dry Principle

We are trying to reuse the existing functionalities in Expertiza, thus avoiding code duplication. Whenever possible, code modification based on the existing classes, controllers, or tables will be done instead of creating the new one.


Test Plan

Both manual and RSpec test will be performed on the following items.

1. a proper error message for improper information filled in, such as wrong email address format or existing account.

2. When a pending account gets approved or rejected, an email will be sent to the submitted email address.

3. A new item "show" should be added under administration and direct instructor to pending requests page when clicked

4. pending requests will have an email column that is clickable which allows instructor to send emails to applicants before a decision is made.

5. when a request is processed, its record is still kept with the status of processed.


Team Informantion

Guiyang Fan(gfan@ncsu.edu)

Haoxu Ren(hren3@ncsu.edu)

Dongyu Wang(dwang32@ncsu.edu)

Yichi Zhang(yzhan222@ncsu.edu)