stamhoofd / stamhoofd

Stamhoofd supports associations with open-source software.

Supporting clubs and non-profits with great software

Folder structure

We recently moved to a monorepo to make it easier for new contributors to make changes without having to work in different repositories and creating multiple pull requests. Now you can bundle all your changes in one pull request.

Frontend

For everything frontend related, you can take a look at the readme in the frontend folder. We have two SPA, written with Vue + TypeScript. The frontend is build on a custom (open-source) framework 'vue-app-navigation' that makes handing responsive and app-like views/navigation/animations easy. You'll see that it is easy to learn and understand.

Backend

Documentation and code is located in the backend folder.

Shared

We have some packages that are shared between the frontend and backend. The most important one is structures. This package contains all the data structures (communication in the API, stored in the backend, in an encrytped blob or in localstorage) and how they should be encoded and decoded. The data structures are versioned: when an old client communicates with an updated backend, everything will work as usual. Make sure you keep everything backwards compatible, read the documantation in @simonbackx/simple-encoding. If you need to add some new data, you'll probably need to make some changes in this package.

Contributing

Do you want to contribute? GREAT! :D You can build features that you need for your own club or you can help the project.

This is what you need to know:

1. Try to keep all communication in English, even when you know everyone is speaking the same language. It makes it easier for others to find answers to some questions later on and to join a conversation. We know the software is currently in Dutch only, but that will change in the future ;)
2. We recommend you to create an issue before starting to build something (unless it is a bugfix or a small improvement, then you can open up a PR right away). Big features should be discussed first.
3. Look at the issues if you want to help build something, or open an issue if you want to help but don't know where to start. Tip: you can look at our feedback system (https://stamhoofd.nolt.io to find inspiration).
4. Create a pull request, make a draft if you feel some discussion is needed or if you want to show your WIP

Development

To run everything locally, we run everything on a fake TLD domain and host the dashboard on dashboard.stamhoofd. We use Caddy and Coredns to wire everything together. You can follow the following steps to run everything:

1. We use yarn. Do not use npm. That will break things. Use yarn policies set-version 1.22.19 to set the version of yarn to the one used in the project (and the server). Replace 1.22.19 with the version in package.json > engines > yarn. We use version version 1.22.19 of yarn because of a bug in workspaces after that version (yarnpkg/yarn#7807).
2. When switching branches, cloning the repo or when pulling changes, run yarn install && yarn build first in the project root. We use yarn workspaces to glue all packages together in the monorepo. We don't publish individual packages (not anymore, we used to do that).
3. Use yarn build:shared in the project directory to build all shared dependencies inside the project. This will make sure eslint works correctly.
4. Install all needed vscode extensions: vetur & eslint. Please use VSCode because that makes sure all the developer tools are the same (e.g. eslint).
5. Make sure you create all /backend/app/*/.env.json based on /backend/app/*/.env.template.json (make sure you create the required MySQL8 database and start MySQL)
6. Make sure you create /frontend/.env.json based on /frontend/.env.template.json
7. Run migrations by running yarn migrations in the backend/app/api folder
8. Run yarn dev. This will start all servers. If something fails, try to run it again and/or fix the error.
9. Install and run caddy via yarn caddy (this serves the app on the default development domains)
10. Install (brew install coredns) and start coredns via yarn dns (this makes sure the default development domains resolve to your local IP address, this is required because we need wildcard domains).
11. Update your computer's DNS-server to 127.0.0.1 (in case coredns is not running). On MacOS when using Wi-Fi you can run networksetup -setdnsservers Wi-Fi 127.0.0.1. Run networksetup -listallnetworkservices to list all your network services. Don't forget to remove this again if you stop coredns again (or you won't have any internet connection since all DNS queries will fail). You can also manually go to the network settings of your Mac to change the DNS server.
12. Next time you can run yarn dev, yarn caddy and yarn dns in one go by running yarn dev:server

Everything should run fine now and you should be able to visit https://dashboard.stamhoofd (make sure to enter http(s):// manually because the browser won't recognize the TLD by default and will default to search otherwise) to create your first organization.

Feel free to contact us via [email protected] if you have questions about development and how to set it up.

E-mails

Stamhoofd bundles with maildev to test emails in development. This is automatically started when using the yarn dev:server command or yarn mail manually. This starts an SMTP server and web client at http://0.0.0.0:1080/ (to see all incoming emails).

Backend

Use these commands in /backend

yarn build

Build the backend into the /dist folder, using TypeScript cache if possible.

yarn build:full

Build the backend into the /dist folder, clearing cache before building

yarn start

Run the backend server locally. This will use the /backend/.env file for configuration. You can use .env.template to create your own .env file.

yarn migrations

Run all the migrations. If you don't have the tables in your database, this will also create all the tables. You'll need to create the database yourself (choose your connection details and name in .env)

yarn test

Run the tests on a separate test database. You'll need to setup .env.test (same as .env, but please modify it first and make sure NODE_ENV=test is in it)

Frontend

You can use the following commands in both /frontend/app/registration and /frontend/app/dashboard (the current frontend apps)

yarn build

Build the whole app into /dist, without optimizations (for development)

yarn build:production

Build the whole app into /dist, with optimizations

yarn serve

Serve the frontend locally with HMR (use this for development in combination with yarn start in the backend)

Shared dependencies

All shared dependencies are located in /shared. These packages are used by the backend and the frontend. If you make changes here, you must rebuild the package with yarn build. You can rebuild them all at once by running the same command in the project root.

Support and information

Feedback and ideas: Feedback (use this for feature suggestions instead of issues)

More info on our website: Stamhoofd

Localizations and translations

Translations are still WIP, not all strings are ported to the translations files yet. Feel free to contribute here!

Translations are stored inside the package shared/locales. They need to get build (cd shared/locales && yarn build), because we use one single .json file to store each locale (this makes it easier to use developer and translation tools). Before we use those in the frontend, we need to filter out unused translations to save some bandwidth, that is what happens in the build step. Translations are divided in 4 namespaces: shared, dashboard, registration and webshop. The shared namespace is always loaded. For the dashboard frontend, only the dashboard namespace is loaded etc. After the build step, we have 4 JSON files (one for each namespace) for each locale. The frontend and backend knows which file to load.

The possible language / country combinations are not restricted. E.g. en-NL is still a valid locale, for users from the Netherlands who want to use the English version.

Translations are resolved in the following order: en-NL > en. So translations from a specific language + country combination are used before the translation for a given language. Try to define most translations only in the language.json file, only country specific translations should be placed in the full locale files.

License

Stamhoofd is open-source software, licensed under the GNU Affero General Public License Version 3 (AGPLv3). View license.

stamhoofd's Issues

Reduced price after a certain date

Skipped for now but should get implemented by Dec 2020

Steekkaart sorteren op prioriteit

Verwacht gedrag

In het leidingspaneel: bij een ingeschreven lid dat meer dan 1 iets heeft aangeduid op de steekkaart, zijn deze items gesorteerd op prioriteit.

Echt gedrag

Deze items zijn niet gesorteerd op prioriteit.

Steps to Reproduce the Problem

1. Klik op een lid.
2. De items van de steekkaart zijn niet gesorteerd.

Ik ga hiervoor een pull request indienen.

Repository is stale

Is stamhoofd no longer being developed in this repository, is it still developed as open source?

Registreren via site / portaal aanmaken lukt niet

Setting free contributions might create multiple extra values

When updating the free contributions, there is some bug that causes more than the allowed values (3) + which doesn't reflect what is set in the dashboard. So this needs to get corrected.

Join our developer chat

Have a question? Want to discuss something outside of GitHub? We're experimenting with a better way to communicate with the community. We've joined the Matrix network. Join our private, end-to-end encrypted chat at chat.stamhoofd.dev and say hi 👋 in the General channel.

PS: we still recommend using GitHub for posting feature ideas (and related public discussions) and bugs. But the chat is a better way to communicate if you have questions while developing.

Proposed architecture

Frontend

Two separate single-page-web applications using Vue.js.

• Members: Part that is visible for members
• Organizations: Part that is visible for the administrators of organizations

Backend

Microservice architecture. Main language of choice is Golang.

The communication between the microservices and the frontend goes to the GraphQL gateway (Gateway service). This gateway makes the calls to the microservices and exposes their services in one API.

Needed microservices:

• Member service
  • Create a new member
  • Get the available members you have created or have been granted access to
  • Get the members in an organization if you have access to them
  • Modify members
  • Modify member contacts (parents etc)
  • Modify member information (allergies etc)
• Auth service
  • oAuth2 based authentication
  • User login
  • User registration
  • Still need to check where and how some authentication and authorization logic should happen in other services
• Organization service
  • Create a new organization
  • Modify organization settings and setup
  • Get information about an organization
  • Modify and create privileges of users in an organization
• Billing service
  • Managing subscriptions
  • Payment methods
  • Billing plan selection

And other shared microservices we might need in the future

• Email services
• Translation service

Beheerder invitelink downgrade hoofdbeheerder account

Wanneer je als hoofdbeheerder een beheerders invitelink accepteert wordt je account gedowngrade naar een beheerders account en verlies je toegang tot de instellingen van je organisatie. Je sluit jezelf dus (in ons geval perongeluk) buiten van je beheerdersaccount :)

Disable parts or all of the asked medical information

The current records are too much focused on youth. As a current solution, we should allow disabling some questions. In the future we can add the possibility to add your own questions.

Register for activities

[Feature] Ticket sale

Hey guys! What is the current status of the ticketsale module? That's something I would love to join and help on the analysis/development/design/...

The selling of the tickets would be pretty use to implement by reusing the existing webshop module. It seems to fit pretty closely to how existing ticket sale software like eventsquare do. I have used eventsquare in the past and it works really well. We could get some great inspiration and lend some ideas on how they do it.

This could also be a big source of revenue depending on the monetization scheme. But there are also some risky aspects like paying back because of cancelation, servers slowing down because of traffic, holding the money ourselves or directly transferring the money to the host of the event, ...

Filteren op betaalmethode "ter plaatse" niet mogelijk

De optie "Ter plaatse" staat niet bij de filtermogelijkheden bij bestellingen. Dit wil ook zeggen dat als je alle opties aanvinkt, bestellingen uitgefilterd worden die ter plaatse worden betaald.

QR Code betaling kapot zonder rekeningnummer

Verwacht gedrag

Wanneer de groep geen rekeningnummer heeft ingesteld, wordt een lid/ouder daarvan op de hoogte gebracht bij de inschrijving.

Echt gedrag

Er wordt bij de betaling een qr-code gegenereerd zonder rekeningnummer, waardoor de qr-code niet werkt.

Steps to Reproduce the Problem

• Maak een groep aan zonder rekeningnummer.
• Schrijf een lid in.
• Open de betaling, de qr-code werkt niet.

Documentation and CLI tools for self hosted solution

• Install scripts
• Build the frontend without needing to recompile for different domain configurations (maybe use in place replacement of specific variables)
• Split parts of Stamhoofd that are more 'platform' like and being able to host only a single organization
• Update scripts
• Documentation

External login providers

Managing user accounts can be a hassle for organizations, if parents or members have an account only used for stamhoofd many will forget the password or login, by supporting external login providers like Google, Facebook or Microsoft using oauth or openid-connect.

The organizations will have less overhead in supporting people who lost their login data.

Since openid-connect/OAuth (not entirely the same but interchangeable here for for now) are widely supported by the industry many people already have an account.

Many providers can be added either as a setting from organization to organization or globally in stamhoofd.

This doesn't need to replace email login but can as it is on many sites on the internet an option for those who want to use it.

Documenting backend endpoints

In the back end endpoints folder there are many endpoints, it can be hard to grasp what they all are.

Documentation should include:

• the uri of the endpoint
• the request type
• the expected body
• the response codes
• needed permission

Ideally this documentation would be generated from the source code and automatically updated after new commits to a certain branch.

However this seems hard to accomplish in the way the endpoints are structured at the moment, as each endpoint uses the doesMatch function to check if it should be the one responding to a request and there is no single file or configuration where all the endpoint are defined.

A solution could be creating some higher order functions that take some kind of a config object and handle the request checking in the does match function, and the config object would easily be extracted from the endpoint files for building documentation.

Error bij mailadressen toevoegen

Wanneer ik mailadressen wil toevoegen aan onze stamhoofd krijg ik deze error, niet zo handig!

Extra rol financieel verantwoordelijke

Vaak is de financieel verantwoordelijke (met toegang tot de bankrekening) iemand anders dan de verantwoordelijke voor de ledenlijst. Het zou handig zijn om in de modal voor "nieuwe beheerder" een checbox te hebben "toegang tot de financiën". Die persoon kan dan aangeven wie al dan niet overgeschreven heeft, maar niet perse de volledige ledenlijst zien.

Member sign up flow

1. Sign up or sign in with a user account on the page of the organization
2. Check if the user already has members registered in this organization, go to the member overview in that case
3. Else, go to the create a new member page
4. Ask firstname, lastname, gender, birth date, phone (if over 16 years) and contacts/parents (required if under 18 years) + some optional information text about the family situation
5. Contacts contain the following information
   • Firstname + lastname
   • Type (mother, father, guardian, grandparent, family, friend...)
   • Phone number (optional, but required for -18)
   • Email address (optional, but required for -18)
6. All contacts/parents have an ID and can get linked to users by the following methods:
   • Invite link
   • Email address linked to user (not phone, since we can't verify phone numbers due to the high costs)
7. All contacts can access and modify the member's information if the member is a minor (during the duration of the membership + a small period for renewal). For 18+ members, contacts/parents are just there for emergencies. The signed in user at time of creation always has full access (maybe for a longer period than the contacts).
8. During this flow, depending on the organization setup. We automatically link the member to an age group or report that he is too old/young for the organization. If multiple age groups match, the user should be able to select an age group from a dropdown menu.
9. We then ask for the 'medical' information (not always medical, but for now we call it this way, need to give it another name) about the member (not for all organizations we should ask this information, it's an age group setting). This step should be skippable, but we need to send a reminder for this if skipped.
10. We go to the payment page, after this the member creation is confirmed.

Membership renewal is done via a link in a mail to the owner of the account or linked contacts, where all the information will be auto-filled. It's also possible to renew with a different or new account. The user should be able to use a new account because the member could now be 18+ and do the registration on a personal account. Maybe a member + contacts should be a completely different entity with a different ID every year to make this more clear. This also makes privacy easier and we can auto delete all the data at a given time in the year without having to think about losing data that we still need. The old data is only used for auto fill in the renewal process.

We'll check for duplicate members on sign-up, but we have to be very careful about privacy here.

Improve local development

Currently it can be a bit hard to develop Stamhoofd locally due to domain + certificate issues. You'll need to use Caddy locally and use your own domain and use wildcards to map it to the correct IP' + ports.

• Include documentation about Caddy + maybe a script to configure it correctly
• Include a DNS server or documentation that can be used on your localhost and maybe your network (to test on smartphones) with a fake domain name preconfigured.
• Disable HTTPS requirement in Caddy and the server in development

[Feature] Duplicate button for groups

When setting up a new category (a weekend or camp). Most of the settings are the same for all groups. But you have to manually create all of these groups which wastes time and increases mistakes.

So I had to idea to add a duplicate button on GroupMembersView. It automatically creates a new group with all of the same settings.

#95

Automatically re register

Allow for the creation of a policy that at the beginning of the new work year would add existing members to new groups (according to tags or something). And send them billing information without their interaction.

GUI bug when confirming payments

We are currently using Stamhoofd for both our member registration and a webshop.
When marking bank transfer payments for the members there is only the confirmation box: 'Ben je zeker?'.
When marking bank transfer payments for the webshop, there is an extra message 'De besteller(s) van bestellingen ontvangen een automatische e-mail.'

When confirming payments of a member after confirming a webshop payment, this extra message remains visible, even when no webshop payments are being confirmed in the selection. This can be confusing for the end-users. Refreshing the page fixes this issue.
As far as I was able to test, this is only a minor GUI bug, and the system works as intended in the back-end.

Allow for importing bank transfer logs for checking manual transfers

When using regular transfers allow for the importing of the logs from the banking dashboard to automatically check if paimends are made.

Splitting application and platform code

First let met define application and platform

Platform: everything to do with setting up an organization, invoicing for that organization and management of stamhoofd for that organization.
Application: the web application the users of stamhoofd interact with from day to day, being the management of there members, stores and events.

To allow for the self hosting of stamhoofd this should be split into two parts.

I propose two strategies for achieving this.

Locking the platform features

Add an install script that creates an organzation in the beginning and locking the ability to add other organizations, creating in practice an instance of stamhoofd for a single organizations.

Pro:

• More compatible with the current state of stamhoofd

Contra:

• A lot of dead code that is never used in a single instance

Splitting of the platform features

Running the platform features and the application features in a different process.

Pro:

• This is a good separation of concerns
• This should make it more easy to dockerize the project

Contra:

• A new instance must be ran for each organization in the hosted version of stamhoofd.

More general registration page

Instead of having to select a group which requires parents or new members to know the structure of the group allow for a general registration page that just asks basic info (such as age) and then adds the member to the correct group.

We could also not add the user to a group directly after registration but add them to a staging area/waiting list as suggested in #58.

This could also have the benefit that parents/members of potential new members wouldn't directly have to make an account. They would just leave there email. And if the registration is accepted the would get an email allowing them to make an account.

[Feature] Confirmation mail after signing up a member to a group

I think it would be nice to receive a confirmation mail with the info of registration + payment details (for manual transfers) after signing up to a group as a member.

What do ya think?

Webshop return URL for online payments not working in some cases

A case is reported where the return URL for Bancontact was not working (this webshop doesn't exist error). This could be related to an emtpy suffix.

Signup stuck on creating keys in firefox

In the signup flow I keep getting stuck on the creating keys spinner.

This occurred on Firefox version 80.0b8.
I have also tested this in chromium version 84.0.4147.135 where this issue did not occur.

Bot of these browsers run in arch linux.

GraphQL Federation

Currently we are using a GraphQL gateway that is written in Go. This basically just stitches the schemas together (putting it in a simple way). But we should look at using a federation which would allow us to refer to other service's models and more in a more structured way. More info: https://www.apollographql.com/docs/apollo-server/federation/introduction/

The gateway will then also be an Apollo NodeJS server because that currently is the only one implementing it. There also is a pull request for gqlgen, our GraphQL golang library, that adds support for this. We should use that fork during development.

Parallel groups for members of the same age group

Some larger organizations have multiple groups that tender to the same age group. In this case new members should not in a specific group.

As a concrete example at our scouts we have 12 groups, of which 7 are in some way parallel to each other. (2 * kapoenen, 3 * jongverkenners/jongivers, 2 * verkenners/givers).

A user should be able to try to register for an age group (ex: kapoenen) and upon confirmation of enrollment by the administrator a specific group should be assigned.

Add "Bus" to csv import.

Option to ask for code in section "Financiële ondersteuning"

I was wondering if it would be possible to be able to choose between a checkbox and a text field in section the section "Financiële ondersteuning" because for example UiTPAS works with a code and only people with a code should be eligible for a discount.

[BUG] Selecting a time before 10:00 doesn't work

When you try to select a time before 10:00 it automatically clears the input. I assume it fails because timestamps before 10:00 have a leading zero.

time_input_issue.mov

[Feature] Mobile application

Hey Simon,

If I'm not mistaken, you were planning to provide a mobile application for stamhoofd. If so, I would definitely recommend to look into using flutter. It's a easy to use framework with a similar programming style/structure like react.

Flutter is also compiled to native code and works out-of-the-box for Android and iOS. Performance is great and it's much easier to develop with than android/ios imho.

There is a learning curve, but once you get a good architecture it's really easy to implement features. There are also build tools for deploying everything automatically.

Another benefit is that it's a growing community, completely open source and like it or not -> backed by Google :p

MIgration 1593789706-keychain.sql failing on mysql

When running the migrations the migrations fails on the keychain migration with following error message.

Error: ER_UNKNOWN_COLLATION: Unknown collation: 'utf8mb4_0900_ai_ci'

When trying to run on myql version 5.7.31.

Groups that aren't linked to price

Some organizations might want to have the possibility to create groups that aren't linked to the price (pure for organizational purposes).

For example: an organization has a price for members older than 16 years old (100 EUR) en one for younger members (50 EUR).
The price should be selected automatically, based on age, and the member should automatically join the corresponding group (adults or youth).
But they also have different groups based on the level of the member. (Let's take starter, experienced and expert as example).

So members should have a choice to join one of these level-based groups, but the price should be selected automatically based on age.

A feature like this would be amazing because groups like this are often used in sport clubs.

[oauth2] Implement proper token storage

Currently the auth service doesn't properly store tokens. We need to think about how we will do this. Just making this issue already so we can track this.

License change

Update: Stamhoofd is was relicensed to the GNU AGPLv3 open-source license.

---

We decided to change our open-source Apache License 2.0 to the BSL 1.1 License. We made this change in advance to protect Stamhoofd against competitors, while still keeping if as free and open as possible. An important note here is that nothing changes for all our contributors and non-profit organizations, they can still keep using the source as long as they have fewer than 500 members. So you can still suggest new features, build them yourselves, help with bugfixes...

After 4 years, the source becomes open-source under the Apache License 2.0 and everyone is able to use it how they please. This new license will help protect Stamhoofd and it contributors and make sure we are in here for the long run, to build great software that will last.

The only sad thing is that we can no longer call Stamhoofd open-source, as it is no longer possible for commercial companies and competitors to use it (only after 4 years). This is a requirement for open-source software, but we believe that this will damage Stamhoofd.

An interesting read about this topic can be found at: https://blog.sentry.io/2019/11/06/relicensing-sentry

Build our own external login provider

Instead of relying on third party login providers, it migh be a good idea to create one ourselves.

Why?

End-to-end encryption is super important in Stamhoofd. The web doesn't really offer good alternatives for persistently saving keys withoout risking losing them. You also have other difficulties: multiple browsers on same device, browser updates, clearing of storage, devicelost/stolen...

The only alternative for now is using passwords and deriving the keys from the password. This is a good solution, but it also has tradeoffs:

• Choosing a password while members will only need to use it at max 4 times in a year. Which will cause a lot of users to forget their passwords. Once you forget your password, you also loose access to all the encrypted data. Luckily, we take that into account and we try to make it as easy as possible to recover from this. But you still need to enter ALL data again.
• It is not that secure if people decide to use bad passwords

Solution

A generic app that users need to install in order to sign-in. This could be the same app as organizations will use to manage their organization, but it should be very easy to understand.

In the app the user only need to enter their email and the key is generated and stored inside the app. We could also store the keys far more safely and on some devices we could use the HSM. In case of devive loss or theft we default back to the same recovery as 'password forgot', but this should happen far less.

The app could be used as an OpenID-like authentication mechanism, with the only difference that it will create an unique encryption key for every client and saves them securely. This also enables self-hosted websites to use this system and automatically enables a kind of SSO for organizations. External services for organizations could build on top of this system (even when they don't need E2EE).

Desktop flow

Instead of showing a login + password form, we show a QR-code that is generated and ask the users to scan the QR-code with the app. When scanned, the app opens and asks to confirm to give permission to client X. After that the user will automatically sign in on the desktop computer (no possibility for a redirect flow since we are using two different devices).

Below the QR-code we also add a "help" button with more instructions and a possibility to sign in with password/email.

Mobile flow

Instead of showing a QR-code we show a "sign in with X" button which will open the app or redirect to a page that explains how to install the app (if not installed).

Advantages

• Less 'forgot password' events
• Less duplicate sign ups from users who forgot that they already have an account and create an account with a different email address
• Less overhead for organizations to help with account recovery
• Much faster sign in
• No generation time needed to derive the keys (which can take a while on slow devices). This also helps with older devices where the key derivation doesn't work somehow (memory / CPU limits?).
• Increased security
  • No bruteforce attack possible
  • High entropy keys
• Same login for multiple organizations, even when they are hosted on different servers or when they run different software
• This will be easy to explain to members and/or parents as they are already used to scan QR-codes. E.g. for mobile payments and ordering in a bar.
• We could extend E2EE and also encrypt email addresses (and remove all personal information from accounts) for organizations where that is sensitive information (unions, LGBT+ organizations, political party...)
• Could be optional
• (idea) We could also use phone numbers instead of email addresses since we only need to verify the phone numer once for every app install. SMS is expensive in Europe (10 cent in Belgium). And since most users only have one phone number, this will make it easier to link new users to imported users (we could match phone number to auto assign access - without keys).

Downsides

• Slower sign-up
• The need to install an app (we should keep that very small). We could keep the password based login as a secundary login method.
• Dependency on vendor of the app. It should be open-source and as open as possible.
• We need one app for multiple organizations. So there is a no whitelabeling possibility here (or at least only for big organizations).

Feel free to leave your remarks below :)

Broken functionality in mobile app

Some features are not working in the mobile app (v 1.15.0):

• Selecting/deselecting "wijzig zichtbare gegevens" (change visible data) has no effect, or shows strange behaviour.
• Moving people between groups using "verplaatsen naar>afdelingen>..." does not have any affect.

Mono repo managemet

The monorepo for stamhoofd provides benefits for development but makes it complex to manage dependencies. There are some existing projects that run on top of yarn workspace that try to tackle these issues, the main one seems to be lerna.

It might be interesting to start using it over bare yarn workspaces to make the dependency management easier.

Reduced price for brothers/sisters like 'standard price' minus 'discount'

In the current situation, it's only possible to configure a fixed reduced price for the second brother or sister, and a fixed reduced price for following brothers and sisters.
Some organizations might use a discount like the standard price - x EUR.

1st child: Standard price - 0x discount
2nd child: Standard price - 1x discount
3rd child: Standard price - 2x discount
4th child: Standard price - 3x discount
and so on.
It should be possible to configure a minimal price ofcourse ;)

[Feature] Toevoegen optie voor vrijwillige bijdrage/donatie

In mijn omgeving zijn er verschillende clubs/stichtingen die hun leden een vrijwillige contributie/bijdrage laten betalen. D.w.z. dat een persoon zelf bepaalt wat deze kwijt wil. Een betaalverzoek/tikkie is vaak niet voldoende, omdat dan moeilijk te achterhalen is van wie deze bijdrage afkomstig is en deze verloopt.

Het zou dus mooi zijn als het ook mogelijk wordt om bij de prijs van een product voor een vrije input te kunnen kiezen.

[Feature] "Verzekerd" of "Ingeschreven" toevoegen aan lid

Met onze KSA moeten we gebruik maken van Digit om onze leden in te schrijven en dus ook te verzekeren. Het is moeilijk overzicht te bewaren welke er al in Digit zitten zonder dit handmatig te bekijken.

Integratie met digit is natuurlijk nog beter, als je dat kan regelen via KSA NAtionaal

Vrije mededeling betalingen

Bij de betaling via overschrijving zou een vrije mededeling moeten kunnen verkozen worden door de leiding i.p.v. een gestructureerde. Zo is het makkelijker bij te houden wie al heeft betaald.

Deze mededeling moet volgens een vast template gebeuren, zodat het voor de leiding duidelijk is over welke overschrijving het gaat. Het volgende template lijkt een goede keuze: LIDGELD <voornaam> <achternaam> - <tak>, <voornaam> <achternaam> - <tak> ..., waar de broers/zussen een voor een worden vermeld.

Aangezien de de qr-codestandaard maximum 140 karakters toelaat voor vrije mededelingen moet er bij betaling voor meerdere leden gecheckt worden of de namen deze lengte niet overschrijden. Indien dit wel gebeurt stel ik voor toch een gestructureerde mededeling te gebruiken, in tegenstelling tot delen van de namen weg te laten vallen of zelf een willekeurig getal te genereren, om het voorlopig simpel te houden. In de toekomst zou dit uitgebreid kunnen worden.

[Feature] Becoming the all-in-one platform for organisations

This is probably the direction you we were going already, but some confirmation never hurts 😄

Stamhoofd is in a perfect position to become the number 1 platform for managing organisations/clubs. But looking from the perspective of the consumer, it could include features like searching for a new club or youth organization that you want to join. Find a new hobby, a dancing or sports club, ... It has a overview and filters to search clubs by name, location, type of club, age range, ...

Another interesting path is to add the aspect of being a "social media" app where you have a "feed" with your latest info and news about the clubs you have joined. This is always a risky move and has the potential to exponentially increase your users, but it can also be a feature that no one like nor sees the benefits. It remains an interesting thing to keep in the backlog.

Did I already see somewhere that you were planning a mobile application? The more useful features for an app like that would definitely be the possibility to manage your club registrations, upcoming events, your tickets, registrations, availability to activities, ...

Organization creation flow

1. User creates an account (firstname, lastname, email, password, maybe phone)
2. The user creates an organization: name + amount of members + how did they discover stamhoofd
3. Choose one of the templates of age group layouts, or create your custom structure. Should be very easy to create a new one, and advanced options should be hidden by default (you can view them with a toggle or something)
4. Add all the other administrators
5. Setup billing (first month is free, just cancel before that date). Need to have SEPA support, organizations don't have a creditcard.

Should be possible to skip the last steps, but somehow need some UI to recover and continue to those steps.

Privacy Foto's

Momenteel heb je de optie om aan te duiden of het kind al dan niet op een foto wilt. Is er ook een mogelijkheid waar de ouders/het kind kan aanduiden dat het enkel op groepsfoto's wilt. Wij hebben nu een aantal kinderen die enkel op groepsfoto's willen. Is het mogelijk om hier ook een selectievakje in te steken en tegen wanneer zou dit in orde kunnen zijn?