Proteus - Role Based Access Control and Feature Modularization

Challenge Overview

• Add the role management admin pages
• Refactor the UI and API to be more modular for the feature permissions

��� 

Project background

Proteus platform targeted to achieve resource efficiency, focus on Lean process, standards and policies by assisting in automating device on-boarding and device acceptance process

More specifically, Platform designed to have integration with NMT tools in order to perform device registration and validation for given devices

 

Technology Stack

• Backend

  • Python 2.7

  • Flask

  • MySql

  • Celery + Flower + Redis

• Frontend

  • React.js

 

Individual Requirements

The code has 3 repositories:

• https://gitlab.com/tc-proteus/frontend - the front end ReactJS code

• https://gitlab.com/tc-proteus/backend - the backend Python Flask REST APIs and Celery tasks

• https://gitlab.com/tc-proteus/mockups - the dependent BCG and VAPI mockup services as well as the docker setup files. Follow the instruction in docker sub-directory to run the backend and dependent services

Implement two user types in this application: user and admin. 

• User are restricted only from the Admin link and the admin features
• Admin Role is unrestricted on all user interfaces including User ownership of Deployment Groups/Inventory Locks/Jobs.  (currently if you are not the user that defined a deployment group or a job you are restricted on some UI’s)

And admin can manage the user role permissions on these new pages: https://xd.adobe.com/view/88a714cf-7b65-4679-4a42-526387c36cd8-fe96/

• For each user role, admin can associate the groups, users and features. You need to add new db tables for them. 
• The Okta token for the user will contain the groups that the user belongs to. So after user logs in, get all the roles associated with this user as well as this user's groups. Then this user will be able to access all the features associated with all the associated roles. 
• The features list should be predefined in the application
  • You should refactor the front-end and back-end code to be more modular so that each module corresponds to a feature. 
  • If user has read-only permission for the feature, the user can only *view* the contents on the UI as well only be able to call GET apis in the corresponding module. 
    • The write related actions / buttons / UI elements should be hidden or made readonly. 
  • And if user has readwrite permission for the feature, the user can access all the contents on the UI and all apis in the corresponding module. 
  • To make the code modular according to features, you should refactor the code to make it extensible, so that it's easier for us to add or remove a new feature. 
    • A recommended approach is to make all the pages in the same module use the same base route and make all the apis used in the same module use the same base route too. Then you can implement some general handling for features based upon the base routes. 
    • Or for each feature, you can configure a list of UI routes and API routes associated with them. Note that we don't need arbitrary flexibility, only the logically related UI pages and APIs should be grouped into the same module. 
    • Note that they are only recommendations, and may not be the best approach, please investigate the existing code and setup a clean and extensible modular feature framework. 
  • For the existing application, it's expected the following features (or modules) should be defined: inventory, deployment, report validation, dashboard

Note that the existing functionalities should be kept the same. 
       

Final Submission Guidelines

Submission Deliverable

• Patch files
• Deployment and Verification Guide