Unexpected hours_til_expiration behavior

[zpchavez]

1. There is an hours_til_expiration column in the client table that defaults to 24
2. The /api/invite and /api/resend-invite/{userId} endpoints accept an hours_til_expiration param
3. If not provided in the request payload, these values default to 48 instead of the client-level default.
4. The client-level default is used in verification emails and forgot password emails, just not invites.

It seems odd that the client-level default is overridden for invites. However, removing the route-level default of 48 would be a breaking change and would reduce the invite expiration time for existing projects that don't explicitly pass an hours_til_expiration in their invites. Maybe we should add a hours_til_invite_expiration column that defaults to 48 and remove the default defined at the route level. Then existing functionality would be preserved.

The reason this came up for me is because we wanted to extend invite expiration time and I tried to do it by updating hours_til_expiration in the client table.

[zpchavez]

There should probably be some discussion about this before it is worked on

[zpchavez]

I also just noticed that the endpoint param spells till with two Ls. Maybe we can fix that but also continue accepting two Ls for backwards compatibility? And then in 3.0 we can introduce a breaking change and leave it to one L always.

[spruce-bruce]

hours_til_expiration is a but of a bummer field name now in retrospect. I'd like to go hunt down when it was added and try and remember the whole context to understand if I want 2 columns or 1.

At the very least some kind of column rename and possibly abstraction is probably in order here.