19.0 tutorials- Server framework 101 ( PIKRI ) - #1355
Draft
Piyush11204 wants to merge 27 commits into
Draft
Conversation
The estate busniess has huge number of data thats needs to be manage and track. here we are creating an platfrom to mange the Real estate busniess This provides the base structure of the model. Chapter: 2
A real estate business needs to manage and track a large amount of property information in a structured way. Introduce the property model for storing and managing real estate data. This provides the base structure required to build the property management workflow. Chapter: 3
|
|
Consistent coding conventions make the estate module easier to read, review, and maintain as its functionality grows. Resolve the reported linting issues to keep the implementation aligned with the expected coding standards by the odoo runbot. Chapter: 3
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
July 3, 2026 06:36
410170f to
4bea8f1
Compare
The estate module should remain free of linting violations to ensure that new changes comply with the project's code quality requirements. Resolve the remaining reported lint errors so that the affected code passes the expected checks without changing its functional behavior. Chapter: 3
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
July 3, 2026 08:56
51ea9f3 to
99f7eb7
Compare
Add access control rules for the estate property model to define the required permissions for creating, reading, updating, and deleting property records. This makes the model accessible through the application while following Odoo's model security mechanism. Chapter: 4
The security configuration needs to follow the expected conventions to ensure access rights are defined consistently and pass the required validation checks. Correct the reported issues in the estate security file while preserving the intended access permissions and functional behavior. Chapter: 4
Standerd spacing keeps the estate module readable and prevents style violations errors from the odoo runbot. Correct the affected formatting to follow the expected coding conventions without changing the module's functional behavior. Chapter: 4
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
July 3, 2026 12:06
58a5db4 to
f8a252c
Compare
Property records need a user interface so users can access and manage real estate data without interacting directly with the underlying model. Added the required property views and menu entries for the property records through the estate application Chapter: 5
New property records should start with some default values to reduce repetitive input and ensure consistent initialization. Added the default bedroom count and availability date computation so that newly created properties receive the expected values automatically. Chapter: 5
As property records contain more information, users need a structured form and efficient search options to navigate and manage them easily. Improve the property form layout to organize related information and add search filters to help users quickly narrow down properties based on relevant criteria. Chapter: 6
Users need a convenient way to identify higher-priced properties without manually reviewing individual records or repeatedly applying the same price criteria. Add a dedicated search filter for expensive properties so that users can quickly narrow the property list to records matching the defined price threshold. Chapter: 6
Add property type and property tag models to provide structured classification of estate properties. Integrate the new relational fields into the property model and enhance the property form so users can assign types and tags while managing property records. Chapter: 7
The estate module needs to comply with the expected coding standards to pass Runbot validation. Resolve the reported linting issues so that the module passes the automated checks without affecting its functional behavior.
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
2 times, most recently
from
July 9, 2026 12:13
8ce52d1 to
24e0f40
Compare
Properties receive multiple offers from multiple buyers, so each proposal needs to be tracked independently. Added the property offer model and link it to the property model. This allows multiple offers to be managed separately while keeping them accessible from their corresponding property record. Chapter: 7
An offer belongs to the property for which it was originally created and should not be reassigned afterward, as this could associate the offer with an unrelated property. Make the property relation readonly to preserve the association between a property and its offers throughout the offer lifecycle. Chapter: 7
bit-odoo
reviewed
Jul 20, 2026
bit-odoo
left a comment
bit-odoo
left a comment
There was a problem hiding this comment.
Hello @Piyush11204
Good Start!
First, can you please improve all your commit titles and add the message as well?
And you have left many unneccary empty lines.
Also, improve the PR title and description.
Thanks
| date_availability = fields.Date( | ||
| copy=False, default=lambda self: fields.Date.add(fields.Date.today(), months=3) | ||
| ) | ||
|
|
|
|
||
| expected_price = fields.Float(required=True) | ||
| selling_price = fields.Float(readonly=True, copy=False) | ||
|
|
| bedrooms = fields.Integer(default=2) | ||
| living_area = fields.Integer() | ||
| facades = fields.Integer() | ||
|
|
| garage = fields.Boolean() | ||
| garden = fields.Boolean() | ||
| garden_area = fields.Integer() | ||
|
|
| <field name="name">Property Tags</field> | ||
| <field name="res_model">estate.property.tag</field> | ||
| <field name="view_mode">list,form</field> | ||
|
|
Comment on lines
+53
to
+55
|
|
||
|
|
||
|
|
Inconsistent formatting introduces unnecessary issues in the code reviews and makes the estate module harder to read and maintain. here we removed the unnecessay whitespace and formatting across the property and offer models, menus, and views to keep the implementation consistent with the expected coding conventions. Chapter: 7
Piyush11204
changed the title
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
3 times, most recently
from
July 21, 2026 08:58
912875e to
3897a20
Compare
Author
Hello Sir, Thank you for reviewing my PR. I have fixed all the changes you suggested
Thank you. |
Piyush11204
added a commit
to odoo-dev/tutorials
that referenced
this pull request
Jul 21, 2026
Clean up unnecessary whitespace and improve formatting across the property and offer models, menus, and views. This refactoring improves code readability and consistency without changing any existing functionality or behavior. Related PR: odoo#1355 Signed-off-by: Piyush Yadav<pikri@odoo.com>
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
2 times, most recently
from
July 24, 2026 07:39
8d9d8f9 to
53b1939
Compare
To maintain the Strcture of the offer form and make sure to follow the UI consistency in this model Added the missing offer form view while keeping the property field hidden, as offers are managed directly from their related property. Chapter: 7
Always invisible fields need an explicit explanation in the view so that their purpose is clear and the view passes the corresponding validation checks. Document why the property relation is intentionally kept invisible in the offer form without changing its existing behavior. Chapter: 7
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
July 24, 2026 12:58
c9b782a to
b0df03f
Compare
The offer form needs to keep the property relation hidden while making its purpose explicit for view validation. This keeps the existing offer behavior unchanged while satisfying the expected view conventions. Chapter: 7
Properties store the living and garden areas separately, requiring users to manually calculate the total area for each property. here we computing the total area automatically and remove the need for manual calculations and ensures the displayed value always remains consistent. Chapter: 8
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
July 28, 2026 10:28
b9d1ff3 to
1c376a8
Compare
Clean up style issues reported by the linter in the computed field implementation. Improve code consistency and comply with the project's coding standards without changing the existing behavior. Chapter: 8
TO get the highest offer amount for each property to provide a quick overview of its current best offer without requiring users to check every related offer manually By calculating the highest offer directly on the property, important pricing information becomes immediately available Chapter: 8
Offers need a consistent way to determine their expiration date while allowing users to modify either the validity period or the deadline. Compute the deadline from the offer creation date and validity period, and implement the inverse computation so that changing the deadline automatically updates the corresponding validity. Chapter: 8
The validity period and deadline represent the same perpuse information from different perspectives. They should remain consistent regardless of which value users choose to edit. Compute the deadline from the offer creation date and validity period, and provide an inverse computation so that changing the deadline automatically updates the corresponding validity. Also clean up the property offer xml formatting to keep the file consistent with the expected coding conventions without changing its existing behavior. Chapter: 8
Piyush11204
force-pushed
the
19-tutorial-pikri
branch
from
August 3, 2026 09:38
7efaee9 to
a2e8f28
Compare
Property information should stay consistent while reducing manual updates. Implement computed fields for the total area, best offer, and offer deadline. Add an inverse method to keep the deadline and validity in sync, and an onchange method to update garden-related fields based on user input. Chapter: 8
Extract the common base date calculation into a dedicated helper method to avoid duplicated logic in the deadline compute and inverse methods. This improves code readability, simplifies maintenance, and centralizes the fallback behavior for offers without a creation date without changing the existing functionality. Chapter: 8
The default list ordering was added only for testing and is not part of the intended behavior of the estate module. Remove the temporary ordering configuration to restore the default view definition and avoid keeping unnecessary test changes. Chapter: 8
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.
This PR contains my work on the Real Estate module from the Server Framework 101 tutorial.
It includes the property, property type, tag, and offer models, along with their fields and relationships. It also adds the required views, menus, actions, access rights, and the business logic implemented throughout the tutorial.
This PR covers the changes made while progressing through the Server Framework 101 chapters.