feat: active and inactive users

[readmemyrights]

Closes #139

Backend works as expected,
perhaps there can be some improvements to the interface.

[aleksasiriski]

Can you try to rebase and solve conflict to my branch as/feat/guests since that one will be merged first for sure and it touches a lot of the codebase?

[readmemyrights]

I'll try that once I've added things like navigation links. Is there any other place I should add links to the new route?

[readmemyrights]

I tried to rebase on the guests branch, the biggest problem is the database migrations. On as/feat/guests there was only the addition related to guests, while on the main branch and by extension as/feat/active there were two additions first about entry and exit times and the second about deactivating users. The trouble is that the numbering is inconsistent and most of the conflicts are within machine-generated files.

I believe it's best to override your migrations with the ones on the main branch, and later you regenerate new ones numbered 0009. For that however this branch would have to be merged in first. Basically I'm suggesting to merge this branch into main, rebase main into as/feat/guests making sure your migration-related changes don't get applied, you generate new migrations related to your guest changes, and finally merge as/feat/guests. I think this would cause the least problems, assuming that nobody except developers is running the code on the as/feat/guests branch.

I'll be likely on campus tomorrow so we can discuss this offline if necessary, just DM me on discord.

[aleksasiriski]

You can easily resolve the conflict for migrations by deleting your migration (in drizzle folder), rebasing onto as/feat/guests and afterwards running pnpm drizzle-kit generate to create your migrations again

[aleksasiriski]

Overall looks very good! I would suggest renaming active field name to disabled and having it default to false (to represent that a user isn't enabled).

Also, note my comment about logging out currently logged in users utilizing hooks.server.ts file.

In addition to that: we must add a button to "disable all users" because otherwise admins will have a hard time managing users.

[aleksasiriski]

This is a great start to implementing this feature, but there was a slightly different idea on how this should be achieved: Admins should be able to set DateTime intervals in which the users are active

IMO we should have both options, this global enable / disable mechanism (for rouge users) and also the DateTime intervals (global disable should take precedence over whatever the interval is currently set).

TLDR. Admins should also be able to create schedules for users, alongside this enable / disable mechanism

P.S. Probably best to make the schedules into a separate PR that builds upon this one (after we merge this into main, or you can make a stacked PR)

P.S.P.S. THANK YOU FOR YOUR CONTRIBUTION, YOU ROCK!

[readmemyrights]

You can easily resolve the conflict for migrations by deleting your migration, rebasing onto as/feat/guests and afterwards running pnpm drizzle-kit generate to create your migrations again

I thought about this too, the problem is that it isn't only the as/feat/active related migrations but also the changes regarding statistics, the ones that I believe have already been applied on our campus (I'll ask when I go to campus today though).