Closed dbenaben closed 1 month ago
To clarify, (beyond the 1-day delay), the issue is that the 'first' (60 day) and 'second' (15 days) are only sent once, and are skipped when they should be re-sent a year later?
It does seems like expiration_notif is not reset upon extend/renew... Can you check in DB if that's the case?
To clarify, (beyond the 1-day delay), the issue is that the 'first' (60 day) and 'second' (15 days) are only sent once, and are skipped when they should be re-sent a year later?
Yes, exactly. As far as I understand.
It does seems like expiration_notif is not reset upon extend/renew... Can you check in DB if that's the case?
In our database: Number of user without expiration_notif set: 459 Number of user with expiration_notif = 0: 960 Number of user with expiration_notif = 1: 220 Number of user with expiration_notif = 2: 88 Number of user with expiration_notif = 3: 58
For example, I have an user with expiration_notif = 2 that never receive an email from the past 2 month (last email received in september 2023).
Ok, that's really weird. expiration_notif should be reset at three steps:
The reset should have been added by his commit, two years ago.
If you manually extend a user (as an admin), does the reset work?
If it doesn't work, not sure what the issue is, outside of your instance not being actually in 1.4.28 (How do you check the version number on your end?)
If you manually extend a user (as an admin), does the reset work?
Example with an user. Before:
expiration_notif: 2
created_at: 2019-06-20
expiration: 2024-09-25
After renewed the account (via My, admin account):
expiration_notif: 0
created_at: 2019-06-20
expiration: 2025-07-24
(How do you check the version number on your end?)
Just checking /opt/my/CHANGELOG.md
and version deployed with ansible.
Ok, so it does work 'now'. I'm assuming a manual extend for users would work too.
I'm assuming the issue affect users who extended (or were renewed) in a previous version of my, when expiration_notif was not reset. So the issue 'should' be fixed now if users manually extend or if an admin renew, but you still have a lot of users who will not get the first/second/third mail and will let their account expire 🤔
One 'solution' would be reset expiration_notif
to 0 in database. It might be easier to do it for everyone rather than trying to isolate users with the issue.
Depending on the expiration date, some users might receive all three notifications (60,15,2), but it might be acceptable.
One 'solution' would be reset expiration_notif to 0 in database. I
Done !
# Extract infos script: clust-account-manager:/root/extract_bdd_expiration_notif.sh
Number of user without expiration_notif set: 404
Number of user with expiration_notif = 0: 958
Number of user with expiration_notif = 1: 283
Number of user with expiration_notif = 2: 84
Number of user with expiration_notif = 3: 54
Number of user with expiration_notif > 0: 421
# Set expiration_notif to 0
mongo gomngr --quiet --eval 'db.users.update({ status : "Active", is_fake : false, expiration_notif: { $gt: 0 }}, { $set: { expiration_notif: 0 } }, { multi: true} )'
# Resuts
Number of user without expiration_notif set: 404
Number of user with expiration_notif = 0: 1379
Number of user with expiration_notif = 1: 0
Number of user with expiration_notif = 2: 0
Number of user with expiration_notif = 3: 0
Number of user with expiration_notif > 0: 0
Thanks for your help !
Hello GenOuest Team,
We seems to have a weird bug at IFB Core Cluster about the expiration notification.
We should have an email 60 days before account expiration, then 15days and finally 3 days. My colleagues note that it works well at GenOuest but seems failed at IFB Core. For example, we can have (over a period of 3 years):
In short, the notice period shortens over time...
Maybe something wrong with the
expiration_notif
variable (https://github.com/genouest/genouestaccountmanager/blob/master/cron/test_expiration.js) ? Could you help us to check this behavior ? Could you help us to check the log ? Any help is welcome :)My Accounts Manager version: 1.4.28