Joining, leaving and a club page of its own

Added

• A public club page. Every club gets a page with the groups, courses, appointments, badges and news it chooses to show — section by section, down to the single entry, with the tasks behind a badge expandable. A club directory, a sitemap and structured data make the page findable, and how findable it is can be set.
• Membership applications with a form builder. A club builds its own application form from blocks: pages, fields that are asked once or per person, participant management, fee group choice, address confirmation and a SEPA mandate per person. Applicants confirm their mail address and sign; the finished application arrives in the dashboard for review, is accepted with the entry date set to the day of the decision, and stays attached to the member as a PDF together with its documents, the family it belongs to and any follow-up question.
• Cancellation and leaving. Notice periods are set per fee group and the deadline is calculated in one place. A member submits a cancellation from the app or the member area and can withdraw it; the club confirms it. Leaving is then wound up with a closing overview, and coming back is possible.
• A member area and self-service in the app. Members see their membership, offices, balance, dues and invoices, download an invoice as a PDF, and see how an open item is meant to be paid. The SEPA mandate can be looked at and a new bank account reported for the club to take over. The club calendar sits in the appointments tab with filters, a subscription and sign-up per appointment; membership, departments and the club's own fields show up in the profile; lendings and reservations have their own screen; and a data section carries the GDPR report and the deletion request.
• Two-factor authentication and passkeys for everyone. Both are managed on your own account, in the app and in the browser, with recovery codes and a list of your devices. The login asks for the second factor as a step of its own, and a club can require it, in which case setting it up is part of signing in.
• Departments. A department is an organisational unit in its own right: members belong to it for a period with a history, groups, courses, inventory and places are assigned to it, rights can be cut down to it, department fees run along in the fee run, and it works as an audience for news, appointments, mailings and badges. Membership counts per department can be reported to the federation, and departments appear in the app, in the application form and on the public page with pages of their own.
• Methacore as an OpenID Connect provider. Other applications can sign people in with a Methacore account — discovery, JWKS, authorization code flow with PKCE, ID token claims, userinfo and a consent screen that looks like the rest of the product. Sign-in is limited to the club the application belongs to, and members see and manage their connected applications in their account. Grafana is documented as an example client.
• A website builder. Beyond the club page: drafts and publishing, eight official templates plus your own, protected pages, custom code, collections for template pages, SEO settings and a cookie banner, mobile styles derived from the desktop layout, an address turned into map coordinates on the server, and publishing to the club's own domain. The public club page is the starting template, and "sign in with Methacore" on a built site opens the regular login.
• The club's mailboxes. Mail domains are managed in Methacore against a real mail server, with IMAP retrieval and Cloudflare connected over OAuth. The webmail client reads and writes mail, signs in with the Methacore account, carries the club's contact book, supports acting for another mailbox and a combined view of several, and reports the storage in use. Distribution lists stay current, and address books can be reached over CardDAV.
• Migration from easyVerein and Webling. Members, groups and invoices are taken over, with errors reported and a summary at the end. Migration is the first step of setting a club up.
• File storage. Files and folders for the club, shared with individual people or with groups.
• Support without leaving the product. Tickets and a chat in the app and in the dashboard, and the app names the club's administrators as contacts.
• Documents and mails in one design. Templates for invoices, receipts, offers, dunning letters and donation confirmations, plus membership certificates, serial letters, applications, cancellations, minutes, votes and lists; the design of a template can be chosen. Mails were rebuilt on the same basis.
• An assistant in the dashboard. It answers questions and carries out actions across the administration: it looks records up, asks back when a field needs a value, offers the values a field allows, names its sources, and says no to what it is not allowed to do.
• A dashboard you arrange yourself. The layout can be set per organisation and per user.
• A developer API with webhooks. Endpoints for members, fees, finance, payments, documents, events, competitions, training plans, meetings, mail and the website, versioned and served on their own subdomain, plus webhooks that report changes in an organisation.
• Ticket orders in the app. Members see the tickets they ordered.
• A new website. Five product films with the media served from the CDN, a blog post for each dashboard page with a sidebar and a glossary, and posts on migration, newsletters, the organigram, storage, the club mailbox, webhooks and the website builder. The handle you type when signing up is checked against what is actually taken.

Improved

• Overlays and lists keep to one pattern. Row menus and a click on the row open the detail view, every form lives in the same side panel with one of three widths and one verb for saving, an overlay is titled like the menu entry it came from, closing with unsaved changes asks first, a filter panel no longer throws away what you entered, locked buttons name their reason, field errors stand at the field, empty states also appear in the tabs of a side panel, and the column selection says whether it saved.
• Notifications lead where they point. A notification resolves to its target in the app, a message and its mailbox belong together, the inbox carries a badge, and a note names the channel a message came through.
• Smaller words that were wrong. A missing mail address is a dash instead of a bracketed placeholder, a switch replaces "0 means none", and creating a record is called the same thing everywhere.
• Licenses follow the member. Each accepted member gets a license of its own, deleting a member gives it back, and coming back needs a new one.
• Scrolling on the website no longer stutters on the navigation bar and the blog pages.

Fixed

• The cancellation form was offered even without an exit date, in the app and in the dashboard, and its button had neither its label nor its colour.
• The keyboard covered the input fields in the app, mail confirmation during onboarding left no way out, and the emergency contact page did not scroll to the end.
• Old news items crashed the app.
• Trainings were loaded twice, course appointments came in through the wrong path, and the appointment list is grouped by month again.
• A member without a mandate was shown as having one named "Unknown", and the fields for reporting a bank account carried no labels.
• Webmail sent over the external address instead of the system's mail server, "link" did not actually link, placeholders showed up in the contact book, and credentials travelled in the wrong part of the request.
• When Cloudflare refused, its own reason now comes through, and only offline_access is requested.
• An unusable token at login was reported as a server error.
• On the club page the training time came from the wrong field, a badge picture and a badge identifier were named inconsistently, and a selection box disappeared when it had nothing to offer.
• The club directory came back after it had gone missing.
• Uploading pictures in the administration works again, and the member list survives a group that was deleted.