Skip to content

[ADD] estate: added a new Estate Module #844

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 10 commits into
base: 18.0
Choose a base branch
from

Conversation

kdes-odoo
Copy link

@kdes-odoo kdes-odoo commented Jul 9, 2025

An Odoo real estate module, created by following Odoo's tutorials, is a
specialized application designed to streamline property management within the
Odoo platform. This module provides a centralized system for managing property
listings, including key details like property type, price, and location. It
allows users to efficiently track property offers, manage their status, and
oversee the entire sales process from initial offer to final sale. Additionally,
the module helps in organizing property types and tags for better categorization
and searching, while also managing real estate agents and their associated
properties. By leveraging Odoo's integrated framework, this module offers a
practical, hands-on introduction to building business applications,
demonstrating how to create models, design views, and implement business logic
specific to the real estate industry.

@robodoo
Copy link

robodoo commented Jul 9, 2025

Pull request status dashboard

@kdes-odoo kdes-odoo marked this pull request as ready for review July 9, 2025 09:56
@kdes-odoo kdes-odoo marked this pull request as draft July 9, 2025 09:59
Copy link

@deso-odoo deso-odoo left a comment

Choose a reason for hiding this comment

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

Here is the review!

Some comments:

  1. Follow commit message guidelines. This tool can be helpful.
  2. Commit 2 and 7 are useless you should use git commit --amend to do such stuff.
  3. Can you have a look at linting in all your files. I see too many linting issues.

@kdes-odoo kdes-odoo force-pushed the 18.0-training-kdes branch 12 times, most recently from 046086f to 657f0e2 Compare July 14, 2025 09:27
Created a new 'estate' module as per Chapters 2 and 3. Defined the module
structure, added the business object 'estate.property' in a Python class, and
configured the __manifest__.py and __init__.py to make the app visible in the
 apps page.
Applied the security access to base users group using CSV.
Started working on UI:
Create the estate_property_views.xml file in the Views folder
Created an action for the model estate.property.
Created the estate_menus.xml
Created the three levels of menus for the estate.property

Added the appropriate default attributes so that:
the default number of bedrooms is 2
the default availability date is in 3 months

Added active and state field.

Defined a custom list view for the estate.property
Defined a custom form view for the estate.property
Defined a custom search view for the estate.property
Added Property type model, created view and added it to menu

Added filed to Buyer and salesperson field to property model

Added Property tag model, created view and added it to menu

Created many2many relation between property tags and property model

Added Property offer model, created view and added property form page.

Added the total_area field to estate.property. It is defined as the sum of
 the living_area and the garden_area.

Added the best_price field to estate.property. It is defined as the highest
 (i.e. maximum) of the offers’ price.

Added validity and date_deadline to property offer

Defined inverse function so that the user can set either the date or the
validity.

Created an onchange in the estate.property model in order to set values for the
garden area (10) and orientation (North) when garden is set to True. When unset,
clear the fields.

Added the buttons ‘Cancel’ and ‘Sold’ to the estate.property model. A cancelled
property cannot be set as sold, and a sold property cannot be cancelled.

Added the buttons ‘Accept’ and ‘Refuse’ to the estate.property.offer model.

When an offer is accepted, set the buyer and the selling price for the
 corresponding property.
@kdes-odoo kdes-odoo force-pushed the 18.0-training-kdes branch 8 times, most recently from a65fa79 to 0c0cc72 Compare July 16, 2025 08:04
Added the following constraints to their corresponding models:
A property expected price must be strictly positive
A property selling price must be positive
An offer price must be strictly positive
A property tag name and property type name must be unique

Added a python constraint so that the selling price cannot be lower than
90% of the expected price.

Used the statusbar widget in order to display the state of the estate.property

Added ordering to each model as per requirement.

Added manual ordering to property type field.

Added widget options to color the tag.

Added conditional display of buttons Using the invisible attribute

Made property tag and offers list view editable

Made the field date_availability on the estate.property list view optional and
hidden by default

Added conditional decoration to property and offer list view.

Added availability to the default search filter

Added a stat button to the property type to view offers for each property.
Added Kanban View to the property page

Added automated invoicing for the sold property

added user types in module defined in user defination
Managers could see all properties

Salesperson could see properties assigned to them
and those which are not assigned to any user

User can only view properties that belongs to their company

added default demo data for property type and property
added report generation feature for the properties

added property details in report
and added offers to the report

added demo data for ease

commented out last demo data files in manifest file
as it was causing replication issues
@kdes-odoo kdes-odoo force-pushed the 18.0-training-kdes branch from 0c0cc72 to 193a952 Compare July 16, 2025 08:08
Implemented basic Counter component with useState and increment method

Extracted Counter as reusable sub-component with own template and files

Created Card component with title and content props, styled with Bootstrap

Enabled rendering of safe HTML content using t-out and markup function

Added props validation for Card and Counter components

Implemented parent-child communication: Counter triggers onChange callback to
update Playground sum

Built TodoList and TodoItem components with hardcoded todos and t-foreach
 rendering

Added dynamic classes to TodoItem based on isCompleted state

Enabled adding todos via input and keyup event with unique IDs
Used t-ref and useRef with onMounted to autofocus input, extracted useAutofocus
hook

 Implemented toggling todo completion state with callback prop toggleState

Added removeTodo callback and delete functionality in TodoItem with click
handler

Refactored Card component to use slots for arbitrary content, including nested
components

Added toggle button to Card to show/hide content with local state and
conditional rendering
… charts

Integrated  component from @web/search/layout for consistent UI
structure

Applied  class with custom background via new

Added control panel buttons for:
Navigating to Customers via action XML ID
Navigating to Leads via dynamic CRM model action

Created reusable  component with optional  prop for
flexible layout
Used  to fetch data from
Displayed key metrics: new orders, total amount, avg t-shirt/order, cancelled
orders, avg processing time
Created a persistent  service using
 for cached data loading
Updated Dashboard to consume statistics service with  and reactive
 state
Added  component with lazy-loaded Chart.js to visualize t-shirt sales
 by size
Enabled auto-refresh of statistics every 10s (simulating real-time data)
Used a shared reactive object in the service for live updates in Dashboard
Update statistics service to reload data reactively every 10 seconds
(for testing)

Use reactive object for statistics to enable live dashboard updates

Modify Dashboard component to consume reactive statistics via useState

Implement lazy loading of dashboard assets and component using LazyComponent and
asset bundles

Refactor dashboard to be generic, rendering dashboard items dynamically from a
registry

Create NumberCard and PieChartCard components for dashboard items

Register dashboard items in awesome_dashboard registry for easy extensibility

Add dashboard customization UI with a settings dialog and checkboxes for
enabling/disabling items

Persist user dashboard configuration in localStorage to maintain preferences
across sessions

Filter dashboard items displayed based on user configuration
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