Elections Info

[EarthenSky]

We'll need database tables to store past elections, enable admins to appoint an elections officer, allow elections officer to configure an election, and to allow logged in student to run for executive positions.

TODO: add more issues for the above tasks

[EarthenSky]

This task will eventually culminate in moving all the elections data to the new site from the csss-site github repo https://github.com/CSSS/csss-site/tree/master/csss-site/src/elections

To start this task, break it into smaller tasks that can be accomplished without access to the data, and that can be tested locally & manually. For example, you might do the following:

• create database tables to store election info
• create permission to check if user is elections officer
• create private fastapi endpoints for an authenticated elections officer
• create public endpoints for accessing public elections data
• create a basic test html site that uses these endpoints (see csss-site-backend/tests/login.html for reference)

[DerpyWasHere]

What exactly is the slug type referred to here?

Edit: nvm read some documentation, this specific implementation is a django type, so i'll just treat it as a unique String

[EarthenSky]

i'll just treat it as a unique String

Yeah! Slugs as a feature are pretty common, but I would def treat it as just a string. Not sure what the Django type is, but string is much easier to understand :)

[DerpyWasHere]

I've simplified the tables to the following and have created new tables according to this.

We'll have to do a bit of migrating but I feel like this simplifies our work a lot more in the future.

[EarthenSky]

simplified the tables to the following

Looks awesome! The layout makes a lot of sense, I can't think of anything missing. I'd love to render the other tables in this way as well.

In your opinion, what's the biggest change wrt to the old tables?

[micahdbak]

@DerpyWasHere , amazing chart for the DB stuff - cardinalities look good, info is good.
I really appreciate seeing stuff like that 🥹

Really excited to see where this goes from here!!

[micahdbak]

Although actually, election_nominee looks like it holds a subset of info held by a user in the user table, do you want to keep these separate or maybe take advantage of the user table a little?

[EarthenSky]

subset of info held by a user in the user table

I did consider this actually; since elections_nominee is independent of a specific election, it would make more sense for the table to be included under auth/ as extended user info. That being said, some of the info there overlaps with officer info, but we can't assume the user will have officer info filled in. Thus, it makes sense to be separate

Maybe the best course of action would be to move the table to auth/ and call it something like social_info, as this data could be part of a users' account & be used in separate places.

[EarthenSky]

But now it makes me think, maybe nominee_speech should actually be nominee_application, as the user might want to decide what info they want to make public (bit flags showing which socials they want public / private). In any case, whoever implements the frontend can decide later if this is required or not, so we can hold off on implementing it for now.

But more importantly, we will need to store which positions the user is applying for under nominee_application!

[micahdbak]

Good points! I'll leave it to y'all to decide.

[DerpyWasHere]

Wrt which socials to have public or not, could we not just have that behaviour hinge on the data existing?

Haha oops forgot to store the position tehe

[EarthenSky]

hinge on the data existing

probably! That sounds like a good way to do it. Once the frontend is implemented by @micahdbak, he can make requests based on the user experience that'll makes the most sense.