Tp expiration

[rsiminel]

@mboudet
Will close #499 once finished.

In the notification email after TP creation, how should we differentiate between the "expiration" from CONFIG.tp.extra_expiration and the "expiration" field that we are adding in this PR?
How should we handle a TP coming to the end of it's expiration date?
Should we just add a button for a TP owner or an admin to make the TP accounts inaccessible to students, like a "Lock" button that activates a "locked" state?

[mboudet]

Yeah, 'expiration' is the wrong term I guess, maybe 'lock' would be better (though effectively, the accounts would be expired in our system).

I feel like a 'lock' button available user-side would need an 'unlock' button to avoid mistakes 🤔 .

The cleanest way would be a 'lock date' on the TP registration field. On the lock date we expire all TP accounts (but do not delete them)

We also need to manage passing this info through the mail sent to the TP manager, which might be a bit complicated (since replacing variable is not very flexible). Maybe setting #LOCKED# to '' by default, and to 'Account will be locked on this date' if set? That would leave an empty line in the mail if the value is not set, but it's acceptable.

/!\ This mean that in the deletion workflow, we need to account for the case that the TP account might already be expired (making sure to not throw an error)

[mboudet]

Not sure how we want to manage this. As it stand, we will print the locked date everytime (even if its equal to the end date), which might be confusing to the user.

Maybe instead of passing a date directly, optionally passing a full string?
That way, if there is not lock date, there would just be a blank line in the mail

[rsiminel]

Currently, we display the lock date in the TP overview every time, like this:

I don't think it's too bad to display the lock date everywhere. If you think this is important, should we then have "lock" be set to null when the user does not specify a lock date instead of setting it to be equal to the end date?

[mboudet]

I was mostly talking about the email sent with the passwords: like here.

I'm not sure if adding a line with 'Accounts will be locked on #LOCK' make sense if a user did not select a lock time.

The issue is also that if the user did not select a lock date, it will seems like the accounts will be locked on the end date, and then be deleted 5 days later (the grace period). Might be confusing since they did not ask for a lock.

[mboudet]

Three more things:

• How do we want to manage the 'extra_expiration' ? I'm guessing that if the user provided a lock date, we want to actually lock in at that date, and ignore the extra_expiration.

• Currently, the 'lock' key does not do anything. You need to modify cron/reservation_remove.js to take it into account.
  (Need to make sure not to lock if lock_date == end_date (without the extra expiration)

• We need to manage the case where the users are locked, but the reservation owner extend the lock date beyond today.
  (By unlocking the users I'm guessing?)