[ADD] estate: implement estate module (setup, models, fields, security)#1226
Draft
[ADD] estate: implement estate module (setup, models, fields, security)#1226
Conversation
Initialize the estate module by creating its base structure. This includes adding the required __init__.py and __manifest__.py files, and defining the module with its name and dependency on the base module. The purpose of this step is to register the module in Odoo so it can be detected, listed in the Apps menu, and installed for further development.
|
|
bit-odoo
reviewed
Apr 8, 2026
bit-odoo
left a comment
bit-odoo
left a comment
There was a problem hiding this comment.
Hello @sngohodoo
Good Work!
Can you please follow the git commit message guidelines?
https://www.odoo.com/documentation/19.0/contributing/development/git_guidelines.html
Thanks
sngohodoo
force-pushed
the
19.0-tutorials-sngoh
branch
3 times, most recently
from
0a4e7af to
3a25de3
Compare
The entire purpose of this application is to manage real estate, but the system first needs a central place to actually store those listings. This establishes the foundational data structure for a property. Without this core record, we have no way to save, track, or manage the houses the business wants to sell. This provides the essential blank canvas that all future features—like pricing, UI, and buyer information—will eventually attach to. Chapter: Chapter 3: Models And Basic Fields Task: Define and initialize estate.property model
Add basic fields to the estate.property model to store property details. This includes fields such as name, description, pricing, location, and property characteristics using appropriate Odoo field types. The purpose of this change is to enable structured data storage for real estate properties and prepare the model for further business logic and UI integration. Additionally, set required=True on name and expected_price to enforce data integrity and ensure these critical fields are always provided. Chapter 3: Models And Basic Fields Task: Add basic fields and set required attributes
To make the real estate application functional for internal users, explicit security permissions must be established. Odoo's default security architecture strictly restricts access to all newly created models to prevent unauthorized data exposure. By defining these baseline access rights, real estate agents and employees can actively manage the property portfolio, allowing them to freely view, create, modify, and remove listings as required for daily business operations. Chapter: Chapter 4: Security Intro Task: Define access rights using ir.model.access.csv
The __manifest__.py file contained unnecessary whitespace which could affect readability and consistency. This commit removes the extra blank spaces to keep the file clean and aligned with coding standards. Chapter: 4
Up until now, property records were only accessible from the backend database. Real estate agents need a practical workspace to actually do their jobs. This introduces the foundational navigation and screens so users can easily browse available properties, enter new listings, and manage the inventory directly through the standard interface without needing technical access. Chapter: Chapter 5: First UI Task: Menus, Actions, and Views
Refined the list and form views of the estate.property model to make the UI more structured and easier to use. Added a custom list view to display the main property fields in a clear tabular format. Updated the form view layout using sheet and group to organize fields properly. Also introduced basic UI behaviors such as readonly fields and conditional visibility using attrs, so the form reacts dynamically based on user input. Chapter: 6 (Basic Views) Task: list and form view structure with basic UI behavior
Properties don't exist in a vacuum—they need to be categorized and tied to the people involved in the transaction. Sales agents need to track their own portfolios, and the business needs to know who is buying what. Linking properties to specific contacts and internal users makes it possible to actually manage the sales pipeline. Defaulting the agent to the current user saves time during data entry, and stripping the buyer info when duplicating a listing prevents us from accidentally attaching an old buyer to a brand new property. Chapter: Chapter 7: Relations Between Models Task: Add buyer, salesperson, and property type using Many2one
Improve UI for property type model. Added a list view to display all property types instead of always opening the form view directly. Also adjusted the form view for better usability. Chapter: 7 (Relations Between Models) Task: Add buyer, salesperson, and property type using Many2one
Listings need searchable characteristics so agents can quickly find exactly what a buyer is looking for, like 'renovated' or 'cozy'. Additionally, to handle the actual sales process, we need a way to log incoming bids. Since a single property will naturally receive multiple bids over time, agents need a dedicated space within the property record to track the history, amounts, and status of every offer made during negotiations. Chapter: Chapter 7: Relations Between Models Task: Add tags (Many2many) and offers (One2many)
Buyers and agents need to know the total footprint of a property at a glance. Instead of forcing sales agents to pull out a calculator to manually add the living and garden areas together—which is annoying and leaves room for typos—the system now handles the math automatically. This guarantees the total area displayed on the listing is always completely accurate without requiring any extra data entry. Chapter: Chapter 8: Computed Fields And Onchanges Task: Add computed fields
To provide maximum flexibility during property negotiations, sales agents need the ability to define an offer's expiration either by a specific calendar date or a set number of days. By bidirectionally synchronizing the validity duration with the hard deadline date, the system prevents manual calculation errors and ensures agents can seamlessly negotiate using whichever metric the buyer prefers. This guarantees data consistency across the offer records regardless of which field the user manipulates on the interface. Chapter: Chapter 8: Computed Fields And Onchanges Task: [Insert Task Number]
sngohodoo
force-pushed
the
19.0-tutorials-sngoh
branch
from
3a25de3 to
838709c
Compare
Resolving these minor whitespace infractions prevents automated CI checks from flagging the branch and blocking future merges. Chapter: Chapter 8: Computed Fields And Onchanges
Real estate agents need a fast, reliable way to move listings through the sales lifecycle without manually updating every single status field. By introducing dedicated actions to handle bids, agents can instantly accept or reject offers with a single click. Automatically locking in the buyer and the final sale price upon offer acceptance eliminates repetitive data entry, prevents manual mistakes, and ensures the property record instantly reflects the finalized deal. Chapter: Chapter 9: Ready For Some Action? Task: Add actions to manage property status and process offers
The previous logic crashed if an agent tried to accept or reject multiple offers from the list view at the same time. This ensures bulk actions work without errors. It also ensures the main property's overall status updates when an offer is processed so the listing accurately reflects the current state of the sale. Chapter: Chapter 9: Ready For Some Action? Task: Fix batch processing and sync property state
Agents shouldn't be able to accidentally save a property or an offer with a negative price, as that makes no business sense and would mess up our reporting. We also need to stop duplicate property tags from cluttering up the search filters. Locking these rules down directly in the database guarantees our data stays clean no matter how the records are created. Chapter: Chapter 10: Constraints Task: Add SQL constraints for prices and tags
To protect the agency's profit margins, we need to ensure agents aren't accepting offers that are drastically below market value. This adds a strict business rule that prevents any property from being sold for less than 90% of its expected price. This catches typos during fast-paced negotiations and automatically stops bad deals from being approved in the system. Chapter: Chapter 10: Constraints Task: Add Python constraint for expected and selling price
Keeping the codebase tidy makes it much easier for the team to maintain. This removes leftover dead code to reduce clutter and adjusts the constraint logic to strictly match the standard coding guidelines. It also fixes an invalid attribute in the list view so the UI labels actually display correctly to the users without throwing background warnings. Chapter: Chapter 10: Constraints
bit-odoo
reviewed
Apr 22, 2026
bit-odoo
left a comment
bit-odoo
left a comment
There was a problem hiding this comment.
Hello
I have added some more comments.
You haven't applied any changes that I suggested to you in a previous comment.
Thanks
sngohodoo
force-pushed
the
19.0-tutorials-sngoh
branch
3 times, most recently
from
04827cf to
0fa25da
Compare
A fast-paced sales environment requires an interface that is visually intuitive and minimizes unnecessary clicks. This update introduces color-coded list views so agents can instantly assess the status of properties and offers at a glance. Small records like tags and bids are now directly editable in the list to speed up data entry. Finally, the search logic now defaults to 'Available' properties and evaluates living areas as a minimum size requirement, perfectly matching how real buyers actually search for homes. Chapter: Chapter 11: Add The Sprinkles Task: Add view attributes, UI decorations, and search defaults
Code needs to be clean and stable before we add more features. This patches a few minor errors that were causing test failures and reformats the logic to strictly follow standard coding guidelines. This keeps the files easy to read for the rest of the team and ensures the module runs smoothly without throwing unexpected background errors. Chapter: Chapter 11: Add The Sprinkles Task: Fix minor errors and code styling
Sales managers and agents need to instantly see their assigned properties directly from their user profiles without constantly navigating back and forth across different apps. By extending Odoo's built-in user model and views, we seamlessly tie the real estate application into the core system to streamline the agent's daily workflow. Additionally, this incorporates recent PR feedback to improve overall readability and ensure strict adherence to Odoo's standard coding guidelines. This guarantees the codebase remains clean, predictable, and easy for the team to maintain as the module grows. Chapter: Chapter 12: Inheritance Task: Extend user model, inherit views, and apply PR feedback
Agencies need to bill clients the moment a property is sold. Instead of forcing agents to manually enter data into the Accounting app, this new module bridges the gap. Now, marking a property as 'Sold' automatically generates a draft invoice with administrative fees. This prevents forgotten bills and completely eliminates double data entry for the team. Chapter: Chapter 13: Interact With Other Modules Task: Create estate_account module to automate invoicing
sngohodoo
force-pushed
the
19.0-tutorials-sngoh
branch
from
0fa25da to
a232e82
Compare
Agents need a more visual way to track their real estate portfolio at a glance. Standard list views can be too dense for quick scanning. By introducing a card-based Kanban board, the team can now view properties grouped by type, with tags and dynamically displayed prices based on the property's current state. This provides a much cleaner, pipeline-style overview, making daily property management significantly more intuitive. Chapter: Chapter 14: A Brief History Of QWeb Task: Add property kanban view and conditional field display
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
[IMP] estate: add visual kanban view for properties
Agents need a more visual way to track their real estate portfolio at a
glance. Standard list views can be too dense for quick scanning. By
introducing a card-based Kanban board, the team can now view properties
grouped by type, with tags and dynamically displayed prices based on the
property's current state. This provides a much cleaner, pipeline-style
overview, making daily property management significantly more intuitive.
Chapter: Chapter 14: A Brief History Of QWeb
Task: Add property kanban view and conditional field display