membership_last_start is not correct

[PRMA974]

Module

Membership extension

Describe the bug

Le renouvellement d'une adhésion ne donne pas la bonne information sur le début de la dernière adhésion (membership_last_start)

To Reproduce

Affected versions: 12, 13, 14

Steps to reproduce the behavior:

1. Créer une adhésion de date à date : ie du 01/01/2021 au 31/12/2021
   2.Créer un renouvellement d'adhésion : ie du 01/01/2022 au 31/12/2022

Expected behavior
Voici les informations attendues
Date de début d'adhésion : 01/01/2021
Dernière date d'adhésion : 01/01/2022
Date de fin d'adhésion : 31/12/2022

Additional context
Or, il y a une erreur car membership_last_start = membership_start soit 01/01/2021 au lieu de 01/01/2022.
Je pense qu'il y a une erreur dans la boucle avec les variables last_from et date_from dans le fichier res.partner.py.

[PRMA974]

Je constate également qu'en opérant un tri par date sur les adhésions et en remettant l'adhésion à un état null puis à un état "membre payant" cela résoud le problème...peut-être un début de solution à appliquer dans le code ?

[carmenbianca]

Reporting the same bug on version 15 14. Copied from internal bug tracker:

Scenario:

Partner has three memberships:

1. Membership A going from 2022-08-01 to 2022-08-31.
2. Membership B going from 2022-09-01 to 2022-09-30.
3. Membership C going from 2022-10-01 to 2022-10-31.

The current date, if it matters, is 2022-09-09 (during Membership B).

What should the value of membership_last_start be? In my patch, it's 2022-10-01. On the previous behaviour, it's 2022-08-01.

The patch:

commit 798bb24970f67fe2fe5109efebf3d96355cc8782
Author: Carmen Bianca Bakker <[email protected]>
Date:   Wed Sep 7 16:28:51 2022 +0200

    [FIX] membership_extension: Use latest start date for Membership Last Start Date
    
    I'm not sure what the behaviour prior to this patch is.
    
    Signed-off-by: Carmen Bianca Bakker <[email protected]>

diff --git a/odoo/temp-oca-src/membership_extension/models/res_partner.py b/odoo/temp-oca-src/membership_extension/models/res_partner.py
index 9cc4757..1882d61 100644
--- a/odoo/temp-oca-src/membership_extension/models/res_partner.py
+++ b/odoo/temp-oca-src/membership_extension/models/res_partner.py
@@ -168,7 +168,7 @@ class ResPartner(models.Model):
                             continue
                         date_to = line_date_to + timedelta(days=delta)
                         if not last_from or (
-                            last_from <= date_to and last_from > line.date_from
+                            last_from <= date_to and last_from < line.date_from
                         ):
                             last_from = line.date_from
                         if not last_to or last_to < line_date_to:

[chienandalu]

@carmenbianca Have you proposed a PR with such patch?

[carmenbianca]

@chienandalu I haven't. I'd be happy to create a PR if the maintainer acknowledges the issue and describes what the behaviour should be.

My colleague is of the opinion that the correct value of membership_last_start is 2022-09-01 in the above example.

[PRMA974]

Hello. I'm not really sure that this patch works. It doesn't for me.
Here is my patch for res.partner.py :

139 partner.membership_start = date_from
140 partner.membership_last_start = last_from

I remplaced by

139 partner.membership_start = last_from
140 partner.membership_last_start = date_from

It works as long as there is no gap in adhesion period.
Sorry, i am not used with Pull Request...

[chienandalu]

@carmenbianca

@chienandalu I haven't. I'd be happy to create a PR if the maintainer acknowledges the issue and describes what the behaviour should be.

Sure, the current behavior isn't right. So the PR will be welcome

What should the value of membership_last_start be? In my patch, it's 2022-10-01. On the previous behaviour, it's 2022-08-01.
My colleague is of the opinion that the correct value of membership_last_start is 2022-09-01 in the above example.

I would expect the date of the current period as well.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

[yajo]

The fix landed in 93c8e75 FWIW.

[rafaelbn]

#132

[yajo]

Hello folks. Sorry for resurrecting this old thread. After some analisys, we found out that the solution applied for this issue was wrong, and that the previous behavior was right.

Reasons explained in #190 (comment) so I invite you to join the conversation. We're preparing a fix.

Thanks!