Agreed!

This makes sure we scroll to the first invalid input, which can be helpful when submitting invalid forms. In case there's more than one error, it first tries to scroll so all of them are in the view, and then it finally focuses on the first invalid one. This gives us a reasonable chance to get all of the invalid inputs in the viewport.

Yeah, I think this is a step in the right direction!

Sorry, seems like I've had a brain damage or something making me write UserInfo instead of EntryInfo every time. Please re-read my comments with s/UserInfo/EntryInfo/g. 🤦

The idea here is that EntryInfo is the metadata for an entry that a user can change. This MR takes that idea and runs with it a bit.

The idea is to eventually extend the EntryInfo so it can contain a generic dictionary of JSON data, so orgas can store extra metadata (like Evoke's GEMA info for authorship etc). But I didn't do that last bit yet, just restructured things a bit first instead.

So UserInfo would have an additional string field containing JSON? I was thinking UserInfo itself represented the JSON, but if that's not the case, I misunderstood and you can ignore my comment. :)

Let's merge the two first commits, and rework the last one a bit to be less dependent on JavaScript?

The idea is to eventually extend the EntryInfo so it can contain a generic dictionary of JSON data, so orgas can store extra metadata (like Evoke's GEMA info for authorship etc).

Won't having a predefined struct UserInfo with fields mapped to database columns make this dictionary to JSON mapping in the same UserInfo struct harder in the future?

This seems like a very neat and useful feature!

This renders a version of the visitor-list and compo-slides with mock data to try and catch styling-issues early on.

Marked as draft, because these pages aren't discoverable.

To me, the mock stuff added here doesn't seem like tools. "Mocking tools" indicates the creation of mock data to me, while the mocks here are static data rendered in existing views.

An alternative to a /mock root resource would be to append .mock or ?mock to the URL of other resources. When added (perhaps through a switch inside the admin interface somewhere), all links could be altered to provide mock data, sort of like going into "mock mode". Thoughts?

It might be useful to add a tooltip explaining why the button is disabled, no?

              <button id="add-all" type="submit"{{ if eq (len .MissingEntries) 0 }} disabled data-tooltip="No more entries to add"{{ end }}>Add all entries</button>

Here's a few fixes/cleanups for invite-related stuff...

Yeah, I think some sort of disclaimer or warning can be given in these "Download" dialogs, such that the person downloading knows that the archive might not be suitable for direct upload to scene.org.

Also, !406 (merged) is going to improve on this situation so we at some point in the future might remove such a disclaimer/warning.

this adds a button to download all entries of all playlists in one zip containing subdirectories. this basically then is what was played at the party and can be used to create dirs for scene.org.

LGTM! 🙂

Here's an MR that implements diploma printing.

While it's not perfect, I think it's better than nothing. Here a few things that could be improved:

• I'd love to get rid of the hard-coding of the A4, size, but I can't seem to figure out a good way that works in all browsers to make the diploma take up the entire page. width: 100vw; height: 100vh; works in Chrome, but not in Firefox (when printing).
• Perhaps make the number of placements to print configurable? Dunno, 3 seems pretty standard...
• Probably want some sort of integration with a configurable party-logo, like has been recently suggested by @steam0r

Neither of these seems critical, so perhaps we land this as-is soon?

Closes: #101