Skip to content

[ADD] estate: implement estate module (setup, models, fields, security)#1226

Draft
sngohodoo wants to merge 14 commits intoodoo:19.0from
odoo-dev:19.0-tutorials-sngoh
Draft

[ADD] estate: implement estate module (setup, models, fields, security)#1226
sngohodoo wants to merge 14 commits intoodoo:19.0from
odoo-dev:19.0-tutorials-sngoh

Conversation

@sngohodoo
Copy link
Copy Markdown

This PR introduces the initial implementation of the estate module following the Odoo tutorials.

The following features have been implemented:

  • Development environment setup and configuration
  • Creation of the estate module structure
  • Definition of the estate.property model
  • Implementation of basic fields
  • Addition of required attributes on fields
  • Creation of access control rules for the module

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

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.
@robodoo
Copy link
Copy Markdown

robodoo commented Apr 3, 2026

Pull request status dashboard

Copy link
Copy Markdown

@bit-odoo bit-odoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unneccary diff.

@@ -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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be one empty line at the end of the file.

</search>
</field>
</record>
</odoo> No newline at end of file
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be one empty line at the end of the file.

</form>
</field>
</record>
<record id="estate_property_view_search" model="ir.ui.view">
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is good to have one empty line before it.

</list>
</field>
</record>
<record id="estate_property_view_form" model="ir.ui.view">
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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">
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is good to have one empty line before it.

@sngohodoo sngohodoo force-pushed the 19.0-tutorials-sngoh branch 3 times, most recently from 0a4e7af to 3a25de3 Compare April 9, 2026 17:30
sngohodoo added 11 commits April 9, 2026 23:06
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 sngohodoo force-pushed the 19.0-tutorials-sngoh branch from 3a25de3 to 838709c Compare April 9, 2026 17:37
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants