[ADD] estate: implement estate module (setup, models, fields, security)#1226
[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
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
estate/security/ir.model.access.csv
Outdated
| @@ -0,0 +1,3 @@ | |||
| id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink | |||
| access_estate_property,access_estate_property,model_estate_property,base.group_user,1,1,1,1 | |||
| access_estate_property_type,access_estate_property_type,model_estate_property_type,base.group_user,1,1,1,1 No newline at end of file | |||
There was a problem hiding this comment.
should be one empty line at the end of the file.
| <menuitem id="property_types" action="estate_property_type_action" /> | ||
| </menuitem> | ||
| </menuitem> | ||
| </odoo> No newline at end of file |
There was a problem hiding this comment.
should be one empty line at the end of the file.
| <field name="view_mode">form</field> | ||
| </record> | ||
|
|
||
| </odoo> No newline at end of file |
There was a problem hiding this comment.
should be one empty line at the end of the file.
| </search> | ||
| </field> | ||
| </record> | ||
| </odoo> No newline at end of file |
There was a problem hiding this comment.
should be one empty line at the end of the file.
| </form> | ||
| </field> | ||
| </record> | ||
| <record id="estate_property_view_search" model="ir.ui.view"> |
There was a problem hiding this comment.
It is good to have one empty line before it.
| </list> | ||
| </field> | ||
| </record> | ||
| <record id="estate_property_view_form" model="ir.ui.view"> |
There was a problem hiding this comment.
It is good to have one empty line before it.
| <field name="res_model">estate.property</field> | ||
| <field name="view_mode">list,form</field> | ||
| </record> | ||
| <record id="estate_property_view_list" model="ir.ui.view"> |
There was a problem hiding this comment.
It is good to have one empty line before it.
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]
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

This PR introduces the initial implementation of the estate module following the Odoo tutorials.
The following features have been implemented:
This work establishes the foundation for managing real estate properties within Odoo.
Chapter: 1, 2, 3, 4
Task: Setup environment, create module, define models, add fields, and implement security access