You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If there is set overdue on "tilamaksu" service to allow member have "tilamaksu" in overdue before suspended, door API does not still allow member in.
I think it should, as admins specifically allow overdue when value is set. Optimally all the current reminder mails (or future whatever methods) should be sent like currently in overdue state, but door should still open.
Either same HTTP 200 status, or optimally different 200 status to differentiate, could pick 281 to be opposing for our current 481 =)
Anyway most acute thing would be overdue considered valid access.
Testing from different type of member statuses against door API, answers below, problematic one would be the 3, MonthlyOverdue:
There were some discussions on chat that at least original design was intentionally for overdue to block access. For that there is the "suspended" state, and this is also why "overdue" length can be adjusted or disabled completely, if any leeway is not desired to be given.
At current behavior "overdue" is kind of broken concept, it does not allow overdue.
We need to spec overdue and new deactivated state. As initial general overview point rename current "overdue" to "deactivated" while otherwise logic stays same, and introduce new "overdue" that does allow door access still.
If there is set overdue on "tilamaksu" service to allow member have "tilamaksu" in overdue before suspended, door API does not still allow member in.
I think it should, as admins specifically allow overdue when value is set. Optimally all the current reminder mails (or future whatever methods) should be sent like currently in overdue state, but door should still open.
Either same HTTP 200 status, or optimally different 200 status to differentiate, could pick 281 to be opposing for our current 481 =)
Anyway most acute thing would be overdue considered valid access.
Testing from different type of member statuses against door API, answers below, problematic one would be the 3, MonthlyOverdue:
Also GET method for whole allowed list:
The text was updated successfully, but these errors were encountered: