With only acbeo.fly.dev live we didn't have any issues with spam, but on acbeo.ch we had to require login for the contact form after a few days. Now we start to get quite some bots registered ...

Ideally, when we have the bots under control, we would have the contact forms public again, and also publish an email and phone number, at least for logged in.

https://simpleisbetterthancomplex.com/tutorial/2017/02/21/how-to-add-recaptcha-to-django-site.html

For backwards compatibility Django still uses a username to identify users. To make matters worse, this username is not case sensitive. So if Geri forgets his password, he could just register a second account for geri with the same email ...

As a first miniature patch we require email to be unique in the registration form. However, the proper way would probably be to write a custom User(AbstractUser) without username and identified by email instead, see https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#a-full-example. This would also allow us, to collect phone numbers at registration and use them to simplify announcing trainings and generating emails for the emergency services.

Unfortunately, introducing a custom User is somewhat delicate and tends to mess with Django's neat authentication and permission system ...

An alternative would be to go with Django's User with some more patching and a Profile, which would contain phone number for now and potentially prepaid flights later on.

Just collecting small ideas :-)

• Show number of selected pilots when listing trainings?
• Write down useful information for new pilots (e.g. toilets, drinking water, parking spots, prices, ...)
• Add links to Birdwing and other partners
• Go back to page after updating signup from paginated trainings list
• Only to for next Saturday from Monday on, still go by default to today if it's Sunday
• Add columns to admin table of Training (e.g. max_pilots) and Signup (e.g. is_certain)
• Batch role change in admin panel
• Success URL when ending up on login and having to register
• Try 4.1's bulk_create for creating Trainings, as it might be able to update existing Trainings
• Make pre-filled texts when updating training a drop-up, they are not visible on mobile. Also color code might be nice.
• Check priority date is before start when bulk creating or updating trainings
• Ask for address in membership form
• Make form's error more useful (e.g. state which field is required, might have to set required=False and clean everything manually)
• Sign up for several days at once? Date range selector? Picking several trainings from list?
• Prefill stored Training.infos when updating Training!
• Fix margin between "Über uns" and "Partner" cards
• Explain, that we don't store postal addresses with holiday plans
• Use "einschreiben" everywhere (e.g. in "Über uns" we use "Anmeldung)
• Require is_certain or WholeDay for is_motivated?
• Add sidebar to contact.html and 404.html maybe too?
• Make upcoming trainings more readable: grey out count of canceled signups, warn-color for 75% and not WholeDay
• Print week day in signups success message, to make mistakes easier to notice
• add season begin and end to infos
• Add link to AirG and mention that we also have those demos
• sleeping options
• admin: sort signups by descending date, trainings too
• validate phones, apparently chrome fills in emails sometimes ... Also use these tags for readers?
• Make login cookies live longer than two weeks
• Assert no emergency mail was sent, before sending; currently I guess two orgas could be sending one at the same time 🤔
• Make emergency button clickable to list phone numbers of participants, and rather disable send button for emergency mail
• Paginate SignupListView by year (along the lines of ReportListView)
• Forward to QR code when paying by TWINT
• Add warning for earlier unpaid Signup in create_bill
• "Bitte Kassenstand erfassen" warning should not show up, when any cash_at_end is saved
• URL to Bilanz should be berichte/bilanz
• Welcome email after registration; someone was not sure whether registration worked 🤷 and might help to figure out with which email one registered 🤔
• Replace None with ? in list_reports before Report.cash_at_end is saved
• There might be a bug in update_bill when flights were paid (and not from abo)
• Aggregate TWINT transactions by week (as we get weekly receipts)
• ReportListView and BalanceView are getting slower with every report ...
• Show IBAN in create_absorption
• Redirect when creating report before sending emergency mail
• Add pull-to-refresh
• List all active pilots of season
• Yesterday's training is still listed for the one or two hours after midnight, when UTC is still yesterday; likely create_report also goes wrong ...
• Would be nice to have checkboxes for CTR/TMA, parking tickets, and briefing if new pilots are there, when creating a report.
• Use MessagesTestMixin.assertMessages() from Django 5
• Add Absorptions to TWINT revenue in balance

We have this beautiful vertical logo (Highres):

We should somehow incorporate it and create a theme around it!

Also, the layout and forms overall wouldn't mind some love :-)

Minor points:

• It would be amazing, if the dropdown menu for Trainings was open when the whole menu is collapsed into a hamburger
• Currently, some buttons are in d-grid, others not; we should have a concept there 🤔
• pilot_update.html should include sidebar.html and arrange cards side by side on large screens
• Green success-button looks ugly next to the ACBeo green normal buttons

Currently we do the accounting in another app on a laptop. While this works and it is not necessary to integrate the accounting in the web site, it would have advantages:

• One system, one language
• No more season openings with the laptop missing
• Continuous, automated database backups
• Single user account with maintained membership status, all selected signups automatically in balance sheet
• Cashing in could be done anytime, anywhere (e.g.when the laptop would be on the bus), and in parallel
• Technical support and correcting mistakes could be done anytime and remotely

Small TODOs:

• Report should have a field for remarks.
• There should be at least a warning when updating a Report with unpayed Signups.
• There should be a column for unpayed Singups when listing Reports.
• Make sure there are not tricks to get back to the waiting list before paying once a relevant Run is associated with the Signup.
• @classmethod Purchase.save_item(ITEM, signup)
• Form for creating Expense should have radios with the most common things, like the form for Purchase, but with an addtional other text field
• ExpenseCreateForm for Abschöpfungen
• Always go to first unpayed Singup for Pilot when creating Bill.
• Add warning message when last Signup is stored and Report.cash_at_end is missing.
• Axalpkleber warning
• Count number of day passes in member email
• Warnings before leaving page with unsaved changes
• Send an email with a picture of receipt when creating an Expense
• Use actual prices in info.html
• Forward to QR code when paying by TWINT
• Write down explanations on billing

We currently have mostly integration tests. They make sure, that GET and POST requests lead to expected changes in the database and that the resulting responses contain expected elements, e.g. a button or a link. However, we do not test if these elements are rendered correctly and if the HTML forms generate the correct POST requests.

While I don't think it's absolutely necessary, it might be fun to try visual end-to-end testing :-)

Resources:

• https://playwright.dev/python/docs/intro
• https://devblogs.microsoft.com/python/announcing-playwright-for-python-reliable-end-to-end-testing-for-the-web/

• Select signups for training based on order of registration
• Priority with deadline for members and pilots signing up for the whole day with certainty
• Reserving two spots for organizers
• Collect weather preference
• Contact form
• Mail form for joining club
• Mail form for emergency services; with a button next to update training that turns inactive when sent
• Password recovery
• (Bulk) create trainings ahead, with default info (e.g. "Axalpwochen") and priority date
• Pages like Jahresprogramm
• Actually sending emails