Enezaframework — Developer Documentation Index

Entry point for the Enezaframework developer guides. Start here, then follow the links to the topic you need.

Table of Contents

1. What Enezaframework Is
2. The Problem It Solves
3. Core Technologies
4. Architecture at a Glance
5. How a CRUD Feature Fits Together
6. Documentation Map
7. Suggested Reading Paths
8. Repository Layout
9. A Note on Testing

What Enezaframework Is

Enezaframework is a low-code framework for Django for building CRUD (Create, Read, Update, Delete) functionality in ERP-style systems. Instead of writing list, detail, create, and delete views by hand for every model, a developer:

1. Defines a model that inherits from a framework base model.
2. Declares a view that inherits from a framework base view.
3. Describes the form layout in a small configuration method.
4. Registers the view with a decorator and adds a menu entry.

The framework then supplies the generic templates, the CRUD behavior, navigation, and URL routing.

Who it is for: Django developers and coding agents building Small to Medium Enterprise (SME) business applications on top of Enezaframework.

The Problem It Solves

ERP modules are dominated by repetitive CRUD screens. Hand-writing them is slow, inconsistent, and hard to maintain across many systems and companies. Enezaframework centralizes that repetition into reusable base models and base views so developers can focus on the unique business logic — posting rules, validations, workflows — instead of boilerplate.

Expected outcome: an entity's full set of list/detail/create/delete pages, inline child editors, navigation, and URLs, produced from a model plus a small amount of configuration.

Core Technologies

Architecture at a Glance

The project is organized into three kinds of Django apps with a strict layering rule.

flowchart BT
    DJ[Django]
    EF[enezaframework<br/>base models + base views + utils]
    EC[enezacommon<br/>shared models + choices]
    BIZ[Business apps<br/>accountpayable, generalledger, inventorymanagement]

    DJ --> EF
    EF --> EC
    EF --> BIZ
    EC -. shared models .-> BIZ

• enezaframework — the heart. Base models, base views, @auto_url_register, get_registered_urls, load_icon, image fields.
• enezacommon — shared domain data (Business, Person, User) and reusable choice classes. Depends only on the framework.
• Business apps — the actual system functionality, built from the framework's building blocks.

Most records belong to an Entity (a legal company/organization), which is how the ERP separates data per tenant.

How a CRUD Feature Fits Together

Every standard feature follows the same chain, from model to menu.

flowchart LR
    MODEL[Model<br/>inherits Eneza base model] --> VIEW[View<br/>inherits Base CRUD view]
    VIEW --> LAYOUT[detail_ui_view<br/>tabs + columns]
    VIEW --> DECORATE["@auto_url_register"]
    DECORATE --> URLS[urls.py<br/>get_registered_urls]
    VIEW --> MENU[apps.py menus<br/>fast tabs + items]
    URLS --> PAGE[Rendered CRUD pages<br/>generic templates]
    MENU --> PAGE

1. Model — pick the right base (EnezaMaster, EnezaDocument, EnezaSetup, and others) and declare fields.
2. View — pick the right base (BaseListView, BaseDetailView, and others) and set model.
3. Layout — implement detail_ui_view to organize fields into tabs and columns.
4. URLs — decorate with @auto_url_register; the app's urls.py spreads *dynamic_urls into urlpatterns.
5. Navigation — add the generated URL names to the app's menus list in apps.py.

Related records (children, one-to-one extensions) are handled by inline views declared in get_inline_related_objects.

Documentation Map

The original, unsplit reference remains available at architecture.md.

CLI, deployment and release notes

For models that need address, contact, and person/organization profile data, see the Party System series — a parallel set of guides for PartyModelMixin, party types, party inlines, and migration.

For the approval engine, its workflow type registry, and query/aggregate conditions, see the Workflow series.

For automatic document numbering (CUST-0001, INV-00001) via SequenceMixin and SequenceConfig, see the Sequence Generation series.

For creating, previewing, testing, and publishing email templates, and for the meaning of workflow placeholders, see the Email Templates user and admin guide.

For Agent Assistance, the AI Workspace, provider/model/tool/agent configuration, publishing, AI Audit, AI Insights, Document Intelligence, and embedding the assistant in custom templates, see the AI Agents series. For document schemas, templates, extraction, analysis, and processing jobs, see the Document Processing guide.

AI Agents documentation

Suggested Reading Paths

Creating a new project 1. Eneza CLI Developer Guide 2. Standardized App Structure 3. Menu & Navigation Configuration 4. Docker/Coolify deployment

New to the framework 1. Framework Architecture Overview 2. Base Models & Model Types 3. CRUD Base Views 4. End-to-End CRUD Example (VendorTable)

Adding a new entity to an existing app 1. Base Models & Model Types 2. CRUD Base Views 3. Field & Inline UI Configuration 4. URL Auto-Registration 5. Menu & Navigation Configuration

Adding related/child records 1. Inline & Specialized Views 2. Field & Inline UI Configuration

Working on layout and UI 1. Frontend Templates & UI Reuse 2. Field & Inline UI Configuration 3. Model-Level Image Size Definition

Using, administering, or extending AI 1. AI Agents — Documentation Index 2. AI Agents — End User Guide 3. AI Agents — Administrator Guide 4. AI Agents — Dashboard Builder 5. AI Agents — Report Design Recommendations 6. AI Agents — Document Processing 7. AI Agents — Custom Template Integration

Repository Layout

enezaframework/          # Base models, base views, utilities (the framework)
enezacommon/             # Shared models and choices
<business apps>/         # e.g. accountpayable, generalledger
docs/Documentions/       # These developer guides
Dockerfile               # Production image
docker-compose.yml       # db, init, web, worker, periodic, optional redis
docker/                  # init/web/worker/periodic scripts
vristo-html-template/    # Base HTML design and static assets
feature_Planure/         # Feature planning documents
feature_architecture/    # Feature architecture documents
docs/Release note/       # Changelog and release notes

Inside a business app, the important pieces are models/ (one file per model, re-exported in __init__.py), views/ (one file per view group, re-exported in __init__.py), apps.py (navigation), and urls.py (aggregates generated routes). See Standardized App Structure.

A Note on Testing

Per project rules, the developer or agent does not run or claim test results. The user is solely responsible for all testing and validation of the output described in these guides.