❓Problem Statement

We’re in the midst of evolving our Society Management Panel, which today is tightly bound to an Apartment → Block → Floor → Flat hierarchy. ****At its core, every building, every unit and every filter assumes that four-tier structure—so much so that our database tables, API endpoints, and even the smallest dropdown in the UI all expect floors and blocks to exist.

In reality, many communities consist of standalone houses that have no concept of floors or blocks. While apartments nest neatly into blocks and floors, houses sit on single plots of land, each with its own address but no sub-levels. This mismatch means that when a housing-only or mixed community is loaded into our panel, floor and block fields break, filters show empty options, and reports either omit houses entirely or display confusing “n/a” entries.

🎯 Objectives

• Support Apartment-only, Housing-only, and Mixed (Apartment & Housing) use cases.
• Define a flexible data model that accommodates different property hierarchies.
• Revise filtering, data representation, and UI flows accordingly.
• Ensure backward compatibility with existing apartment-only functionality.

<aside> 💡

Main Problem :

</aside>

• Current Usecase Scenario Screenshots

1. Detailed Analysis of Current State & Challenges

1.1. Current Hierarchy & Assumptions:

• Top-Level: Society/Community (e.g., "Hane - Johnson Apartment"). This seems to be the entry point for managing a community.
• Implied Structure: Community contains Blocks, Blocks contain Floors, Floors contain Flats.
• Core Unit: The Flat is the fundamental unit for residents, occupancy, and potentially billing.
• Database Schema (Inferred):
  • Societies (or Communities) table.
  • Blocks table (linked to Societies).
  • Floors table (linked to Blocks).
  • Flats table (linked to Floors).
  • Residents table (likely linked directly to Flats).
  • Other modules (Billing, Complaints, Amenities) likely have direct or indirect links to Flats or Residents.
• API Endpoints (Inferred): Endpoints like /blocks, /floors/{blockId}/flats, /residents/{flatId} would exist.

Data Representation Examples

Apartment Example

{
  "property": "Green Towers",
  "type": "apartment",
  "block": "A",
  "floor": 3,
  "unit": "302"
}

Housing Example

{
  "property": "Maple Residency",
  "type": "house",
  "house": "H-12"
}

ddddd