OpenSPP v2.0.0 (Biliran)

OpenSPP v2 — Public Release

OpenSPP v2 is a complete social protection platform built on Odoo 19, covering the full programme lifecycle from registration and eligibility through payments, grievances, and compliance. It is designed for national and subnational deployments where data quality, privacy, and interoperability with government systems are non-negotiable requirements. The 90+ module architecture allows governments and implementing organisations to install only what they need, from a standalone farmer registry to a full SP-MIS with disaster response and case management.

---

Platform Components

Registry

The Registry is the authoritative source of record for individuals and groups — households, families, cooperatives — providing a unified data model with configurable identity documents, verification workflows, and relationship mapping. It is designed to handle the messy realities of population data at scale: overlapping group memberships, multiple ID types with varying verification confidence, and the need to expose data to officers without exposing it to everyone.

• Unified res.partner model with is_registrant / is_group flags — no separate tables for individuals vs. groups
• Privacy-by-default search interface loads zero records until a 3-character query is entered
• Four-tier RBAC (viewer, officer, manager, config admin) with hierarchical group nesting (e.g., cooperative → farm → individual)
• ID documents support regex validation per type, namespace URIs for standards compliance, and seven verification methods (DCI API, physical document, biometric, etc.)
• CEL-powered registry search compiles expressions to SQL for filtered queries at scale
• Group metric invalidation automatically triggers recomputation of household-level indicators when membership changes

---

Area Management

Area Management provides the geographic backbone of the platform — a configurable administrative boundary hierarchy that drives access control, reporting, and spatial queries across every other module. Rather than hard-coding country-specific boundary structures, it supports up to ten levels with bulk import from standard humanitarian datasets.

• Max 10-level hierarchy with parent_path indexing for efficient subtree queries
• Bulk Excel import parses COD-style column patterns (adminNName_{lang}, ADMN_PCODE) in 1,000-row job-queue batches
• HDX Common Operational Datasets integration downloads admin boundaries with official P-codes
• center_area_ids on res.users computed from role lines — drives automatic domain filtering on spp.area and res.partner
• Area tags (spp.area.tag) with unique codes enable CEL-based and report-based filtering
• PostGIS extension (via spp_gis) adds find_by_coordinates() and find_all_containing() spatial lookups

---

Security

OpenSPP's security model is built around the principle that access rules should be composable, auditable, and enforceable at the database level — not just the UI. The three-tier architecture separates technical groups, functional privileges, and optional user roles so that permissions can be granted and revoked cleanly without side effects.

• 24 ir.module.category entries organise permissions by domain (registry, programs, payments, GIS, audit, etc.)
• group_spp_admin inherits all domain manager groups; linked to base.group_system via post-init hook
• group_access_restrict_self limits field agents to their own user record
• Multi-company rule_partner_company record rule gates res.partner access by company_id
• Odoo 19 privilege system (res.groups.privilege) provides clean per-domain UI for permission assignment
• Auditor bypass group grants unrestricted registry browse for compliance staff

---

Vocabulary

Vocabulary management provides a shared semantic layer so that data from different countries, systems, and standards can be compared and combined without transformation errors. Each code list is anchored to a globally unique namespace URI, and concept groups abstract over local vs. international schemes so that business logic written once works across all deployments.

• Namespace URIs per vocabulary (e.g., urn:iso:std:iso:5218, urn:fao:icc:1.1) for unambiguous cross-system exchange
• Deployment profiles activate context-relevant codes without modifying underlying vocabularies; local extensions via is_local=True
• Concept groups enable vocabulary-aware CEL functions like is_female() and is_head()
• Vocabulary mappings transform between code systems (e.g., national disability codes ↔ DCI standard)
• System vocabularies are write-protected; only active, deprecated, and sequence fields are editable
• REST API exposes vocabularies for external system synchronisation via spp_api_v2_vocabulary

---

Farmer Registry

The Farmer Registry extends the social registry with an FAO-aligned agriculture data model, enabling governments to manage agricultural households and individual farmers within the same platform used for broader social protection. Farm classification, species tracking, and land parcel management are all natively integrated with the CEL targeting engine.

• Farm details use _inherits delegation: type, tenure, holder type (FAO WCA 2020), acreage breakdown, experience years
• Agricultural activities track crop/livestock/aquaculture with species from urn:fao:icc:1.1, urn:fao:livestock:2020, urn:fao:asfis:2024 — extensible via AGROVOC import wizard
• Season state machine (draft → active → closed) with overlap prevention and role-based access
• CEL variables include farm_size_hectares, is_smallholder (configurable threshold, default 5 ha), crop_count, total_livestock_heads, is_female_farmer
• Dedicated CR types for farm details, activities, land parcels, and assets with approval workflows
• Starter bundle (spp_starter_farmer_registry) installs social registry + GIS + programs + API in one click

---

Disability Registry

The Disability Registry implements internationally standardised disability assessment tooling — the Washington Group Short Set and the UNICEF Child Functioning Module — directly within the platform, with automated scheduling, DCI interoperability, and assistive device tracking. Assessment type selection is automatic based on the individual's age at time of assessment.

• WG-SS 4-point scale per domain; "a lot" or "cannot do" in any domain = has_disability
• Review categories: MIE (12 months), MIP (36 months), MINE (72 months) — next review date auto-computed
• Assistive device tracking with ISO 9999-aligned types and status lifecycle (needed → requested → provided)
• Six CEL functions: has_disability(), is_severe_disability(), household_has_pwd(), household_pwd_count(), disability_severity(), needs_reassessment()
• DCI data object mapping (DO.DR.01–05) with vocabularies under urn:dci:cd:dr:01 through urn:dci:cd:dr:04
• spp_dci_client_dr queries external Disability Registries with local caching, sync status, and Ed25519/RSA-256 callback verification

---

SP-MIS (Social Protection Management Information System)

SP-MIS is the full-stack deployment bundle for managing social protection programmes end-to-end. It is the recommended starting point for national deployments, combining the registry, eligibility engine, entitlements, payments, and event data collection into a single cohesive system — while retaining the modular architecture that allows components to be replaced or extended.

• Installs registry, area, security, vocabulary, consent, change requests, CEL, Studio, API, and DCI client modules in one step
• Eight pluggable manager types per programme: eligibility, deduplication, notification, programme, cycle, entitlement, payment, compliance
• CEL-based eligibility engine compiles targeting rules to SQL — configurable via Studio without code changes
• Async job queue for batch operations exceeding 200 records; cycle locking prevents concurrent processing races
• Demo module ships with 6 programmes, 12 personas, all 11 CR types in various states, and pre-activated Logic Packs
• Design targets: <100 ms single record, <500 ms search, 10k enrolments in <10 minutes

---

DRIMS (Disaster Response Inventory Management System)

DRIMS manages the full lifecycle of emergency relief supplies — from donation intake through dispatch and proof-of-delivery — linked to hazard incidents and geographic areas. It is designed for humanitarian operations where stock visibility, donor accountability, and OCHA reporting are required alongside the social protection functions of the platform.

• Donation tracking with inspection, lot/batch/expiry management, and multi-donor coordination
• Multi-tier request approval with SLA monitoring; dispatch generates waybills with proof-of-delivery tracking
• OCHA cluster integration (food security, health, WASH, shelter, etc.) with personnel directory and 4W reporting
• Stock health indicators (critical/warning/good) with configurable thresholds; automatic low-stock and expiry alerts
• KPI hybrid architecture: cheap counts as computed fields, expensive aggregates via spp.data.value with 15-minute async refresh
• Sri Lanka demo data included (spp_drims_sl, spp_drims_sl_demo)

---

Grievance Redress Mechanism (GRM)

The GRM provides a structured, auditable channel for beneficiaries and other stakeholders to raise complaints and track their resolution. It supports multi-channel intake, SLA monitoring, and escalation to case management — and is integrated with the registry and programme modules so that benefit-related grievances are handled in context.

• Auto-ticket creation from email aliases; portal at /my/tickets for beneficiary self-service
• Stage-based workflow with per-stage access control, approval requirements, and decision enforcement
• SLA auto-computed f...