Parallel groups for members of the same age group

[WardToulet]

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.

[SimonBackx]

So the user doesn't choose which group he joins, but an admin 'confirms' his registration and puts him in the right group?

How do you handle renewals? Do you also put them on the queue again?

[SimonBackx]

And how do you handle prices? Because the currently only solution is that you charge the same membership fee for all the groups. Other solution is to not charge anything but send the payment e-mail at time of confirmation.

[WardToulet]

A new type would need to be created. For sake of argument I will call this a staging group.

The staging group will hold the data that is common for all the groups it controls, in my above example this would be pricing and age groups, but this can change if groups get new criteria.

It's child groups refer to this data and don't store this themselves, this will insure they use the same pricing and membership criteria.

For my given example we would create a staging group "kapoenen" witch manages two groups "kapoenen" 1 and "kapoenen 2"

For new enrollments the user would just get to see the option to enroll in the staging group, and they can try to enroll in this staging group.

An administrator who confirms the new enrollments can do so in the staging group and then assign one of the specific groups managed by the staging group.

For renewals if a member still meets the criteria to be a member of the currently assigned group he would just be able to reapply for that specific group, if not the would need to apply for a different group where they are eligible or some kind of suggestion system but that is out of scope for this thread.

Lastly the staging group entity could also be used by all groups even the ones with no parallel groups to make the structure more uniform.

[SimonBackx]

Interesting! We also might add some type of categories in groups to structure them better (e.g. make distintion between volunteers and members) and use those categories to combine certain logic (e.g. required to sign up for at least one of the child groups).

I think the whole system shoould allow some sort of recursive groups / categories to keep everything as general as possible.

We can then use those categories to acomplish something like you explained. You create acategory 'kapoenen', but somehow mangage to set a setting in here to 'stage' registrations before assigning them to a child or subchild.

[WardToulet]

We could maybe approach it like a Unix file system layout with a single root. So we have the root and then collections or groups. This gives several advantages

Inherit properties

Groups and folders inherit properties from their parents this will allow for a price to be set on a the group kap in this example but also allow other properties to be set lower down in sub folders.

UPPERCASE: group
lowercase: folder

root:
- kap:
  - KAP1
  - KAP2
- JW
- W
- SW

Here all the kap groups (KAP1 and KAP2) have the same pricing and age requirements.

root:
- members
 - KAP
 - JW
- volunteers
  - MATERIALS
  - CATERING

In this example you can set pricing for members and volunteers and age groups for the different member groups.

This system would allow for close modeling of the existing structure of an organization.

Registration

New user

In this case the user can only enroll in top level groups.

Old user

Here there are two kinds of user users who in the new year are still withing the requirements for the group there already in and those who are not.

Still eligible

These user can just renew there membership.

Not eligible anymore

These users would need to reapply to a top level group for which they are eligible.

Pure groups

It could also be useful to have groups who defer there power to enroll members to their children in the second example this could be done by the members folder so new members could enroll in the KAP or JW group directly.

Policies

The users who are no longer eligible could be automatically suggested to reply for a different group.

[SimonBackx]

So, I thought about this issue a bit more. I'll need to restructure the groups a bit for activity registrations. Meanwhile I also want to make it possible to register in multiple groups and make the system a bit more flexible. So technically, there won't be any difference anymore between a normal 'member group' and an activity, course or workshop. A group is something a member can sign up for, that can have a price, that can end at a given date etc.

The problem with having users sign up for a folder, instead of a group is that it creates a lot of complexity. Not only in code (folders would need a different ID, with different relations...), but also for setup. You'll need to write a huge text (that no one will read) in order to explain the behaviour to administrators.

Folders would simply be a way to structure the groups and allow some inherited properties (e.g. pricing, questions asked) but can get overwritten by individual groups. You can create a group "Activities", "Weekends", "Age groups" etc. Members should register directly in a specific group.

A more straightforward way to solve your problem would be with tags. You can simply assign tags to users, and filter on those members. Maybe you will also be able to assign permissions based on tags. When a member extends a membership, those tags will stay on the member. And in order to remove the tag 'KAP1' when the member is of age, it might be a solution to assign tags to groups and/or categories. That also solves the issues with different pricing in subgroups and you can extend it freely. This will probably solve a lot of different use cases.

[SimonBackx]

You can now create multiple groups and move members between the groups, while some groups are private. So this behaviour is implemented