Documentation

1. Introduction

Authorization is officially giving permissions and privileges to a user in the system to access resources related to the system, e.g. a company having access to view a graduates profile.
Within authorization, there are access levels, which brings in the concept of roles in a system, where one user may have more privileges than another user.

Roles

1. User

General users of the system. This role is the general user of the system and will have limited permissions with the system.

2. Student

These are the roles reserved for University of Pretoria Computer Sciences graduates and will have more permissions to view other users and companies.

3. Company

These users are the general companies that will search for employees and the STUDENT role will be able to search for employment at the listed companies. These companies will have to be thoroughly investigated as to not make it possible for malicious users to acquire the users of the systems information. These users will only have a very limited set of permissions before and during the vetting process.

4. Representative

These as the representatives of the different companies that will have high level authorities with only the companies account as well as the users accounts under the company.

5. Admin

The Admins will perform the vetting of the company role as well as perform the general administrative role in the system. The Admin role will be able to perform any task that requires permission except for creating new admins. The admin creation role will only be perform by the super admin account of University of Pretoria.

6. Suspended

This is a role reserved for either companies who have not been vetted yet or suspicious accounts as to make sure that those users will not be able to access any information they shouldn't have.

2. Functional requirements

FR1 - The system will give Students/Graduates the permission to edit their profiles and delete their profiles.

Constraints for editing profile:

• When editing profiles, Users will ONLY be authorized to edit changing attributes such as:

• Contact details.
• And/ Uploaded documents such as CVs, Profile Pictures etc.
• Non-changing attributes will Not be tempered with.

• Users will only also be authorized to change ONLY their profile details.

Inputs: Click to the edit profile button

Process: - Check if the user is authorized to edit the profile.

Outputs: Edit profile page(s).

FR2 - The system will authorize or give company representatives permission to scout for prospective employees and view student’s/graduate’s profiles. By:

• Allowing company representatives(users) to request for profile viewing.
• Once the student/graduate has accepted the request, the company will be given further access rights.

Rights to:

• Potentially communicate further details on their recruitment process
• AND/OR query for missing information.

Constraints:

• Company representatives can Only view the student’s profile once the user (student/graduate) has given them access to.
• Company representatives will NOT be authorized to change any student’s or graduate’s details.

Inputs: Click ‘view student’s profile’ button or related button

Process:

• Check if the user is a company’s profile.
• Allow for request to be sent to the specific student(Student)

Outputs: View to Student’s profile.

FR3 - The system will permit authenticated Admins:

• to create, edit and delete users(student’s ,graduates and company’s) profiles, posts etc.

FR4 - The system should be able to inform users that they are not authorized to access certain pages/resources when they are not authorized.

Inputs: Clicks on permission buttons on the User Interface

Process: Check if the user is authorized to access the resource on site

Outputs: Pages or messages such as 403 error.

FR5 - The system will give users-Suspended the permission to edit their profiles and delete their profiles

Inputs: Clicks on buttons on the User Interface

Process: Check if the user is authorized to access the resource on site

Outputs: Pages or messages such as 403 error.

Use case diagrams

3. Non-functional Requirements

l requirements

Quality requirements

NFR1 - Speed : Users who want to access certain resources on the site should access these resources instantly. This is to say authorization should take place instantly, or at least the process should start instantly. This is to also say users can view/access any resources they are eligible for at any given day/time.

NFR2 - Capacity: The system should be able to cater/ authorize more or less students each year as the number of students registered in the system may increase/decrease each year.

NFR3 - Scalability: The resources which can be requested for can grow as new information sources are made available on the system.

4. Components/services

Project Manager role completed by Miss PV(Phumudzo) Ndou u19050993

• As a Project manager, I maintained communication between the PO's and my team, as well as between other teams and my own team. Where ever there was a need for collaboration contact would be made with the PM of the feature team we need to collaborate with.
• Being a representative for my feature team
• I created and maintain the authorization project, to keep track who is doing what and when.
• Reviewing of Pull Requests

What has to be done for Splint 2

• Implementation has to start in the second sprint
• Delegating the designer to help where needed with other roles within the team

Problems

Communication between PM's Organizing meetings that suit everyone on a weekly basis

Working on Problem

Having a set schedule, knowing that every Monday and Friday we should actually have a meeting

5. Business Analyst role completed by Miss KC(Kudakwashe) Chivunga u19068752

• Read through the clients requirements specification and brainstormed on features we could implement as a team. Attached below is the suggested feature doc:

• COS_301_Mini_Project__Cplusplus (1).pdf

• Got Authorization feature and discussed with the project manager
• Based on that l then Documented the

• functional requirements
• non-functional requirements,
• Use cases and their diagrams
• acceptance criteria.

• Worked hand in hand with the design team to ensure that client's expectations would be met.
• Worked hand in hand to ensure that the back-end's designs and mocks would meet the clients standards.

Sprint 2

• I documented the contract document/ endpoint document that will allow other feature teams to use our library The document stated above: Authorization Endpoints.pdf

I hereby declare that all the acceptance criteria, functional requirements and non-functional requirements have been met.The Authorization library is a working feature, and can be accessed and utilized by any other features working on the graduates portal project.

6. Designer role completed by Mr H(Hamza) Allimia u18219919

Design requirements completed for splint 1

• User flow diagrams
• Design wireframes and mockups for:

• Designs.pdf
• Access Denied pop-ups and prompts.
• Forbidden Error - 403 page.

• Adapting designs for mobile.

• UI Designs

https://xd.adobe.com/view/23ca7da0-ce94-404b-983d-2fd6c86487ff-7699/

Goals for splint 2
TBD

7. UI Engineer role completed by Mr MG(Gift) Monwa u18196366

• Collaborated with the Designer for the designs and had multiple discussions on how would implement our pop ups and error messages

• Did some research and video tutorials on building apps with Angular, tailwindcss and all the other related frameworks.

• Did some mock code that helps put how we are going to implement the authorization feature into perspective.

• Used json-server to create a mock API that aided in the implementation of the mock code since I had to demonstrate how we will use HTTPClient to make calls to our API(in this case a mock API) and how we are going to use the response to check if a User has the necessary permissions to access a certain feature of our Graduates App. Below is A snippet of how most of our functions will be like when they check a user's permissions.

• The JSON-Server and the mock

What has to be done for Splint 2

• Making sure that all the popups are designed implemented and ready to be integrated into our Graduates portal.
• Brushing Up the UI interface and updating the mock code to work with our real API instead of the Mock.
• Ensuring that our feature integrates well into the Graduates system

Problems

• Learning Angular has been a long journey since It has been a while since I past COS216 so I had to brush up my traditional web development skills first (HTML,CSS AND JS) before I could dive into this new Framework.
• Setting up a local json-server to provide us with mock JSON response.
• Installing tailwind(Still a problem) and all other components such as Angular Material and Angular CLI.

8. API Engineer role completed by Miss KC(Kudakwashe) Chivunga u19068752

Mocked API

• Above is an attached screenshot on how the API can be called as well as what it would return in each scenario
• Below is an attached document that explains the design of the API and how it will interact with the rest of the system.
• C++ - Authorization API (1).pdf
• Joined this aspect late due to a team member dropping the module last minute, Caught up through meetings and other API engineers
• Designed and created a mock API that would aid in connecting the back-end system with the user's interests.
• Researched and used the technologies that were mentioned in the requirements tabs.
• Collected feedback on how best I could implement the API to cater for all.

What has to be done for Sprint 2

• Adjust the API as a whole if need be
• Make sure the API is connected with entire system and is functional
• Make sure technologies used are those mentioned by the client.

Problems

• Not knowing how exactly this API should look like
• Technical Issues causing me to make the API using graph ql and Apollo server but not Nest JS

Working on Problem

• Continue communicating with team members as to how best the API can be adjusted to meet the clients expectations.
• Implement the API using the technologies required

Sprint 2

• I created the API that connected to the back-end. The endpoints for the API are listed below: Authorization Endpoints.pdf.

proof of working queries from API:

9. Service Engineer role completed by Mr KM(Khotso) Bore u19180642

• Communicated and collaborated with other Service Engineers to establish the groundwork for the service layer
• Worked together with API engineer to map commands, queries and handlers to the API
• Researched CQRS pattern and how to implement it to be better prepared for working on the service layer

What has to be done for Splint 2

• Applying functionality to handlers and integrating them with the repository .
• Working with API Engineer to apply error handling, validation and providing responses.

Problems

Not having a full grasp of how handlers will interact with repository and API.

Working on Problem

Moving forward with integration the communication of different systems will be made much clearer.

Data Engineer role completed by Mr R(Raymond) Boonzaier u19014725

• Communicated with the other data-engineer to create a format for which to code in the database schema and files.
• Communicated and created the schema with the other data-engineers for the general permissions and roll permissions of the different users.
• Created mock entities to the state which permissions different users will have based on the request that they send through i.e. (Users can create stories, but can't create Admins)
• Created a mock repository to simulate getting data from a database using the basic CRUD operations.
• Created mock tests to simulate the calling of the repository functions and making sure that a desired response is received.
• Started creating mock data for the database edge cases.

What has to be done for Splint 2

• Creating a fully functional repository with all necessary CRUD operations.
• Creating tests for the repository to fully test most if not all edge cases.
• Creating and inserting all mock test data for testing purposes.

Problems

The creation of all the edge cases as to be able to fully test the implementation of the authorization feature so that no unauthorized individuals may break the system.

Working on Problem

As the implementation of the authorization feature continues most edge causes will be discovered with the communication between different groups i.e. the admin console group will need certain admin authorities and thus will need form new edge cases.

Developer-Operations role completed by Mr R(Raymond) Boonzaier u19014725

• Joined this aspect late due to a team member dropping the module, had to get caught up through the meeting ideas and seeing what the other developer operations decided to do.
• Implemented the structure of the authorization feature and pushed to github following the lint and gitmoji strategy that was decided on through the other developer operation engineers.
• Ran test to see if the mock data for the repository will function.
• Had a meeting in which was decide how errors on that will break the repository will be handled when found:

The Developer Operation team will be notified immediately that an error occurred and that the pipeline was broken. Then the main CI/CD team will work with the authorization team to see if the problem is in the repository or if it is the fault of the authorization team.

The rest of the Developer Operation team will inform their feature teams not to except pull requests while the pipeline is broken(as not to cause panic in teams who did not create the break)

If it is in the repository the CI/CD Developer Operator will communicate with the rest of their team to be able to fix the error or find the cause of the error.

If the error is on the side of the Authorization team then then the Developer-Operator (Raymond Boonzaier) and the team member whose files broke the pipeline's responsibility so fix their errors.

What will be done for Splint 2

• Continuous integration with the working aspects of the working requirements into the main developer branch.
• Creation of new file layouts if some file structure changes or new file structures are added.
• Testing the pull request code to uphold all testing requirements.
• Fixing the errors that the team may cause that will break the pipe line.

Problems

None as of yet, but the largest problem for this role will be if one of the team members break the pipeline and then having to trace down and repair the mistake.

Working on Problem

The best cause of action for this will be to work closely with the developer who cause the problem as well as to see what might have occurred and then working with the CI/CD teams to make as little impact on the rest of the feature groups.

Tester role completed by Miss PV(Phumudzo) Ndou - u19050993

• As the the collective of testers, we were able to come up with a testing plan, which includes types of tests that will be done and how they should be completed.
• We came up with a testing protocol which shows how to log the tests that will be done
• I added a test plan specific to my team to make it easier for the engineers in this team to come up with feature specific test

What will be done for Splint 2

Making sure that the actual code implementations are tested and result in a pass, before being committed to the repo If a test does fail, helping to solve the issue

Problems

The Wi-Fi in my building isn't the greatest which makes it hard to hear anything during meetings with the other testers
There was a lot of confusion with some of the testers on what was agreed upon

Working on Problem

Asking questions when there is still time