Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Context:

DIGIT is API based Platform here each api is denoting to a DIGIT resource.
Access Control Service(ACS) main job is to Authorize end user based on their roles and provide access of the DIGIT platform resources.

Version:

  • V1 (Jan-2017  To Dec-2018)
  • V1.1(Jan-2019 To March 2019)


Guidelines:

  1. Mobile first - services, info, dashboard and reporting
  2. Localize - language (app, notifications, tracking, info)
  3. All-browsers and all-device compatibility
  4. UX/UI - "aam aadmi" design and not "silicon valley" design
  5. Accountability of gov employee - never compromise
  6. Standard Ontology - complaints, feedback, updates etc
  7. Should work-well in low speed / no speed networks also

Audience:

  1. Product Managers
  2. Developers
  3. Testers
  4. Co-creation partners
  5. Implementation Team
  6. Third Party(TP) integrators

Objectives:

Objective of access control service are listed as below.

...

  • Authorisation of user actions.


Functionality & Definitions :

Access control functionality basically works based on below points:

Actions: Actions are events which is performed by an user. This can be a api end-point or Frontend event. This is MDMS master

Roles: Role are assigned to user, a user can hold multiple roles. Roles are defined in MDMS masters.

Role-Action: Role actions are mapping b/w Actions and Roles. Based on Role,Action  mapping access control service identifies applicable action for role.

Feature List V1:

  • Serve the applicable actions for a user based on user role(To print menu three).
  • On each action which is performed by an user, access control look at the roles for the user and validate actions mapping with the role.

Feature List V1.1(Impacted from user changes):

  • Action authorization for multi tenant user.

  • Module tenant mapping validation based on city-tenant master data from MDMS.

Feature List V1.2(Impacted from user changes):

  1. Actions,Role,& Role-action has to be simplified.(Denormalization)
  2. Support tenant level role-action


Interaction Diagram:


Image Modified

...

Feature

...

Category

...

Why

...

Current

...

Impacted module

...

Priority

...

Remove GL codes from Billing service (faster roll out)

...

TechDebt

...

Gl codes belongs to finance system, hance finance module should own it.

...

Unnecessary data configuration for each revenue module.

...

PT, TL, Collection, Finance

...

P1

...

Move all the master to MDMS (faster roll out and audit)

...

TechDebt & Enhancement

...

PT,TL,Collection

...

P1

...

Business service should be a common master at system level, and it should have a capability of n level children

...

Enhancement

...

Collection,WF, PT, TL

...

P2

...

Roundoff of bill amount should be standardized at the platform level (Keep it to 2 decimal)

...

New Feature

...

Each revenue module is writing the logic for round off the  bill amount.

...

Each revenue module is writing the logic for round off the  bill amount.

...

PT, TL

...

P1

...

Make Income as +ve and deduction as -ve in demand (Ease the apportioning logic)

...

Enhancement

...

PT,TL,Collection,Finance

...

P1

...

Revenue module flow should be standardized at platform level for all known use-cases(A Step to apply and pay)

...

NewDesign

...

Currently Collection and Finance integrations are difficult to support,

...

Revenue module, Collection,
Finance,
Report

...

P1

...

Multiple owners in Demand so that we can generate consolidated bill for all revenue module?

...

Enhancement

...

In Future Billing Service will support
User based consolidated bill for all business service, without this it will not be possible

...

Current system takes only one owner

...

PT,TL

...

P3

...

Single api to create demand and get the bill for the same

...

Enhancement

...

Reduce multiple call to create demand and bill for all the revenue module

...

Currently each revenue module integrating with demand and bill api

...

NA

...

P3

...

First Level abstraction of calculation  

...

New / Enhancement

...

PT,TL

...

P2

...

Billing migration

...

Impacted

...

P1

...

Collection migration

...

Impacted

...

API Contract: 

Need to update the contract

https://raw.githubusercontent.com/egovernments/egov-services/master/docs/egov-accesscontrol/contracts/v1-0-1.yml

Redoc Link:

Need to update the contract

https://egov-micro-dev.egovernments.org/redoc/?api=Egov%20Accesscontrol%20V1.0.1