...
I had some further thoughts, especially did I design the permission system more in detail as that was what failed the previous core development effort by Derk.
...
Bodies
Permissions are granted to members via circles. Permissions are attached to circles and members can be in a circle. Also, permissions are inherited downwards along the circle inheritance tree, e.g. all child circles will grant the same permissions as the parent circle, if not more. Permissions also have a scope, which can be either global or local (maybe even body-types in the future?). Global means the member has this permission, generally, globally. Local means the member only has this permission in the body where he got it from. E.g. if a member is in two bodies but in one of them he is member of a bound circle that grants him a permission, this permission will be valid for all requests concerning just that second body. Also there are always-on permissions that get assigned to every member automatically without body membership. This is to enable future tweaks to the system where things that are right now publicly available to everyone can be restricted dynamically. Also permissions can hold filters which, on supporting requests, will filter parts of the data away. For filtering nested data, you can use a notation like members.name.Bodies are legislative parts of the association and can be joined through join-requests.
Circles
Circles are basically a group of members. Circles grant attached and inherited permissions to a user. There can be bound and free circles, depending whether they are part of a body or not. It is not possible to change a bound circle into a free one and vice versa. Also a body can define a shadow circle which will be automatically joined upon joining the body. A bound circle can only be joined by members of the body.
Circles that are joinable can freely be joined, as long as the body-membership constraint on bound circles is fulfilled. Non-joinable circles can only obtain members by someone adding them forcefully (still respecting the body-membership constraint). If a circle is non-joinable, also all of its children need to be non-joinable. A joinable parent can however have both types of children.
Permission system
The permission system is described more in detail here
User-Member duality
Because I moved out login and signout based concerns into a seperate microservice, the login microservice, there is a one-to-one relation between the table users and the table members, whereas a user does not necessarily need to have a member. This has mainly technical reasons because I am crazy for splitting everything and also because I developped loginservice before oms-core-elixir to also be used standalone. This has the disadvantage of sync need between oms-core-elixir and loginservice on member creation and deletion
Further Permission system improvements
...
Recruitment campaigns
Member accounts can be created in two ways, either by manually adding them as member of a body or by them signing up through a recruitment campaign. A recruitment campaign can, if set, autoactivate the user account or leave that to an admin. Also it can automatically create a join request to a fixed body. This way, admins of the body could activate the account after approving the join request.