[16.0][membership_extension] 'membership_last_start' does not correctly reflect the start of the latest membership period after a break

[fcvalgar]

Module

membership_extension

Describe the bug

It has been observed that the membership_last_start field does not accurately calculate the start date of the most recent membership period when there has been a break in membership. Instead of taking the start date of the new period following the gap, the field appears to rely on the last active fee, resulting in inaccurate information about the continuity of the membership.

This issue makes it difficult to accurately analyze when a member has rejoined and can be considered "new" in a given period. The correct behavior should clearly identify the start date of the latest continuous membership period after any interruption, rather than carrying over outdated information.

References to Previous PRs:

Previous issue: #126
Migration to Odoo 16: #132

To Reproduce

Steps to reproduce the behavior:

1. Create an initial membership (e.g., from 01/01/2020 to 31/12/2020).
2. Leave a gap with no membership activity (e.g., 2021-2022 without any membership).
3. Register a new membership starting from 17/12/2023 to 31/12/2023.
4. Register another membership from 01/01/2024 to 31/12/2024 (a full year).
5. Check the membership_last_start field. Currently, it does not show the correct start date for the latest period, as it carries over previous information.

Expected behavior
membership_last_start should be set to the actual start date of the latest continuous membership period following any break. In the example provided, it should properly reflect the late 2023 and 2024 memberships, offering a clear view of the member as “new” or returning during that period, thereby facilitating accurate analysis of membership base evolution.

Additional context
A fix to the membership_last_start calculation would help provide more reliable metrics, especially after the migration to Odoo 16 discussed in PR #132. Any suggestions or contributions from the community to resolve this issue are welcome.

@moduon MT-8237 @yajo

FYI @carmenbianca @chienandalu

[rafaelbn]

Let fix it @fcvalgar @yajo , I agree 😄 with ❤️

[yajo]

I agree there is a problem here.

There are 3 involved fields:

vertical-association/membership_extension/models/res_partner.py

Lines 38 to 61 in f19fdbc

	membership_start = fields.Date(
	string="Membership Start Date",
	readonly=True,
	store=True,
	compute="_compute_membership_date",
	help="Date from which membership becomes active.",
	recursive=True,
	)
	membership_last_start = fields.Date(
	string="Membership Last Start Date",
	readonly=True,
	store=True,
	compute="_compute_membership_date",
	help="Start date of last membership period.",
	recursive=True,
	)
	membership_stop = fields.Date(
	string="Membership End Date",
	readonly=True,
	store=True,
	compute="_compute_membership_date",
	help="Date until which membership remains active.",
	recursive=True,
	)

According to my tests, membership_stop mostly behaves as expected in any case. However, the other 2 are not always well understood.

I'll write the case that @fcvalgar explained as a table because I understand it better. These would be the memberships recorded in a partner:

date_from	date_to
2020-01-01	2020-12-31
2023-12-17	2023-12-31
2024-01-01	2024-12-31

☝🏼 notice the gap.

Now, we have 2 possible solutions. Option A (this is the behavior we had before v16):

field	meaning	value
membership_start	Earliest historical date this partner ever became a member	2020-01-01
membership_last_start	Date when the partner became a member for the last time	2023-12-17
membership_stop	Date when the latest partner's membership ends	2024-12-31

Option B would be:

field	meaning	value
membership_start	Date when the partner became a member for the last time	2023-12-17
membership_last_start	Start date of the latest renovation of partner's membership	2024-01-01
membership_stop	Date when the latest partner's membership ends	2024-12-31

Currently the behavior in v16 is this one (let's call it option C), which is effectively not much useful:

field	meaning	value
membership_start	Earliest historical date this partner ever became a member	2020-01-01
membership_last_start	Start date of the latest renovation of partner's membership	2024-01-01
membership_stop	Date when the latest partner's membership ends	2024-12-31

Why option C is not useful?

• The earliest historical date is useless when you can't compare it with the last membership start.
• The start of the latest renovation won't help you know whether they're new members or they're just renovating.

My vote goes for restoring option A. This makes the module more useful and keeps old known behavior. Do you agree?

[fcvalgar]

First of all, I want to express my gratitude to @yajo for taking the time and effort to analyze this issue and propose such a clear, well-founded solution. I greatly appreciate the initiative to revert to the logic prior to version 16, as it offered a more coherent and useful approach to the data.

Regarding the options presented, I am fully in agreement with Option A, because:

• membership_start retains its historical function, reflecting the original date the member first joined the organization.

• membership_last_start once again represents the point of re-enrollment, making it easier to identify when a member returns after a period without membership. This adds more clarity when analyzing the evolution of the membership base, enabling a better understanding of “new” members in each period.

• membership_stop indicates the end date of the most recent active membership, and it should remain editable since there may be situations, such as an immediate cancellation, where a manual adjustment of this date is necessary.

This approach not only restores the familiar and useful behavior experienced before v16, but also provides a solid foundation for historical, statistical, and strategic analysis of the membership community.

Once again, thank you, @yajo, for your proposal and for the thoughtful attention you’ve given to this matter. Your contribution is a valuable addition to improving the quality and utility of the module.