Integration with the University - COS-301/graduates GitHub Wiki

Documentation

Introduction

This feature will be responsible for the sharing of information between the graduate portal and the UP website. It shall retrieve the academic records of students for use by the authentication team. This feature will also facilitate any other communication that needs to take place between the portal and UP, such as student details, etc. Lastly, once blockchain integration has occurred, this feature will retrieve the degrees from UP to be accessible through the portal.

System Functional Requirements

Functional Requirements

  1. This feature shall get a students' name and details automatically.
  2. This feature shall get a student's academic record automatically.
  3. This feature shall get a student's degree automatically.

Non-Functional Requirements

Quality Requirements

  • Student privacy must always be maintained
  • The retrievals should be quick so as to not create a speed bottleneck for the whole project.

Architectural Requirements

  • Scalability - The feature should be able to handle large numbers of retrievals.
  • Availability - The feature should be able to make retrievals whenever necessary.
  • Maintainability - The feature needs to be designed in a way that allows it to continue to perform its duty in spite of changes to the APIs on either the server or university’s sides.

Architectural Constraints

  • The University does not have an API currently that we can use to retrieve the required data, so we will need to use mock data for our current implementation.
  • The feature will need to store the pdf files it retrieves with firebase, according to the storage team.

Diagrams

Case Diagrams

Graduate's Personal Details drawio

Academic Details drawio

Qualification drawio

UP Integration drawio

API Documentation

getStudentDetailsUP(a)

a : String that is the student number of the individual returns:

  1. studentNumber
  2. userID
  3. email
  4. contactNumber
  5. name
  6. surname
  7. course

getAcademicRecord()

returns:

  1. fileAsString Is a stub

getDegree()

returns:

  1. fileAsString Is a stub

Database Structure

This feature does automatically what other features allow the user to do manually, and so it is important that the data is stored in the same place. This means that this feature will use the storage and student details features' databases. This is to allow for the data retrieved automatically to still accessible to their features.

Acceptance Criteria

The feature must get the student's personal details such as names and contact details automatically, it must also get the student's academic record and degree and all of that info must be done automatically. And at the same time get the students' consent also maintaining students' privacy.

Acceptance Criteria Checklist.pdf

Testing

PR Number: 179 Commit Hash: 690830e Status: Passed Date: 2022/03/21 Tester: Awelani Murovhi Developer: Gabriel Grobler Description: ✨ (up-integration): Added initial stub

PR Number: 798 Commit Hash: f614980 Status: Passed Date: 2022/04/15 Tester: Awelani Murovhi Developer: Gabriel Grobler Description: 🎨 (up-integration): updated file structure, added .spec file

PR Number: 864 Commit Hash: 7e8adde Status: Passed Date: 2022/04/16 Tester: Awelani Murovhi Developer: Thangeni Faresa Description: 🚧(service engineer)- add models, events and handlers

PR Number: 879 Commit Hash: a9a14f7 Status: Passed Date: 2022/04/17 Tester: Awelani Murovhi Developer: Phillipa Dufana Description: 🗃 (data engineer) Added gets and sets functions PR Number: 899 Commit Hash: n/a Status: Failed Date: 2022/04/16 Tester: Awelani Murovhi Developer: Wesley Pachai Description: A few checks failed, due to dependency errors.

PR Number: 934 Commit Hash: 76647ce Status: Passed Date: 2022/04/17 Tester: Awelani Murovhi Developer: Wesley Pachai Description: ✨(UI): Added Basic Framework

PR Number: 961 Commit Hash: f830c21 Status: Passed Date: 2022/04/17 Tester: Awelani Murovhi Developer: Gabriel Grobler Description: 🎨(up-integration): expanded on academic record entity, added references

PR Number: 978 Commit Hash: 6b65960 Status: Passed Date: 2022/04/17 Tester: Awelani Murovhi Developer: Thangeni Faresa Description: 🚚 (service engineer)- fixed paths, called get methods

PR Number:1005 Commit Hash:ddaacd2 Status:Passed Date:2022/04/18 Tester:Awelani Murovhi Developer:Gabriel Grobler Description:🎨 (up-integration):major changes to api and and attached layers

PR Number:1027 Commit Hash:7394d1d Status: Passed Date:2022/04/18 Tester:Awelani Murovhi Developer:Wesley Pachai Description:✨(UI): Adding UI Components

PR Number:1047 Commit Hash:3d09e83 Status:Passed Date:2022/04/18 Tester:Awelani Murovhi Developer:Gabriel Grobler Description:✅ (up-integration): added unit tests for api resolver, fixed api error

PR Number:1104 Commit Hash:43c4a1e Status:Passed Date:2022/04/18 Tester:Awelani Murovhi Developer:Wesley Pachai Description:✨(UI): Added HTML and SCSS

PR Number:1127 Commit Hash:n/a Status: Failed Date:2022/04/18 Tester:Awelani Murovhi Developer:Wesley Pachai Description:The PR was not up to date with the latest branch.

PR Number:1143 Commit Hash:n/a Status:Failed Date:2022/04/18 Tester:Awelani Murovhi Developer:Wesley Pachai Description:Includes were missing from some of the files, causing a check to fail.

PR Number:1149 Commit Hash:f49ccaa Status: Passed Date:2022/04/19 Tester:Awelani Murovhi Developer:Wesley Pachai Description:✨(UI): Receives Student Number and Choices

PR Number:1199 Commit Hash:02f148c Status:Passed Date:2022/04/21 Tester:Awelani Murovhi Developer:Wesley Pachai Description:(UI): Fixes to routing Module

Roles for Sprint 2

James Butler - u20437863 - Project Manager

  • I have fulfilled much of the same role as in sprint 1 in addition to the following points.
  • I have given guidance about how the different components should integrate.
  • I have given reviews and critiques of the code put forward in my teams’ PRs and merged them once I was satisfied that all issues were addressed.

Ponalo Notwane - u16115092 - Business Analyst

  • Worked on outlining the acceptance criteria of the feature.
  • I’ve been working closely with other BAs on figuring out how each document should be formatted under a specific given criteria which requires a bit of research first.
  • I’ve also drawn use case diagrams which can be seen on the wiki under the documentation page titled Diagrams.
  • Worked on compiling the team wiki document along with my PM
  • Assessing whether the whole feature does meet the acceptance criteria or not.

Thangeni Faresa - u18312374 - Service Engineer

  • I Fulfilled the role of a service engineer and applying the information and knowledge acquired from the research.
  • I Worked on implementing the service layer for the UP integration feature.
  • I Worked with the API engineer and Data engineer to integrate our code and their functionalities.
  • I Participated in service engineers and API engineers discussion to resolve and offer potential solutions to common problems.

Gabriel Grobler - u20534541 - API Engineer

  • I Worked on implementing the API layer for our feature so that it is currently a framework that acts as an example for future years to expand on.
  • I worked alongside the service and data engineer to implement the current API structure.
  • I worked on creating the unit tests for the API layer.

Brett du Plessis - u19037717 - Developer Operations

  • I helped with reviewing pull requests.
  • I followed the various DevOps channels and chats and stayed informed about any pipeline breakages.

Wesley Pachai - u20578688 - Designer and UI Engineer

  • I Collaborated with designers to finalize themes.
  • I Worked on implementing the User Interface for the feature.
  • I Worked on implementing the routing for the feature.
  • I Stayed up to date on the developments in the UI Engineer role, including the inclusion of the mobiles friendliness considerations from @SeePeeYou.

Philippa Dufana - u19053313 - Data Engineer

  • I created the get and set functions that our feature requires.
  • I had meetings and collaborated with the API and Service engineers.

Awelani Murovhi - u18335412 - Tester

  • I have worked on compiling the testing logs for my team’s PRs as per the specifications on the testing wiki.
  • I advised the rest of the team on implementing unit tests.

Plans for future implementation

Getting the Student Details

Currently the function getStudentDetailsUP gets the data directly from the systems database. This is what should be altered to get the data from the UP API. The data returned at present should not be used for validation. In future, when access to the UP API becomes available then the student details can be fetched directly from the UP API instead of fetching only mock data from the database. With this data that has been retrieved from the UP side, validation of the user can take place for example: a student does belong to the course that they specified when creating their account (being a CS student or an IKS student).

Getting Academic Record

Currently the user is expected to upload their academic record manually. This is done by making a call to the storage API as they have accounted for uploading files to the database. In future this process can be automated by getting the academic record directly from the UP API and uploading it to the database through the storage API. If this is not the case and the academic record is still expected to be uploaded manually then the retrieved one can be used to verify that the information is correct.

Getting Degree

Similar to the academic record the user is currently expected to upload their degree manually. This is done by making a call to the storage API as they have accounted for uploading files to the database. In future this process can be automated by getting the academic record directly from the UP API and uploading it to the database through the storage API or the blockchain if that is functional. If this is not the case and the academic record is still expected to be uploaded manually then the retrieved one can be used to verify that the information is correct.

Suggestion for future implementation

Validation

When a query from the service layer is handled it uses what is written in the repository layer to retrieve the information from the database. If the data from the UP API is to be used for validation purposes then the current query's may suffice to retrieve what is in the database to compare with what the UP API has returned.

Automatic addition

Currently the API makes a call to the service layer where the query's are handled by the service layer. If the data that is being retrieved from the UP API is going to be stored automatically then commands will have to be added and handled to perform these tasks. This will be done in the service layer. If the degree and academic record are to be retrieved and stored automatically then it should directly call the storage API for the addition of the files to the database.

API Endpoint Calls

The API endpoint calls that the UI makes need to be checked for errors and be updated to retrieve the correct values.