[16.0][ADD] real_estate: Addon to manage real estate #17

curonny · 2024-05-24T14:41:03Z

No description provided.

rousseldenis · 2024-05-24T17:12:50Z

What I wanted on the first version is to inherit from all properties of res.partner(and even added ones). As an estate has all properties of addresses.

This approach has a drawback is the implementation it needs. But IMHO, the advantages have more pro than cons. I'm not too much in favor of these changes

curonny · 2024-05-27T12:35:28Z

What I wanted on the first version is to inherit from all properties of res.partner(and even added ones). As an estate has all properties of addresses.

This approach has a drawback is the implementation it needs. But IMHO, the advantages have more pro than cons. I'm not too much in favor of these changes

I understand your point, but one of the problems, which arose when trying to use the currently published version, is that the fields of res.partner many2one list the contacts and also the properties, which forces us to add unnecessary domains so as not to list the properties .
Actually, I think the ideal behavior should be to isolate it, and link it with a product or partner according to the need of each solution to be carried out on this basis.

pedrobaeza · 2024-05-27T18:26:02Z

I agree it should be an isolated one with the needed m2o, or maybe fields sync.

curonny · 2024-06-14T15:36:29Z

@rousseldenis So, would it be possible to validate the PR, with the new approach?

mymage

Hi all,
for a project I'm working on (16.0) I need the management of estate.
My needs are very basic at the moment so I could create my custom module, but if it possible to use an OCA one I am happier.
For what I can understand from the comments and the code, this version is "better" than the 13.0.
So if it is possible to update the commit to have a runboat to test I will do it.
Thanks

curonny · 2024-09-02T15:41:56Z

@jelenapoblet is this PR, the other PR it's closed

jelenapoblet · 2024-09-02T15:51:57Z

Got it @curonny , thank you! Is there anything else we can do to move this forward?

curonny · 2024-09-02T15:54:37Z

Got it @curonny , thank you! Is there anything else we can do to move this forward?

everything is done, waiting for approval

rousseldenis · 2024-09-02T16:03:03Z

@curonny Could you provide migration scripts if needed ?

rousseldenis · 2024-09-02T16:07:21Z

real_estate/models/real_estate.py

+    real_estate_latitude = fields.Float(digits=(10, 7))
+    real_estate_longitude = fields.Float(digits=(10, 7))
+    comment = fields.Html()
+    owner_ids = fields.Many2many(


This could be enhanced in order to support different kind of property (bare ownership, ....).

Not sure if Im catching the idea. Right now we can assign rental estate type and if some filter is needed at contact level you could set it up in some MISC field.

The owner field relation is maybe too generic.

As there are several kind of (legal) ownerhsip on a property (bare ownership, usufruct, ...)

I created a middle model to handle those cases and added some ownerhsip type examples I found.

The owner field relation is maybe too generic.

As there are several kind of (legal) ownerhsip on a property (bare ownership, usufruct, ...)

... payer for taxes who can be someone else than the owner...
More complicated case : one payer for rubbish tax and another one for water tax
So maybe add some selection field with kind of relation with the estate... how about keeping inheritage on res.partner and integrating partner_multi_relation ?

Why not using partner_multi_relation to have any kind of relation between real_estate and res_partner ? let's discuss that here

rousseldenis · 2024-09-02T16:08:35Z

real_estate/models/real_estate.py

+    country_code = fields.Char(
+        related="country_id.code",
+    )
+    real_estate_latitude = fields.Float(digits=(10, 7))


We are in the real estate model, so removing real_estateshould be great for both fields

I removed those fields, maybe we can add it in the future with some geolocation feature

@Christian-RB I think Denis means 'remove real_estate from the name of the field' not 'remove the field'

I removed the fields since they were not being displayed at all

rousseldenis · 2024-09-02T16:10:13Z

@curonny Could you rebase ?

rousseldenis · 2024-09-02T16:18:56Z

real_estate/models/real_estate.py

+        index=True,
+    )
+    active = fields.Boolean(default=True)
+    image = fields.Image(


Why don't you use theimage.mixinpresent in v16 in order to manage all sizes ?

Done, thanks for the tip

Christian-RB · 2024-12-18T15:20:37Z

Hi, @rousseldenis I will continue @curonny's work here, sorry for the delay. I have already applied some changes following your comments and I'm checking the migration scripts right now. Thanks in advance.

cvinh · 2025-01-20T03:30:27Z

Hello

After doing some research, we see that there are different approaches to manage real estates

In OCA we have a repo that inherits on res.partner as here in v13... there is a lot of work on that one and we can imagine it's in production somewhere
In Odoo industry and here, we have the property inheriting from account.analytic.account which is unexpected but nice when you think you could have some accounting data afterwards. It's only data, there is nothing more...

I don't know which is the best but I think account.analytic.account must be considered

Also, is there a chance for every approach to converge to a unique OCA's approach ?
Is there a place where contributors can discuss about that ?

cvinh · 2025-01-20T03:30:54Z

cc @max3903

cvinh · 2025-01-20T03:31:14Z

cc @vehi-invitu

rousseldenis · 2025-01-20T07:52:41Z

Hello

After doing some research, we see that there are different approaches to manage real estates

In OCA we have a repo that inherits on res.partner as here in v13... there is a lot of work on that one and we can imagine it's in production somewhere

In Odoo industry and here, we have the property inheriting from account.analytic.account which is unexpected but nice when you think you could have some accounting data afterwards. It's only data, there is nothing more...

I don't know which is the best but I think account.analytic.account must be considered

Also, is there a chance for every approach to converge to a unique OCA's approach ? Is there a place where contributors can discuss about that ?

@cvinh Hi Cyril, indeed, I started the modules stack few years ago and have an instance running in v13. A discussion on this can be done here or in a separate issue.

In fact, I've implemented analytic too. You can create an issue, I will try to get in touch with updates as I've been busy for months on other topics.

pedrobaeza · 2025-01-20T07:54:26Z

I also think that property should be a separated entity, and then connected to whatever you want (partner, analytic, product...), like for example projects auto-create analytic accounts on creation.

cvinh · 2025-01-20T08:06:49Z

Well do you think pms and vertical-estate can converge somehow ?
I know PMS and REMS can diverge according to business workflows but if I'm telling you that we need properties in a 3rd business (city halls or government that tax properties) it obvious that we should have an basic model describing the property itself and then link it to pms or vertical-estate or vertical-somethingelse...
BTW, analytic, address, owner, geodata and other fields could be common to both approaches before they diverge...
WDYT ?

pedrobaeza · 2025-01-20T08:11:29Z

Yeah, both may have the same base property definition.

cvinh · 2025-01-20T08:14:03Z

Yeah, both may have the same base property definition.

What's your vision achieving this ? Another repo ?, take pms as basis and inherit it for vertical-* ?

pedrobaeza · 2025-01-20T08:49:44Z

You can have the base module in OCA/pms, and inherit here.

rousseldenis · 2025-01-20T08:52:52Z

You can have the base module in OCA/pms, and inherit here.

We can do that but in a new module as pms one is very big.

pedrobaeza · 2025-01-20T08:53:59Z

Yeah, I was talking just about the repository host. The module may be base_property or similar.

jelenapoblet · 2025-01-20T09:31:50Z

I agree with the approach. Creating a lightweight base_property module that inherits from OCA/pms is a smart solution. @Christian-RB

Christian-RB · 2025-01-20T12:13:26Z

I believe I understand the approach. The idea would be as follows:

Analyze the PMS module to identify common property values shared with the Real Estate module.
Create a new module base_property in OCA/pms to house the shared data, and establish dependencies for both the PMS and Real Estate modules on this new module.
Develop migration scripts to reassign the relevant fields to the new module (this will likely be necessary).
Adapt the migration logic here to align with this structure and ensure consistency.

Let me know if I am right

cvinh · 2025-01-20T16:14:51Z

I believe I understand the approach. The idea would be as follows:

Analyze the PMS module to identify common property values shared with the Real Estate module.

Create a new module base_property in OCA/pms to house the shared data, and establish dependencies for both the PMS and Real Estate modules on this new module.

Develop migration scripts to reassign the relevant fields to the new module (this will likely be necessary).

Adapt the migration logic here to align with this structure and ensure consistency.

Let me know if I am right

I'm opening a new issue in pms repo to discuss about the common fields to have in base_property module

max3903 · 2025-01-20T16:23:31Z

We can do that but in a new module as pms one is very big.

FYI pms has been refactored in this branch:
https://github.com/OCA/pms/tree/14.0-pms_base

rousseldenis and others added 7 commits May 24, 2024 08:33

[13.0][ADD] realestate_estate

2cc98df

[IMP] realestate_estate: Improve AGPL url, Improve estate model

8683acf

[UPD] Update realestate_estate.pot

9e7de36

[UPD] README.rst

fd0ae6c

realestate_estate 13.0.1.0.1

932d208

[UPD] README.rst

f05be3b

[UPD] README.rst

f88507e

curonny mentioned this pull request May 24, 2024

[16.0][ADD] real_estate: Addon to manage real estate, without odoo class dependency #16

Closed

mymage approved these changes Jul 20, 2024

View reviewed changes

rousseldenis added needs review migration labels Sep 2, 2024

rousseldenis added this to the 16.0 milestone Sep 2, 2024

rousseldenis reviewed Sep 2, 2024

View reviewed changes

Christian-RB force-pushed the 16.0-ADD-real-estate branch 3 times, most recently from 9e719b7 to 906ae2b Compare December 18, 2024 15:10

Christian-RB force-pushed the 16.0-ADD-real-estate branch from 906ae2b to 8efbd75 Compare December 18, 2024 17:08

RonnyBinhexTeam added 2 commits December 18, 2024 17:17

[16.0][REM] realestate_estate: Remove real estate module

62f2399

[16.0][ADD] real_estate: Addon to manage real estate

7ae8a43

Christian-RB force-pushed the 16.0-ADD-real-estate branch from 8efbd75 to 7ae8a43 Compare December 18, 2024 17:18

cvinh mentioned this pull request Jan 20, 2025

Creating a module base_property to be the base of pms/realestate/other repos that share property concept OCA/pms#319

Open

[16.0][ADD] real_estate: Addon to manage real estate #17

Are you sure you want to change the base?

[16.0][ADD] real_estate: Addon to manage real estate #17

Conversation

curonny commented May 24, 2024

rousseldenis commented May 24, 2024

curonny commented May 27, 2024

pedrobaeza commented May 27, 2024

curonny commented Jun 14, 2024

mymage left a comment

Choose a reason for hiding this comment

curonny commented Sep 2, 2024

jelenapoblet commented Sep 2, 2024

curonny commented Sep 2, 2024

rousseldenis commented Sep 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cvinh Jan 17, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rousseldenis commented Sep 2, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Christian-RB commented Dec 18, 2024

cvinh commented Jan 20, 2025

cvinh commented Jan 20, 2025

cvinh commented Jan 20, 2025 • edited Loading

rousseldenis commented Jan 20, 2025

pedrobaeza commented Jan 20, 2025

cvinh commented Jan 20, 2025 • edited Loading

pedrobaeza commented Jan 20, 2025

cvinh commented Jan 20, 2025

pedrobaeza commented Jan 20, 2025

rousseldenis commented Jan 20, 2025

pedrobaeza commented Jan 20, 2025

jelenapoblet commented Jan 20, 2025

Christian-RB commented Jan 20, 2025

cvinh commented Jan 20, 2025

max3903 commented Jan 20, 2025

cvinh Jan 17, 2025 •

edited

Loading

cvinh commented Jan 20, 2025 •

edited

Loading

cvinh commented Jan 20, 2025 •

edited

Loading