- Created the  module to manage estate properties
- Includes fields for property details, state management, and availability dates
- Adds selection options for property states and default values for new records
- Created xml files for menu and properties. (estate_menus.xml,
  estate_property_views.xml)

Chapter 6 - Add Basic Views for Real Estate Module

- Organized fields logically for the estate.property model.
- List View: Added custom list view to display more than just the name.
- Form View: Added custom form view with grouped fields for better organization.
- Search View: Enhanced search view to allow searching by more fields, including
 'Available' properties filter and 'Group by postcode' shortcut.
- Implemented domains for advanced filtering.
- Task 1: Added smiling face element when there are no records in the module
- Task 2: Added sample data background when no records are there.

Chapter 7: Implemented Relations Between Models in Real Estate Module

- Created `estate.property.type` model with relative menu, action, and views.
- Added `property_type_id` Many2one field to `estate.property` model and
  updated its form, tree, and search views.
- Added `buyer_id` and `salesperson_id` Many2one fields to `estate.property`
  model, with default salesperson as current user and buyer not copied. Updated
  form view to include these fields in a new tab.
- Created `estate.property.tag` model with corresponding menu and action.
- Added `tag_ids` Many2many field to `estate.property` model and updated its
  form and tree views with `widget=many2many_tags`.
- Created `estate.property.offer` model with fields: `price`, `status`,
 `partner_id`, and `property_id`. Created tree and form views for offers.
- Added `offer_ids` One2many field to `estate.property` model and updated its
  form view.

Chapter 8 & 9:

Chapter 8:

- Added `total_area` and 'best_price' computed field to `estate.property` model.
- Implemented `date_deadline` as a computed field, calculated from `create_date`
  and `validity`.
- Defined inverse function for `date_deadline` to update `validity` based on the
  difference between `date_deadline` and `create_date`.
- Added onchange method in `estate.property` to set default `garden_area` and
 `garden_orientation` when `garden` is set to True.

Chapter 9:

- Added 'Cancel' and 'Sold' buttons to `estate.property` model to manage
  property state transitions.
- Added 'Accept' and 'Refuse' buttons to `estate.property.offer` model to manage
  offer decisions.
- Introduced business logic for buttons, ensuring only one offer can be accepted
  per property.
- Used `UserError` to raise errors for invalid state transitions.

Chapter 10: Constraints

Added constraints to ensure data integrity in the real estate module:

- SQL Constraints:
  - Enforced that property expected price must be strictly positive.
  - Ensured property selling price must be positive.
  - Guaranteed that offer price must be strictly positive.
  - Implemented uniqueness constraints for property tag names and property type
    names.

- Python Constraints:
  - Added a constraint to ensure the selling price is not lower than 90% of the
    expected price.

Chapter 11: Add UI Enhancements and Inline Views

- Improved the user interface of the real estate module with color decorations
  and conditional display of fields and buttons.
- Added inline list view for estate.property.type to display related properties
  with specific fields (name, expected price, and state).
- Implemented statusbar widget to display the state of estate.property with
  specific statuses (New, Offer Received, Offer Accepted, Sold).
- Added ordering to models for deterministic list views and manual ordering for
  estate.property.type.
- Added widget options to prevent creation/editing from the form view and added
  color picker for tags.
- Configured conditional display of buttons based on property state and made
  some fields invisible based on conditions.
- Enhanced list views with color decorations and made lists editable and fields
  optional.
- Added default filters to search views and adjusted filter domains for living
  area searches.
- Implemented a stat button on estate.property.type form view to show related
  offers with appropriate filtering.
Task: Added chatter in the estate property.for that made changes to
estate_property_views.xml, __manifest__.py file and estate_property.py file.

…t model

Chapter-12: Implement inheritance for CRUD methods and model extensions

- Added custom business logic to prevent property deletion if the state is not
  'New' or 'Canceled'.
- Modified property state to 'Offer Received' upon offer creation.
- Prevented creation of offers with a lower price than existing ones.
- Extended `res.users` model by adding `property_ids` field to display
  salesperson's properties.
- Implemented view inheritance to include the new field in the user form view.

Chapter 13: Interact With Other Modules

- Created the 'estate_account' module as a link between the 'estate' and
  'account' modules.
- Added logic to generate an invoice when a property is marked as 'Sold'.
- Overrode the 'action_sold' method in the 'estate.property' model to initiate
  the invoice creation process.
- Implemented the creation of an empty 'account.move' (invoice) with the
  necessary details (partner_id, move_type, and journal_id).
- Added functionality to include two invoice lines during the invoice creation:
  6% of the selling price and an additional 100 INR for administrative fees.

Chapter 14: Implemented Kanban View with QWeb Templates

- Added a minimal Kanban view to the real estate module, displaying property
  names
- Introduced QWeb templates for flexible view design, enabling the
  customization of the Kanban card layout.
- Implemented conditional rendering using `t-if` for dynamic content based on
  the property's state.
- Enhanced the Kanban view to display additional fields: expected price,
  best price (when an offer is received), selling price (when an offer
  is accepted), and tags.
- Set up default grouping of properties by type, and disabled drag and drop for
  better user experience.
- Leveraged QWeb as the templating engine to provide a unique and polished
  interface for the real estate module.

Define module data and demo data for Estate module

- Added master data for standard Real Estate Property Types (Residential,
  Commercial, Industrial, Land)
- Created demo data for properties and offers to support testing and development
- Configured data extension to populate new fields in dependent modules
- Ensured properties are correctly categorized as Residential in demo data

Implementation of PDF reports using QWeb templates in the estate module.

Key updates include:

- Creation of basic and minimal PDF report templates that display all offers for
  a property.
- Organization of the file structure with the `report` folder containing
 `estate_property_templates.xml` and `estate_property_reports.xml`.
- Addition of report templates and actions to the `__manifest__.py` file.
- Implementation of sub-templates for code reusability across different reports.
- Introduction of logic in templates using `t-if` and `t-else` to handle cases
  where there are no offers.
- Inheritance of reports in the `estate_account` module to include additional
  information like invoices for sold properties.

1. Create a 'Properties' menu on the website to list available properties
   (not sold/canceled/archived) in a grid view.
   - Added property images to be displayed on the front-end.
   - Implemented pagination with a maximum of 6 properties per page.

2. Developed an 'Add Offer' wizard allowing salespersons to select multiple
   properties and submit offers in one action.
   - Wizard includes fields for price, validity, and buyer.
   - Added 'Make an offer' and 'Cancel' buttons.

3. Updated security to restrict property access and actions:
   - Added roles for Real Estate Agent and Manager with appropriate access
     rights.
   - Ensured agents can only view and manage properties within their assigned
     companies.
   - Implemented security overrides to allow agents to confirm sales without
     full invoicing access.

- Created different models for this: dental.patients, dental.allergies,
  dental.habits, dental.chronic.condition, dental.medical.aids,
  dental.medication
- Created appropriate views file for all of the models
- Added security file: ir.model.access.csv

- Created the `dental.patient.history` model to store detailed patient history,
 including allergies, x-ray files, habits, and treatment notes.
- Added fields to capture information such as:
  - Patient name, responsible person, company, main complaint, and various
    dental-specific details.
  - Selection field for consultation type and several boolean fields for teeth
    staining and treatment procedures.
- Designed tree and form views:
  - Tree view shows the date, display name, main complaint, and tags.
  - Form view provides sections for patient details, teeth history, tooth chart,
    and treatment notes with placeholders for images and text.

…site

- This commit introduces a new route '/my/dental' in the WebsiteProperty
  controller, allowing public users to view dental patients associated with
  their guarantor ID on a custom webpage.

- Additionally, a new method `action_create_invoice` has been added to the
  dental.patients model and button for the same in the view of the model.