Going to focus on getting some base features before I work on code infrastructure. When I do setup dependabot, I want to use this style config:

https://fosstodon.org/@tylerayoung/112639286262924119

Inside of #28 I'm adding an /admin/ballots view but it's wide open.

This issue captures the concern that I need to add some validation around this.

This will allow people to control the URLs being generated.

This will help the admin know which votes to boost.

Can this be gamed? Sure, but this is fine for a first pass.

Currently, I'm reusing the ballot id for the secret part of the URL, which feels wrong since the id could leak.

Should consider making a separate value.

I built out the vote UI using a more standard top-down form, and I think that works pretty well.

When I researched ranked voting, I found this UI, which might make more sense, but I'm just going to capture this idea here for future consideration.

When a user is editing the weight and an invalid value is present, we should render the input with a red outline.

Right now, it does not work like this because we are avoiding the CoreComponents input component due to that having spacing expectations that do not make sense here.

Additionally, I'd like to replace Save and Cancel with checkbox and X small icon buttons. Might be related to this work. Long term I think this should be a dedicated component.

I'm using autofocus on the inline edit weight form, but it only works on first show and now if I edit multiple weights.

Up to now, I've been mostly tinkering on the domain. I need to spend some time on the user experience.

Do a breadboard for the full user path (to spark ideas to enhance current ballot creation and vote capture pages) as well as to define what the vote tally page should look like.

Currently solving for this at the Flick.Ballots module level but it might be better to also do it in the changeset.

Investigate why Gettext is included in the project template under *Web and not the main app?

I want to use this in my Ecto schema, but by doing so, I'm crossing a boundary.

Defaults to 1.0 and is editable by the admin.

Allows the admin to boost the value of individual voters. For our book club we boost the votes of regular attendees.

The first pass at the vote report is done in memory. I attempted to do this in SQL but did not figure it out.

I think this solution is acceptable for now, but ideally, I would come up with a pure SQL solution.

https://www.hex.pm/packages/tiny_maps

With the work I am doing in #1 I am allowing for a very soft attrs type of map().

I'd prefer this type to be more specific, BUT since the payload is very dynamic and the keys I need to accept are strings, I'm not sure how to best approach this, and so I'm noting the concern here to come back to it.

  ballot_params #=> %{
    "questions" => %{
      "0" => %{"_persistent_id" => "0", "title" => "12"},
      "1" => %{"_persistent_id" => "1", "title" => "34"}
    },
    "questions_drop" => [""],
    "questions_sort" => ["0", "1"],
    "title" => "Lunch Survey123"
  }

Currently, we repeat many validation tests across create_* and update_* function tests.

We should try to figure out a better pattern to validate these validations across both functions.

Users should be able to see a ballot page and then provide a ranked vote for each answer option.

We are not going to do anything with the ranked votes in this branch, just capture them somewhere.

Sample:

What pizza topping do you want (we can only have one):

• Pepperoni
• Sausage
• Mushrooms
• Anchovies

A user could provide a ranked vote recording

1st pref: Sausage, 2nd pref: Pepperoni , 3rd pref: Mushrooms, 4th pref: Anchovies