OpenSPP v2 - 2026.07

OpenSPP July 2026 Release

OpenSPP v2.1.0 is the first feature release since the v2.0.0 public release, spanning 786 commits and over 90 merged pull requests. It introduces geofence-based geographic targeting, a redesigned change-request experience for group and membership management, internationally standardised child disability assessments, and full Social Registry interoperability over the DCI protocol — alongside a systematic performance campaign on the program engine and a security-hardening pass covering menus, record rules, and every externally reachable API surface.

---

Highlights

Geographic Targeting with Geofences

Programs can now target beneficiaries by drawing or importing geographic boundaries, independent of the administrative area hierarchy. The new spp_program_geofence module resolves eligibility with a two-tier strategy — precise coordinate intersection where GPS data exists, area-intersection fallback where it doesn't — and is fully integrated into program configuration and the program creation wizard.

• Two-tier resolution: Tier 1 coordinate intersection for registrants with GPS locations, Tier 2 area-intersection fallback
• New spp.gis.geofence.tag model replaces vocabulary-based geofence tags; existing tag links are remapped automatically on upgrade
• Spatial operators now support MultiPolygon and GeometryCollection geometries, including distance buffering
• Map renderer and edit widgets fall back to OSM styles when no MapTiler API key is configured
• Geofence GeoJSON output includes the record UUID as the feature id for stable external references

Metric Disaggregation in GIS Reports

GIS reports can now break metrics down by demographic dimensions — gender, age, disability, or any configured dimension — computed in SQL for performance at scale. Choropleth outputs and the GeoJSON API expose the disaggregated values directly.

• Configurable breakdown dimensions (dimension_ids) replace the fixed gender/age/disability booleans, with an automatic migration for existing report configurations
• spp_metric_service gains demographic breakdown expansion with SQL column support; expansion is all-or-nothing — any individuals-scoped dimension expands the whole registrant set to active members
• spp_cel_domain compiles CEL ternary expressions to SQL CASE via to_sql_case, with a right-associative ternary parsing fix
• Smart-operator label lookup during expression compilation is now read-only — it never creates vocabulary records or uses sudo()

Change Requests, Redesigned

The group and membership change-request flows were rebuilt end-to-end around how field officers actually work (#242). Review pages now render the real data as tables and detail sections instead of raw form fields.

• Create Group no longer requires a pre-existing registrant; Add Member searches for an existing individual instead of creating one inline; Remove Member first-page and review pages were cleaned up; Change Head of Household uses a per-member role table; Split Household is a relational member move with single-head validation
• Split Household captures the new household's address and latitude/longitude with an interactive OSM map picker — coordinates and map stay in sync, out-of-range values are rejected
• Post-submit change requests (pending / approved / applied / rejected) open in the stage review form from list views, matching the Edit Details → Upload Documents → Review & Submit workflow
• New spp_cr_type_assign_program module: an assign_program CR type that creates a draft program membership on apply, with live program-domain filtering and duplicate-assignment conflict blocking
• CR document types are selected from the vocabulary (inline creation disabled), and the demo generator seeds country-appropriate document types

Disability Registry

The disability registry now covers children as well as adults, with automatic instrument selection and a configurable approval workflow — completing the assessment lifecycle from questionnaire to registry status.

• UNICEF Child Functioning Module questionnaires for ages 2–4 and 5–17, alongside the Washington Group Short Set
• Age-driven assessment type selection with manual override
• Configurable assessment approval workflow; approved assessments are recognised in the registry
• Impairment classification on its own multi-row tab; improved assistive-device management and proxy response by assessment type
• New spp_starter_disability_registry bundle installs registry, API, change requests, and disability assessment in one click (no DCI)
• Removed the misleading "No Disability" status smart button from the registrant form — full status lives on the Disability tab

DCI Social Registry Interoperability

OpenSPP now implements both sides of the DCI Social Registry integration, allowing it to serve beneficiary data to other systems and query external Social Registries — with results feeding directly into CEL eligibility expressions.

• spp_dci_server_social exposes Social Registry beneficiaries via the DCI API with sender registry, subscription, and transaction tracking
• spp_dci_client_sr queries external Social Registries with local caching and sync status
• spp_dci_indicators integrates DCI-sourced data into CEL eligibility expressions
• spp_dci_compliance and spp_dci_client_compliance provide an SPDCI protocol compliance test suite (test-only, disabled by default)
• The Disability Registry client now parses the DCI v1.0.0 spec envelope and record fields

Performance at Scale

A sustained optimisation campaign on the program engine and registry, targeting national-scale datasets. Enrolment, entitlement generation, and payment batching were reworked from per-record ORM operations to set-based SQL.

• Bulk membership creation via INSERT … ON CONFLICT DO NOTHING; batch creation of entitlements and payments; fund balance fetched once per approval batch
• OFFSET pagination replaced with NTILE-based ID-range batching in all async job dispatchers
• Python-level uniqueness checks replaced with SQL UNIQUE constraints (with a deduplicating pre-migration); composite indexes added for frequent query patterns
• Cycle computed fields (totals, counts, approval flags) replaced with SQL aggregation
• Job queue: parallel-safe channel limits raised from 1 to 4, serial channels for entitlement approval and statistics refresh, identity keys prevent duplicate submission on double-click
• Context flags skip expensive statistics recomputation during bulk operations, with one-shot refresh methods afterwards
• Registry search optimised for large datasets with split queries and trigram indexes
• spp_audit skips full-record snapshot reads when no audit rule matches, and a new audit_disable context key lets trusted machine flows (e.g. cross-instance replication) bypass audit logging
• Stuck cycle/program locks are released when an async pipeline fails

Security & Access Control

A dedicated hardening pass on every externally reachable surface, plus a systematic menu and record-rule audit (OP#951, OP#989) enforcing role-based visibility at the database level.

• DCI/external APIs: external predicate symbols (fields and metrics) are allowlisted; sensitive parameterised metrics are denied in external searches; the Data API pull is restricted to non-sensitive provider variables; notification delivery is scoped per subscriber with consent and filter checks; unresolved search senders fail closed and page size is capped; DCI sync and cached value access are restricted; the Studio variable-values endpoint is allowlisted
• Area-based access control is now enforced with global ir.rule records — covering registrants, change requests, and program/cycle memberships — closing gaps where name_search, search_count, read_group, and related-field traversal bypassed earlier Python-level filters
• Menu audit: top-level menus for Registry, Hazard, GIS Reports, Helpdesk (GRM), Studio, and Apps are gated by role groups, with role definitions updated across all affected modules
• Program membership ACL bypass closed, along with approval/payment bugs
• Stored XSS prevented by HTML-escaping all computed Html fields with sanitize=False
• Registry Search "New Individual/Group" buttons are gated on registry create-permission roles
• User roles: removed a default that copied role lines from arbitrary users; role-backing groups excluded from the Groups dropdown; assigning groups to a new role works in a single save

REST API v2

The OpenAPI contract is now complete enough for external consumers to work from the document alone — polymorphic bodies are fully described and authentication is discoverable.

• Polymorphic schema utilities inject oneOf schemas for dict-typed fields; registrant-serving endpoints document bundle entries as Individual/Group bodies
• The auth middleware advertises an OAuth2 client-credentials scheme with an absolutised token URL, so Swagger UI, QGIS, and other strict clients can discover how to authenticate
• OpenAPI contract tests cover bundle schema rendering and the overall document
• Concurrent endpoint sync across workers is serialised with a Postgres advisory lock, fixing SerializationFailure races after -u all
• Program and program-membership endpoints split into the spp_api_v2_programs companion module

Modular Architecture

spp_programs is no longer a hard dependency of the core API, Studio, audit, or source-tracking modules (#1080). Registry-only deployments get a leaner install; full deployments are unaffected because the companion modules install automatically when both parents are present.

• spp_api_v2_programs — program REST endpoints
• spp_audit_programs — program/cycle audit rules
• spp_source_tracking_programs — source tracking for program memberships
• `spp_studio_prog...

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...