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.

[micahdbak]

IMO you can just place socials information as possibly empty attributes (if they're private - keep them null) and return the attributes as empty or not even included in the endpoint that serves info about the election candidate

[EarthenSky]

I thought of a few more features that we'll want to have. These need not be part of the MVP, but should eventually exist:

• Import websurvey results. This generates a bar graph of the results. Technically, the data is stored in order & timestamped to the minute. Not sure if survey monkey will have similar functionality.
• (frontend only; @micahdbak) We expect new users who have never created an account will want to become execs. These users will authenticate through the sfu cas api, have a site user entry generated for them, then be sent to a page to fill in required elections information. Each user should have their own unique page.
• Election will need to be created by a website admin (DoA usually)

[DerpyWasHere]

Could I get a list or example of what public and private election data look like?

Actually, now that I think about it. How should we go about saving/reading the actual election results data, should we just make another table or read it from whatever the source is?

[EarthenSky]

public and private election data look like?

Before an election starts, nominee_speech data should be private. Only once a specific datetime (election start time) passes, is the data accessible through the API. election_nominee data should be thought of as unlisted, as it can't be accessed unless there is an election that points at it. However, this brings up the question; should the past officer info change with for past elections or not? If it did change, it would be a little unwelcome, as the data seems private, but anyone can actually see it change in real time.

There are several ways to go about this, and I'm not sure which feels best. Maybe attach socials to election_speech 1:1?

How should we go about saving/reading the actual election results data

Probably just store it as two fields; raw string + parsed results (also string). If so, we can extend it to something more complicated in the future.

[EarthenSky]

FYI, it's up to you the order you think is best to implement this :)

Stage 1

• create database tables to store election info
• create permission to check if user is a current elections officer
• create a private endpoint for website admins (see the WebsiteAdmin permission) to create the election (will usually be DoA)
• create private fastapi endpoints for an authenticated elections officer
  • which endpoints? depends what the frontend team wants. For now, just give the bare minimum that makes sense. Try to avoid premature optimization!
• create public endpoints for accessing public elections data (see https://sfucsss.org/elections/)
• do manual or automated tests for every endpoint as a sanity check

Stage 2 (optional)

• Import websurvey results. This generates a bar graph of the results. Technically, the data is stored in order & timestamped to the minute. Not sure if survey monkey will have similar functionality.

Stage 3

• Someone makes the frontend page(s) & may request more reasonable endpoints

//

I suggest 1 PR per 1-2 checkboxes