PRP
  • PRP Documentation
  • Introduction
    • Glossary / Terminology
    • Indicators
      • Disaggregations
      • Calculating progress
    • FAQ
    • Releases / Changelog*
    • Report an Issue / Contact us
  • Product / End-user Documentation
    • IP Reporting
      • Overview
      • Partner roles and permissions
      • User Interface
      • Setting calculation methods for indicators
      • Progress Reports
        • Reporting Overview
        • Special Reports (SR)
        • Humanitarian Reports (HR)
        • Quarterly Progress Reports (QPR)
        • Reporting Process
        • Data Uploader for QPR and HR
      • Various data exports
    • Cluster Reporting
      • Overview
      • User Authentication, Roles and permissions
      • AD Integration
      • Response Plans
      • Cluster Indicators
      • Response Plan Dashboard
      • Response Parameters setup
      • Planning your action as a Partner
      • Reporting on results
        • Reporting to UNICEF
      • Analysis of results
      • OCHA Integration
    • ID Management
      • Overview
      • AD Integration & Sign In
      • Email Notifications
      • User Statuses
      • Permissions
      • IP ID Management
        • User Interface
        • Users screen
      • Cluster ID Management
        • User Interface
        • Users screen
        • Partners screen
  • Technical Documentation
    • Architecture
    • Development Setup
    • Deployment / DevOps
    • Data Model
    • API Documentation
      • Error Handling
    • CartoDB location sync
    • OCHA Integration - Research Summary
      • Response Plan Import
      • Project Import
    • ID Management
      • Backend API's
    • Handover session question
Powered by GitBook
On this page
  1. Technical Documentation

ID Management

PreviousProject ImportNextBackend API's

Last updated 6 years ago

ID management in PRP should be its own application id_management.

The primary data model relationships that supports ID management in PRP is depicted below. The User model is associated with one Partner instance (none in case of an internal user). Additionally there is a One To Many relationship from the User model to a new model called PRPRole. This represents a unique role this user has in the context of a Workspace (used for IP) or a Cluster (used for Cluster).

The backend API's are written with the help of Django REST Framework like the rest of PRP. The frontend however is its own service, written as a Single Page Application (SPA).

React
Data model to support ID management