-
Notifications
You must be signed in to change notification settings - Fork 2.3k
[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
kdes-odoo
wants to merge
10
commits into
odoo:18.0
Choose a base branch
from
odoo-dev:18.0-training-kdes
base: 18.0
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
+1,590
−20
Conversation
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
deso-odoo
reviewed
Jul 11, 2025
There was a problem hiding this 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:
- Follow commit message guidelines. This tool can be helpful.
- Commit 2 and 7 are useless you should use
git commit --amend
to do such stuff. - Can you have a look at linting in all your files. I see too many linting issues.
046086f
to
657f0e2
Compare
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.
a65fa79
to
0c0cc72
Compare
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
0c0cc72
to
193a952
Compare
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
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.
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.