Cap possible registrations

[dorodere]

Sometimes the service might not have the bus with 1337 seats available, but only the one with 50 seats. Of course then not more than 50 people should register.

After some back and forth, we've decided that this should go on a first-come first-served basis: If you've registered early enough for the drive, you're in. Else, if the limit is already reached, your registration is denied and an error pops up.

Partly linked to #2, since this must be both configurable as in

• per-instance default
• per-drive actual limit

the second overriding the first. Not sure if this configuration should happen in the web UI or in Rocket.toml, first one would require a whole new table.

[dorodere]

Rough todo:

• [x] Add a new setting for the default registration cap
  • [x] In the UI
  • [x] In the DB (remember to write a migration)
  • [x] In the backend (there's not much to validate except parsing the string to an integer)
• [x] Display the registration cap on every drive
  • [x] Nicely modify the backend to accept such modifications
  • [x] Reorder buttons to make more sense?
• [x] When adding a drive, use the setting as the default registration cap (can that setting query be done inside the SQL itself? maybe)
• [x] When registering, retrieve the registration cap for the current drive and error out if it's already reached (do check if the registration update is to register, not to unregister)
• [x] "Grey out" (disable) buttons for drives which are inaccessible at the moment

[dorodere]

Short note so I don't forget it: pretty_date in the drives panel code is not needed anymore.

[dorodere]

@Nitro-paul Be advised, I need to write a registration count function in sql_interface anyways in order to implement the registration cap. Which I'd do as the next thing, and would mean you could just use that one instead of crafting your own one.

Should I build it and you rebase your branch and use mine? Or should I wait for/help you and tackle other stuff like #23 or #24 in the meantime?

[Nitro-paul]

Thats a good idea, you writing that function would probably have good impact on development time and i would happily use your funcion wich will most likely be more eficient. Only things i need to know will be function name and minor details about the returned value.

[dorodere]

It's not about efficiency, but rather about you learning something :D I believe you could indeed learn a lot about SQL and how to use rusqlite here. How about this?

• You randomly write the query you'd use. It doesn't need to actually work, it can also just be a text file, you can test it as much as you want.
• I'll push in near future to my cap-registrations branch containing a function you could use.
• Next time we meet, we can compare and talk about it.

This will be the signature:

pub fn count_registrations(conn: &mut rusqlite::Connection, drivedate: chrono::NaiveDate) -> Result<u32, rusqlite::Error>

[dorodere]

fwiw the query is up on the cap-registrations branch

[dorodere]

Actually implementing the backend logic for moving a drive into the "inaccessible" section turns out to be more interesting. I wanted to include a subquery in the general registrations-per-person query for the dashboard which would be basically count_registrations, but that turned out to be a whole jungle I'm not sure I want to execute on every single index call.

I have to sleep about this. Maybe you were right about keeping the current registration count in a new column on the drives.

[dorodere]

Alright, I'll do this transparently in the sql_interface by adding a new column registration_count. Not really feeling like doing cursed nested subqueries atm.

[dorodere]

wait count with an OVER clause seems interesting

[dorodere]

Nevermind, rolling back. Manually caching the registration count that currently points to this drive has a way too large surface for bugs and introduces many additional queries just to keep the field valid and correct. The subquery isn't that bad.

[dorodere]

Alright, I'm pretty much done. I only need to implement being able to unregister after having registered/only displaying a drive in the locked section if the registration intention would to register, but that's not yet.

[dorodere]

...something's terribly broken on the superuser drives panel. But not today.

[dorodere]

Nevermind, probably joins are trolling me instead.

[dorodere]

Turns out, NULL < 2 is nothing, so NULL again.