Reference
This is the authoritative technical reference for the Vruksha Real Estate ERP. Where the user guides explain how to perform a task, this section documents the precise rules the system enforces — the exact status values, the transitions the backend permits, the validation it applies, the conditions under which a record cannot be deleted, who is allowed to do what, and how authentication behaves.
The facts on these pages are transcribed directly from the backend enums, transition maps, validation logic, and permission guard. They are intended for power users, administrators, implementers, and support staff who need an exact answer rather than a walkthrough.
How to use this section
- Looking up an exact status name or transition? Start with Status Lifecycles. Every status enum is listed verbatim with a plain-English meaning, plus a state diagram showing which transitions the system allows.
- Need to know a field format or a business rule? See Validation Rules for formats (PAN, Aadhaar, GSTIN, percentage, currency, phone), the 100% holdings rule, optimistic locking, soft deletes, and auto-numbering.
- A record won't delete? See Delete Guardrails for the exact reference checks that block deletion and the recommended alternative (deactivate / close / cancel).
- A permission question? See RBAC Matrix for the eight organization roles, the three subproject roles, the override/merge rule, and the hard stops.
- An authentication question? See Auth Flows for signup, email verification, login lockout, password reset, invitations, and token rotation — with exact TTLs and rate limits.
Authoritative source. Status names, transitions, and limits on these pages come from the backend source code (
status.enum.ts, module transition maps,permissions.guard.ts, and the auth module). If a screen, tooltip, or informal summary disagrees with this section, the backend — and therefore this section — wins.
Reference pages
| Page | What it covers |
|---|---|
| Status Lifecycles | All 8 status enums (User, Stock, Unit, Project, Partnership, Quotation, Sales Order, Sales Invoice) with verbatim values, meanings, and Mermaid state diagrams of allowed transitions. |
| Validation Rules | Cross-cutting rules: 100% holdings + managing partner, field formats, password policy, optimistic locking (409), soft deletes, auto-numbering, multi-tenant isolation, submit-time validation. |
| Delete Guardrails | Which entities are blocked from deletion and exactly when (Party, Partner, Partnership, Stock, Project, Unit, Quotation, Sales Order, Sales Invoice), plus the recommended alternative. |
| RBAC Matrix | The override/merge model, an access matrix of 8 org roles × modules, the 3 scoped subproject roles, a decision flow, and hard stops. |
| Auth Flows | Signup → org + admin, email verification (24h), login lockout (5 / 15 min), password reset (24h, 60s cooldown, 5/hour), invitations (7-day), token rotation. |
Related reference pages
The following companion pages live in this section and complete the reference set:
| Page | What it covers |
|---|---|
| Data Security | How PII is masked, the permission-gated reveal flow, file sensitivity tiers, and what's audited. |
| Glossary | Definitions of domain terms (party, partner, partnership, holding, allocation, subproject, unit, and more). |
| Notification Catalog | The full catalog of notification types, channels, and priorities. |
| Sales Calculations | How quotation, sales order, and invoice amounts (discount, TDS, GST, totals) are computed. |
| FAQ | Frequently asked questions across modules. |
Conventions used on these pages
- Verbatim enums. Status values are shown exactly as defined in code (e.g.
IN_NEGOTIATION,PENDING_APPROVAL). Screens may display friendlier labels (e.g. "In Negotiation"), but the underlying value is what is documented here. - State diagrams. Lifecycle diagrams use Mermaid
stateDiagram-v2. An arrow means the backend permits this transition. The absence of an arrow means the transition is rejected with a validation error. - "Conceptual" transitions. Where a module does not enforce a strict transition map (for example, User and Project status), the statuses are presented and the diagram is labelled conceptual.