stamhoofd / stamhoofd Goto Github PK

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

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

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?

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Recommended reading: https://v3-migration.vuejs.org/

All input components are located at frontend/shared/components/src/inputs.

These still use some removed vue2 features, such as v-model's value and input events. They should get updated for this new syntax and we should double check everywhere in the frontend whether they are actually used correctly.

• Some parts have already been updated.
• In some cases it might be interesting to move away from the class based components to the new setup syntax.
• Writing automated tests for components would be nice, but is not a requirement

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.

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.

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.

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.

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

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

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.

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.

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

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, ...

Skipped for now but should get implemented by Dec 2020

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 :)

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.

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.

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 ;)

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?

Have a question? Want to discuss something outside of GitHub? We're experimenting with a better way to communicate with the community. Join our Slack account and say hi 👋 in the General channel.

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.

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.

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 :)

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, ...

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.

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

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

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.

• 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