[ADD] estate training : Created a new training module #350
Conversation
|
|
+Added the __init__.py and __manifest__.py files
+ Added the primary `estate_property` model + Created `ir.model.access.csv` for access control + Modified manifest to make the module an installable app
jhra-odoo
force-pushed
the
18.0-training-jhra
branch
from
b70829a to
5a38ffa
Compare
+Added an app icon +Added the three level menu +Added actions for the estate_property model +Added new fields to the estate_property model +Changed attributes of certain fields +Made new entries inactive (hidden) by default +Updated manifest to reflect the view changes -License changed to LGPL-3
… navigation +Added list view with common fields for the properties +Improved the layout of a property form +Added filters and grouping for property search +Added property types for better categorisation +Seller and buyer info can now be changed from the property form
+Implemented a basic offer proposal form +Now we have the ability to add tags to properties +Updated the list and form views to reflect these changes
+We can now decide on the termination date of an offer. +Best offer price for a property will be displayed. +Total area of a property will auto compute based on the entered data.
jhra-odoo
force-pushed
the
18.0-training-jhra
branch
from
518d65a to
cf9fd2d
Compare
| ) | ||
| partner_id = fields.Many2one('res.partner', string="Partner", required=True) | ||
| property_id = fields.Many2one('estate.property', string="Property", required=True) | ||
| date_deadline = fields.Date(copy=False, default=fields.Date.today(), compute='_compute_date_deadline', inverse='_inverse_date_deadline', store=True) |
There was a problem hiding this comment.
whats the purpose of using inverse field here? Also, why are we using store=True, what does that do?
There was a problem hiding this comment.
The inverse method (_inverse_date_deadline) allows date_deadline to be updated manually by users. When modified, it recalculates and updates the validity field accordingly, ensuring consistency between deadline and validity period. As, by default a calculated field will be read-only, so this write back action can't be performed.
Setting store=True saves date_deadline in the database, making it searchable, filterable, and sortable in Odoo views. Without it, the field is recalculated on the fly, impacting performance and preventing domain filtering.
| @@ -0,0 +1,8 @@ | |||
| <?xml version="1.0" encoding="utf-8"?> | |||
| <odoo> | |||
| <record id="estate_property_tag_action" model="ir.actions.act_window"> | |||
There was a problem hiding this comment.
what is the difference between ir.actions.act_window and ir.ui.view?
There was a problem hiding this comment.
ir.actions.act_window defines how a view opens, specifying the model, view type (form, tree, etc.), and behavior. ir.ui.view defines the UI layout, determining how fields and elements are displayed in forms, lists, or kanbans.
So, simply put: ir.actions.act_window opens a view, and ir.ui.view defines its appearance.
+Invalid operations regarding properties and their offers have been fixed. +Offer proposals are easier to manage. +Users can directly access their properties from their profile page. +Added new ui elements and improved existing property form. +Accidental deletion of properties has been fixed.
| validity = fields.Integer(default=7, store=True) | ||
|
|
||
| @api.depends('create_date', 'validity') | ||
| def _compute_date_deadline(self): |
There was a problem hiding this comment.
why 'for record in self', why are we not directly updating self here?
There was a problem hiding this comment.
We use for record in self: because self is a recordset that can contain multiple records, and iterating ensures each record is handled individually. Directly updating self would not work correctly for computed fields and constraints that need per-record logic. Iteration prevents errors and ensures correct ORM behavior.
| name = fields.Char(required=True) | ||
| color = fields.Integer(default=1) | ||
|
|
||
| _sql_constraints = [ |
There was a problem hiding this comment.
what can be the substitute for this constraint? Why that substitute is not used here?
There was a problem hiding this comment.
A Python constraint (@api.constrains) could replace the SQL constraint by checking duplicates with search_count(). However, the SQL constraint is used because it's more efficient, prevents duplicates at the database level, and avoids race conditions in multi-user environments.
There was a problem hiding this comment.
can you please let me know what is this search_count(), when and why it is used?
There was a problem hiding this comment.
search_count() is an Odoo ORM method that returns the number of records matching a given domain. It is used when we only need the count of records instead of fetching full record data.
Usage Example: count = self.env['estate.property'].search_count([('state', '=', 'sold')])
+Added kanban view to the main properties view +Added a filter for toggling active properties from view +Invoice generation for sold properties has been properly implemented
| name = fields.Char(required=True) | ||
| color = fields.Integer(default=1) | ||
|
|
||
| _sql_constraints = [ |
There was a problem hiding this comment.
can you please let me know what is this search_count(), when and why it is used?
estate/security/ir.model.access.csv
Outdated
| id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink | ||
| estate.access_estate_property,access_estate_property,estate.model_estate_property,base.group_user,1,1,1,1 | ||
| estate.access_estate_property_type,access_estate_property_type,estate.model_estate_property_type,base.group_user,1,1,1,1 | ||
| estate.access_estate_property_tag,access_estate_property_tag,estate.model_estate_property_tag,base.group_user,1,1,1,1 |
There was a problem hiding this comment.
in these you have mentioned 'base.group_user' what is that?
There was a problem hiding this comment.
base.group_user is the default user group of Odoo, applying to all internal users. And that 'base' prefix is because it's defined in the base module.
basically, each row in the ir.model.access.csv file defines access control for a model and assigns it to a group.
so, by setting group_id:id to base.group_user, we are giving all internal users permissions to the specified models.
| 'author': "Rahul", | ||
| 'website': "https://www.odoo.com/", | ||
| 'category': 'Tutorials/RealEstateAccount', | ||
| 'version': '0.1', |
There was a problem hiding this comment.
version is 0.1? Are you serious! XD
By the way, What this version actually means?
There was a problem hiding this comment.
Well, at this stage, the accounting module can only generate invoices for properties marked as sold. Without any proper accounting and transaction logic implemented, it doesn’t really deserve an integer version just yet. Basically, consider this an alpha release. 🗿
As for what that version is, it's a string that represents the version number of an Odoo module. It helps track updates, manage dependencies, and indicate compatibility with Odoo versions. And a version of 0.x indicates an experimental or alpha-stage software.
+ Set default company to current user's company + Applied company access rule to restrict record visibility based on the user's company - Fixed an error where new offers were not being created
- Added new record rules to limit access to specific models based on user groups. - Updated security XML files to define appropriate access rights. - Modified Python methods to enforce domain filtering for restricted records.
- Added sample entries for properties - Few predefined property types are added
+ PDF report of offers for any property can now be generated + PDF report of properties related to any salesman along with their associated offers can now be generated
+ Ability to enable warranty for certain products + If available, the user should be able to assign a warranty to a product while creating a sale order
…line model + Removal of associated warranty lines when the main product is deleted. Bug: - Unable to add warranties with same duration for different products.
Module Setup: Created the Real Estate module, made it installable, and added access control.
Core Features: Added the estate_property model with key fields and default inactive entries.
UI & Interactivity: Implemented menus, actions, an app icon, and improved property forms.
Navigation & Search: Added list views, filters, grouping, and property types for better categorization.
Updates: Changed license to LGPL-3 and updated the manifest.